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.2013 00:19, Robinson, Eric wrote: > 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. DRBD is synchronous and rsync is not which is why you cannot use rsync to replicate a live database. With DRBD every write request returns only after the data has been written to both the primary and secondary which means both systems always carry the exact same data. When you shut down MySQL and do an rsync the data will only be in sync as long as the db stays offline. The moment you start it again on the primary and updates/inserts come in the data will be out of sync again and you'll have to stop MySQL and resync again. > 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. Diskspace and RAM is cheap these days though and the fact that with innodb you can do live backups without shutting down the database or locking tables for potentially a long time is an important gain if you care about your data. The biggest improvement is of course the row level locking and transaction isolation so a single long running query can no longer lock a whole table for minutes and block everything else coming in. Regards, Dennis