在一條DML語句中插入/更新/刪除/獲取幾百萬行資料，你會特別注意什麼？

KunlunDB發表於2022-01-17

前言


  • 一個分散式計算和儲存系統的任何節點都可能因為節點負載過重，節點的計算、儲存資源不足，網路延時，網路短暫不可達而導致操作超時。


  • 分散式系統的任何操作在等待遠端節點返回期間，通常會持有各種資源，不可以無限制等待下去，否則系統整體執行都會因此被阻塞而逐步停滯。


所以超時控制是所有分散式系統需要去解決好的問題，而解決不好就會導致系統執行停滯，無法正常工作。



崑崙分散式資料庫的超時控制機制簡介



崑崙分散式資料庫有以下超時控制變數：


  1. 一部分在計算節點中，計算節點的超時變數都在計算節點例項的配置檔案中，可以按需修改，並且修改後重新整理執行例項的引數。

  2. 一部分在儲存節點中，儲存節點的超時變數在儲存節點配置檔案中，可以修改配置檔案，也可以透過在計算節點或者儲存節點執行set語句修改對應變數值。

 
通常情況下使用者並不需要修改這些變數，因為我們已經針對常規情況最最佳化了計算節點和儲存節點的配置引數。

不過在 特殊場景下還是需要修改這些超時變數的。

典型場景就是需要在一個DML語句中插入/更新/刪除數百萬行甚至更多的資料，或者一個select語句中要返回數百萬行甚至更多的資料。

例如，邏輯匯入超大的資料表或者全量資料，對超大的表做全表更新，資料分析（OLAP）查詢需要掃描一個超大的表，以及程式設計師或者DBA打算刪庫跑路?等等。

這些場景下使用者最好根據預估插入/更新/刪除/讀取的資料量，提前增大下述各個超時值，以確保相關語句和操作可以正常工作直至完成，不會被超時機制誤認為是已經超時無法正確執行的語句而提前終止掉。

或者使用者可以在嘗試這些操作並得到錯誤之後，再增大這些超時值。

下面就讓我們看一下崑崙分散式資料庫的所有超時控制變數。



計算節點的超時變數功能


1.  statement_timeout：語句超時。

如果計算節點執行查詢的總時間超過這個限制，語句就會被回滾。

比如，如果計算節點使用儲存叢集返回的部分資料執行表連線時耗過長，那麼最終會在達到這個超時限制後停止（預設100秒）。
 
2.  mysql_read_timeout和mysql_write_timeout：計算節點於儲存節點/後設資料節點之間的通訊收發（讀寫）超時。

讀取超過mysql_read_timeout或者寫入超過mysql_write_timeout 那麼計算節點使用的mysql客戶端庫就會報錯並且從讀取/寫入等待中返回，這樣語句執行就提前終止了。

如果一條傳送給計算節點的一條insert語句會插入100萬行資料，或者一條select語句會從儲存節點返回上百萬行資料，那麼最好增加這兩個變數的值，它們預設是50秒。

另外，這種情況下還要增大mysql_max_packet_size 變數，確保這樣的超大資料包可以正確傳送給儲存節點。
 
3.  lock_timeout：計算節點等待表鎖的時間。

併發執行的增刪改查語句對錶的所是相容的，不需要等待鎖。

但是如果某個alter table語句正在執行，那麼同一個計算節點上其他連線中無法執行針對這個表的DML語句，它們最多等這麼久，還拿不到鎖就會報錯返回（預設 100秒）。
 
3.  log_min_duration_statement：超過這個時間的語句會作為慢查詢記錄到日誌檔案中。

如果要在每條insert語句中插入數萬行甚至更多，那麼一定要把這個變數增大，否則會在日誌檔案中記錄大量資料，導致計算節點磁碟空間用盡（預設10秒）。


儲存節點的超時變數功能

1.  lock_wait_timeout：mysql server層的鎖超時變數。

等待server層的表鎖的最大時間。如果一個DDL語句在alter table, 那麼所有對該表做DML語句的事務會阻塞等待最多這麼多表，還得不到表鎖就會返回錯誤。

 在MySQL8.0時代，加列和加索引這種最常見的曾經要鎖住全表才能完成的操作已經不需要全表長期鎖定了，已經變成了online ddl，因此預設5秒一般來說足夠了。

 
2.  innodb_lock_wait_timeout：mysql innodb的鎖超時變數，等待innodb行鎖的最大時間。

超過了那麼DML語句就會報錯返回 。

如果要做全表更新，並且表的資料量非常大，比如幾百GB甚至更多，那麼update語句會鎖住大量的行很長時間，此時其他事務通常會發生鎖超時，除非增大了其innodb_lock_wait_timeout（預設20秒）。
 
3.  如果儲存叢集使用了MySQL Group Replication做高可用，那麼需要增大
MGR的group_replication_member_expel_timeout，group_replication_component_stop_timeout, group_replication_unreachable_majority_timeout 超時控制變數，否則MGR的備機會誤以為主節點當機了從而發起主備切換，或者主節點以為備機失去聯絡了從而無法寫入。

結語

崑崙分散式資料庫具備完善的超時控制機制，在任何節點間通訊機制中都有超時控制，確保任何操作都有最大時耗上限，確保系統狀態可以持續推進，系統資源持續可服務更多的服務請求。

推薦閱讀





THE END


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70011764/viewspace-2852628/，如需轉載，請註明出處，否則將追究法律責任。

相關文章