Binlog日志(主服務器) => 中繼日志(從服務器 運行一遍,保持一致)。從服務器是否要二進制日志取決于架構設計。如果二進制保存足夠穩定，從性能上來說，從服務器不需要二進制日志。默認情況下，mysql主從復制是異步的。

異步：命令寫操作是在內存中完成的。同步：在磁盤完成才認定寫操作是完成的。

異步：主服務器執行10條命令，主服務器不等待從服務器，從服務器才復制3條命令道中繼日志。這叫做從服務器的延遲delay。異步延遲是難免的。

Mysql是多用戶的，多個用戶進來并發 發起 寫操作，同時進行的，寫到寫到二進制語句是一條一條的，從服務器一次執行一條，是單線程的。比主服務器慢是難免的。

整個復制架構：3個線程，主服務器dump線程，發送到從服務器上。從服務器上IO線程，接受主服務器上dump線程發送過來的數據，寫入到中繼日志中去。而后一旦中繼日志有心內容，SQL線程一句一句執行內容。

以上，所以配置就是：主服務器啟用bin log日志，從服務器啟用relay log，建立身份標示server id，每臺服務器需要唯一的server id。

負載均衡集群

高可用集群:冗余

高性能集群：完成復雜運算

AXFR：AXFR請求，是從DNS服務器請求在主DNS服務器上更新信息的一類域名系統的請求。AXFR請求經常導致全區域傳輸。如果區域文件很大的話，它需要花費很多的時間并消耗可觀的帶寬。

IXFR：增量區域傳輸，增量區域傳輸協議。

?

權限：

主服務器建立賬戶，從服務器使用賬戶。mysql有一些特殊的權限允許復制進程運行，運行在從服務器上的I/O線程創建了到master的連接，這就意味著必須在主服務器上創建一個用戶并且需要授予特殊的權限。

這樣I/O線程就會一特定的身份連接到主服務器上并且讀取二進制日志。但是需要說明的一點是，復制用戶在主服務器上實際只需要 replication? client 權限就可以運行的，這里授予replication? slave的原因是用于監視和管理復制賬號需要這個權限，并且這兩個功能（復制需要的權限，監視和管理復制賬號權限）通常是一個賬號在管理，而不是為了達 到這兩個目標而分別設置2個賬號。

replication slave

replication client

主服務器和從服務器雙雙互相認證，SSL認證。

基于邏輯，Mysql Dump從主服務器復制到從服務器。Mysql有一個選項master data，從什么地方讀取二進制數據。主服務器放在邏輯卷上，從服務器基于備份也可以放邏輯卷上。

CHANGE MASTER TO master_def[,master_def] ...

可以更改從屬服務器用于與主服務器進行連接和通訊的參數。

mysql>CHANGE MASTER TO->????MASTER_HOST='master2.mycompany.com',->????MASTER_USER='replication',->????MASTER_PASSWORD='bigs3cret',->????MASTER_PORT=3306,->????MASTER_LOG_FILE='master2-bin.001',->????MASTER_LOG_POS=4,->? MASTER_CONNECT_RETRY=10;

show slave status,檢查以下兩項是否啟動：

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes

如何讓從服務器的mysql服務在啟動時候不要自動啟動從服務線程？
在從服務器上
[mysqld]
skip-slave-start=1

數據庫復制過濾：
主服務器：
binlog_do_db
binlog_ignore_db

無論怎么過濾，都不在主服務器上做過濾。任何不涉及到的數據庫相關的寫操作都不會記錄到二進制中。

從服務器：
replicate_do_db
replicate_ignore_db
replicate_do_table
replicate_ignore_db
基于通配符的匹配
replicate_wild_ignore_db = mysql.%
replicate_wild_do_db = magedu.%

浪費額外的網絡帶寬，復制過來的數據沒用。

主服務器崩潰：事務已經提交-->寫入二進制日志：
在主從架構上建議使用的配置：
主服務器：
sync_binlog=1
innodb_flush_logs_at_trx_commit=1

從服務器
skip_slave_start=1
read_only=1

使用mysql的sharding，多臺服務器寫操作。切分主要有兩種方式：水平切分（Horizental Sharding）和垂直切分（Vertical Sharding）。水平切分所指的是通過一系列的切分規則將數據水平分布到不同的DB或table中，在通過相應的DB路由 或者table路由規則找到需要查詢的具體的DB或者table以進行Query操作，比如根據用戶ID將用戶表切分到多臺數據庫上。垂直切分指的是按業務、產品切分，將不同類型的數據且分到不同的服務器上，通過數據庫代理疏通程序與多個數據庫的通訊、降低應用的復雜度。

讀寫分離簡單的說是把對數據庫讀和寫的操作分開對應不同的數據庫服務器，這樣能有效地減輕數據庫壓力，也能減輕io壓力。主數據庫提供寫操作，從數據庫提供讀操作，這樣既避免了主數據庫服務器（Master）的過載，也有效地利用了從數據庫服務器（Slave）的資源。

主主(互為主從)架構
1、雙方都要建立有復制權限的用戶；2、不同的server id；3、雙方都要開啟二進制日志和中繼日志；4、在啟動之前必須知道左服務器的二進制日志文件名和位置、右服務器的二進制日志文件名和位置。

主從分離(實現分層)

讀寫分離（代理），常用的由mysql官方提供的mysql proxy 和阿里巴巴開源的Amoeba。

?已經聽完第八講。。。

轉載于:https://www.cnblogs.com/zl0372/p/mssql.html

總結

以上是生活随笔為你收集整理的马老师 生产环境mysql主从复制、架构优化方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。