在從伺服器上執行show sl**e status;可以檢視到很多同步的引數，我們需要特別注意的引數如下,希望文章對各位會有所幫助。在從伺服器上執行show sl**e status;可以檢視到很多同步的引數，我們需要特別注意的引數如下：
master_log_file： sl**e中的i/o執行緒當前正在讀取的主伺服器二進位制日誌檔案的名稱
read_master_log_pos： 在當前的主伺服器二進位制日誌中，sl**e中的i/o執行緒已經讀取的位置
relay_log_file： sql執行緒當前正在讀取和執行的中繼日誌檔案的名稱
relay_log_pos： 在當前的中繼日誌中，sql執行緒已讀取和執行的位置
relay_master_log_file： 由sql執行緒執行的包含多數近期事件的主伺服器二進位制日誌檔案的名稱
sl**e_io_running： i/o執行緒是否被啟動並成功地連線到主伺服器上
sl**e_sql_running： sql執行緒是否被啟動
seconds_behind_master： 從屬伺服器sql執行緒和從屬伺服器i/o執行緒之間的時間差距，單位以秒計。
從庫同步延遲情況出現的
1、show sl**e status顯示引數seconds_behind_master不為0，這個數值可能會很大
2、show sl**e status顯示引數relay_master_log_file和master_log_file顯示bin-log的編號相差很大，說明bin-log在從庫上沒有及時同步，所以近期執行的bin-log和當前io執行緒所讀的bin-log相差很大
3、mysql的從庫資料目錄下存在大量mysql-relay-log日誌，該日誌同步完成之後就會被系統自動刪除，存在大量日誌，說明主從同步延遲很厲害
a、mysql資料庫主從同步延遲原理
mysql主從同步原理：
主庫針對寫操作，順序寫binlog，從庫單執行緒去主庫順序讀」寫操作的binlog」，從庫取到binlog在本地原樣執行（隨機寫），來保證主從資料邏輯上一致。
mysql的主從複製都是單執行緒的操作，主庫對所有ddl和dml產生binlog，binlog是順序寫，所以效率很高，sl**e的sl**e_io_running執行緒到主庫取日誌，效率比較高，下一步，問題來了，sl**e的sl**e_sql_running執行緒將主庫的ddl和dml操作在sl**e實施。dml和ddl的io操作是隨即的，不是順序的，成本高很多，還可能可sl**e上的其他查詢產生lock爭用，由於sl**e_sql_running也是單執行緒的，所以乙個ddl卡主了，需要執行10分鐘，那麼所有之後的ddl會等待這個ddl執行完才會繼續執行，這就導致了延時。
有朋友會問：「主庫上那個相同的ddl也需要執行10分，為什麼sl**e會延時？」，答案是master可以併發，sl**e_sql_running執行緒卻不可以。
b、 mysql資料庫主從同步延遲是怎麼產生的？
當主庫的tps併發較高時，產生的ddl數量超過sl**e乙個sql執行緒所能承受的範圍，那麼延時就產生了，當然還有就是可能與sl**e的大型query語句產生了鎖等待。
首要原因：資料庫在業務上讀寫壓力太大，cpu計算負荷大，網絡卡負荷大，硬碟隨機io太高
次要原因：讀寫binlog帶來的效能影響，網路傳輸延遲。
c、 mysql資料庫主從同步延遲解決方案。
架構方面
1.業務的持久化層的實現採用分庫架構，mysql服務可平行擴充套件，分散壓力。
2.單個庫讀寫分離，一主多從，主寫從讀，分散壓力。這樣從庫壓力比主庫高，保護主庫。
3.服務的基礎架構在業務和mysql之間加入memcache或者redis的cache層。降低mysql的讀壓力。
4.不同業務的mysql物理上放在不同機器，分散壓力。
5.使用比主庫更好的硬體裝置作為sl**e
總結，mysql壓力小，延遲自然會變小。
硬體方面
1.採用好伺服器，比如4u比2u效能明顯好，2u比1u效能明顯好。
2.儲存用ssd或者盤陣或者san，提公升隨機寫的效能。
3.主從間保證處在同乙個交換機下面，並且是萬兆環境。
總結，硬體強勁，延遲自然會變小。一句話，縮小延遲的解決方案就是花錢和花時間。
mysql主從同步加速
1、sync_binlog在sl**e端設定為0
2、–logs-sl**e-updates 從伺服器從主伺服器接收到的更新不記入它的二進位制日誌。
3、直接禁用sl**e端的binlog
4、sl**e端，如果使用的儲存引擎是innodb，innodb_flush_log_at_trx_commit =2從檔案系統本身屬性角度優化
master端
修改linux、unix檔案系統中檔案的etime屬性， 由於每當讀檔案時os都會將讀取操作發生的時間回寫到磁碟上，對於讀操作頻繁的資料庫檔案來說這是沒必要的，只會增加磁碟系統的負擔影響i/o效能。可以通過設定檔案系統的mount屬性，組織作業系統寫atime資訊，在linux上的操作為：
開啟/etc/fstab，加上noatime引數
/dev/sdb1 /data reiserfs noatime 1 2然後重新mount檔案系統
#mount -oremount /data
ps：主庫是寫，對資料安全性較高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1之類的設定是需要的
而sl**e則不需要這麼高的資料安全，完全可以講sync_binlog設定為0或者關閉binlog，innodb_flushlog也可以設定為0來提高sql的執行效率
1、sync_binlog=1o
mysql提供乙個sync_binlog引數來控制資料庫的binlog刷到磁碟上去。
預設，sync_binlog=0，表示mysql不控制binlog的重新整理，由檔案系統自己控制它的快取的重新整理。這時候的效能是最好的，但是風險也是最大的。一旦系統crash，在binlog_cache中的所有binlog資訊都會被丟失。
如果sync_binlog>0，表示每sync_binlog次事務提交，mysql呼叫檔案系統的重新整理操作將快取刷下去。最安全的就是sync_binlog=1了，表示每次事務提交，mysql都會把binlog刷下去，是最安全但是效能損耗最大的設定。這樣的話，在資料庫所在的主機作業系統損壞或者突然掉電的情況下，系統才有可能丟失1個事務的資料。
但是binlog雖然是順序io，但是設定sync_binlog=1，多個事務同時提交，同樣很大的影響mysql和io效能。
雖然可以通過group commit的補丁緩解，但是重新整理的頻率過高對io的影響也非常大。對於高併發事務的系統來說，
「sync_binlog」設定為0和設定為1的系統寫入效能差距可能高達5倍甚至更多。
所以很多mysql dba設定的sync_binlog並不是最安全的1，而是2或者是0。這樣犧牲一定的一致性，可以獲得更高的併發和效能。
預設情況下，並不是每次寫入時都將binlog與硬碟同步。因此如果作業系統或機器(不僅僅是mysql伺服器)崩潰，有可能binlog中最後的語句丟失了。要想防止這種情況，你可以使用sync_binlog全域性變數(1是最安全的值，但也是最慢的)，使binlog在每n次binlog寫入後與硬碟同步。即使sync_binlog設定為1,出現崩潰時，也有可能表內容和binlog內容之間存在不一致性。
2、innodb_flush_log_at_trx_commit （這個很管用）
抱怨innodb比myisam慢 100倍？那麼你大概是忘了調整這個值。預設值1的意思是每一次事務提交或事務外的指令都需要把日誌寫入（flush）硬碟，這是很費時的。特別是使用電池供電快取（battery backed up cache）時。設成2對於很多運用，特別是從myisam表轉過來的是可以的，它的意思是不寫入硬碟而是寫入系統快取。
日誌仍然會每秒flush到硬 盤，所以你一般不會丟失超過1-2秒的更新。設成0會更快一點，但安全方面比較差，即使mysql掛了也可能會丟失事務的資料。而值2只會在整個作業系統 掛了時才可能丟資料。
3、ls(1) 命令可用來列出檔案的 atime、ctime 和 mtime。
atime 檔案的access time 在讀取檔案或者執行檔案時更改的
ctime 檔案的create time 在寫入檔案，更改所有者，許可權或鏈結設定時隨inode的內容更改而更改
mtime 檔案的modified time 在寫入檔案時隨檔案內容的更改而更改
ls -lc filename 列出檔案的 ctime
ls -lu filename 列出檔案的 atime
ls -l filename 列出檔案的 mtime
stat filename 列出atime，mtime，ctime
atime不一定在訪問檔案之後被修改
因為：使用ext3檔案系統的時候，如果在mount的時候使用了noatime引數那麼就不會更新atime資訊。
這三個time stamp都放在 inode 中.如果mtime,atime 修改,inode 就一定會改, 既然 inode 改了,那ctime也就跟著改了.
之所以在 mount option 中使用 noatime, 就是不想file system 做太多的修改, 而改善讀取效能
MYSQL從庫延遲提高從庫效率
主從複製延期設定從庫的sycn binlog提高複製效率 mysql配置引數sync binlog說明 mysql提供乙個sync binlog引數來控制資料庫的binlog刷到磁碟上去。預設，sync binlog 0，表示mysql不控制binlog的重新整理，由檔案系統自己控制它的快取的重新整...
解決主從資料庫同步延遲問題
場景 需要在主機寫入之後，保證在備機一定能夠讀取到已經寫入的資料，也就是需要主從架構下的強一致性。主機與備機之間的物理延遲是不可控的，也是無法避免的。但是如果僅僅需要滿足這種強一致性，是相對簡單的事情 只需要在主機寫入時，確認更新已經同步到備機之後，再返回寫操作成功即可。主從資料庫支援這種完全的同步...
Kafka從SQL Server資料庫同步資料
前提 已安裝 vmware station，linux centos xshell，xftp，zookeeper，kafka 一 安裝confluent的connector 開始安裝 1 解壓至 kafka home connector 資料夾下，kafka home本人的是 usr local k...