Description:
I use /usr/bin/mysqlhotcopy to do backups of several databases. All of my databases are named with 2 leters (e.g. TZ, SC, DH, etc.). I just noticed today that my backups have not been generated for over a month! I managed to track it down to an assumption that mysqlhotcopy makes:
line 266:
my $raid_dir_regex = '[A-Za-z0-9]{2}';
line 606:
my @non_raid = map { "'$_'" } grep { ! m:/$raid_dir_regex/[^/]+$: } @$files;
If I understand this correctly, mysqlhotcopy assumes that files that have 2 alphanumberic as a component of their path are "raid". And, thus it skips them. It looks like some code that comes after handles @$raid_dirs, but these aren't set for me. I'm not using RAID. So, no files get copied for me.
The file copy step of the mysqlhotcopy script seems to have a few potential ways it can end up copying stuff. But, it my cases, it copies nothing because it thinks all my file are raid, but then has no raid_dirs.
I suspect this change was made between 5.0.21 and 5.0.37. I think it was when I upgraded for 21 to 37 that my backups stopped working. I see the perldoc mentions something about RAID support being worked on (recently?).
How to repeat:
# mysqladmin cr XX
# mysql XX <<!
create table foo (id int);
!
# ls /var/lib/mysql/XX
db.opt foo.frm foo.MYD foo.MYI
# mysqlhotcopy XX
Using copy suffix '_copy'
Locked 1 tables in 0 seconds.
Flushed tables (`XX`.`foo`) in 0 seconds.
Copying 4 files...
Copying indices for 0 files...
Unlocked tables.
mysqlhotcopy copied 1 tables (4 files) in 0 seconds (0 seconds overall).
# ls /var/lib/mysql/XX_copy
# It's empty!
Suggested fix:
I'm unclear on why 2 alphanumerics in the db file pathname indicates RAID, so maybe that assumption is the core problem.
Or, perhaps, conditionally setting @non_raid based on whether @$raid_dirs exists would make sense(?):
my @non_raid;
if (@$raid_dirs) {
@non_raid = map { "'$_'" } grep { ! m:/$raid_dir_regex/[^/]+$: } @$files;
} else {
@non_raid = @$files;
}
Description: I use /usr/bin/mysqlhotcopy to do backups of several databases. All of my databases are named with 2 leters (e.g. TZ, SC, DH, etc.). I just noticed today that my backups have not been generated for over a month! I managed to track it down to an assumption that mysqlhotcopy makes: line 266: my $raid_dir_regex = '[A-Za-z0-9]{2}'; line 606: my @non_raid = map { "'$_'" } grep { ! m:/$raid_dir_regex/[^/]+$: } @$files; If I understand this correctly, mysqlhotcopy assumes that files that have 2 alphanumberic as a component of their path are "raid". And, thus it skips them. It looks like some code that comes after handles @$raid_dirs, but these aren't set for me. I'm not using RAID. So, no files get copied for me. The file copy step of the mysqlhotcopy script seems to have a few potential ways it can end up copying stuff. But, it my cases, it copies nothing because it thinks all my file are raid, but then has no raid_dirs. I suspect this change was made between 5.0.21 and 5.0.37. I think it was when I upgraded for 21 to 37 that my backups stopped working. I see the perldoc mentions something about RAID support being worked on (recently?). How to repeat: # mysqladmin cr XX # mysql XX <<! create table foo (id int); ! # ls /var/lib/mysql/XX db.opt foo.frm foo.MYD foo.MYI # mysqlhotcopy XX Using copy suffix '_copy' Locked 1 tables in 0 seconds. Flushed tables (`XX`.`foo`) in 0 seconds. Copying 4 files... Copying indices for 0 files... Unlocked tables. mysqlhotcopy copied 1 tables (4 files) in 0 seconds (0 seconds overall). # ls /var/lib/mysql/XX_copy # It's empty! Suggested fix: I'm unclear on why 2 alphanumerics in the db file pathname indicates RAID, so maybe that assumption is the core problem. Or, perhaps, conditionally setting @non_raid based on whether @$raid_dirs exists would make sense(?): my @non_raid; if (@$raid_dirs) { @non_raid = map { "'$_'" } grep { ! m:/$raid_dir_regex/[^/]+$: } @$files; } else { @non_raid = @$files; }