轉自：https://zhuanlan.zhihu.com/p/165047153

Amazon Aurora MySQL 資料庫配置最佳實踐

在AWS Cloud當中遷移或啟動新的Amazon Aurora MySQL例項之後，您是否考慮過以下幾個問題？

• “接下來該做什麼？我該如何讓例項保持最佳執行狀態？”
• “是否需要對現有引數做出修改？”
• “具體該對哪些引數做出修改？”

如果這些問題確實困擾著您，希望本篇文章能給大家帶來一點有意義的指導與啟發。

在本文中，我們將探討、闡述並總結Amazon Aurora（相容MySQL）當中的引數配置建議。這些資料庫引數本身及其取值，將在AWS Cloud內新建立或遷移例項的存留、調優及重新配置當中發揮重要作用。另外，我們還將討論應該將Amazon RDS for MySQL中的哪些引數保留至Aurora例項當中。最後，本文還將論述引數的預設值、哪些引數對您例項的穩定性及效能優化至關重要等具體問題。

在執行變更之前，首先需要明確的就是變更背後的需求與動機。儘管大多數引數設定已經具有不錯的預設值，但應用程式工作負載本身的變化可能要求我們對引數做出具體調整。因此在著手修改之前，請先回答以下幾個問題：

• 當前是否存在穩定性問題，例如重新啟動或者故障轉移？
• 我能讓應用程式的查詢執行速度更快一些嗎？

Aurora引數組快速入門

Aurora MySQL引數組分為兩種型別：資料庫引數組與資料庫叢集引數組。其中某些引數會對整個資料庫叢集的配置產生影響，例如二進位制日誌格式、時區與字集集預設值等。其他引數的影響範圍則僅限於單一資料庫例項。

在本文中，我們將結合不同的上下文對各項引數進行分類，聊聊哪些引數會影響Aurora叢集的行為、穩定性及功能，而哪些引數會在變更之後影響效能表現。

需要強調的是，這兩種引數型別都具有預設預設值，而且只有部分引數允許修改。

要深入瞭解引數組的修改與使用基礎知識，請參閱《Aurora使用者指南》中的以下主題：

• 如何使用資料庫引數組與資料庫叢集引數組
• Aurora MySQL引數

在對生產資料庫“下手”之前

引數變更往往會產生意想不到的結果，包括效能下降或者系統不穩定等。在對任何資料庫配置引數做出變更之前，請首先思考以下最佳實踐：

• 在測試環境中為生產例項建立克隆或還原快照（詳見說明文件）。通過這種方式，您既獲得高度近似於生產環境的測試條件，又不致對實際業務造成影響。
• 為測試例項生成可模擬生產工作負載的工作負載。
• 根據各項關鍵效能指標檢查系統性能，具體包括CPU利用率、資料庫連線數量、記憶體利用率、快取命中率、查詢吞吐量以及延遲等。請在執行變更之前提取這些基準資料，並在變更之後觀察結果變化。
• 一次只變更一項引數，以避免發生歧義。
• 如果變更未能對測試系統產生可以直接測量的影響，請考慮將引數恢復為預設值。
• 記錄哪些引數能夠產生積極影響，以及哪些效能指標因變更而發生了切實改善。

預設引數值及其重要性

某些資料庫例項引數當中包含變數或者公式，其值則由常量確定——例如例項大小、記憶體佔用量、例項的網路埠及其分配到的儲存容量等。大家最好不要變動這些設定，因為這些引數會隨著例項的規模伸縮而自動調整。

例如，Aurora資料庫引數innodb_buffer_pool_size的預設值為：

{DBInstanceClassMemory*3/4}
DBInstanceClassMemory 
是一項變數，以GiB為單位設定為您例項的記憶體大小。

例如：對於擁有30.5 GiB記憶體的db.r4.xlarge例項來說，此值為20090716160 bytes，即18.71 GiB。

假如我們決定將此引數設定為一個固定值，例如18000000000 bytes，而後對db.r4.large例項執行縮容操作，那麼例項總記憶體將降低至原本的一半（15.2 GiB）。在對資料庫引擎的修改完成之後，我們很可能遭遇記憶體不足問題，並導致例項無法正確啟動。

