首先參考兩篇文章：
1，
http://www.21andy.com/blog/20090610/1323.html2，
http://blog.51yip.com/mysql/1042.html這兩篇文章主要是針對增量備份與恢復做了詳細的探討，沒有時間，沒有興趣的同學就別點進去了。
1，我現(xiàn)在的備份方案為：
A(master)----->B(slave)進行實時同步，在B(slave)上每周日凌晨3點做一次全備份，周一至周六做
增量備份，增量備份的時刻選擇，根據(jù)業(yè)務需求靈活修改。當DB出現(xiàn)故障時，或是服務器業(yè)務邏輯出現(xiàn)
重大bug，玩家投訴較為嚴重時，這時我們需要對數(shù)據(jù)進行恢復。
2，我現(xiàn)在的恢復方案為：
首先停掉所有服務器，在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****
這樣所有的數(shù)據(jù)庫，所有的表單都恢復到了正常狀態(tài)。
3，這樣做的問題是：
相當麻煩，很痛苦。如果只是db_account中的一個表單 tb_account出現(xiàn)了問題，其他的數(shù)據(jù)庫均正常。那么這樣做就太折騰了，
因為全備份對所有的數(shù)據(jù)庫都生效，這樣的恢復當然也是對所有的數(shù)據(jù)庫生效。那么恢復之后，要在B(slave)上找到想要的恢復后的數(shù)據(jù)，
導入到A(master)中，而其他的數(shù)據(jù)都不能保持不動。痛苦！！！
4，改進后的方案為：
對每個數(shù)據(jù)庫進行全備份，不用原來的對所有的數(shù)據(jù)庫備份的做法（即下面的做法）：
mysqldump -h $HOST -u $USER -p$PASSWORD --opt --all-databases --flush-logs > $BAKDIR/$DATESTR.sql
這樣的話，每個數(shù)據(jù)庫的備份數(shù)據(jù)都會相應的生成在一個sql文件中，也就是說原來的備份目錄下的sql文件由一個增加到了N個，這樣就
可以去恢復具體的數(shù)據(jù)庫了，哪個數(shù)據(jù)庫出問題就去恢復哪個數(shù)據(jù)庫，哪里不會點哪里，媽媽再也不用擔心我的學習了。
省去了很多麻煩。即你可以這樣寫：
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指定數(shù)據(jù)庫進行增量恢復，這樣就可以對指定的數(shù)據(jù)庫進行全備份恢復和增量備份恢復了，一切是多么的和諧。
5，一點點的小擔心：
就是在對具體的一個數(shù)據(jù)庫db_account進行全備份，flush-logs的時候，會刪除db_account的增量數(shù)據(jù)。那么有沒有以下的可能：
5.1，兩個數(shù)據(jù)庫中的增量數(shù)據(jù)在一個mysql-bin文件中
5.2，一個數(shù)據(jù)庫的增量數(shù)據(jù)在兩個mysql-bin文件中
如果有以上的可能，那么在flush-logs的時候會不會出現(xiàn)什么隱患或是問題呢？如db_account在flush-logs的時候刪除了
一個文件，但這個文件中還有其他數(shù)據(jù)庫的增量數(shù)據(jù)。或是說flush-logs不是基于文件刪除，而是基于數(shù)據(jù)刪除，在所有的
文件中找到db_account的增量數(shù)據(jù)，然后做刪除，當發(fā)現(xiàn)一個文件沒有數(shù)據(jù)的時候，再刪除該文件。大家都知道的，
mysql-bin的文件是相當多的，如果不做刪除清理的話，總有一天硬盤會爆炸的。
===============================華麗的分割線==========================
2012.11.15補增：
1，上面的方案基本上是沒什么問題的，擔心的情況也是基本不成立的，可能是原來對mysql的增量不理解造成的。
2，mysql的--flush-log會觸發(fā)增量事件：即本次較上次flush之后的增量，（而且每次flush之后會把新的增量生成在新的二進制文件中，即使沒有增量也會生成新的二進制文件）
并不會刪除文件，如果需要刪除多余的增量備份文件，需要手動delete。
3，大概的原理是：新一天在全備份之前flush一次log，生成的log是前一天的增量，備份完成后，把前一天的所有增量文件刪除，并備份到遠程服務器。
之后每次增量備份通過flush-log生成即可，并不需要刪除舊的log，該天的log由全備份時統(tǒng)一刪除管理。
4，每個增量備份文件內部，不會按照數(shù)據(jù)庫或其他的方式歸類管理，在flush的時候，會根據(jù)index一次性生成，所以在恢復的時候，要在當天的所有增量文件
中做選擇。
5，假設0點做全備份，每3小時做一次增量備份，那么在5點的時候做恢復，只能恢復到3點，4點和5點的時候數(shù)據(jù)將丟失。
==============================第二次割=============================
2013.1.9補增;
1，感謝王亮同學終于把增量備份的bug解決了，這次對日志備份的理解更深刻一層。
2，mysql在flush之后新生成的bin是空的，下次新增的數(shù)據(jù)，將寫在該bin中，所以本次無需拷貝該文件。
3，為什么我們的腳本拷貝該文件了呢？因為咱們的shell腳本寫錯了，對空格的理解不深刻啊！！寒
4，要保證logbinback中的Bin和/var/log/mysql中的bin保持一致，至少logbinback中的日期要比var中多0天或1天。
如果主數(shù)據(jù)庫的bin保留10天，那么備份數(shù)據(jù)庫中的bin保留20天即可，沒有必要全部保留。