【編者按】本文作者為 John Matson，主要介紹 mysql 性能監(jiān)控應(yīng)該關(guān)注的 4 大指標(biāo)。 文章系國(guó)內(nèi) ITOM 管理平臺(tái) OneAPM 編譯呈現(xiàn)。

MySQL 是什么？

MySQL 是現(xiàn)而今最流行的開源關(guān)系型數(shù)據(jù)庫(kù)服務(wù)器。由 Oracle 所有，MySQL 提供了可以免費(fèi)下載的社區(qū)版及包含更多特性與支持的商業(yè)版。從 1995 年首發(fā)以來(lái)，MySQL 衍生出多款備受矚目的分支，諸如具有相當(dāng)競(jìng)爭(zhēng)力的 MariaDB 及 Percona。

關(guān)鍵 MySQL 統(tǒng)計(jì)指標(biāo)

如果你的數(shù)據(jù)庫(kù)運(yùn)行緩慢，或者出于某種原因無(wú)法響應(yīng)查詢，技術(shù)棧中每個(gè)依賴數(shù)據(jù)庫(kù)的組件都會(huì)遭受性能問(wèn)題。為了保證數(shù)據(jù)庫(kù)的平穩(wěn)運(yùn)行，你可以主動(dòng)監(jiān)控以下四個(gè)與性能及資源利用率相關(guān)的指標(biāo)：

• 查詢吞吐量

• 查詢執(zhí)行性能

• 連接情況

• 緩沖池使用情況

MySQL 用戶可以接觸到數(shù)百個(gè)數(shù)據(jù)庫(kù)指標(biāo)，因此，在本文中，筆者將專注于能幫助我們實(shí)時(shí)了解數(shù)據(jù)庫(kù)健康與性能的關(guān)鍵指標(biāo)。

本文參考了我們?cè)诒O(jiān)控入門系列文章中介紹的指標(biāo)術(shù)語(yǔ)，后者為指標(biāo)收集與告警提供了基礎(chǔ)框架。

不同版本與技術(shù)的兼容性

本系列文章討論的一些監(jiān)控策略只適用于 MySQL 5.6 與 5.7 版本。這些版本間的差異將在后文中提及。

本文列出的大多數(shù)指標(biāo)與監(jiān)控策略同樣適用于與 MySQL 兼容的技術(shù)，諸如 MariaDB 與 Percona 服務(wù)器，不過(guò)帶有一些明顯的差別。例如，MySQL Workbench(工作臺(tái)) 中的一些特性（在本系列第二篇中有詳細(xì)介紹）就與當(dāng)下的一些 MariaDB 版本不兼容。

Amazon RDS 用戶應(yīng)該查看我們專門制作的 MySQL 在 RDS 以及與 MySQL 兼容的 Amazon Aurora監(jiān)控手冊(cè)。

查詢吞吐量

image.png

在監(jiān)控任何系統(tǒng)時(shí)，你最關(guān)心的應(yīng)該是確保系統(tǒng)能夠高效地完成工作。數(shù)據(jù)庫(kù)的工作是運(yùn)行查詢，因此在本例中，你的首要任務(wù)是確保 MySQL 能夠如期執(zhí)行查詢。

MySQL 有一個(gè)名為 Questions 的內(nèi)部計(jì)數(shù)器（根據(jù) MySQL 用語(yǔ)，這是一個(gè)服務(wù)器狀態(tài)變量），客戶端每發(fā)送一個(gè)查詢語(yǔ)句，其值就會(huì)加一。由 Questions 指標(biāo)帶來(lái)的以客戶端為中心的視角常常比相關(guān)的Queries 計(jì)數(shù)器更容易解釋。作為存儲(chǔ)程序的一部分，后者也會(huì)計(jì)算已執(zhí)行語(yǔ)句的數(shù)量，以及諸如PREPARE 和 DEALLOCATE PREPARE 指令運(yùn)行的次數(shù)，作為服務(wù)器端預(yù)處理語(yǔ)句的一部分。

通過(guò)以下指令，查詢諸如 Questions 或 Com_select 服務(wù)器狀態(tài)變量的值：

SHOW GLOBAL STATUS LIKE "Questions";
+---------------+--------+
| Variable_name | Value |
+---------------+--------+
| Questions | 254408 |
+---------------+--------+