要快速瀏覽由系統變數自動計算得出的引數，大家可以在引數組定義中搜索這些引數，具體方法為：搜尋大括號字元“{”。

如果您打算查詢例項所使用的實際值，可以通過兩種方式在命令列上實現。具體方法為使用SHOW GLOBAL VARIABLES 或者 SELECT語句：

mysql> SHOW GLOBAL VARIABLES where Variable_Name='innodb_buffer_pool_size';
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 8001683456 |
+-------------------------+------------+
1 row in set (0.01 sec)

mysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                8001683456 |
+---------------------------+
1 row in set (0.00 sec)

引數值設定錯誤的症狀與診斷

當某些引數發生設定錯誤時，有可能在MySQL錯誤日誌中被記錄為記憶體不足。在這種情況下，例項會進入滾動重啟狀態並生成類似於以下形式的事件日誌，同時就需要調整的引數值提供相應建議：

2018-12-29 19:05:16 UTC  [-]MySQL has been crashing due to incompatible parameters. Please check your memory parameters, in particular the max_connections, innodb_buffer_pool_size, key_buffer_size, query_cache_size, tmp_table_size, innodb_additional_mem_pool_size and innodb_log_buffer_size. Modify the memory parameter and reboot the instance.

引數分類

在本文的討論範圍之內，我們將Aurora MySQL引數分為兩大類：

1. 負責控制資料庫行為與功能，但對資源利用率及例項穩定性沒有影響的引數。
2. 通過管理例項中資源（例如快取及基於記憶體內的緩衝區）的分配方式，對效能造成影響的引數。

下面，我們一起來看其中一部分具有代表性的引數、對應預設值，以及對它們做出修改後會給例項的行為或效能造成哪些影響。下表所示，為引數組中列出的引數名稱、Aurora與MySQL預設值、以及受此引數影響的功能摘要。

建議與影響

下面我們對各項關鍵引數給資料庫帶來的具體影響做出簡要說明，同時通過具體用例介紹這些引數的調整方式：

autocommit

推薦設定：使用預設值（1或ON）以保證每條SQL語句（除非屬於由使用者開啟的事務的組成部分）在執行時可自動提交。

影響：將值設定為OFF可能導致使用模式錯誤，例如未決事務的開啟速度減慢、未被關閉甚至無法正確提交。這會影響到資料庫的效能與穩定性。

max_connections

建議設定：使用預設值（可變值）。在使用自定義值時，請保證只配置為應用程式實際用於任務執行的連線數量。

影響：將連線限制數量設定得過高，有可能佔用更多記憶體容量，且其中大部分資源被浪費在未使用連線上。此外，這種設定還可能引發資料庫連線峰值，進而影響資料庫的效能與穩定性。

系統會根據您的例項記憶體分配方式與大小，利用以下公式自動填充此變數引數，因此建議您優先使用預設值：

GREATEST({log(DBInstanceClassMemory/805306368,2)*45},{log(DBInstanceClassMemory/8187281408,2)*1000})

例如，對於擁有15.25 GiB記憶體的Aurora MySQL db.r4.large例項而言，此項引數將被設定為1000：

DBInstanceClassMemory = 16374562816 bytes
max_connections = GREATEST({log(16374562816/805306368,2)*45},{log(16374562816/8187281408,2)*1000})
max_connections = GREATEST(195.56,1000) = 1000

如果遇到連線錯誤，且連線錯誤日誌中顯示大量Too many connections，可將此項引數設定為固定值（而非變數值）。

如果您的應用程式需要更多連線，因此有必要將max_connections設定為固定值時，請考慮在應用程式與資料庫之間建立連線池或代理。這種方式同樣適用於難以可靠預測或控制連線數量的場景。

當大家將這項引數手動配置為超過建議連線數的值時，Amazon CloudWatch中的資料庫連線指標會在超出閾值的部分顯示紅線。CloudWatch的判斷標準源自以下公式：

Threshold value for max_connections = {DBInstanceClassMemory/12582880}

例如，對於具有15.25 GiB記憶體（ 15.25 x 1024 x 1024 x 1024 = 16374562816 bytes）的db.r4.large例項，警戒閾值大約為1300條連線。當然，如果例項資源充足，您仍然可以使用配置中指定的最大連線數。

max_allowed_packet

建議設定：使用預設值（4194304 bytes）。僅在資料庫工作負載有明確需求時，才使用自定義值。在處理會返回大元素（例如長字串或BLOB）的查詢時，請調整此項引數。

影響：在此處設定較大的值，並不會影響到訊息緩衝區的初始大小。相反，此引數只是在查詢負載增加時，允許系統將訊息緩衝區擴容至預先定義的上限。如果設定較大的引數值，一旦出現大量合法的併發查詢，則可能引發記憶體不足問題。

如果將此項引數設定得太小，則會顯示以下錯誤：

ERROR 1153 (08S01) at line 3: Got a packet bigger than 'max_allowed_packet' bytes

group_concat_max_len

建議設定：使用預設值（1024 bytes）。僅在工作負載有明確需求時使用自定義值。具體而言，只在您希望變更GROUP_CONCAT()語句的返回值並允許引擎返回更長的列值時，才對此項引數做出調整。此值應與max_allowed_packet並行使用，後者負責確定響應的最大大小。

影響：將這項引數設定得過高，可能導致記憶體佔用量過高以及記憶體不足等問題。而設定得太低則可能導致查詢失敗。

innodb_ft_result_cache_limit

建議設定：使用預設值（2000000000 bytes）。在工作負載有明確需求時使用自定義值。

影響：由於該值已經接近1.9 GiB，進一步增大該值有可能導致記憶體不足。

max_heap_table_size

建議設定：使用預設值（16777216 bytes）。限制使用者在記憶體內建立表時指定的最大大小。變更此值只會影響新建立的表，原有表不受影響。

影響：將此引數設定過高會導致記憶體利用率提升，並在記憶體內表量激增時導致記憶體不足問題。

performance_schema

建議設定：由於會大量佔用記憶體，請在t2例項上禁用此引數。

影響：在Aurora MySQL 5.6當中，系統已經通過啟發式方式對Performance Schema記憶體進行了預分配。這項預分配以其他配置引數為基礎，具體包括max_connections, table_open_cache及table_definition_cache等。在Aurora MySQL 5.7中，Perofmrance Schema記憶體採用按需分配模式。Performance Schema通常會消耗1到3 GB記憶體。如果資料庫例項的記憶體不足，則啟用Performance Schema有可能引發記憶體不足問題。

binlog_cache_size

建議設定：使用預設值（32768 bytes）。這項引數負責控制二進位制日誌快取所能使用的記憶體量。調高這項引數可利用緩衝區避免大量磁碟寫入，從而提升系統對大型事務的處理效能。此快取按連線進行分配。

影響：對於資料庫連線數量較大的環境，請控制此項引數以避免導致記憶體不足問題。

bulk_insert_buffer_size

建議設定：使用預設值，此引數並不適用於Aurora MySQL。

innodb_buffer_pool_size

建議設定：使用預設值（可變值），此引數在Aurora中被預配置為例項記憶體總量的75%。您可以在SHOW ENGINE INNODB STATUS的輸出結果中檢視緩衝池的使用情況。

影響：較大的緩衝池可在系統重複訪問同一表內資料時減少磁碟I/O操作，進而提高整體效能。由於需要容納InnoDB引擎本體，因此實際分配的記憶體量可能略高於實際配置值。

innodb_sort_buffer_size

建議設定：使用預設值（1048576 bytes）。

影響：高於預設值可能會給具有大量併發查詢的系統帶來整體記憶體壓力。

join_buffer_size

建議設定：使用預設值（262144 bytes）。各種型別的操作（包括JOIN）中已經預先分配有該值，且單一查詢可對緩衝區內的多個例項進行分配。如果需要提高聯接效能，建議大家向相應表中新增索引。

影響：在具有大量併發查詢的環境中，更改此引數可能帶來嚴重的記憶體壓力。即使增加索引，調高此值也無法實現更好的JOIN查詢效能。

key_buffer_size

建議設定：使用預設值（16777216 bytes），因為此項引數與Aurora無關，且僅影響MyISAM表的效能。

影響：不會對Aurora效能造成影響。

myisam_sort_buffer_size

建議設定：使用預設值（8388608 bytes）。由於不會影響到InnoDB，因此這項引數不適用於Aurora。

影響：不會對Aurora效能造成影響。

query_cache_size

建議設定：使用預設值（可變值）。此項引數在Aurora中已經預先調整，且實際值遠大於MySQL預設值。Aurora的查詢快取不會出現可擴充套件性問題（MySQL中的查詢快取同樣不會出現此類問題）。但您也可以根據實際需求，修改此項引數以適應高吞吐量、高需求工作負載。

影響：通過此快取訪問查詢時，會對查詢效能造成影響。您可以在“QCache”部分下SHOW STATUS命令的輸出結果中檢視查詢快取的使用情況。

query_cache_type

建議設定：啟用。在預設情況下，查詢快取在Aurora中處於啟用狀態，我們建議您保留這種啟用狀態，從而提高效能並降低運營成本。但如果您確定當前工作負載無法因此受益，則可禁用查詢快取。此類用例之一為高強度寫入型工作負載，其中不涉及任何讀取查詢。

影響：如果您的工作負載會複用查詢內容（例如可重複的SQL語句），那麼在Aurora中禁用查詢快取可能會影響資料庫效能。您可以在“QCache”部分SHOW STTUS命令的輸出結果中檢視查詢快取的使用情況。

read_buffer_size

建議設定：使用預設值（262144 bytes）。

影響：設定較大的值可提升整體記憶體壓力，並可能導致記憶體不足問題。除非您確定能夠在不損害系統穩定性的前提下改善效能，否則請不要調高此值。

read_rnd_buffer_size

建議設定：使用預設值（524288 bytes）。由於底層儲存叢集的效能特點，這裡我們無需改動Aurora的預設設定。

影響：設定較大的值可能導致記憶體不足問題。

table_open_cache

建議設定：除非您的工作負載需要同時訪問大量表，否則請不要改動此項引數。表快取會佔用大量記憶體，而Aurora中的預設值已經遠高於MySQL預設值。此項引數會根據例項大小自動調整。

影響：對於包含大量表（數十萬級別）的資料庫，可能需要調高此項引數，這是因為某些表可能不適合儲存在記憶體中。但將此值設定得過高可能導致記憶體不足。如果您啟用了Performance Schema，此項設定也會間接影響到Performance Schema的可用記憶體量。

table_definition_cache

建議設定：使用預設值。此項引數在Aurora中的預設值已經遠高於MySQL預設值，並會根據例項大小與型別進行自動調整。如果您的工作負載要求使用此引數，且資料庫需要同時開啟大量表，則調高參數可能會加快表開啟操作的速度。此引數需要與table_open_cache配合使用。

影響：如果您啟用了Performance Schema，此項設定也會間接影響到Performance Schema的可用記憶體量。如果使用高於預設值的設定量，可能會導致記憶體不足問題。

tmp_table_size

建議設定：使用預設值（16777216 bytes）。與max_heap_table_size配合，此項引數會限制用於查詢處理的記憶體內表大小。當超出臨時表容量上限時，表將被交換至磁碟。

影響：如果值設定得過高（數百MB以上）可能導致記憶體問題甚至記憶體不足。此項引數不會影響由MEMORY引擎建立的表。

結論與要點

在部署新的Aurora MySQL例項時，大部分引數已經完成預優化，足以作為後續引數變更前的良好基準。不同引數值的具體組合主要取決於系統實際情況、應用程式工作負載以及所需要的吞吐量等因素。此外，在變化率高、增長速度快、資料攝取量大且工作負載動態程度較強的資料庫系統上，大家也需要對這些引數進行持續監控與評估。我們建議您每隔幾個月（或者幾周）進行一輪監控與評估，確保資料庫始終適應應用程式與業務的實際需求。

要將引數調整成功轉化為可量化的效能提升，我們建議您不斷試驗、建立基準並認真比較每變更後的效能結果。此外，我們還建議您在向實時生產系統提交變更之前，做好測試與效能比較工作。

如果您希望瞭解關於特定引數的更多詳細資訊，請參閱AWS支援文件或聯絡AWS技術客戶團隊。如果你喜歡今天的文章，請多多點贊評論和我們互動哦～

本篇作者