先假設(shè)有以下幾個變量：
1，DB_A：提供服務(wù)的database，也就是master
2，DB_B：它是DB_A的一個slave
3，DB_C：安全起見，異地的一個備份中心，跨局域網(wǎng)（不是一個機房的）
方案也不是很復(fù)雜，基本上是通過一些shell腳本實現(xiàn)的，沒有用第三方的工具，這里的備份都是做的邏輯備份，沒有做物理備份，數(shù)據(jù)量前期不大，不打算物理備份。
切入主題，首先做A與B的一個master->slave的單向同步，由于A和B是在同一個局域網(wǎng)，所以速度應(yīng)該很快，沒有問題。接下來，我就有一個疑惑了，就是本地備份在哪臺機器上做，是A還是B，如果在A上做，那么肯定會影響服務(wù)的性能，如果在B上做，那么B萬一和A不小心失去連接了怎么辦，盡管你會說這是維護的問題，但從直覺上講，我更相信A上的數(shù)據(jù)，把你的想法告訴我，謝謝。假定是在A上做邏輯備份，24小時做一個全備份，3小時做一次增量備份，注意在做備份的時候，可以把備份日志發(fā)送到維護人員的郵箱，這樣就省去了登陸服務(wù)器看日志了。在本地做好備份后，還要把備份數(shù)據(jù)用ssh發(fā)到C,（這么看來，還是B來做這些比較妥當(dāng)）。這里又多出一個問題，由于用腳本維護，必會讓A無須密碼驗證就可以ssh C了，是否存在安全隱患呢？
恢復(fù)數(shù)據(jù)的工作，做起來量要比備份少很多，但是要求精度要高更多。這里要提醒下各位官人就是要定期的檢查自己的備份方案，測試自己的備份數(shù)據(jù)是否生效。否則災(zāi)難發(fā)生的時候，只能看著腳本發(fā)呆，一切都是個悲劇。恢復(fù)的流程為：先恢復(fù)全備份數(shù)據(jù)，然后針對logbin做基于時間點，或是基于位置的恢復(fù)。梗概也就如是，歡迎大家交流！
方案修訂后記：
A對B&C做實時集群同步，不用B再向C做同步了。B所作的事情，C一樣都可以做，包括全備份和增量備份。
http://hi.baidu.com/litaosmile/blog/item/280823135f250e29dc540151.html這篇文章詳細說明了同步的原理，mysql的同步是異步的，所以不管如何同步，都不會影響Master的性能，感謝文刀兄的特別提醒！