面試mysqldbabrqacqu的時候遇到乙個題：
描述msyql replication 機制的實現原理，如何在不停掉mysql主庫的情況下，恢復資料不一致的sl**e的資料庫節點？
mysql的複製（replication）是乙個非同步的複製，從乙個mysql instace（稱之為master）複製到另乙個mysql instance（稱之sl**e）。實現整個複製操作主要由三個程序完成的，其中兩個程序在sl**e（sql程序和io程序），另外乙個程序在master（io程序）上。
引用新浪某位大牛的話：mysql複製就是一句話：基於binlog的單執行緒非同步複製過程。
mysql replication複製的基本過程如下：
1、sl**e上面的io程序連線上master，並請求從指定日誌檔案的指定位置（或者從最開始的日誌）之後的日誌內容；
複製** **如下:
mysql> change master to
-> master_host='master_host_name',
-> master_user='replication_user_name',
-> master_password='replication_password',
-> master_log_file='recorded_log_file_name',
-> master_log_pos=recorded_log_position;
2、mastebrqacqur接收到來自sl**e的io程序的請求後，通過負責複製的io程序根據請求資訊讀www.cppcns.com取制定日誌指定位置之後的日誌資訊程式設計客棧，返回給sl**e的io程序。返回資訊中除了日誌所包含的資訊之外，還包括本次返回的資訊已經到master端的bin-log檔案的名稱以及bin-log的位置；
3、sl**e的io程序接收到資訊後，將接收到的日誌內容依次新增到sl**e端的relay-log檔案的最末端，並將讀取到的master端的bin-log的檔名和位置記錄到master-info檔案中，以便在下一次讀取的時候能夠清楚的高速master「我需要從某個bin-log的哪個位置開始往後的日誌內容，請發給我」；
4、sl**e的sql程序檢測到relay-log中新增加了內容後，會馬上解析relay-log的內容成為在master端真實執行時候的那些可執行的內容，並在自身執行
操作過程：
（1）登陸主伺服器，檢視主伺服器的狀態
mysql>show master status；
找到現階段master的資料偏移量的值。
（2）登陸從伺服器，執行同步操作。
mysql>stop sl**e;
mysql > change master to 直接定位到這個值得位置； 這裡也就相當於給sl**e指明了相應的位置。
mysql > start sl**e;
（3）從伺服器上檢視狀態
mysql > show sl**e status
本文標題: 深入mysql主從複製延遲問題的詳解
本文位址: /shujuku/mysql/96597.html
mysql讀寫分離，主從複製，主從延遲
為了提公升資料庫的效能，一般會採用讀寫分離，即寫請求去主庫，讀請求去從庫。支援開啟多個io執行緒，可以提公升效率。開啟mysql的semi sync 半同步複製功能，即資料落庫，寫入binlog，並至少同步給一台從庫的relay日誌，才算寫成功。從庫開啟多個sql執行緒，可以併發讀取relay日誌，...
主從複製延遲導致坑
背景 線上出現了使用者註冊了多條重覆記錄 排查問題 原來 邏輯 先查詢傳過來的openid是否在從庫中存在，不存在就進行主庫插入。出現問題關鍵點 前端第一次請求時候，判斷從庫不存在，然後主庫插入註冊資料。由於出現複製延遲，前端第二請求過來，因為延遲了從庫查詢還是不存在，那就gg了，又重複插了一條。解...
主從複製延遲及原因
1.主庫方面原因 1 binlog寫入不及時 sync binlog 1 2 預設情況下dump t 是序列傳輸binlog 在併發事務量大時或者大事務,由於dump t 是串型工作的,導致傳送日誌較慢 如何解決問題?必須gtid,使用group commit方式.可以支援dump t並行 3 主庫...