MySQL主從同步道理引見。本站提示廣大學習愛好者：（MySQL主從同步道理引見）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL主從同步道理引見正文
概述
Mysql的Replication(復制)是一個異步的復制進程，從一個 Mysql instance(我們稱之為 Master)復制到另外一個Mysql instance(我們稱之 Slave)。在 Master 與 Slave之間的完成全部復制進程重要由三個線程來完成，個中兩個線程(Sql線程和IO線程)在 Slave 端，別的一個線程(IO線程)在Master端。
主從同步需求
要完成 MySQL 的 Replication ，起首必需翻開 Master 真個BinaryLog(mysql-bin.xxxxxx)功效，不然沒法完成。由於全部復制進程現實上就是Slave從Master端獲得該日記然後再在本身身上完整次序的履行日記中所記載的各類操作。翻開 MySQL 的 Binary Log 可以經由過程在啟動 MySQL Server 的進程中應用“—log-bin” 參數選項，或許在 my.cnf 設置裝備擺設文件中的 mysqld 參數組([mysqld]標識後的參數部門)增長“log-bin” 參數項。
主從同步進程
MySQL 復制的根本進程以下：
1.Slave下面的IO線程銜接上Master，並要求從指定日記文件的指定地位(或許從最開端的日記)以後的日記內容;
2.Master吸收到來自Slave的IO線程的要求後，經由過程擔任復制的IO線程依據要求信息讀取指定日記指定地位以後的日記信息，前往給Slave真個 IO線程。前往信息中除日記所包括的信息以外，還包含本次前往的信息在Master真個Binary Log文件的稱號和在Binary Log中的地位;
3.Slave的IO線程吸收到信息後，將吸收到的日記內容順次寫入到 Slave 真個RelayLog文件(mysql-relay-bin.xxxxxx)的最末尾，並將讀取到的Master真個bin-log的文件名和地位記載到master-info文件中，以便鄙人一次讀取的時刻可以或許清晰的告知Master“我須要從某個bin-log的哪一個地位開端往後的日記內容，請發給我”。
4.Slave的SQL線程檢測到Relay Log中新增長了內容後，會立時解析該Log文件中的內容成為在Master 端真實履行時刻的那些可履行的Query語句，並在本身履行這些Query。如許，現實上就是在Master端和Slave端履行了異樣的Query，所以兩頭的數據是完整一樣的。
現實上，在老版本中，MySQL 的復制完成在 Slave 端其實不是由 SQL 線程和 IO線程這兩個線程配合協作而完成的，而是由零丁的一個線程來完成一切的任務。然則 MySQL的工程師們很快發明，如許做存在很年夜的風險和機能成績，重要以下：
1.起首，假如經由過程一個單一的線程來自力完成這個任務的話，就使復制 Master 真個，BinaryLog日記，和解析這些日記，然後再在本身履行的這個進程成為一個串行的進程，機能天然會遭到較年夜的限制，這類架構下的Replication 的延遲天然就比擬長了。
3.其次，Slave 真個這個復制線程從 Master 端獲得 Binary Log 過去以後，須要接著解析這些內容，復原成Master 端所履行的原始 Query，然後在本身履行。在這個進程中，Master端極可能又曾經發生了年夜量的變更並生成了年夜量的Binary Log 信息。假如在這個階段 Master真個存儲體系湧現了沒法修復的毛病，那末在這個階段所發生的一切變革都將永久的喪失，沒法再找回來。這類潛伏風險在Slave端壓力比擬年夜的時刻特別凸起，由於假如 Slave壓力比擬年夜，解析日記和運用這些日記所消費的時光天然就會更長一些，能夠喪失的數據也就會更多。
所以，在前期的改革中，新版本的 MySQL 為了盡可能減小這個風險，並進步復制的機能，將 Slave真個復制改成兩個線程來完成，也就是後面所提到的 SQL 線程和 IO線程。最早提出這個改良計劃的是Yahoo!的一名工程師“JeremyZawodny”。經由過程如許的改革，如許既在很年夜水平上處理了機能成績，延長了異步的延不時間，同時也削減了潛伏的數據喪失量。
固然，即便是換成了如今如許兩個線程來協作處置以後，異樣也照樣存在 Slave數據延時和數據喪失的能夠性的，究竟這個復制是異步的。只需數據的更改不是在一個事務中，這些成績都是存在的。
總結
初步懂得了MySQL主從復制的道理。
