MySQL Replication常用SQL、應用、文件、流程、模式 無聊時寫的，算科普吧，畢竟內置的Replication是MySQL的驕傲 ㈠ SQL語句篇 管理主庫部分 show master logs 列出主庫二進制日志 show master status 列出當前主庫二進制日志狀態 show slave hosts 列出連接到主庫的備庫信息 show binlog events in 'log_name' 列出二進制日志中的事件 reset master 置空二進制日志索引文件，並創建一個新的二進制日志 purge master logs to 'log_name' purge master logs before 'date' 刪除主庫的二進制日志 建議刪除流程： ① 目標日志確認如下： 在主庫：show master logs 在備庫：show slave status[每個備庫都執行，抓取延遲最大的備庫] ② 備份 ③ purge 管理備庫部分 change master to master_** 告訴備庫如何連接到主庫並重放其二進制日志 參數較多較雜，請自行參閱手冊 reset slave 刪除master.info、relay-log.info以及所有中繼日志，並新建一個中繼日志 show slave status 查看當前備庫狀態 輸出較多，下面撿幾個重要的談談 Slave_IO_State、Slave_IO_Running、Slave_SQL_Running：表示IO線程和SQL線程健康狀況 Master_Log_File：IO線程當前正在讀取的主庫的二進制日志的名稱 Read_Master_Log_Pos：當前主庫的二進制日志中，IO線程已經讀取的位置 Relay_Log_File：SQL線程當前正在讀取和執行的中繼日志的名稱 Relay_Log_Pos：當前中繼日志中，SQL線程已經讀取和執行的位置 Exec_Master_Log_Pos：同步到備庫的二進制日志的位置 能借助該輸出來計算復制延遲： Read_Master_Log_Pos-Exec_Master_Log_Pos：表示SQL線程延遲，進而表示了主備是否同步 順道提一點，二進制日志坐標：Position，減去Read_Master_Log_Pos：表示IO線程延遲 start slave 啟動備庫SQL線程/IO線程 stop slave 停止備庫SQL線程/IO線程 ㈡ 應用篇 數據分布 →給地理上互相隔離的IDC分發數據 熱備份 →復制是備份的技術補充，但不能代替備份 讀擴展 →負載均衡 報表分析 →在不影響主庫業務的情況下，月底的審計和報表分析可放到備庫上做 升級測試 →用最新版本的mysql做備庫 故障轉移 →提升備庫為主庫，最小化宕機時間 ㈢ 文件篇 master.info 記錄備庫連接主庫所需要的信息，如：主機、用戶名、密碼、當前二進制日志坐標等 同時，他也能告訴主庫："我需要某個日志的某個位置之後的內容，請發給我" relay-log.info 記錄當前備庫正在復制的二進制日志和中繼日志的坐標 binlog index 記錄主庫磁盤上二進制日志文件 relay log 存儲IO線程從主庫復制的二進制日志事件 relay log index 作用同binlog index ㈣ 流程篇 ⑴ 主庫記錄二進制日志：按事務提交的順序記錄事件 ⑵ 備庫將主庫的二進制日志復制到本地中繼日志 啟動IO線程 發起TCP/IP連接 在主庫啟動binlog dump線程 讀取主庫二進制日志 IO線程記錄到relay log和master.info ⑶ 備庫讀取並重放二進制日志事件 ㈤ 模式篇 復制模式可分：STATEMENT和ROW，通過binlog_format控制 沒有哪種模式能勝任任何場景，謂之：存在即是合理 MySQL能在這兩種模式動態卻換(binlog_format='MIXED') 缺省以STATEMENT運行，當無法正確復制時則以ROW運行 下面列出他們各自的優缺點 ROW模式 優點 幾乎沒有基於行的復制無法處理的場景 更少的鎖競爭，因為對強串行化的需求降低 更低的CPU花費，因為沒有必要在構造SQL上下文信息 更好的保證了復制到備庫的數據的品質 更快的定位和解決數據不一致，如當找不到修改的行時，ROW模式會使整個復制過程停止而STATEMENT不會 缺點 無法確定執行了什麼SQL 黑盒子，很難定位出故障的地方 占用更多的磁盤空間 更多的網絡帶寬開銷 STATEMENT模式 優點 基於行的復制整個過程基本上就是執行SQL 這很容易定位問題 缺點 無法正確復制，特別是當涉及到存儲過程、觸發器、函數等 這會失去復制的意義
