List:General Discussion« Previous MessageNext Message »
From:Dimitre Radoulov Date:June 22 2011 1:46pm
Subject:Re: MySQL Replication - promote slave
View as plain text  
On 22/06/2011 15:21, Matthias Urlichs wrote:
> Hi,
>> 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?).

Hi Matthias,
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.

Best regards
MySQL Replication - promote slaveDimitre Radoulov21 Jun
  • Re: MySQL Replication - promote slaveMatthias Urlichs22 Jun
Re: MySQL Replication - promote slaveDimitre Radoulov22 Jun