前段時間使用MySQL作為數據存儲做了一個小項目。項目上線運行了幾十天之后，數據已經越來越多，達到了100多M。用mysqldump每天備份全量數據然后傳輸到另外一台機器上這種方式進行數據備份，久而久之越來越慢。於是開始研究如何利用mysql的主從同步功能實現自動備份。如果實現自動備份，主從服務器之間只需要在有數據更新時同步一點增量數據，不會在備份時占用大量的CPU和內網的網絡帶寬資源了。介紹主從同步之前，還是先從基礎的mysqldump備份開始講起。
mysqldump
mysqldump是mysql數據庫提供的一個數據備份工具。顧名思義，mysqldump可以把mysql數據庫導出成sql語句文件，並保存到磁盤上。mysqldump命令產生的.sql文件包含一系列SQL INSERT語句，可以用來進行數據恢復。
假定我們在星期日下午1點進行了備份，此時負荷較低。下面的命令可以完全備份所有數據庫中的所有表：
shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
各種用法說明
A. 最簡單的用法：
mysqldump -uroot -pPassword [database name] > [dump file]
上述命令將指定數據庫備份到某dump文件（轉儲文件）中，比如：
mysqldump -uroot -p123 test > test.dump
生成的test.dump文件中包含建表語句（生成數據庫結構哦）和插入數據的insert語句。
B. --opt
如果加上--opt參數則生成的dump文件中稍有不同：
. 建表語句包含drop table if exists tableName
. insert之前包含一個鎖表語句lock tables tableName write，insert之后包含unlock tables
C. 跨主機備份
使用下面的命令可以將host1上的sourceDb復制到host2的targetDb，前提是host2主機上已經創建targetDb數據庫：
mysqldump --host=host1 --opt sourceDb| mysql --host=host2 -C targetDb
其中：-C指示主機間的數據傳輸使用數據壓縮
D. 只備份表結構
mysqldump --no-data --databases mydatabase1 mydatabase2 mydatabase3 > test.dump
將只備份表結構。--databases指示主機上要備份的數據庫。如果要備份某個MySQL主機上的所有數據庫可以使用--all-databases選項，如下：
> test.dump
E. 從備份文件恢復數據庫
使用mysqldump進行數據備份，至少有兩個問題：
（1）mysqldump運行時，需要消耗一定的計算資源。而且數據庫越大，消耗的計算資源也就越多，因此可能會造成系統在備份時運行效率低，容易造成用戶卡死。
（2）對mysqldump備份的數據進行恢復，會丟掉從備份點開始的更新數據。
為了解決第2點的問題， mysql文檔中給出了一個解決辦法。那就是利用mysqlbinlog二進制文件保存增量的數據。采用全量mysqldump+增量mysqlbinlog的方式進行數據恢復。
mysqlbinlog
mysqlbinlog就是mysql的二進制數據文件。在對mysql進行一些配置之后，mysql會把數據庫的更新操作都記錄在一個文件中。mysqlbinlog可以在mysqld的--bin-log選項或者在配置文件(my.cnf或者my.ini)中打開。
[mysqld]
log-bin=mysql-bin //[必須]啟用二進制日志
在啟用了二進制日志以后，在mysql的數據目錄下，會出現一些以數字為結尾的文件，例如：
-rw-rw---- 1 guilhem guilhem 1277324 Nov 10 23:59 mysql-bin.000001
-rw-rw---- 1 guilhem guilhem 4 Nov 10 23:59 mysql-bin.000002
這些文件就是二進制的日志文件。每次mysql啟動都會增加一個文件。
下面回到上節提出的問題，如何采用全量mysqldump+增量mysqlbinlog的方式進行數據恢復？
mysqldump全量備份+mysqlbinlog二進制日志增量備份
從mysqldump備份文件恢復數據會丟失掉從備份點開始的更新數據，所以還需要結合mysqlbinlog二進制日志增量備份。確保my.ini或者my.cnf中包含下面的配置以啟用二進制日志，或者mysqld ---log-bin：
[mysqld]
log-bin=mysql-bin
在每次使用mysqldump進行全量數據備份時，用--flush-logs選項：
mysqldump --single-transaction --flush-logs --master-data=2 > backup.sql
在使用這樣的語句進行備份之后，mysql就會關閉原來的二進制日志文件，開啟一個新的二進制日志文件。比如，新開啟的二進制日志文件為 mysql-bin.000003。 那么在進行數據恢復的時候，你可以利用backup.sql進行全量恢復+ mysql-bin.000003進行增量同步。
數據恢復的方法也很簡單。
shell> mysql -uroot -pPwd < backup_sunday_1_PM.sql shell> mysqlbinlog mysql-bin.000003 | mysql -uroot -pPwd
或者：
cat backup.sql | mysql -uroot -ppassword mysqlbinlog mysql-bin.000003 | mysql -uroot -ppassword
此外mysqlbinlog還可以指定--start-date、--stop-date、--start-position和--stop-position參數，用於精確恢復數據到某個時刻之前或者跳過中間某個出問題時間段恢復數據，直接摘錄MySQL文檔說明中相關內容如下：
5.9.3.1. 指定恢復時間
對於MySQL 4.1.4，可以在mysqlbinlog語句中通過--start-date和--stop-date選項指定DATETIME格式的起止時間。舉例說明，假設在今天上午10:00(今天是2005年4月20日)，執行SQL語句來刪除一個大表。要想恢復表和數據，你可以恢復前晚上的備份，並輸入：
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/bin.123456 \
| mysql -u root -pmypwd
該命令將恢復截止到在--stop-date選項中以DATETIME格式給出的日期和時間的所有數據。如果你沒有檢測到幾個小時后輸入的錯誤的SQL語句，可能你想要恢復后面發生的活動。根據這些，你可以用起使日期和時間再次運行mysqlbinlog：
mysqlbinlog --start-date="2005-04-20 10:01:00" /var/log/mysql/bin.123456 \
| mysql -u root -pmypwd \
在該行中，從上午10:01登錄的SQL語句將運行。組合執行前夜的轉儲文件和mysqlbinlog的兩行可以將所有數據恢復到上午10:00前一秒鍾。你應檢查日志以確保時間確切。下一節介紹如何實現。
5.9.3.2. 指定恢復位置
也可以不指定日期和時間，而使用mysqlbinlog的選項--start-position和--stop-position來指定日志位置。它們的作用與起止日選項相同，不同的是給出了從日志起的位置號。使用日志位置是更准確的恢復方法，特別是當由於破壞性SQL語句同時發生許多事務的時候。要想確定位置號，可以運行mysqlbinlog尋找執行了不期望的事務的時間范圍，但應將結果重新指向文本文件以便進行檢查。操作方法為：
mysqlbinlog --start-date="2005-04-20 9:55:00" --stop-date="2005-04-20 10:05:00" \
/var/log/mysql/bin.123456 > /tmp/mysql_restore.sql
該命令將在/tmp目錄創建小的文本文件，將顯示執行了錯誤的SQL語句時的SQL語句。你可以用文本編輯器打開該文件，尋找你不要想重復的語句。如果二進制日志中的位置號用於停止和繼續恢復操作，應進行注釋。用log_pos加一個數字來標記位置。使用位置號恢復了以前的備份文件后，你應從命令行輸入下面內容：
mysqlbinlog --stop-position="368312" /var/log/mysql/bin.123456 \
| mysql -u root -pmypwd
mysqlbinlog --start-position="368315" /var/log/mysql/bin.123456 \
| mysql -u root -pmypwd \
上面的第1行將恢復到停止位置為止的所有事務。下一行將恢復從給定的起始位置直到二進制日志結束的所有事務。因為mysqlbinlog的輸出包括每個SQL語句記錄之前的SET TIMESTAMP語句，恢復的數據和相關MySQL日志將反應事務執行的原時間。
mysqlbinlog是一個讀取 mysql二進制日志輸出sql語句的命令行工具。使用方法可以從http://doc.mysql.cn/mysql5/refman-5.1-zh.html-chapter/client-side-scripts.html#mysqlbinlog 查到。
還記得上文提出的mysqldump備份的兩個問題嗎，現在第二個問題解決了，第一個問題還沒有解決
“ mysqldump運行時，需要消耗一定的計算資源。而且數據庫越大，消耗的計算資源也就越多，因此可能會造成系統在備份時運行效率低，容易造成用戶卡死。”
下文中我們利用mysql主從同步來解決這個問題。
主從同步
主從同步的含義非常簡單。通過一定的設置，讓兩台或者多台mysql服務器的數據保持一致。設置的方法網上已經有很多方法了，推薦這篇帖子http://369369.blog.51cto.com/319630/790921
設置成主從同步之后，基本上就免去了每天全量備份之苦。而且一但主數據庫出問題，可以馬上切換到從數據庫進行服務，大大減少了故障恢復的時間。
我講一講我在配置中遇到的2個問題：
1 在從服務器上 show slave status時，顯示 Slave_SQL_Running: No. 錯誤的原因是 mysql 數據庫的db表已經存在，不能再建立。
錯誤的原因是這樣的， 我在每台數據上都運行了 mysql_install_db這個命令安裝了 mysql test info_schema這3個數據庫。當我主從同步開始時，主數據庫要向從數據庫同步建立mysql數據庫的操作。而從數據庫已經建立了mysql數據庫。
我解決的方法是在配置文件里指明寫二進制文件的數據庫名稱。只有真正需要同步的業務數據庫才寫二進制文件。
主數據庫：
[mysqld]
binlog-do-db=exampledb
從數據庫：
[mysqld]
replicate-do-db=exampledb
2 我的主數據庫已經運行有一段時間了。在從服務器設置master_log_pos的時候設置成主服務器的當前日志位置。結果同步時也出現了Slave_SQL_Running: No. 錯誤的原因是： 執行Insert語句時數據表沒有建立。
錯誤的原因也很簡單，我在從數據庫里面還沒有建立對應的數據庫，而同步的操作為插入數據。
解決的方法是通過mysqldump對主數據庫進行一次全量數據備份，並且在從數據庫中恢復這個備份之后才開始進行主從同步。
參考：
1、 https://www.cnblogs.com/martinjinyu/articles/3750422.html