你也可以監(jiān)控讀、寫指令的分解情況，從而更好地理解數(shù)據(jù)庫(kù)的工作負(fù)載、找到可能的瓶頸。通常，讀取查詢會(huì)由 Com_select 指標(biāo)抓取，而寫入查詢則可能增加三個(gè)狀態(tài)變量中某一個(gè)的值，這取決于具體的指令：

Writes = Com_insert + Com_update + Com_delete</pre>

應(yīng)該設(shè)置告警的指標(biāo)：Questions

當(dāng)前的查詢速率通常會(huì)有起伏，因此，如果基于固定的臨界值，查詢速率常常不是一個(gè)可操作的指標(biāo)。但是，對(duì)于查詢數(shù)量的突變?cè)O(shè)置告警非常重要——尤其是查詢量的驟降，可能暗示著某個(gè)嚴(yán)重的問(wèn)題。

查詢性能

image.png

MySQL 用戶監(jiān)控查詢延遲的方式有很多，既可以通過(guò) MySQL 內(nèi)置的指標(biāo)，也可以通過(guò)查詢性能模式。從 MySQL 5.6.6 版本開始默認(rèn)啟用，MySQL 的 performance_schema 數(shù)據(jù)庫(kù)中的表格存儲(chǔ)著服務(wù)器事件與查詢執(zhí)行的低水平統(tǒng)計(jì)數(shù)據(jù)。

性能模式語(yǔ)句摘要

性能模式的 events_statements_summary_by_digest 表格中保存著許多關(guān)鍵指標(biāo)，抓取了與每條標(biāo)準(zhǔn)化語(yǔ)句有關(guān)的延遲、錯(cuò)誤和查詢量信息。從該表截取的一行樣例顯示，某條語(yǔ)句被執(zhí)行了兩次，平均執(zhí)行用時(shí)為 325 毫秒（所有計(jì)時(shí)器的測(cè)量值都以微微秒為單位）：

*************************** 1. row ***************************
SCHEMA_NAME: employees
DIGEST: 0c6318da9de53353a3a1bacea70b4fce
DIGEST_TEXT: SELECT * FROM employees WHERE emp_no > ?
COUNT_STAR: 2
SUM_TIMER_WAIT: 650358383000
MIN_TIMER_WAIT: 292045159000
AVG_TIMER_WAIT: 325179191000
MAX_TIMER_WAIT: 358313224000
SUM_LOCK_TIME: 520000000
SUM_ERRORS: 0
SUM_WARNINGS: 0
SUM_ROWS_AFFECTED: 0
SUM_ROWS_SENT: 520048
SUM_ROWS_EXAMINED: 520048
...

      SUM_NO_INDEX_USED: 0     
 SUM_NO_GOOD_INDEX_USED: 0                 
             FIRST_SEEN: 2016-03-24 14:25:32                  
              LAST_SEEN: 2016-03-24 14:25:55</pre>

摘要表會(huì)標(biāo)準(zhǔn)化所有語(yǔ)句（如上面的 DIGEST_TEXT 一欄所示），忽略數(shù)據(jù)值，規(guī)范化空格與大小寫，因此，下面的兩條查詢會(huì)被認(rèn)為是相同的：

select * from employees where emp_no >200;
SELECT * FROM employees WHERE emp_no > 80000;</pre>

想要按模式抽取出以微秒為單位的平均運(yùn)行時(shí)間，你可以這樣查詢性能模式：

SELECT schema_name
, SUM(count_star) count
, ROUND( (SUM(sum_timer_wait) / SUM(count_star))
/ 1000000) AS avg_microsec

 FROM performance_schema.events_statements_summary_by_digest 

WHERE schema_name IS NOT NULL
GROUP BY schema_name;
+--------------------+-------+--------------+
| schema_name | count | avg_microsec |
+--------------------+-------+--------------+
| employees | 223 | 171940 |
| performance_schema | 37 | 20761 |
| sys | 4 | 748 |
+--------------------+-------+--------------+</pre>

相似地，按模式計(jì)算出現(xiàn)錯(cuò)誤的語(yǔ)句總數(shù)，可以這么做：

SELECT schema_name
, SUM(sum_errors) err_count
FROM performance_schema.events_statements_summary_by_digest
WHERE schema_name IS NOT NULL
GROUP BY schema_name;
+--------------------+-----------+
| schema_name | err_count |
+--------------------+-----------+
| employees | 8 |
| performance_schema | 1 |
| sys | 3 |
+--------------------+-----------+</pre>

sys 模式

