# Waiting for slaves to catch up to old master. # Checking candidate slave prerequisites. # Performing switchover from master at utils1:3307 to slave at utils1:3306. # Discovering slaves for master at utils1:3307 Make sure MySQL Servers are configured correctlyįor some of the utilities, it’s important that you’re using Global Transaction IDs binary logging needs to be enabled may as well use the new crash-safe slave functionality… It’s beyond the scope of this post to go through all of those and so instead I’ll just give example configuration files for the 5 MySQL Servers that will be used: The user then executes a single command to fail over to their preferred slave. In the monitoring mode, the utility still continually checks the availability of the master, and informs the user if it should fail.The user is also able to bind in their own programs to be run before and after the failover (for example, to inform the application). The user can override this behaviour (for example by limiting which of the slaves are eligible for promotion). In the fully automated mode, the utilities will continually monitor the state of the master and in the event of its failure identify the best slave to promote – by default it will select the one that is most up-to-date and then apply any changes that are available on other slaves but not on this one before promoting it to be the new master.The MySQL replication utilities aim to support you whichever camp you belong to: Probably the truth is that it all depends on your specific circumstances. Of course, if the triggering of the failover is to be left to a human then you want that person to have access to the information they need and an extremely simple procedure (ideally a single command) to execute the failover. There are inherent risks to this though – What if the failover implementation has a flaw and fails (after all, we probably don’t test this out in the production system very often)? What if the slave isn’t able to cope with the workload and makes things worse? Is it just a transitory glitch and would the best approach have been just to wait it out?įollowing a recent, high profile outage there has been a great deal of debate on the topic between those that recommend auto-failover and those that believe it should only ever be entrusted to a knowledgeable (of the application and the database architecture) and well informed (of the state of the database nodes, application load etc.) human. For many applications this may be the correct approach. Do you really need/want auto-failover?įor many people, the instinctive reaction is to deploy a fully automated system that detects when the master database fails and then fails over (promotes a slave to be the new master) without human intervention. To get full use of these utilities you should use the InnoDB storage engine together with the Global Transaction ID functionality from the latest MySQL 5.6 DMR.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |