On 22/06/2011 15:21, Matthias Urlichs wrote:
>> 1. flush logs on the master (only if it's accessible, of course).
> Not really necessary if you block clients (firewall rule for new
> connections to port 3306?).
thank you for replying!
Isn't the flush logs command necessary in order to flush
any remaining buffered content and make it available to
the dump reading replication thread, even when there are
no client connections?
> Anyway, why don't you use a dual-master setup?
Yes, this could be an option.
We have two application environments:
production and spare, the app data is synchronized with rsync and
we use replication for the databases. If the application is started on
the wrong node by mistake, with multi-master replication active,
the production database could be "logically corrupted".
> I find that this is a whole lot easier to administer than a master/
> fallback-slave situation. In particular, restoring the master after it
> comes back happens automatically, or (if you need to re-install the master
> from scratch) the command
> slave# mysqldump --single-transaction --master-data=1 --all-databases \
> | ssh master mysql
> ensures that you can continue to use the slave while restoring the master.
> Assuming you use only transaction-safe tables, of course.
> (You should.)
Unfortunately we have both MyISAM and InnoDB tables,
I don't have control over this choice.