複製功用： 數據分佈 負載均衡：讀操作，適用於讀密集型的應用 備份 高可用和故障切換 MySQL升級測試 在從伺服器上有兩個線程： I/O線程：從master請求二進位日誌信息，並保存至中繼日誌 SQL線程：從relay log中讀取日誌信息，在本地完成重放 在主伺服器上為每個從伺服器的I/O線程啟 ...
複製功用：
數據分佈
負載均衡：讀操作，適用於讀密集型的應用
備份
高可用和故障切換
MySQL升級測試
在從伺服器上有兩個線程：
I/O線程：從master請求二進位日誌信息，並保存至中繼日誌
SQL線程：從relay log中讀取日誌信息，在本地完成重放
在主伺服器上為每個從伺服器的I/O線程啟動一個dump線程，向其發送binary log events
過程圖：
補充：對資料庫修改的操作首先得應用到磁碟文件才能被寫入磁碟二進位日誌，因此不可避免從伺服器上的數據是會落後於主伺服器的
隨著網站的發展，當主節點擁有過多從伺服器，會給主節點帶來過大壓力，可以專門使用一臺從伺服器從主節點上複製二進位日志，再使此從節點變為其他從節點的主節點
過程圖：
補充：第一臺從伺服器不需要存儲數據，它只負責傳遞二進位日誌，因此此從伺服器的資料庫引擎使用BLACKHOLE 當重放中繼日誌時，它會把所有的數據都放入/dev/null（這相當於一個宇宙黑洞）
二進位日誌的格式：建議使用mixed模式，如果可以使用row模式
主從配置過程：
主：1.啟用二進位日誌，2.設置一個在當前集群中惟一的server-id(以上兩步在配置文件中修改）:
3.創建一個有複製許可權(REPLICATION SLAVE, REPLICATION CLIENT)賬號：
grant replication slave,replication client on *.* to 'repl'@'%' identified by 'replpass';
flush privileges;
從：1.啟用中繼日誌，2.設置一個在當前集群中惟一的server-id(以上兩步在配置文件中修改）:
3.使用有複製許可權用戶賬號連接至主伺服器，並啟動複製線程:
change master to master_host='192.168.238.224',master_user='repl',master_password='replpass',master_log_file='ON.000003',master_log_pos=4;
使用help change master to查看命令幫助
start slave; 開啟I/O和SQL線程
show slave status; 查看同步狀態，其中的Seconds_Behind_Master可以查看是否落後主節點，以及落後多少
查看從節點是否只讀show global variables like 'read_only';
log_slave_updates = 1 （允許備庫將其重放的事件也記錄到自身的二進位日誌，這樣自己既可是從節點也可是主節點）
sync_binlog =1 mysql每次在提交記憶體中的事物會將記憶體中的二進位日誌同步到磁碟上，保證在伺服器崩潰的時候不會丟失事件（強烈建在主節點開啟）
innodb_support_xa 預設為true，如果關閉則binlog記錄事務的順序可能與實際不符，造成slave不一致
如果有一臺新的從伺服器加入，該怎麼融入架構中：
1.在主節點做一個完全備份，並記錄二進位日誌文件及位置
2.在從節點恢復此完全備份，併在啟動複製時從記錄的二進位日誌文件和位置開始
問題：如何提供主節點的高可用？