用上面的方式查詢性能模式能以編程方式有效地從數(shù)據(jù)庫(kù)中檢索出指標(biāo)。然而，對(duì)于特別查詢或調(diào)查，使用 MySQL 的 sys 模式通常更為簡(jiǎn)單。sys 模式以人們更易讀的格式提供了一個(gè)有條理的指標(biāo)集合，使得對(duì)應(yīng)的查詢更加簡(jiǎn)單。例如，想要找出最慢的語(yǔ)句（運(yùn)行時(shí)間在 95 名開外）：

SELECT * FROM sys.statements_with_runtimes_in_95th_percentile;</pre>

或者查看哪些標(biāo)準(zhǔn)化語(yǔ)句出現(xiàn)了錯(cuò)誤：

SELECT * FROM sys.statements_with_errors_or_warnings;</pre>

在 sys 模式的文檔中，詳細(xì)介紹了許多有用的例子。sys 模式在 MySQL 5.7.7 版本中是默認(rèn)包含的。不過(guò)，MySQL 5.6 用戶通過(guò)簡(jiǎn)單的幾個(gè)指令就能安裝它。

慢查詢

除了性能模式與 sys 模式中豐富的性能數(shù)據(jù)，MySQL 還提供了一個(gè) Slow_queries 計(jì)數(shù)器，每當(dāng)查詢的執(zhí)行時(shí)間超過(guò) long_query_time 參數(shù)指定的值之后，該計(jì)數(shù)器就會(huì)增加。默認(rèn)情況下，該臨界值設(shè)置為 10 秒。

SHOW VARIABLES LIKE 'long_query_time';
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+</pre>

long_query_time 參數(shù)的值可通過(guò)一條指令進(jìn)行調(diào)整。例如，將慢查詢臨界值設(shè)置為 5 秒：

SET GLOBAL long_query_time = 5;</pre>

（請(qǐng)注意，你可能要關(guān)閉會(huì)話，再重新連接至數(shù)據(jù)庫(kù)，這些更改才能在會(huì)話層生效。）

調(diào)查查詢性能問(wèn)題

如果你的查詢運(yùn)行得比預(yù)期要慢，很可能是某條最近修改的查詢?cè)趽v鬼。如果沒有發(fā)現(xiàn)特別緩慢的查詢，接下來(lái)就該評(píng)估系統(tǒng)級(jí)指標(biāo)，尋找核心資源（CPU，磁盤 I/O，內(nèi)存以及網(wǎng)絡(luò)）的限制。CPU 飽和與 I/O 瓶頸是常見的問(wèn)題根源。你可能還想檢查 Innodb_row_lock_waits 指標(biāo)，該指標(biāo)記錄著 InnoDB 存儲(chǔ)引擎不得不停下來(lái)獲得某行的鎖定的次數(shù)。從 MySQL 5.5 版本起，InnoDB 就是默認(rèn)的存儲(chǔ)引擎，MySQL 對(duì) InnoDB 表使用行級(jí)鎖定。

為了提高讀取與寫入操作的速度，許多用戶會(huì)想通過(guò)調(diào)整 InnoDB 使用的緩沖池大小來(lái)緩存表與索引數(shù)據(jù)。本文的第二部分會(huì)對(duì)監(jiān)控與調(diào)整緩沖池大小做詳細(xì)解讀。

應(yīng)該設(shè)置告警的指標(biāo)：

• 查詢運(yùn)行時(shí)間：管理關(guān)鍵數(shù)據(jù)庫(kù)的延遲至關(guān)重要。如果生產(chǎn)環(huán)境中數(shù)據(jù)庫(kù)的平均查詢運(yùn)行時(shí)間開始下降，應(yīng)該尋找數(shù)據(jù)庫(kù)實(shí)例的資源限制，行鎖或表鎖間可能的爭(zhēng)奪，以及客戶端查詢模式的變化情況。

• 查詢錯(cuò)誤：查詢錯(cuò)誤的猛增可能暗示著客戶端應(yīng)用或數(shù)據(jù)庫(kù)本身的問(wèn)題。你可以使用 sys 模式快速查找可能導(dǎo)致問(wèn)題的查詢。例如，列舉出返回錯(cuò)誤數(shù)最多的 10 條標(biāo)準(zhǔn)化語(yǔ)句：

SELECT * FROM sys.statements_with_errors_or_warnings
ORDER BY errors DESC LIMIT 10;</pre>

