Copyright (c) 2006-2014 MindTouch Inc.
This file and accompanying files are licensed under the MindTouch Master Subscription Agreement (MSA).
At any time, you shall not, directly or indirectly: (i) sublicense, resell, rent, lease, distribute, market, commercialize or otherwise transfer rights or usage to: (a) the Software, (b) any modified version or derivative work of the Software created by you or for you, or (c) MindTouch Open Source (which includes all non-supported versions of MindTouch-developed software), for any purpose including timesharing or service bureau purposes; (ii) remove or alter any copyright, trademark or proprietary notice in the Software; (iii) transfer, use or export the Software in violation of any applicable laws or regulations of any government or governmental agency; (iv) use or run on any of your hardware, or have deployed for use, any production version of MindTouch Open Source; (v) use any of the Support Services, Error corrections, Updates or Upgrades, for the MindTouch Open Source software or for any Server for which Support Services are not then purchased as provided hereunder; or (vi) reverse engineer, decompile or modify any encrypted or encoded portion of the Software.
A complete copy of the MSA is available at http://www.mindtouch.com/msa
Is it possible to set up autofailover for MySQL databases? What is involved in setting it up?
RightScale does not recommend or provide autofailover for MySQL databases for a number of reasons. Let's begin by looking at some of the possible causes of database failure:
Of course, there could also be a problem with the monitoring system that could have caused it to not receive data (for example, collectd dies or the monitoring server or monitoring daemons are not running or running slow).
With so many possible causes of database failure it is difficult to pinpoint a cure that will solve all of them. For example if mysqld dies because the server ran out of hard drive space then a new slave will get promoted to master with the same issue. So a chain of slaves will get promoted one after the other. If collectd dies, it may fix the problem for that server but if it's a problem with the monitoring servers themselves or a configuration issue then again, a chain of slaves will be promoted. In no case can autofailover fix the problem with a bad query. The same query will be in the application and the new master will again be brought down when the query is executed again. Remember, if data is corrupted on the master, it will propagate to the slave and will still be there in the new master. Given all of these possible causes for database failure, autofailover is not rendering a cure (at best) and could possibly make things worse.
Now it comes down to detecting a few specific cases where one could use autofailure such as item 5 - a problem with the cloud causing an unresponsive server. The real question is how to distinguish this from any of the other issues. And what if you are getting a false positive where the server is running fine, but there is a communication problem between the server and the monitoring system? Now you are blindly promoting slaves one after the other on a false positive when in fact there is nothing wrong with the database.
So even if you were able to predict all of the possible outcomes and the cases where autofailover would work and a new slave is launched correctly, it still does not resolve the underlying problem if there is a false positive by the monitoring server. And even if you had a perfect monitoring server that never failed and could predict all possible outcomes, it could still not tell you if your slave is worth promoting. What if your only good database is your master and your slave is not replicating or is corrupted? In this case, you would blindly promote the slave and possibly lose your good master database that has your good, uncorrupted data.
In summary, there are too many variables in implementing autofailover to recommend it as a solution to the age old problem of the database going down at 3am. And even if you did autofailover, you could not trust that it fixed the problem so the DBA would still have to get up and look into the situation to be sure things were working. It is far more prudent to look at the causes and facts before blindly promoting a slave.
|Glossary | 用語 | 용어||Site Map | Site Help||Community||Corporate Site||Get Support||Dashboard Login|
|Doc Feedback||Product Feedback||Resources||MultiCloud Marketplace||Forums|
© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.