不停庫不鎖表在線主從配置mysql
1，Mysqldump對於10G如下的數據庫或表，比較適用又快捷。當數據量達到100-500G的時候，mysql就力不從心了。ios
2，Percona-xtrabackup能夠實現mysql在線熱備工做。可進行全量，增量，單表備份和還原。sql
3，2.2版本的xtrabackup能對innoDB和XtraDB存儲引擎的數據庫非阻塞的備份，對myISAM的備份經過加表讀鎖的方式實現，2.3版本xtrabackup命令直接支持myISAM引擎。數據庫
Xtrabakup 優點：1，無需中止數據庫進行InnoDB熱備安全
2，增量備份MySQL服務器
3， 熱壓縮到傳輸到其餘服務器app
4， 能比較容易的建立主從同步異步
5， 備份MySQL時不會增大服務器負載。性能
4，主從複製是爲了實現讀寫分離，減輕主庫負載，還能夠數據備份，保證數據恢復，還能夠主從切換高可用。ui
5，複製類型
· 基於語句的複製：STATEMENT 在主服務器執行的SQL語句，在從上執行一樣的語句，有可能因爲執行上下文環境不一樣而致使數據不一致。（mysql在5.7.7之前默認採用STATEENT,在5.7.7及之後版本，默認改用row-based
· 基於行的複製：row ，把改變的內容複製過去，不是把命令在從上執行一遍。從mysql5.0開始支持，可以嚴格保證數據完整一致。（注：遷移時，從庫改正了字段默認值定義，但數據在主庫更改後，即便產生的新數據默認值正確。但基於行的複製依然用不正確的值字段所有更新）
· 混合類型的複製：MIXED ，默認採用基於語句的複製，一旦發現基於語句的沒法精確複製時，就會採用基於行的複製。
- 1 mysql 系統庫mysql庫裏面的表的日誌記錄格式，在經過如INSERT,UPDATE、DELETE、TRUNCATE等方式直接修改數據的語句，使用binlog_format指定的方式記錄，但使用GRANT、ALTER、CREATE、RENAME等改動的mysql庫裏數據的，會強制使用statement-based方式記錄binlog。
在線修改二進制日誌，須要SUPER權限（如SET SESSION binlog_format=MIXED）
6.2 複製類型分爲異步複製和半同步複製。
異步複製：一般沒後，說明指的都是異步。在主庫執行完Commit後，在主庫寫入binlog日誌後便可成功返回客戶端，不等binlog日誌傳送給從庫，一旦主庫宕機，可能會丟失日誌。
半同步複製；是等其中一個從庫也接收到binlog事物併成功寫入relay log以後，才返回commit操做成功給客戶端。這樣保證事務成功提交後至少有兩份日誌，一份在主庫binlog上，另外一份在從庫relay log上。進一步保證數據完整性。
原理
(1) master將改變記錄到二進制日誌(binary log)中（這些記錄叫作二進制日誌事件，binary log events）；
(2) slave將master的binary log events拷貝到它的中繼日誌(relay log)；
(3) slave重作中繼日誌中的事件，將改變反映它本身的數據。
7，配置主從
1，準備工做；主從版本一致—>主庫受權複製賬號—>確保開啓binlog及主從server_id惟一—>xtrabackup恢復到從庫—>記錄xtrabackup_binlog_info中binlog名稱及偏移量—>從庫change master to —>slave start—>檢查兩個yes
,2， 主庫上建立複製帳號
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_ali'@'192.168.5.%' IDENTIFIED BY 'slave_ali_pass';
mysql> FLUSH PRIVILEGES;
3，使用percona-Xtrabackup恢復數據。
假設，全量備份，全量恢復，不涉及增量。
mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 'bkppass';
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT,PROCESS,SUPER ON *.* TO 'bkpuser'@'localhost';
mysql> FLUSH PRIVILEGES;
假設 MySQL 安裝目錄在/opt/mysql，my.cnf配置文件/opt/mysql/my.cnf，端口3306，數據目錄/opt/mysql_data，sock位於/opt/mysql_data/mysql.sock。備份數據放在/data/backup/mysql/。
3.1全量備份（默認會以當天 日期+時間 戳命名備份目錄，如 2015-09-16_00-00-02)
$ export BKP_PASS="bkppass"
$ innobackupex --defaults-file=/opt/mysql/my.cnf --host=localhost --port=3306 --user=bkpuser --password=${BKP_PASS} /data/backup/mysql
3.2 全量恢復(在恢復的數據庫服務器（從庫）上)
恢復準備
$ innobackupex --use-memory=16G --apply-log 2015-09-16_00-00-02
確認數據庫是關閉的，而且datadir，目錄下爲空
$ innobackupex --defaults-file=/opt/mysql/my.cnf --use-memory=16G --copy-back 2015-09-16_00-00-02
第一步是恢復準備，apply-log應用全備時 log sequence number 以後的數據，完了後會輸出相似 InnoDB: Last MySQL binlog file position 0 262484673, file name ./mysql-bin.000135 的信息，告訴咱們了後面的從庫應該從哪一個地方開始複製。時間不會很長，但最好用screen之類的軟件放到後臺執行，以避免終端斷開，功虧一簣。
第二步使用新的my.cnf文件，將完整的mysql數據文件拷貝到datadir下。
- 作從庫
上面恢復過程最後一步apply-log完成以後，會獲得一個lsn position 和binlog文件名：26248467三、mysql-bin.000135。下面開始從庫製做。
通常在copy-back以後須要修改數據文件目錄的屬性：
# chown -R mysql.mysql /opt/mysql_data
4.1 my.cnf
從庫的配置文件簡單一點能夠從主庫拷貝過來。根據須要要注意如下幾處。
1，server-id必定不能與主庫相同，不然，會出現以下錯誤：Slave: received end packet FROM server, apparent master shutdown
2，從庫通常做爲只讀庫使用，因此爲安全起見，設置只讀 set global read_only=1;能夠在從服務器的 my.cnf 里加入read-only參數來實現這一點，惟一須要注意的一點事read-only僅對沒有super權限的用戶有效。因此最好覈對一下鏈接從服務器的用戶，確保其沒有super權限。
3，關於從庫的事件
MYSQL Replication 能夠很好的達到你的預期：從庫的事件不會本身去執行，主庫會把event執行的結果直接同步。在statement模式下，複製的是 event BODY 裏的SQL，在row模式下是主庫事件執行完成後影響的行精確複製。
4，從庫 event_scheduler 參數是被忽略的，而且每一個event 狀態會是 SLAVESIDE_DISABLED ，但CREATE/ALTER EVENT等操做語句是會複製。主從切換後，從庫事件狀態會變成ENABLE。
5，參數調整
從庫是不容許寫入的，不然數據就不一致了。從庫實例的配置能夠不要主庫那麼高，好比原16G的buffer pool，根據用途，從庫能夠設到4-8G（當時前提是未來你也不打算把它切換爲主庫用）。相應的，read_buffer_size，sort_buffer_size, query_cache_size 這些讀相關參數能夠略微增大。
6，skip-slave-start
主從建立完成後，默認狀況下次啓動從庫，會自動啓動複製進程，通常這也正是咱們須要的，但在維護階段時你可能不想從庫啓動後當即開始複製，--skip-slave-start選項能夠幫到你。
7，log-slave-updates
正常狀況從庫是不須要寫回放日誌產生的binlog，無形中增長服務器壓力。但若是你想要實現級聯複製即 A -> B -> C ，B同時是A的從庫，也是C的主庫，就須要開啓 log-bin 和 log-slave-updates 。
另外，建議顯示設置 log-bin=mysql-bin 確保主從正常切換。 show variables like 'log%' 查看當前值。
8，關於過濾表見mysql-replica-filter
9，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.
上面的話同時也意味着性能最低。能夠在這埋點，假如出現慢的狀況，把兩參數調成2。
4.2 啓動從庫
# /opt/mysql/bin/mysqld_safe --defaults-file=/opt/mysql/my.cnf &
提示：若是你不肯定這個庫是誰的從庫，保守起見加上--skip-slave-start啓動，興許能防止數據不一致。
4.3 change master（從庫上）
$ mysql -uslave_ali -p'slave_ali_pass' -S /opt/mysql_data/mysql.sock
mysql> change master to master_host=MASTER_HOST, master_port=3306,
master_user='slave_ali',master_password='slave_ali_pass',
master_log_file='mysql-bin.000135', master_log_pos=262484673;
mysql> show slave status\G
mysql> start slave;
mysql> show slave status\G
4.4 驗證同步延遲
從庫執行 show slave status\G
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線程當前正在讀取的主服務器二進制日誌文件的名稱
Read_Master_Log_Pos：本機I/O線程讀取主服務器二進制日誌位置
上面2各值，與在主庫執行show master status;看到的值若是基本接近，說明從庫IO線程已經遇上了主庫的binlog。
Relay_Master_Log_File: 由SQL線程執行的包含多數近期事件的主服務器二進制日誌文件的名稱
Exec_Master_Log_Pos: SQL線程執行來自master的二進制日誌最後一個事件位置
與上面的Relay_Master_Log_File一塊兒，同Master_Log_File、Read_Master_Log_Pos比較，能看到SQL線程是否已經遇上從庫本地的IO線程。
Slave_IO_Running：I/O線程是否啓動併成功鏈接到主服務器上
通常和下面的Slave_IO_Running和Seconds_Behind_Master一塊兒監控主從健康狀態
Slave_SQL_Running：SQL線程是否啓動
Seconds_Behind_Master: 從屬服務器「落後」多少秒
Mysql主從不一樣步解決方法
主從同步配置好後，運行一段時間，出現了不一樣步現象，
能夠用命令檢查，
msyq > show slave status \G;
Last_Errno: 1062
Last_Error: Error 'Duplicate entry '149' for key 'PRIMARY'' on query. Default database: 'zabbix'. Query: 'insert into escalations (escalationid,actionid,status,triggerid,itemid,eventid,r_eventid) values (149,7,0,16272,null,3334811,null)'
看報錯，應該是主MYSQL上建表時，主鍵有重複的值報錯，形成從不能同步。
解決的辦法是在從庫上執行:
mysql> slave stop;
mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
mysql> slave start;
上面的方法能夠解決問題，還有一種解決問題的辦法是經過修改mysql的配置文件，讓從庫的同步線程忽略這個錯誤，
修改mysql配置文件 /etc/my.cnf 在 [mysqld]下加一行slave_skip_errors = 1062 ,保存重啓mysql
mysql slave能夠正常同步了.
MYSQL主從同步故障一例及解決過程！
nagios 報警，mysql_AB error，檢查從庫
show slave status \G; 果真
Slave_IO_Running: Yes
Slave_SQL_Running: No
並且出現了1062錯誤，還提示
Last_SQL_Error: Error 'Duplicate entry '1001-164761-0' for key 'PRIMARY'' on query. Default database: 'bug'. Query: 'insert into misdata (uid,mid,pid,state,mtime) values (164761,1001,0,-1,1262623560)'
tail -f mysql_error.log 查看錯誤日誌
[ERROR] Slave SQL: Error 'Duplicate entry '1007-443786-0' for key 'PRIMARY'' on query. Default database: 'ufo'. Query: 'insert into misdata (uid,mid,pid,sta
te,mtime) values (443786,1007,0,-1,1262598003)', Error_code: 1062
100104 17:39:05 [Warning] Slave: Duplicate entry '1007-443786-0' for key 'PRIMARY' Error_code: 1062
100104 17:39:05 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'ufolog.000058
8' position 55793296
解決思路：先中止同步，鎖表，在從上從新配置
先手動同步一下，從庫上首先 stop slave;中止同步
進入主庫鎖表，FLUSH TABLES WITH READ LOCK；
mysql> show master status;
進入從庫，從新配置
mysql>change master to master_host='192.168.1.141', master_user='slave',
master_password='xxx',
master_port=3306,
master_log_file='ufo.000063',
master_log_pos=159164526;
完成後start slave;
回到主庫
unlock tables; 解鎖
回到從庫 查看
show slave status \G
解決未果，嘗試跳過錯誤的方法。
stop slave;
set global sql_slave_skip_counter=1; （1是指跳過一個錯誤）
slave start;
再show slave status \G;查看
結果仍是報錯，由原來的164761變成其餘數字。
/etc/my.cnf 修改從庫的配置文件，在[mysqld]加入一行。
slave-skip-errors = 1062
mysql /etc/init.d/mysqld restart 重啓下從庫的
show slave status \G; 查看正常，這是數據可能已經不一樣步了。
tail -f mysql_error.log 再次查看錯誤日誌
100106 16:54:21 [Warning] Statement may not be safe to log in statement format. Statement: delete from `system_message_1` where `to_uid` = 181464 ORDER BY `id` ASC LIMIT 1 （大概意思是statement格式不安全）
statement format 應該是 binlog的一種格式，進入從庫查看一下
show global variables like 'binlog_format';
果真當前的格式爲statement
我須要把格式改成 mixed格式
修改從庫的 my.cfg
在[mysqld]下面加入下面這行
binlog_format=mixed