Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 13/06/13 10:37, Dan Barker wrote: > ProActive Software > > rsync will not be able to synchronize from a “failed” disk, drbd > already has done so. > > > > Dan in Atlanta > > > > *From:*drbd-user-bounces at lists.linbit.com > [mailto:drbd-user-bounces at lists.linbit.com] *On Behalf Of *Robinson, Eric > *Sent:* Wednesday, June 12, 2013 6:20 PM > *To:* Dirk Bonenkamp - ProActive > *Cc:* drbd-user at lists.linbit.com > *Subject:* Re: [DRBD-user] drbd+mysql+innodb > > > > Hi Dirk – Thanks for the feedback. I do need some clarification, > though. DRBD replicates disk block changes to a standby volume. If the > primary node suddenly fails, the cluster manager promotes the standby > node to primary and starts the MySQL service. Logically, this seems > exactly the same as simply rsyncing the data to the new server and > starting the MySQL service. Why would it work with DRBD but not with > rsync? Thanks for your patience while I explore this. > > > > Note: we have over 500 separate MySQL database instances using MyISAM. > I am totally not stoked about the idea of using 300% more disk space > and gobs more memory. > > I think the real issue with rsync is that it will start copying the file, but new writes may come in during the copy process, therefore the destination copy is not a point in time copy of the source. This is the same issue with using rsync for disk images of VM's that are running during the rsync. As explained, this is not an issue for DRBD replication, because at any instant in time, the replica (destination copy) is an exact copy of the source at some point in time, even if it is not the latest point in time. Regards, Adam -- Adam Goryachev Website Managers www.websitemanagers.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20130613/5a3666ef/attachment.htm>