Am 26.07.2011 19:13, schrieb Todd Lyons:
> On Tue, Jul 26, 2011 at 8:18 AM, Reindl Harald <h.rei...@thelounge.net> wrote:
>>> 1.  I did a full copy of the running master database server using
>>> xtrabackup to a backup server via nfs.  It took 2 hours, of which the
>>> last 15 minutes did a write lock of the entire server as it copied
>>> over the *.frm files and the few myisam tables.  This was the most
>>> troublesome part as it was visible to both users and website owners
>> why are not using two rsync-runs?
>> the first while mysqld is running
>> the second directly after stop mysqld
>>
>> this way you can be 100% sure that you can start the replication
>> from scratch and your downtime is only a few seconds, best if
> 
> 43 GB is more than a few seconds.

well, but it is faster in summary and without any pitfalls

>> enough space to have this target on the master-machine because
>> while you take the slow way over the network the master is running
>> with a fresh binlog
> 
> I tested a slightly modified version of your quickie script, first
> using the nfs share:
> Starting first rsync
> real  37m48.201s
> Stopping MySQL:                                            [  OK  ]
> Starting second rsync
> real  4m24.536s
> Starting MySQL:                                            [  OK  ]

this is a good value for remote

> Then I ran it using local spindles:
> Starting first rsync
> real  26m10.747s
> Stopping MySQL:                                            [  OK  ]
> Starting second rsync
> real  3m11.945s
> Starting MySQL:                                            [  OK  ]

weel, 3 minutes is a acceptable downtime with the benefit
that the slave will be binary-identical and all old logs
are gone away

> So I could have lowerd the amount of time mysql was not available by
> quite a bit doing it that way.  Plus I would have removed the
> requirement to apply-logs (due to not copying innodb files while they
> were open).  In the end, xtrabackup worked as designed, but the fact
> that my large number of databases and tables and innodb_file_per_table
> slows things down tremendously, so it isn't the best fit in this case

with smaller databases it is the same, our main webserver has
only 800 MB database files and here we are speaking really
about few seconds for the second rsync and the only thing to do
is re-init the replication after that - i find really no case where
the rsync will not win at the end :-)

i am doing this since years for all sort of backups (as example
stopping the slave shortly and make a consistent off-site-backup)
because i do not trust any tool which makes a hot-backup and trying
a sync with binary logs

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to