• Slow_queries：如何定義慢查詢（并由此設(shè)置 long_query_time 參數(shù)）取決于你的用戶案例。但是，無(wú)論你如何定義 “慢”，你都會(huì)想知道慢查詢的數(shù)量是否超出了基準(zhǔn)水平。為了找出真正執(zhí)行緩慢的查詢，你可以詢問(wèn) sys 模式，或深入了解 MySQL 提供的慢查詢?nèi)罩荆ㄔ摴δ苣J(rèn)是禁用的）。有關(guān)啟用并讀取慢查詢?nèi)罩镜母嘈判?，?qǐng)參考 MySQL 文檔。

連接

image.png

檢查并設(shè)置連接限制

監(jiān)控客戶端連接情況相當(dāng)重要，因?yàn)橐坏┛捎眠B接耗盡，新的客戶端連接就會(huì)遭到拒絕。MySQL 默認(rèn)的連接數(shù)限制為 151，可通過(guò)下面的查詢加以驗(yàn)證：

SHOW VARIABLES LIKE 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 151 |
+-----------------+-------+</pre>

MySQL 的文檔指出，健壯的服務(wù)器應(yīng)該能夠處理成百上千的連接數(shù)。

“常規(guī)情況下，Linux 或 Solaris 應(yīng)該能夠支持 500 到 1000 個(gè)同時(shí)連接。如果可用的 RAM 較大，且每個(gè)連接的工作量較低或目標(biāo)響應(yīng)時(shí)間較為寬松，則最多可處理 10000 個(gè)連接。而 Windows 能處理的連接數(shù)一般不超過(guò) 2048 個(gè)，這是由于該平臺(tái)上使用的 Posix 兼容層?！?/p>

連接數(shù)限制可以在系統(tǒng)運(yùn)行時(shí)進(jìn)行調(diào)整：

SET GLOBAL max_connections = 200;</pre>

然而，此設(shè)置會(huì)在服務(wù)器重啟時(shí)恢復(fù)為默認(rèn)值。想要永久地改變連接數(shù)限制，可以在 my.cnf 配置文件中添加如下配置（查看本文了解如何定位配置文件）：

max_connections = 200</pre>

監(jiān)控連接使用率

MySQL 提供了 Threads_connected 指標(biāo)以記錄連接的線程數(shù)——每個(gè)連接對(duì)應(yīng)一個(gè)線程。通過(guò)監(jiān)控該指標(biāo)與先前設(shè)置的連接限制，你可以確保服務(wù)器擁有足夠的容量處理新的連接。MySQL 還提供了Threads_running 指標(biāo)，幫助你分隔在任意時(shí)間正在積極處理查詢的線程與那些雖然可用但是閑置的連接。

如果服務(wù)器真的達(dá)到 max_connections 限制，它就會(huì)開始拒絕新的連接。在這種情況下，Connection_errors_max_connections 指標(biāo)就會(huì)開始增加，同時(shí)，追蹤所有失敗連接嘗試的Aborted_connects 指標(biāo)也會(huì)開始增加。

MySQL 提供了許多有關(guān)連接錯(cuò)誤的指標(biāo)，幫助你調(diào)查連接問(wèn)題。Connection_errors_internal 是個(gè)很值得關(guān)注的指標(biāo)，因?yàn)樵撝笜?biāo)只會(huì)在錯(cuò)誤源自服務(wù)器本身時(shí)增加。內(nèi)部錯(cuò)誤可能反映了內(nèi)存不足狀況，或者服務(wù)器無(wú)法開啟新的線程。

應(yīng)該設(shè)置告警的指標(biāo)

• Threads_connected：當(dāng)所有可用連接都被占用時(shí)，如果一個(gè)客戶端試圖連接至 MySQL，后者會(huì)返回 “Too many connections(連接數(shù)過(guò)多)” 錯(cuò)誤，同時(shí)將Connection_errors_max_connections 的值增加。為了防止出現(xiàn)此類情況，你應(yīng)該監(jiān)控可用連接的數(shù)量，并確保其值保持在 max_connections 限制以內(nèi)。

• Aborted_connects：如果該計(jì)數(shù)器在不斷增長(zhǎng)，意味著用戶嘗試連接到數(shù)據(jù)庫(kù)的努力全都失敗了。此時(shí)，應(yīng)該借助 Connection_errors_max_connections 與 Connection_errors_internal 之類細(xì)粒度高的指標(biāo)調(diào)查該問(wèn)題的根源。

緩沖池使用情況

image.png

