Up to the day before my short vacation, I wasn’t been able to install v0.8 since the RPMs weren’t yet posted.

As posted by Sheeri, the permissions concerns come from the fact that the ‘innobackupex’ script kept failing with a ‘Permission denied’ message. I didn’t think there was a need for the ‘w’ permission meant that something was being written to ‘ibbdata1′, but *nix security is there for a reason, and I didn’t see why then we needed to relax it w/o understanding what was going on. Apparently this has been fixed from what I understand from the comment thread.

As you know Pythian work is done on customer’s time most of time, so we try the solutions that best work under the circumstances. With that criteria in mind, I usually avoid going into the source code of any tool unless there is a really compelling reason to do it. That’s why I didn’t go ahead and fixed the compilation issues for 4.1 and rather wait for Percona to do it.

I hope this helps to clarify Sheeri’s original blog.

I’m not sure what you mean by “…I have not disputed that the “write” is actually just opened with read/write permissions.” Are you contradicting your earlier statement that “YES the ibdata file IS written to”? Or is “write” being defined in some non-standard way?

I’m a little curious, given that you were rather acerbic with the comment that:
“So perhaps if you took the time to read BOTH the edit in the middle of the page, made 5 hours before your comment, as well as the rest of the comments, you’d understand that:

YES the ibdata file IS written to”

Which is wildly incorrect – I apologize for being so persistent in stating so. Something like “I can’t use xtrabackup as a non-mysql, non-root user”, seems much more fitting without more interesting evidence to the contrary.

So, I suppose all I would ask is that the terminology be a bit more accurate so that we would not have necessarily talk past each other.

Again, Thank you for the otherwise productive discussion. Warm Regards.

Before Vadim clarified what the writes actually were, it did indeed *look* like an external process (xtrabackup) was writing to the files. Thus, the concern.

I had not had time to read the patches, and I have not disputed that the “write” is actually just opened with read/write permissions.

As for portraying the issue actually, as soon as I got the facts I updated the blog post. What more would you like me to do?

I was not disputing the fact that you can’t run xtrabackup without write access to the ibdata file. This in itself is a (somewhat minor) problem, but nowhere near as scary as an external process directly writing to my ibdata files (which again, is NOT happening).

I was pointing out that the original, source ibdata file that my production MySQL server is running with is NOT written to, despite what you keep saying. But it is opened with read/write permissions. No actual “write” is taken out in the xtrabackup trunk, the ibdata files themselves will just be opened in read-only mode – read the patches, they’re very simple.

I don’t mean to split hairs here, but I think its important to portray the underlying issue accurately. Again, the ibdata files are NOT written to by xtrabackup today.

My coworker, Gerry, commented that it was writing to ibdata files. He has the exact information, but he’s currently on vacation.

I hardly think that calling attention to a fact is “alarmist”. After the previous post saying that Xtrabackup was good and there was no real reason not to use it, I received feedback from others, which I then shared.

At any rate, Vadim explained the reason, and even fixed it. So perhaps if you took the time to read BOTH the edit in the middle of the page, made 5 hours before your comment, as well as the rest of the comments, you’d understand that:

YES the ibdata file IS written to

BUT that’s an artifact of using InnoDB as the starting code for Xtrabackup

AND the write has been taken out of the Xtrabackup trunk, so hopefully it won’t exist in the next version.

# md5sum ibdata1
891d6ec8b4885df30c6dabcec86d1dfc ibdata1
# xtrabackup –backup –target-dir=/mnt/mysql/backups/
xtrabackup Ver rc-0.7 for 5.0.77 unknown-linux-gnu (x86_64)
…
Copying ./ibdata1
to /mnt/mysql/backups//ibdata1
…
>> log scanned up to (0 2793120394)
…done
xtrabackup: The latest check point (for incremental): ‘0:2793120394′
>> log scanned up to (0 2793120394)
xtrabackup: Stopping log copying thread.
xtrabackup: Transaction log of lsn (0 2793120394) to (0 2793120394) was copied.
# md5sum ibdata1
891d6ec8b4885df30c6dabcec86d1dfc ibdata1

Of course, if you use the innobackupex wrapper, it will create a marker innodb table, as previously noted. This is going through the running MySQL instance – not xtrabackup – and will change the ibdata file.

I think clarity on exactly what tools like these do is critical, but claims about “direct writes to the data dictionary by the process” are a bit alarmist when there’s no evidence of that provided.

Any time the ibdata file is written to, there is a chance of corruption. I have clarified to note that the only writes come from the fact that this is a restricted instance of InnoDB, so there is nothing different about the write than just plain running InnoDB.

However, before you explained that, all we knew was that the file was being written to, which *is* scary and vague.

As for the confusion issue — anyone running Xtrabackup *already knows* that they cannot run it with a user that does not have write privileges to the ibdata file. And if they do not realize that, they should.

InnoDB by default requires O_RDWR option on ibdata1 files at start, and xtrabackup therefore also did that. In the latest push to trunk it was fixed, now xtrabackup opens file with O_RDONLY flag.

I would ask to refute message that xtrabackup may cause corruption on working database as it is misleading and already confused a lot of users.