mysql主從同步 binlog-do-db replicate-do-db

在主服務器上爲從服務器創建一個用戶：

grant replication slave on *.* to '用戶名'@'主機' identified by '密碼';

若是使用的是MySQL 4.0.2以前的版本，則用file權限來代替replication slave

編輯主服務器的配置文件：/etc/my.cnf

server-id=1
log-bin
binlog-do-db=須要複製的數據庫名，若是複製多個數據庫，重複設置這個選項便可
binlog-ignore-db=不須要複製的數據庫苦命，若是複製多個數據庫，重複設置這個選項便可

注意：若是你想作一個複雜點的結構：好比說，A->B->C，其中B是A的從服務器，同時B又是C的主服務器，那麼B服務器除了須要打開log-bin以外，還須要打開log-slave-updates選項，你能夠再B上使用「show variables like 'log%';」來確認是否已經生效。

編輯從服務器的配置文件：/etc/my.cnf

server-id=2
master-host=主機
master-user=用戶名
master-password=密碼
master-port=端口
replicate-do-db=須要複製的數據庫名，若是複製多個數據庫，重複設置這個選項便可
replicate-ignore-db=須要複製的數據庫名，若是複製多個數據庫，重複設置這個選項便可

配置主從服務器的my.cnf時，留心各自的server-id必定要彼此獨立，不能重複，不然，會出現以下錯誤：

Slave: received end packet FROM server, apparent master shutdown

另外一個須要注意的是最好在從服務器的my.cnf裏設置read_only選項，防止發生意外（鏈接用戶不能有SUPER權限，不然無效）。

記得先手動同步一下主從服務器，數據量小的話能夠用mysqldump，它有一個master-data參數頗有用，經過使用此參數，導出的SQL文件裏會自動包含CHANGE MASTER TO MASTER_LOG_FILE='...', MASTER_LOG_POS=...;，這樣建立從服務器就更方便了。

若是數據量大的話不太適合使用mysqldump（慢），若是是myisam表的話，加上--lock-all-tables參數，若是是innodb表的話，加上--single-transaction參數。

而應該採用拷貝文件的方式，請按以下操做步驟：

先在主服務器上鎖定全部的表，以避免在複製過程當中數據發生變化：

mysql> flush tables with read lock;

而後在主服務器上查詢當前二進制文件的文件名及偏移位置：

mysql > show master status;

而後中止主服務器上的MySQL服務：

shell> mysqladmin -u root shutdown

注意：若是僅是MyISAM的話，能夠不中止MySQL服務，但要在複製數據文件的過程當中保持只讀鎖，若是是InnoDB的話，必須中止MySQL服務。

再拷貝數據文件：

shell> tar -cvf /tmp/mysql-snapshot.tar .

拷貝完別忘了啓動主服務上的MySQL服務了。

而後把數據文件應用到從服務器上，再次啓動slave的時候使用，記得啓動時加上skip-slave-start選項，使之不會馬上去鏈接master，再在從服務器上設置相關的二進制日誌信息：

mysql> CHANGE MASTER TO
->     MASTER_HOST='master_host_name',
->     MASTER_USER='replication_user_name',
->     MASTER_PASSWORD='replication_password',
->     MASTER_LOG_FILE='recorded_log_file_name',
->     MASTER_LOG_POS=recorded_log_position;

啓動從服務器上的複製線程：

mysql> start slave;

驗證主從設置是否已經成功，能夠輸入以下命令：

mysql> show slave status\G

會獲得相似下面的列表：

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

若是這兩個選項不全是Yes，那就說明你前面某個步驟配置錯了。

應該保證從服務器上任何數據的修改都是經過從主服務器上覆制操做獲取的，換句話說，從服務器應該是隻讀的，若是不能保證這一點，則可能形成主從數據不一致。能夠在從服務器的my.cnf里加入read-only參數來實現這一點，惟一須要注意的一點事read-only僅對沒有super權限的用戶有效。因此最好覈對一下鏈接從服務器的用戶，確保其沒有super權限。

從理想角度看，主從數據庫應該無端障的運轉下去，能夠有時候仍是會出現一些莫名其妙的問題，好比說即使從未在從服務器上手動更新過數據，但仍是可能遇到「Error: 1062 Duplicate entry」錯誤，具體緣由不詳，多是MySQL自己的問題。遇到這類問題的時候，從服務器會中止複製操做，咱們只能手動解決問題，具體的操做步驟以下：

mysql> set global sql_slave_skip_counter = 1;
mysql> start slave;

一樣的操做可能須要進行屢次，也能夠設置自動處理此類操做，在從服務器的my.cnf裏設置：

slave-skip-errors=1062

最後再嘮叨一下日誌的問題：時間長了，數據庫服務器上的二進制文件會愈來愈多，清理是必要的，你能夠設置自動清理，相關參數是expire_logs_days，也可使用手動刪除的方式，但這裏說的手動不是指rm，而是指PURGE BINARY LOGS，刪除任何日誌前，最好在全部的從服務器上經過show slave status命令確認一下相關日誌是否已經無用。

更詳細的介紹參考官方文檔：How to Set Up Replication，不喜歡英文的話能夠看老葉同志的中文翻譯。

補充：[ERROR] Error in Log_event::read_log_event(): 'Event too big'

在使用主從複製的時候，出現的問題多半是和日誌（主服務器的二進制日誌，從服務器的延遲日誌）相關的。好比說加入你遇到了上面的錯誤，你能夠根據錯誤日誌的信息在主從數據庫服務器上分別執行：

mysqlbinlog 日誌文件 > /dev/null

查看錯誤，若是沒有錯誤，則不會有任何輸出，反之會輸出錯誤信息，若是肯定了錯誤是出如今主服務器二進制日誌上，能夠跳過適當的位置，再在從服務器上從新設定LOG_POS，若是肯定了錯誤是出如今從服務器延遲日誌上，則能夠刪除從服務器的延遲日誌（使用CHANGE TO MASTER的時候，除非設定了延遲日誌信息，不然會自動刪除延遲日誌），並在從服務器上從新設定LOG_POS。期間也能夠考慮手動執行不能自動執行的SQL日誌。

補充：配置的時候若是版本容許最好打開sync_binlog選項。

補充：有時候，從服務器延遲日誌可能已經損壞，這時須要執行CHANGE MASTER TO設置新的日誌文件信息，可是在從服務器上SHOW SLAVE STATUS會顯示不少日誌信息，他們的含義有所不一樣：

Master_Log_File:Read_Master_Log_Pos 是IO相關的日誌信息
Relay_Master_Log_File:Exec_Master_Log_Pos 是SQL相關的日誌信息

從服務器須要設置的是SQL相關的日誌信息：

slave stop;
change master to master_log_file=’(binlog name in relay_master_log_file)’, master_log_pos=(exec_master_log_pos number);
slave start;

1) When you are using the master as a consistent snapshot, use SHOW MASTER STATUS to determine the position.
2) When you are using a slave as a consistent snapshot, use SHOW SLAVE STATUS and Exec_Master_Log_Pos.

參考連接

補充：缺省狀況下，從服務器會以主機名命名延遲日誌，因此一旦你修改了從服務器的主機名就會形成問題，新版MySQL會提示你這個狀況：

[Warning] Neither --relay-log nor --relay-log-index were used;
so replication may break when this MySQL server acts as a slave and has his hostname changed!!
Please use '--relay-log=name-relay-bin' to avoid this problem.