MySQL 默認(rèn)的存儲(chǔ)引擎 InnoDB 使用了一片稱為緩沖池的內(nèi)存區(qū)域，用于緩存數(shù)據(jù)表與索引的數(shù)據(jù)。緩沖池指標(biāo)屬于資源指標(biāo)，而非工作指標(biāo)，前者更多地用于調(diào)查（而非檢測(cè)）性能問(wèn)題。如果數(shù)據(jù)庫(kù)性能開始下滑，而磁盤 I/O 在不斷攀升，擴(kuò)大緩沖池往往能帶來(lái)性能回升。

檢查緩沖池的大小

默認(rèn)設(shè)置下，緩沖池的大小通常相對(duì)較小，為 128MiB。不過(guò)，MySQL 建議可將其擴(kuò)大至專用數(shù)據(jù)庫(kù)服務(wù)器物理內(nèi)存的 80% 大小。然而，MySQL 也指出了一些注意事項(xiàng)：InnoDB 的內(nèi)存開銷可能提高超過(guò)緩沖池大小 10% 的內(nèi)存占用。并且，如果你耗盡了物理內(nèi)存，系統(tǒng)會(huì)求助于分頁(yè)，導(dǎo)致數(shù)據(jù)庫(kù)性能嚴(yán)重受損。

緩沖池也可以劃分為不同的區(qū)域，稱為實(shí)例。使用多個(gè)實(shí)例可以提高大容量 (多 GiB) 緩沖池的并發(fā)性。

緩沖池大小調(diào)整操作是分塊進(jìn)行的，緩沖池的大小必須為塊的大小乘以實(shí)例的數(shù)目再乘以某個(gè)倍數(shù)。

innodb_buffer_pool_size = N * innodb_buffer_pool_chunk_size
* innodb_buffer_pool_instances</pre>

塊的默認(rèn)大小為 128 MiB，但是從 MySQL 5.7.5 開始可以自行配置。以上兩個(gè)參數(shù)的值都可以通過(guò)如下方式進(jìn)行檢查：

SHOW GLOBAL VARIABLES LIKE "innodb_buffer_pool_chunk_size";
SHOW GLOBAL VARIABLES LIKE "innodb_buffer_pool_instances";</pre>

如果 innodb_buffer_pool_chunk_size 查詢沒有返回結(jié)果，則表示在你使用的 MySQL 版本中此參數(shù)無(wú)法更改，其值為 128 MiB。

在服務(wù)器啟動(dòng)時(shí)，你可以這樣設(shè)置緩沖池的大小以及實(shí)例的數(shù)量：

$ mysqld --innodb_buffer_pool_size=8G
--innodb_buffer_pool_instances=16</pre>

在 MySQL 5.7.5 版本，你可以通過(guò) SET 指令在系統(tǒng)運(yùn)行時(shí)修改緩沖池的大小，并精確到字節(jié)數(shù)。例如，假設(shè)有兩個(gè)緩沖池實(shí)例，你可以將其總大小設(shè)置為 8 GiB，這樣每個(gè)實(shí)例的大小即為 4 GiB。

SET GLOBAL innodb_buffer_pool_size=8589934592;</pre>

關(guān)鍵的 InnoDB 緩沖池指標(biāo)

MySQL 提供了許多關(guān)于緩沖池及其利用率的指標(biāo)。其中一些有用的指標(biāo)能夠追蹤緩沖池的總大小，緩沖池的使用量，以及其處理讀取操作的效率。

指標(biāo) Innodb_buffer_pool_read_requests 及 Innodb_buffer_pool_reads 對(duì)于理解緩沖池利用率都非常關(guān)鍵。Innodb_buffer_pool_read_requests 追蹤合理讀取請(qǐng)求的數(shù)量，而Innodb_buffer_pool_reads 追蹤緩沖池?zé)o法滿足，因而只能從磁盤讀取的請(qǐng)求數(shù)量。我們知道，從內(nèi)存讀取的速度比從磁盤讀取通常要快好幾個(gè)數(shù)量級(jí)，因此，如果 Innodb_buffer_pool_reads 的值開始增加，意味著數(shù)據(jù)庫(kù)性能大有問(wèn)題。

緩沖池利用率是在考慮擴(kuò)大緩沖池之前應(yīng)該檢查的重要指標(biāo)。利用率指標(biāo)無(wú)法直接讀取，但是可以通過(guò)下面的方式簡(jiǎn)單地計(jì)算得到：

