您好,登錄后才能下訂單哦!
小編給大家分享一下mysql主從同步原理、配置以及延遲的示例分析,希望大家閱讀完這篇文章之后都有所收獲,下面讓我們一起去探討吧!
mysql的主從同步原理、主從同步配置、主從同步延遲,首先我們先來了解什么是主從同步,主從同步,顧名思義也稱為主從復制,用來建立一個和主數據庫完全一樣的數據庫環境。主從同步使得數據可以從一個數據庫服務器復制到其他服務器上,實現主數據庫的數據和從數據庫的數據保持一致。
集群是共享存儲的,是data-sharing . 主從復制中沒有任何共享 . 每臺機器都是獨立且完整的系統,是nothing-sharing.
從mysql5.6之后主從復制的實現方式主要有3種:
1. 異步復制
2. 全同步復制
3. 半同步復制
主從同步原理圖
1.當主數據庫的更新事件(update、insert、delete)被寫到binary-log .
2.從庫創建一個I/O線程,該線程連接到主庫并請求主庫發送binlog里面的更新記錄到從庫上 .主庫創建一個binlog dump thread線程,把binlog的內容發送到從庫 ,從庫的I/O線程讀取主庫的輸出線程發送的更新并拷貝這些更新到本地relay log文件中 .
3.從庫創建一個SQL線程,這個線程讀取從庫I/O線程寫到relay log的更新事件并執行 .
vim /etc/my.cnf 在[mysqld]下添加 server-id=1(用來標識不同的數據庫)log-bin=master-bin(打開bin-log并配置文件名為master-bin)log-bin-index=master-bin.index(區分不同的log-bin文件)
重啟數據庫:systemctl restart mariadb.service
vim /etc/my.cnf 在[mysqld]下添加 server-id=2relay-log=slave-relay-bin(打開relay-log并配置文件名為slave-relay-bin) relay-log-index=slave-relay-bin.index
重啟數據庫:systemctl restart mariadb.service
在主數據庫中:創建用戶repl ,每一個從服務器都需要用到主數據庫一個賬戶名和密碼來連接主服務器 .
CREATE USER 'repl'@'114.116.77.213' IDENTIFIED BY '12312';GRANT REPLICATION SLAVE ON *.* TO 'repl'@'114.116.77.213' IDENTIFIED BY '12312';
在從數據庫中:
change master to master_host='47.106.78.106',master_user='repl',master_password='12312',master_log_file='master-bin.000001',master_log_pos=0;
啟動同步:start slave;
在主數據庫創建一個數據庫,然后在從數據庫查看
1. 做數據的熱備,作為后備數據庫,主數據庫服務器故障后,可切換到從數據庫繼續工作,避免數據丟失 .
2. 讀寫分離,使數據庫能支撐更大的并發 .
主庫可以讀寫數據,而從庫只能讀數據,因為當從庫寫了數據positon會變化,但是主庫的position是不會變的,當主庫寫數據變化position的時候就可能會有沖突.
當主庫的binatylog文件存儲的數據很多,也就是position很大的時候,會再分裂一個新的binarylog文件,position置為0;
主從庫的mysql版本可以不一樣,但是從庫的mysql版本要比主庫的版本要高,如果不是的話,那么主庫的語句到了從庫可能就不能執行.
因為mysql是向后兼容的,也就是說低版本的語句在高版本里面是支持的,但是高版本的有些語句在低版本是不支持的.
(如果問到數據庫主從問題,必問以下問題):
主從的好處是?
主從的原理是?
從數據庫的讀的延遲問題了解嗎?如何解決?
做主從后主服務器掛了怎么辦?
主從同步的延遲的原因
主從同步的延遲的原因
主從同步延遲問題
1. 主從同步的延遲的原因
我們知道, 一個服務器開放N個鏈接給客戶端來連接的, 這樣有會有大并發的更新操作, 但是從服務器的里面讀取binlog 的線程僅有一個, 當某個SQL在從服務器上執行的時間稍長 或者由于某個SQL要進行鎖表就會導致,主服務器的SQL大量積壓,未被同步到從服務器里。這就導致了主從不一致, 也就是主從延遲。
2. 主從同步延遲的解決辦法
實際上主從同步延遲根本沒有什么一招制敵的辦法, 因為所有的SQL必須都要在從服務器里面執行一遍,但是主服務器如果不斷的有更新操作源源不斷的寫入, 那么一旦有延遲產生, 那么延遲加重的可能性就會原來越大。 當然我們可以做一些緩解的措施。
a. 我們知道因為主服務器要負責更新操作, 他對安全性的要求比從服務器高, 所有有些設置可以修改,比如sync_binlog=1,innodb_flush_log_at_trx_commit = 1 之類的設置,而slave則不需要這么高的數據安全,完全可以講sync_binlog設置為0或者關閉binlog,innodb_flushlog, innodb_flush_log_at_trx_commit 也 可以設置為0來提高sql的執行效率 這個能很大程度上提高效率。另外就是使用比主庫更好的硬件設備作為slave。
b. 就是把,一臺從服務器當度作為備份使用, 而不提供查詢, 那邊他的負載下來了, 執行relay log 里面的SQL效率自然就高了。
c. 增加從服務器嘍,這個目的還是分散讀的壓力, 從而降低服務器負載。
看完了這篇文章,相信你對“mysql主從同步原理、配置以及延遲的示例分析”有了一定的了解,如果想了解更多相關知識,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。