說明1.1 xtrabackupmysqldump對于導(dǎo)出10G以下的數(shù)據(jù)庫或幾個表，還是適用的，而且更快捷。但一旦數(shù)據(jù)量達(dá)到100-500G，無論是對原庫的壓力還是導(dǎo)出的性能，mysqldump就力不從心了。Percona-Xtrabackup備份工具，是實(shí)現(xiàn)MySQL在線熱備工作的不二選擇，可進(jìn)行全量、增量、單表備份和還原。(但當(dāng)數(shù)據(jù)量更大時，可能需要考慮分庫分表，或使用 LVM 快照來加快備份速度了)Xtrabackup有兩個主要的工具：xtrabackup、innobackupex(1)xtrabackup只能備份InnoDB和XtraDB兩種數(shù)據(jù)表，而不能備份MyISAM數(shù)據(jù)表。(2)innobackupex-1.5.1則封裝了xtrabackup，是一個腳本封裝，所以能同時備份處理innodb和myisam，但在處理myisam時需要加一個讀鎖XtraBackup優(yōu)勢 ：

無需停止數(shù)據(jù)庫進(jìn)行InnoDB熱備

增量備份MySQL

流壓縮到傳輸?shù)狡渌?wù)器

能比較容易地創(chuàng)建主從同步

備份MySQL時不會增大服務(wù)器負(fù)載

1.2 復(fù)制為什么要做主從復(fù)制？ 1.為實(shí)現(xiàn)讀寫分離，減輕主庫負(fù)載或數(shù)據(jù)分析。 2.為數(shù)據(jù)安全，做備份恢復(fù)。 3.當(dāng)出現(xiàn)問題時，主從切換，實(shí)現(xiàn)高可用。考慮點(diǎn); 一主一從，一旦做了主從切換，不通過其它HA手段干預(yù)的話，業(yè)務(wù)訪問的還是原IP，而且原主庫很容易就作廢了。 于是 主-主 復(fù)制就產(chǎn)生了，憑借各自不同的 server-id ，可以避免 “A的變化同步到B，B應(yīng)用變化又同步到A” 這樣循環(huán)復(fù)制的問題。但建議是，主主復(fù)制，其中一個主庫強(qiáng)制設(shè)置為只讀，主從切換后架構(gòu)依然是可用的。 復(fù)制過程是slave主動向master拉取，而不是master去推的，所以理想情況下做搭建主從時不需要master做出任何改變甚至停服，slave失敗也不影響主庫。3.原理(1) master將改變記錄到二進(jìn)制日志(binary log)中(這些記錄叫做二進(jìn)制日志事件，binary log events)；(2) slave將master的binary log events拷貝到它的中繼日志(relay log)；(3) slave重做中繼日志中的事件，將改變反映它自己的數(shù)據(jù)。

該過程的第一部分就是master記錄二進(jìn)制日志。在每個事務(wù)更新數(shù)據(jù)完成之前，master在二進(jìn)制日志記錄這些改變。MySQL將事務(wù)串行的寫入二進(jìn)制日志，即使事務(wù)中的語句都是交叉執(zhí)行的。在事件寫入二進(jìn)制日志完成后，master通知存儲引擎提交事務(wù)。

下一步將master的binary log拷貝到它自己的中繼日志。首先，slave開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接，請求從指定日志文件的指定位置之后的日志內(nèi)容，然后開始binlog dump process。Binlog dump process從master的二進(jìn)制日志中讀取事件，如果已經(jīng)跟上master，它會睡眠并等待master產(chǎn)生新的事件。I/O線程將這些事件寫入中繼日志。

SQL slave thread(SQL從線程)處理該過程的最后一步。SQL線程從中繼日志讀取事件，并重放其中的事件而更新slave的數(shù)據(jù)，使其與master中的數(shù)據(jù)一致。只要該線程與I/O線程保持一致，中繼日志通常會位于OS的緩存中，所以中繼日志的開銷很小。

此外，在master中也有一個工作線程：和其它MySQL的連接一樣，slave在master中打開一個連接也會使得master開始一個線程。復(fù)制過程有一個很重要的限制——復(fù)制在slave上是串行化的，也就是說master上的并行更新操作不能在slave上并行操作。

下面開始配置主從：

主從版本一致—>主庫授權(quán)復(fù)制帳號—>確保開啟binlog及主從server_id唯一—>xtrabackup恢復(fù)到從庫—>記錄xtrabackup_binlog_info中binlog名稱及偏移量—>從庫change master to —>slave start—>檢查兩個yes

