I know how you feel! I think your two best options are these:
1.) Use LVM snapshots per the MPB links you mentioned as a guide. Your
incremental backup would be the binary logs that MySQL writes. You could
copy any of this data off site by mounting the snapshots and using your
remote copy mechan
We have a very large, multi-terabyte database with individual tables that
are over 100Gig. We have it on a Red Hat Linux system and we set up logical
volumes, take LVM snapshots, then use rsync to move the data over. This
works well and is a lot faster than dumping and certainly restore is
faster
Something totally ghetto that might work...
If you could convert the files to appear to be text with some kind of
reversible fast translation, rsync might be able to handle the diff part.
You'd sure want to test this out thoroughly...
--
MySQL General Mailing List
For list archives: htt
I would also suggest to use the innodb storage option
'innodb-file-per-table=ON'
so that at least the datafile is split to have as many (smaller)
datafiles as innodb tables.
This could make it easier to deal with the whole database.
Cheers
Claudio
Baron Schwartz wrote:
On Fri, Jan 23, 2009 at
On Fri, Jan 23, 2009 at 4:18 PM, Daevid Vincent wrote:
> We have some INNODB tables that are over 500,000,000 rows. These
> obviously make for some mighty big file sizes:
>
> -rw-rw 1 mysql mysql 73,872,179,200 2009-01-22 02:31 ibdata1
Daevid, we have started working on an incremental/differe
We have some INNODB tables that are over 500,000,000 rows. These
obviously make for some mighty big file sizes:
-rw-rw 1 mysql mysql 73,872,179,200 2009-01-22 02:31 ibdata1
This can take a good amount of time to copy even just the file, and a
mysqldump can take hours to export and import took