總體來說注意以下幾點
slave上查詢盡量用到索引
master my.cnf 配置優化
比主從更可靠的是drbd+keepalive,hearbeat好像更專業點
slave同步過濾 過濾user表，看效果
#replicate-wild-ignore-table =performance_schema.%
gtid
[MySQL 5.6] GTID内部實作、運維變化及存在的bug
http://mysqllover.com/?p=594
gtid-mode用來設定是否開啟GTID功能，如果要開啟GTID功能，需要同時開啟log-bin和log_slave_updates功能，另外還需要開啟enforce_gtid_consistency功能。gtid_mode參數可以設定為on、off、upgrade_step_1、upgrade_step_2四種值，其中upgrade_step_1和upgrade_step_2是給将來mysql可能的新功能預留的，對目前的myql沒有任何意義。同時，mysql建議在mysql_upgrade的時候，關閉gtid_mode功能和enforce_gtid_consistency功能，因為Mysql在upgrade期間可能會操作非事務的MyISAM存儲引擎表，會引起報錯
SHOW CREATE TABLE mysql.gtid_executed\G
select @@global.gtid_executed\G
将GTID值持久化儲存在一張InnoDB表中，并與使用者事務一起進行送出，進而實作資料的一緻性
START TRANSACTION;
# user statement
......
INSERT INTO mysql.gtid_executed VALUES (...)
END;
需要注意的是表mysql.gtid_executed是在主伺服器和從伺服器上有進行更新的，而表slave_relay_log_info僅在從伺服器上更新
MySQL 5.7對于表mysql.gtid_executed的更新政策也有些不同，如果沒有主伺服器沒有開啟log_bin或者從伺服器沒有開啟log_slave_updates，其會每一個事物更新表gtid_executed，這樣伺服器重新開機後可以快速知道目前伺服器執行到的GTID位置。是以，使用者可能在伺服器上看到類似如下的内容
select * from mysql.gtid_executed;
select thread_id,thread_os_id,name,processlist_command,processlist_state from threads where name like '%compress%'\G
因為主從現在在用，是以關注一下
工作原理
MySQL一主多從搭建方式
master my.cnf
# my.cnf檔案中沒有涉及Replicaion機制的配置資訊，就不在這裡列出了
# 開啟日志
log_bin
# 以下這些參數會在後文進行說明 (紅色參數要特别注意)
sync_binlog=1
binlog_format=mixed
binlog-do-db=qiang
binlog_checksum=CRC32
binlog_cache_size=2M
max_binlog_cache_size=1G
max_binlog_size=100M
# 必須為這個MySQL服務節點設定一個叢集中唯一的 server id資訊
server_id=140
# 隻用MySQL用戶端，都可以進行設定：
# 這裡我們直接使用root賬号進行同步，但是生産環境下不建議這樣使用
> grant replication slave on *.* to [email protected] identified by '123456'
# 通過以下指令，可以檢視設定完成後的Master節點工作狀态
> show master status;
+----------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
| kp2-bin.000002 | 404 | qiang | | |
slave my.cnf
log-bin
sync_relay_log=1
# 必須為這個MySQL服務節點設定一個叢集中唯一的server id資訊
server_id=142
# 請注意這裡設定的使用者名和密碼資訊要和Master上的設定一緻
# 另外master log file所指定的檔案名也必須和Master上使用的日志檔案名一緻
> change master to master_host='192.168.61.140',master_user='root',master_password='123456', master_log_file='kp2-bin.000002',master_log_pos=120;
# 啟動Savle同步
> start slave;
# 然後我們就可以使用以下指令檢視salve節點的同步狀态
> show slave status;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.61.140
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: kp2-bin.000002
Read_Master_Log_Pos: 404
Relay_Log_File: vm2-relay-bin.000002
Relay_Log_Pos: 565
Relay_Master_Log_File: kp2-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
......
Master_Server_Id: 140
Master_UUID: 19632f72-9a90-11e6-82bd-000c290973df
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
......
Auto_Position: 0
一主多從方案的使用建議
一主多從的MySQL叢集方式主要針對讀密集型業務系統，其主要目标是将MySQL服務的讀寫壓力進行分離。
使用固态硬碟作為MySQL服務的塊存儲基礎，并使用RAID 10磁盤陣列作為硬體層建構方案——這是生産環境下單個MySQL服務節點的基本組成邏輯
應使用一個獨立的Salve節點作為備用的Master節點，雖然這種方式不可作為異地多活方案的基礎但可作為本地高可用方案的實作基礎。當然，為了防止由于日志錯誤導緻的備份失敗，這個備份的Salve節點也可以采用MySQL Replicaion機制以外的第三方同步機制，例如：Rsync、DRBD。Rsync是筆者在工作實踐中經常使用的，進行MySQL資料增量同步的方式，而DRBD的差異塊同步方式是網際網路上能夠找到最多資料的方式：
在後續的文章中，我們還會專門讨論針對Master節點的叢集調整方案，并且建議讀者如何使用适合系統自身業務的高可用方案。例如使用Keepalived / Heartbeat進行主備Master節點的切換
複雜的統計查詢需要專門的Salve節點進行支援。參與生産環境實時業務處理的任何MySQL服務節點，在這些服務節點上所運作的SQL查詢應該盡可能簡單，并且需要使用索引對檢索進行支援。特别是資料量非常大的資料表，必須保證所有的檢索操作都有索引提供支援，否則Table Full Scan的檢索過濾方式不但會拖慢檢索操作本身，還可能會明顯拖慢其它的事務操作。通過MySQL提供的執行計劃功能，技術人員能夠很友善實作以上的要求。如果您的業務系統存在複雜的業務查詢要求，例如周期性的财務流水報表，周期性的業務分組統計報表等，那麼您最好專門準備一個（或多個）脫離實時業務的Salve節點，完成這個工作
需要業務系統開發人員投入的維護精力就會呈幾何級增長。
高可用層面的問題：在MySQL一主多從叢集中，雖然存在多個Salve節點（read業務性質節點），但是一般隻存在一個Master節點（write業務性質節點）。某一個（或多個）Salve節點崩潰了，不會對整個叢集造成太大影響（但可能影響上層業務系統的某一個子系統）
本文轉自 liqius 51CTO部落格，原文連結：http://blog.51cto.com/szgb17/1870724，如需轉載請自行聯系原作者