MySQL-一主一備和binlog
MySQL的高可用架構（業務開發可以借鑑相關的思想）
一主一備(MS)
主從同步的原理
-
主庫應該會有一個ServerSocket監聽埠
-
從庫通過 change master 命令
- 設定主庫的ip 埠 使用者名稱和密碼 這些簡單說是連線校驗資訊；
- 還需要設定 請求binlog的開始位置
-
從庫執行start slave指令，會啟動兩種執行緒
- io執行緒，負責做網路連線的
- sql執行緒，負責同步relay log中的資料，轉化為sql語句在從庫執行。
-
主庫校驗完相關的資訊後，按照從庫指定的位置把binlog日誌傳遞給從庫
-
從庫的IO thread拿到日誌後，寫入到relay log
-
sql執行緒把相關資料解析並執行
一主一備(MM)
這裡需要再研究
binlog日誌
binlog日誌有三種格式，statement，row和mixed。
當設定為statement時，儲存的是SQL語句；當設定為row時，儲存的是具體被操作的行資訊。
在某種情況下時，使用statement格式可能會導致主從不一致。比如：當delete 語句中包含了limit時，根據不同的索引定位到的資料行不同時（但是這些行都滿足where條件），很可能在主庫上刪除的是A行，但是在從庫中刪除的卻是B行。
根本原因：因為儲存的是sql，所以還需要通過各種步驟進行解析處理，在這個過程很可能兩個庫解析處理的結果不同。
如果修改為row格式，記錄的不是sql，而是被操作的行，這樣就不會有歧義。
但是row格式也有缺點：
因為記錄了每一個操作的行，所以不可避免地會產生很大的日誌量。為了應對這個問題，MySQL提供了mix模式，在mix模式中，由mysql來判斷具體使用哪種格式存入binlog，這種方式更加靈活。
生產實踐中，更推薦用row格式，因為利用row格式可以做資料恢復，其他格式卻不可以。
具體原理：row格式中記錄了行的所有欄位資訊，這樣就可以方便的做相關的逆向操作資訊。
MariaDB的Flashback工具就是利用row格式的binlog來做資料恢復的。
另外，在生產實踐中，不要直接複製貼上mysql中的sql語句來做手動的操作，因為有些指令是依賴上下文的，只使用sql語句可能會出錯。應該使用mysqlbinlog 解析出來，然後一股腦地交給mysql去處理。
mysqlbinlog master.000001 --start-position=2738 --stop-position=2973 | mysql -h127.0.0.1 -P13000 -u$user -p$pwd;