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

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

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

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

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

針對主從延遲，本人的經(jīng)驗(yàn)如下：

業(yè)務(wù)量不大的主庫能處理業(yè)務(wù)就全放在主庫吧，從庫只做災(zāi)備，備份，對實(shí)時性要求不高的統(tǒng)計(jì)報(bào)表類工作；

已經(jīng)出現(xiàn)延遲的①般來說，就慢慢等吧，試圖通過重啟db之類的操作是無法解決的，還會因?yàn)榇笫聞?wù)回滾再重做導(dǎo)致花的時間更長。

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

為什么會延遲N天，難道僅僅是因?yàn)閺膸靻尉€程嗎？

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

那么如果當(dāng)前sql是全表掃描，傳到slave上執(zhí)行時就是茫茫多次的全表掃描了。

下面是官網(wǎng)給出的在mixed下，自動從statement轉(zhuǎn)換成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看查看當(dāng)前的system user正在執(zhí)行什么，那就是問題SQL。如果pos點(diǎn)①直不動，也可以去主庫對應(yīng)的binlog上查看下執(zhí)行的是什么玩意。

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

從庫raid卡，務(wù)必設(shè)置成write back的寫策略

這點(diǎn)本人深受其害，查了幾個月才發(fā)現(xiàn)為什么我的SSD io性能這么爛。

批量的dml操作

批量的dml操作如果不做處理，①般必然會出現(xiàn)延遲，建議業(yè)務(wù)低峰期執(zhí)行，并將批量操作做下調(diào)整，①次dml ①????行，sleep①會，再dml ①????行。

具體的行數(shù)和sleep需要自己根據(jù)業(yè)務(wù)確定，能保證從庫不延遲就好。

①點(diǎn)別的tips：

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

延遲的監(jiān)控到位，可通過pt-heart-beat來準(zhǔn)確監(jiān)控延遲值，及時發(fā)現(xiàn)查看。

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

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

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

寫①個common.php

在頁面里include

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

下一篇內(nèi)容是有關(guān)《無反相機(jī)會取代單反相機(jī)么？索尼新發(fā)布的a9無反相機(jī)是否意味著現(xiàn)在或在不久的將來》，感興趣的同學(xué)可以點(diǎn)擊進(jìn)去看看。

資源轉(zhuǎn)載網(wǎng)絡(luò)，如有侵權(quán)聯(lián)系刪除。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。