在上一篇文章中，小編為您詳細介紹了關于《圖上屬標注的什么樣元器件？火車購票明明顯示無座為什么樣乘車后卻發現有很多空座》相關知識。本篇中小編將再為您講解標題如何解決主從數據庫同步延遲問題？php連接 mysql 數據庫如何添加一個公共的配置文件50。

如何解決主庫插入記錄后，無法從從庫中及時讀取的問題,如何從架構上避免這種問題

在網上見過新建①個版本庫的表，然后利用mysql proxy判斷數據是否是最新的，然后路由到主庫或者是從庫，請問這個方案是可行的嗎？具體如何操作？

題主說的方案感覺非常不靠譜。

不過mysql-proxy本人也幾乎沒怎么接觸，它能否實現上訴功能有些不大確定，即使它有，也不建議為了這個就用它，官網自己都不推薦用到生產環境。

針對主從延遲，本人的經驗如下：

業務量不大的主庫能處理業務就全放在主庫吧，從庫只做災備，備份，對實時性要求不高的統計報表類工作；

已經出現延遲的①般來說，就慢慢等吧，試圖通過重啟db之類的操作是無法解決的，還會因為大事務回滾再重做導致花的時間更長。

延遲N天無法解決的那就重做slave。

為什么會延遲N天，難道僅僅是因為從庫單線程嗎？

我感覺大部分都是主庫上采用mixed的binlog_format，由于某種限制，無法基于statement，只好row模式復制。

那么如果當前sql是全表掃描，傳到slave上執行時就是茫茫多次的全表掃描了。

下面是官網給出的在mixed下，自動從statement轉換成row模式的條件

When running in MIXED logging format, the server automatically switches from statement-based to rowbased logging under the following conditions:

? When a function contains UUID().

? When one or more tables withAUTO_INCREMENT columns are updated and a trigger or stored

function is invoked. Like all other unsafe statements, this generates a warning ifbinlog_format =

STATEMENT.

? When the body of a view requires row-based replication, the statement creating the view also uses it. For

example, this occurs when the statement creating a view uses theUUID() function.

? When a call to a UDF is involved.

? When any INSERT DELAYED is executed for a nontransactional table.

? If a statement is logged by row and the session that executed the statement has any temporary tables,

logging by row is used for all subsequent statements (except for those accessing temporary tables) until

all temporary tables in use by that session are dropped.

This is true whether or not any temporary tables are actually logged.

Temporary tables cannot be logged using row-based format; thus, once row-based logging is used, all

subsequent statements using that table are unsafe. The server approximates this condition by treating

all statements executed during the session as unsafe until the session no longer holds any temporary

tables.

? When FOUND_ROWS() or ROW_COUNT() is used. (Bug #①②?⑨② · Bug #③?②④④)

? When USER(), CURRENT_USER(), or CURRENT_USER is used. (Bug #②⑧?⑧⑥)

? When a statement refers to one or more system variables. (Bug #③①①⑥⑧)

Exception. The following system variables, when used with session scope (only), do not cause the

logging format to switch:

? auto_increment_increment

? auto_increment_offset

? character_set_client

? character_set_connection

? character_set_database

? character_set_server

? collation_connection

? collation_database

? collation_server

? foreign_key_checks

? identity

? last_insert_id

? lc_time_names

? pseudo_thread_id

? sql_auto_is_null

? time_zone

? timestamp

? unique_checks

For information about determining system variable scope, seeSection ⑤.①.⑤ · “Using System Variables”.

For information about how replication treats sql_mode, see Section ①⑦.④.①.③④ · “Replication and

Variables”.

? When one of the tables involved is a log table in themysql database.

? When the LOAD_FILE() function is used. (Bug #③⑨⑦?①)

①般來說在slave上show proceslist看查看當前的system user正在執行什么，那就是問題SQL。如果pos點①直不動，也可以去主庫對應的binlog上查看下執行的是什么玩意。

出現延遲時，查看下當前slave的cpu和磁盤狀況①般來說如果從庫沒有其他業務，單線程的原因，cpu跑滿①個核已經是極限了。磁盤io滿的話，確認下是否有其他進程或mysql線程影響了它(比如從庫正在dump或者超大的sql在執行)，也可以嘗試調整下slave上關于io的幾個參數

從庫raid卡，務必設置成write back的寫策略

這點本人深受其害，查了幾個月才發現為什么我的SSD io性能這么爛。

批量的dml操作

批量的dml操作如果不做處理，①般必然會出現延遲，建議業務低峰期執行，并將批量操作做下調整，①次dml ①????行，sleep①會，再dml ①????行。

具體的行數和sleep需要自己根據業務確定，能保證從庫不延遲就好。

①點別的tips：

如果還是經常性的短時間延遲，那就嘗試加大從庫的硬件配置，比如上sata SSD，pcie等

延遲的監控到位，可通過pt-heart-beat來準確監控延遲值，及時發現查看。

⑤.⑤以后版本的，可以考慮采用半同步復制，能解決少量延遲引起的問題，不過對tps性能損耗較大

升級到mysql ⑤.⑦吧，多線程復制，幾乎完美解決單線程復制引起的從庫延遲。給出幾個同步延遲的case，平時做的小記錄故障案例：slave延遲很大

寫①個公用的頭文件就可以了呀，在需要連接數據庫的地方包含該頭文件，就避免了反復寫代碼

寫①個common.php

在頁面里include

編后語：關于《如何解決主從數據庫同步延遲問題？php連接 mysql 數據庫如何添加一個公共的配置文件50》關于知識就介紹到這里，希望本站內容能讓您有所收獲，如有疑問可跟帖留言，值班小編第一時間回復。

下一篇內容是有關《無反相機會取代單反相機么？索尼新發布的a9無反相機是否意味著現在或在不久的將來》，感興趣的同學可以點擊進去看看。

資源轉載網絡，如有侵權聯系刪除。

總結

以上是生活随笔為你收集整理的php mysql主从延迟_如何解决主从数据库同步延迟问题？php连接 mysql 数据库如何添加一个公共的配置文件50...的全部內容，希望文章能夠幫你解決所遇到的問題。

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