創(chuàng)建復(fù)制賬號

在主庫上

mysql> GRANT REPLICATION SLAVE ON . TO 'slave_ali'@'192.168.5.%' IDENTIFIED BY 'slave_ali_pass';

mysql> FLUSH PRIVILEGES;3. 使用Percona-Xtrabackup恢復(fù)數(shù)據(jù)

這里假設(shè)比較簡單的情況：全量備份，全量恢復(fù)，不涉及增量。

賦予備份用戶權(quán)限：

mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 'bkppass';

mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT,PROCESS,SUPER ON . TO 'bkpuser'@'localhost';

mysql> FLUSH PRIVILEGES;

假設(shè) MySQL 安裝目錄在/opt/mysql，my.cnf配置文件/opt/mysql/my.cnf，端口3306，數(shù)據(jù)目錄/opt/mysql_data，sock位于/opt/mysql_data/mysql.sock。備份數(shù)據(jù)放在/data/backup/mysql/。

3.1 全量備份

$ export BKP_PASS="bkppass"

$ innobackupex --defaults-file=/opt/mysql/my.cnf --host=localhost --port=3306 --user=bkpuser --password=${BKP_PASS} /data/backup/mysql

默認(rèn)會以當(dāng)天 日期+時間 戳命名備份目錄，如 2015-09-16_00-00-02。一般會對它進(jìn)行tar壓縮，由于tar只能單進(jìn)程，所以往往這個壓縮過程會比備份過程耗時2倍還多。拷貝到需要恢復(fù)(做從庫)的目錄。3.2 全量恢復(fù)

恢復(fù)準(zhǔn)備

$ innobackupex --use-memory=16G --apply-log 2015-09-16_00-00-02

確認(rèn)數(shù)據(jù)庫是關(guān)閉的，并且datadir，目錄下為空

$ innobackupex --defaults-file=/opt/mysql/my.cnf --use-memory=16G --copy-back 2015-09-16_00-00-02

第一步是恢復(fù)準(zhǔn)備，apply-log應(yīng)用全備時 log sequence number 之后的數(shù)據(jù)，完了后會輸出類似 InnoDB: Last MySQL binlog file position 0 262484673, file name ./mysql-bin.000135 的信息，告訴我們了后面的從庫應(yīng)該從哪個地方開始復(fù)制。時間不會很長，但最好用screen之類的軟件放到后臺執(zhí)行，以免終端斷開，功虧一簣。

第二步使用新的my.cnf文件，將完整的mysql數(shù)據(jù)文件拷貝到datadir下。4. 做從庫

一般在copy-back之后需要修改數(shù)據(jù)文件目錄的屬性：

chown -R mysql.mysql /opt/mysql_data4.1 my.cnf

從庫的配置文件簡單一點(diǎn)可以從主庫拷貝過來，但根據(jù)需要，要注意以下幾處

server-id一定不能與主庫相同

否則，會出現(xiàn)如下錯誤：

Slave: received end packet FROM server, apparent master shutdown

從庫一般作為只讀庫使用，所以為安全起見，設(shè)置只讀 set global read_only=1;

可以在從服務(wù)器的 my.cnf 里加入read-only參數(shù)來實(shí)現(xiàn)這一點(diǎn)，唯一需要注意的一點(diǎn)事read-only僅對沒有super權(quán)限的用戶有效。所以最好核對一下連接從服務(wù)器的用戶，確保其沒有super權(quán)限。

關(guān)于從庫的事件

MYSQL Replication 可以很好的達(dá)到你的預(yù)期：從庫的事件不會自己去執(zhí)行，主庫會把event執(zhí)行的結(jié)果直接同步。在statement模式下，復(fù)制的是 event BODY 里的SQL，在row模式下是主庫事件執(zhí)行完成后影響的行精確復(fù)制。

從庫 event_scheduler 參數(shù)是被忽略的，并且每個event 狀態(tài)會是 SLAVESIDE_DISABLED ，但CREATE/ALTER EVENT等操作語句是會復(fù)制。主從切換后，從庫事件狀態(tài)會變成ENABLE。

參數(shù)調(diào)整

從庫是不允許寫入的，否則數(shù)據(jù)就不一致了。從庫實(shí)例的配置可以不要主庫那么高，比如原16G的buffer pool，根據(jù)用途，從庫可以設(shè)到4-8G(當(dāng)時前提是將來你也不打算把它切換為主庫用)。