(Innodb_buffer_pool_pages_total - Innodb_buffer_pool_pages_free) /
Innodb_buffer_pool_pages_total</pre>

如果你的數(shù)據(jù)庫(kù)從磁盤進(jìn)行大量讀取，而緩沖池還有許多閑置空間，這可能是因?yàn)榫彺孀罱徘謇磉^(guò)，還處于熱身階段。如果你的緩沖池并未填滿，但能有效處理讀取請(qǐng)求，則說(shuō)明你的數(shù)據(jù)工作集相當(dāng)適應(yīng)目前的內(nèi)存配置。

然而，較高的緩沖池利用率并不一定意味著壞消息，因?yàn)榕f數(shù)據(jù)或不常使用的數(shù)據(jù)會(huì)根據(jù) LRU 算法 自動(dòng)從緩存中清理出去。但是，如果緩沖池?zé)o法有效滿足你的讀取工作量，這可能說(shuō)明擴(kuò)大緩存的時(shí)機(jī)已至。

將緩沖池指標(biāo)轉(zhuǎn)化為字節(jié)

大多數(shù)緩沖池指標(biāo)都以內(nèi)存頁(yè)面為單位進(jìn)行記錄，但是這些指標(biāo)也可以轉(zhuǎn)化為字節(jié)，從而使其更容易與緩沖池的實(shí)際大小相關(guān)聯(lián)。例如，你可以使用追蹤緩沖池中內(nèi)存頁(yè)面總數(shù)的服務(wù)器狀態(tài)變量找出緩沖池的總大?。ㄒ宰止?jié)為單位）：

Innodb_buffer_pool_pages_total * innodb_page_size</pre>

InnoDB 頁(yè)面大小是可調(diào)整的，但是默認(rèn)設(shè)置為 16 KiB，或 16,384 字節(jié)。你可以使用 SHOW VARIABLES 查詢了解其當(dāng)前值：

SHOW VARIABLES LIKE "innodb_page_size";</pre>

結(jié)論

在本文中，我們介紹了許多你應(yīng)該加以監(jiān)控從而了解 MySQL 活動(dòng)與性能表現(xiàn)的重要指標(biāo)。如果你正在躊躇 MySQL 監(jiān)控方案，抓取下面列出的指標(biāo)能讓你真正理解數(shù)據(jù)庫(kù)的使用模式與可能的限制情況。這些指標(biāo)也能幫助你發(fā)現(xiàn)，何時(shí)擴(kuò)展服務(wù)器內(nèi)存或?qū)?shù)據(jù)庫(kù)移至更為強(qiáng)大的主機(jī)，從而保持良好的應(yīng)用性能。

• 查詢吞吐量

• 查詢延遲與錯(cuò)誤

• 客戶端連接與錯(cuò)誤

• 緩沖池利用率

附：

從庫(kù)的復(fù)制延時(shí)

復(fù)制延時(shí)量將直接影響了數(shù)據(jù)庫(kù)處于不一致狀態(tài)的時(shí)間長(zhǎng)短。如果我們是通過(guò)來(lái)提供讀服務(wù)，就不得不重視這個(gè)延時(shí)量。我們可以通過(guò)在Slave節(jié)點(diǎn)上執(zhí)行“SHOW SLAVE STATUS”命令，取Seconds_Behind_Master項(xiàng)的值來(lái)了解當(dāng)前的延時(shí)量（單位：秒）。當(dāng)然，該值的準(zhǔn)確性依賴于復(fù)制是否處于正常狀態(tài)。每個(gè)環(huán)境下的所允許的延時(shí)長(zhǎng)短與具體環(huán)境有關(guān)，所以復(fù)制延時(shí)多長(zhǎng)時(shí)間是合理的，只能由實(shí)際的應(yīng)用環(huán)境來(lái)判斷。

鳴謝

非常感謝來(lái)自 Oracle 的 Dave Stokes 與 VividCortex 的 Ewen Fortune，他們?cè)诒疚陌l(fā)布之前提供了許多寶貴的反饋意見。

本文系 OneAPM 工程師編譯整理。OneAPM Cloud Insight 集監(jiān)控、管理、計(jì)算、協(xié)作、可視化于一身，幫助所有 IT 公司，減少在系統(tǒng)監(jiān)控上的人力和時(shí)間成本投入，讓運(yùn)維工作更加高效、簡(jiǎn)單。想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問(wèn) OneAPM 官方技術(shù)博客。