1，我現在的備份方案為：
A(master)----->B(slave)進行實時同步，在B(slave)上每周日凌晨3點做一次全備份，周一至周六做
增量備份，增量備份的時刻選擇，根據業務需求靈活修改。當DB出現故障時，或是服務器業務邏輯出現
重大bug，玩家投訴較為嚴重時，這時我們需要對數據進行恢復。
2，我現在的恢復方案為：
首先停掉所有服務器，在B(slave)上首先進行一次全備份恢復:
mysql -uroot -p**** < allbackup.sql
然後選擇時間點進行增量恢復:
mysqlbinlog --start-date="2011-06-15 14:00:00" --stop-date="2011-06-15 17:30:00" mysql-bin.[0-9]* |mysql -uroot -p****
這樣所有的數據庫，所有的表單都恢復到了正常狀態。
3，這樣做的問題是：
相當麻煩，很痛苦。如果只是db_account中的一個表單 tb_account出現了問題，其他的數據庫均正常。那麼這樣做就太折騰了，
因為全備份對所有的數據庫都生效，這樣的恢復當然也是對所有的數據庫生效。那麼恢復之後，要在B(slave)上找到想要的恢復後的數據，
導入到A(master)中，而其他的數據都不能保持不動。痛苦！！！
4，改進後的方案為：
對每個數據庫進行全備份，不用原來的對所有的數據庫備份的做法（即下面的做法）：
mysqldump -h $HOST -u $USER -p$PASSWORD --opt --all-databases --flush-logs > $BAKDIR/$DATESTR.sql
這樣的話，每個數據庫的備份數據都會相應的生成在一個sql文件中，也就是說原來的備份目錄下的sql文件由一個增加到了N個，這樣就
可以去恢復具體的數據庫了，哪個數據庫出問題就去恢復哪個數據庫，哪裡不會點哪裡，媽媽再也不用擔心我的學習了。
省去了很多麻煩。即你可以這樣寫：
mysqldump -h $HOST -u $USER -p$PASSWORD --flush-logs db_account > account.sql
mysqldump -h $HOST -u $USER -p$PASSWORD --flush-logs db_test1 > test1.sql
mysqldump -h $HOST -u $USER -p$PASSWORD --flush-logs db_test2 > test2.sql
mysqldump -h $HOST -u $USER -p$PASSWORD --flush-logs db_test3 > test3.sql
那麼增量備份怎麼辦？
如果基於時間點的增量恢復db_account，該怎麼辦？有辦法
mysqlbinlog --start-date="2011-06-15 14:00:00" --stop-date="2011-06-15 17:30:00" -d db_account mysql-bin.[0-9]*
可以用-d指定數據庫進行增量恢復，這樣就可以對指定的數據庫進行全備份恢復和增量備份恢復了，一切是多麼的和諧。
5，一點點的小擔心：
就是在對具體的一個數據庫db_account進行全備份，flush-logs的時候，會刪除db_account的增量數據。那麼有沒有以下的可能：
5.1，兩個數據庫中的增量數據在一個mysql-bin文件中
5.2，一個數據庫的增量數據在兩個mysql-bin文件中
如果有以上的可能，那麼在flush-logs的時候會不會出現什麼隱患或是問題呢？如db_account在flush-logs的時候刪除了
一個文件，但這個文件中還有其他數據庫的增量數據。或是說flush-logs不是基於文件刪除，而是基於數據刪除，在所有的
文件中找到db_account的增量數據，然後做刪除，當發現一個文件沒有數據的時候，再刪除該文件。大家都知道的，
mysql-bin的文件是相當多的，如果不做刪除清理的話，總有一天硬盤會爆炸的。