相應(yīng)的，read_buffer_size，sort_buffer_size, query_cache_size 這些讀相關(guān)參數(shù)可以略微增大

skip-slave-start

主從創(chuàng)建完成后，默認(rèn)情況下次啟動從庫，會自動啟動復(fù)制進(jìn)程，一般這也正是我們需要的，但在維護(hù)階段時你可能不想從庫啟動后立即開始復(fù)制，--skip-slave-start選項(xiàng)可以幫到你

log-slave-updates

正常情況從庫是不需要寫回放日志產(chǎn)生的binlog，無形中增加服務(wù)器壓力。但如果你想要實(shí)現(xiàn)級聯(lián)復(fù)制即 A -> B -> C ，B同時是A的從庫，也是C的主庫，就需要開啟 log-bin 和 log-slave-updates 。

另外，建議顯示設(shè)置 log-bin=mysql-bin 確保主從正常切換。 show variables like 'log%' 查看當(dāng)前值。

關(guān)于過濾表見mysql-replica-filter

sync_binlog

For the greatest possible durability and consistency in a replication setup using InnoDB with transactions, you should use innodb_flush_log_at_trx_commit=1 and sync_binlog=1 in the master my.cnf file.

上面的話同時也意味著性能最低。可以在這埋點(diǎn)，假如出現(xiàn)慢的情況，把兩參數(shù)調(diào)成2

主從參數(shù)注釋：

Slave_IO_State: Waiting for master to send event

Master_Log_File: mysql-bin.000004

Read_Master_Log_Pos: 931

Relay_Log_File: slave1-relay-bin.000056

Relay_Log_Pos: 950

Relay_Master_Log_File: mysql-bin.000004

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Exec_Master_Log_Pos: 931

Relay_Log_Space: 408

Seconds_Behind_Master: 0

*

Master_Log_File： I/O線程當(dāng)前正在讀取的主服務(wù)器二進(jìn)制日志文件的名稱

Read_Master_Log_Pos：本機(jī)I/O線程讀取主服務(wù)器二進(jìn)制日志位置

上面2各值，與在主庫執(zhí)行show master status;看到的值如果基本接近，說明從庫IO線程已經(jīng)趕上了主庫的binlog。

Relay_Master_Log_File: 由SQL線程執(zhí)行的包含多數(shù)近期事件的主服務(wù)器二進(jìn)制日志文件的名稱

Exec_Master_Log_Pos: SQL線程執(zhí)行來自master的二進(jìn)制日志最后一個事件位置

與上面的Relay_Master_Log_File一起，同Master_Log_File、Read_Master_Log_Pos比較，能看到SQL線程是否已經(jīng)趕上從庫本地的IO線程。

Slave_IO_Running：I/O線程是否啟動并成功連接到主服務(wù)器上

一般和下面的Slave_IO_Running和Seconds_Behind_Master一起監(jiān)控主從健康狀態(tài)

Slave_SQL_Running：SQL線程是否啟動

Seconds_Behind_Master: 從屬服務(wù)器“落后”多少秒

官網(wǎng)的解釋是：The number of seconds that the slave SQL thread is behind processing the master binary log。但是當(dāng) SBM 為 0 時也不代表一定沒有延遲，因?yàn)榭赡芤驗(yàn)榫W(wǎng)絡(luò)慢的緣故，從庫的IO線程傳輸binlog太慢，它的SQL線程應(yīng)用日志很容易就趕上relay log，但實(shí)際主庫產(chǎn)生的binlog比傳輸?shù)目?#xff0c;就會造成為0的假象。

有時你反復(fù)status會發(fā)現(xiàn) Seconds_Behind_Master 的值在0與一個很大的數(shù)之間波動，有可能是主庫上執(zhí)行了一個非常大的event，沒執(zhí)行完畢的時候從庫SBM顯示為0，event執(zhí)行完成并傳輸完binlog后，就會顯示SBM非常巨大

另外，relay log 中event記錄的時間戳是主庫上的時間戳，而SQL thread的時間戳是從庫上的，如果主庫和從庫的時間偏差較大，那么這個SBM的意義就基本不存在了。

總結(jié)

以上是生活随笔為你收集整理的mysql xtrabackup 主从_使用 Xtrabackup 在线对MySQL做主从复制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。