UPDATED 2008-07-09 08:53 AEST: resolved (for me!) so sharing for others.
More: As I suspect Brian will tell me that archive_reader is only available in source, I decided to try his 5.0 alternative of flush tables. I did only:
flush tables <tn1>,<tn2>,...
not with read lock because each table is one week's archive, and is not in use after that week is over. I avoided flushing the current week's table. I think the size increased by 10 bytes after the flush.
Then I FTP'ed the .ARZ and .frm for each table to another 5.1 MySQL server, and found that show table status indicated that the copies were all recognised and had the same statistics as the originals. Great! The tables were nearly all ~2.5Gb-3Gb.
As a test, I did "select sum(bytecount) from <tablename>;" on one transferred table, which would have read every row, and got an identical answer (2,648,694,433,614bytes!) on both the original and the copy. I'm convinced!
I will now ensure my data collection program flushes the just-finished last week's table! After that, the cron job to FTP the files should be OK.
BY THE WAY, I read about .ARM meta data files, but have not seen any alongside the .ARZ and .frm files. Have they been discontinued at 5.1 or is it perhaps that my tables do not need a .ARM file?
===================
ORIGINAL NOTE
Thanks Brian. Happily I am using 5.1 Sadly, I cannot find the archive_reader program you mention, at least not in a binary form. I did find archive_reader.c on the web, but I think it is way past my skill level to convert that to binary.
Are you able to point me at a binary download? I am using community edition 5.1.22 "for" RHEL5 though actually on CentOS5.1 x86_64
Edited 1 time(s). Last edit at 07/08/2008 05:46PM by Nick Sharp.