本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
重新啟動 Amazon Aurora 資料庫叢集或 Amazon Aurora 資料庫執行個體
您可能需要重新啟動資料庫叢集或叢集中的某些執行個體,這通常是基於維護原因。例如,假設您修改參數群組內的參數,或將不同的參數群組與您的叢集建立關聯。在這些情況下,您必須重新啟動叢集,才能讓變更生效。同樣地,您可以在叢集中重新啟動一或多個讀取器資料庫執行個體。您可以安排個別執行個體的重新啟動操作,以將整個叢集的停機時間降到最低。
重新啟動叢集中每個資料庫執行個體所需的時間,取決於重新啟動時的資料庫活動。這也取決於您的特定資料庫引擎的復原流程。如果可行,請在開始重新啟動流程之前減少該特定執行個體上的資料庫活動。這樣做可以減少重新啟動資料庫所需的時間。
只有在叢集中的每個資料庫執行個體處於可用狀態時,您才能重新啟動每個資料庫執行個體。資料庫執行個體可能會因多種原因無法使用。其中包括叢集處於停止狀態、有修改套用至執行個體,以及存在維護時段動作,例如版本升級。
重新啟動資料庫執行個體,將重新啟動資料庫引擎流程。重新啟動資料庫執行個體會暫時中斷,在此期間,資料庫執行個體狀態設定為 rebooting (重新啟動中)。
注意
如果資料庫執行個體未使用其關聯資料庫參數群組的最新變更,則會 AWS Management Console 顯示資料庫參數群組的狀態為擱置重新開機。pending-reboot (等待重新啟動) 參數群組狀態不會在下一個維護時段期間造成自動重新啟動。如欲對該資料庫執行個體套用最新參數變更,請手動重新啟動資料庫執行個體。如需參數群組的詳細資訊,請參閱使用參數群組。
主題
在 Aurora 叢集中重新啟動資料庫執行個體
此程序是您在使用 Aurora 執行重新啟動時的最重要操作。許多維護程序涉及以特定順序重新啟動一或多個 Aurora 資料庫執行個體。
重新啟動資料庫執行個體
-
登入 AWS Management Console 並開啟 Amazon RDS 主控台,網址為 https://console.aws.amazon.com/rds/
。 -
在導覽窗格中選擇 Databases (資料庫),然後選擇您要重新啟動的資料庫執行個體。
-
針對 Actions (動作),選擇 Reboot (重新啟動)。
Reboot DB Instance (重新啟動資料庫執行個體) 頁面隨即出現。
-
選擇 Reboot (重新啟動),以重新啟動您的資料庫執行個體。
或者選擇 Cancel (取消)。
若要使用重新啟動資料庫執行個體 AWS CLI,請呼叫reboot-db-instance
命令。
對於LinuxmacOS、或Unix:
aws rds reboot-db-instance \ --db-instance-identifier
mydbinstance
在 Windows 中:
aws rds reboot-db-instance ^ --db-instance-identifier
mydbinstance
若要使用 Amazon RDS API 重新啟動資料庫執行個體,請呼叫 RebootDBInstance
操作。
使用讀取可用性功能重新啟動 Aurora 叢集
使用讀取可用性功能,您可以重新啟動 Aurora 叢集的寫入器執行個體,而無需重新啟動主要或次要資料庫叢集中的讀取器執行個體。這樣做有助於維護叢集的高可用性,以進行讀取操作,同時重新啟動寫入器執行個體。您可以稍後依照您方便的排程重新啟動讀取器執行個體。例如,在生產叢集中,您可以一次重新啟動一個讀取器執行個體,只有在主執行個體重新啟動完成後才會啟動。對於要重新啟動的每個資料庫執行個體,請遵循 在 Aurora 叢集中重新啟動資料庫執行個體 中的程序。
主要資料庫叢集的讀取可用性功能在 Aurora MySQL 2.10 版及更新版本中提供。次要資料庫叢集的讀取可用性在 Aurora MySQL 3.06 版及更新版本中提供。
對於 Aurora PostgreSQL,此功能適用於下列版本:
15.2 版和更新的 15 版本
14.7 版和更新的 14 版本
13.10 版和更新的 13 版本
12.14 版和更新的 12 版本
如需 Aurora PostgreSQL 讀取可用性功能的詳細資訊,請參閱 改善 Aurora 複本的讀取可用性。
在此功能之前,重新啟動主執行個體會導致每個讀取器執行個體同時重新開機。如果您的 Aurora 叢集正在執行較舊版本,請改用 在無讀取可用性的情況下重新啟動 Aurora 叢集 中的重新啟動程序。
注意
對於 Aurora MySQL 版本低於 3.06 的 Aurora 全域資料庫,對具有讀取可用性的 Aurora 資料庫叢集中的重新開機行為的變更不同。如果重新啟動 Aurora 全域資料庫中主要叢集的寫入器執行個體,主要叢集中的讀取器執行個體仍然可用。不過,任何次要叢集中的資料庫執行個體會同時重新啟動。
Aurora 全域資料庫支援限制版本的改良讀取可用性功能,適用於 Aurora PostgreSQL 版本 12.16、13.12、14.9、15.4 及更高版本。
對叢集參數群組進行變更後,您經常重新啟動叢集。您可以依照 使用參數群組 中的程序進行參數變更。假設您重新啟動 Aurora 叢集中的寫入器資料庫執行個體,以將變更套用至叢集參數。部分或所有讀取器資料庫執行個體可能會繼續使用舊的參數設定。不過,不同的參數設定不會影響叢集的資料完整性。任何影響資料檔案組織的叢集參數,僅由寫入器資料庫執行個體使用。
例如在 Aurora MySQL 叢集中,您可以在讀取器執行個體之前更新叢集參數,例如寫入器執行個體上的 binlog_format
和 innodb_purge_threads
。只有寫入器執行個體會寫入二進位日誌並清除復原紀錄。對於變更查詢解譯 SQL 陳述式或查詢輸出方式的參數,您可能需要謹慎地立即重新啟動讀取器執行個體。如果要在查詢期間避免未預期的應用程式行為,請您執行這項操作。例如,假設您變更 lower_case_table_names
參數並重新啟動寫入器執行個體。在這種情況下,在重新啟動讀取器執行個體之前,讀取器執行個體可能無法存取新建立的資料表。
如需所有 Aurora MySQL 叢集參數的清單,請參閱叢集層級參數。
如需所有 Aurora PostgreSQL 叢集參數的清單,請參閱 Aurora PostgreSQL 叢集層級參數。
提示
如果您的叢集正在處理具有高輸送量的工作負載,則 Aurora MySQL 可能仍會重新啟動部分讀取器執行個體以及寫入器執行個體。
在容錯移轉操作期間,重新啟動次數也會減少。Aurora MySQL 只會在容錯移轉期間重新啟動寫入器資料庫執行個體和容錯移轉目標。叢集中的其他讀取器資料庫執行個體仍可使用,以繼續透過連線至讀取器端點來處理查詢。因此,您可以在叢集中擁有多個讀取器資料庫執行個體,以提高容錯移轉期間的可用性。
在無讀取可用性的情況下重新啟動 Aurora 叢集
若無讀取可用性功能,要重新啟動整個 Aurora 資料庫叢集,您需要重新啟動該叢集的寫入器資料庫執行個體。若要執行此作業,請依照 中的程序進行在 Aurora 叢集中重新啟動資料庫執行個體
重新啟動寫入器資料庫執行個體,也會為叢集中的每個讀取器資料庫執行個體啟動重新啟動。如此一來,任何叢集範圍的參數變更都會同時套用至所有資料庫執行個體。不過,重新啟動所有資料庫執行個體會導致叢集的短暫中斷。讀取器資料庫執行個體會保持為無法使用,直到寫入器資料庫執行個體完成重新啟動並變得可已使用。
此重新開機行為適用於 Aurora MySQL 2.09 及較低版本中建立的所有資料庫叢集。
對於 Aurora PostgreSQL,此行為適用於下列版本:
14.6 和較低的 14 版本
13.9 和較低的 13 版本
12.13 和較低的 12 版本
所有 PostgreSQL 11 版本
在 RDS 主控台中,寫入器資料庫執行個體在 Databases (資料庫) 頁面的 Role (角色) 資料欄下具有的值為 Writer (寫入器)。在 RDS CLI 中,describe-db-clusters
命令的輸出包括 DBClusterMembers
部分。代表寫入器資料庫執行個體的 DBClusterMembers
元素,其 true
欄位的值為 IsClusterWriter
。
重要
使用讀取可用性功能時,在 Aurora MySQL 與 Aurora PostgreSQL 中的重新啟動行為有所不同:讀取器資料庫執行個體通常會在您重新啟動寫入器執行個體時保持為可用。然後,您可以在方便的時間重新啟動讀取器執行個體。如果您希望某些讀取器執行個體始終可用,您可以在交錯排程中重新啟動讀取器執行個體。如需詳細資訊,請參閱 使用讀取可用性功能重新啟動 Aurora 叢集。
檢查 Aurora 叢集和執行個體的執行時間
您可以檢查並監控 Aurora 叢集中自每個資料庫執行個體自上次重新啟動以來的時間長度。Amazon 指 CloudWatch 標會EngineUptime
報告自上次啟動資料庫執行個體以來的秒數。您可以在某個時間點檢查此指標,以找出資料庫執行個體的執行時間。您也可以隨時間監控此指標,以偵測何時重新啟動執行個體。
您也可以在叢集層級檢查 EngineUptime
指標。Minimum
和 Maximum
維度會報告叢集中所有資料庫執行個體的最小和最大執行時間值。若要檢查叢集中任何讀取器執行個體重新啟動或因其他原因而重新啟動的最近時間,請使用 Minimum
維度監控叢集層級指標。若要檢查叢集中的哪個執行個體在不重新啟動的情況下工作了最長時間,請使用 Maximum
維度監控叢集層級指標。例如,您可能想要確認叢集中的所有資料庫執行個體在組態變更後重新啟動。
提示
針對長期監控,我們建議您監控個別執行個體的 EngineUptime
指標,而不是在叢集層級監控。將新的資料庫執行個體新增至叢集時,叢集層級 EngineUptime
指標會設為零。這類叢集變更可能會作為維護和擴展操作的一部分發生,例如由 Auto Scaling 執行的操作。
下列 CLI 範例顯示如何檢查叢集中寫入器和讀取器執行個體的 EngineUptime
指標。這些範例使用名為 tpch100g
的叢集。此叢集具有寫入器資料庫執行個體 instance-1234
。它還具有兩個讀取器資料庫執行個體 (instance-7448
和 instance-6305
)。
首先,reboot-db-instance
命令會重新啟動其中一個讀取器執行個體。wait
命令會一直等待執行個體完成重新啟動。
$ aws rds reboot-db-instance --db-instance-identifier instance-6305 { "DBInstance": { "DBInstanceIdentifier": "instance-6305", "DBInstanceStatus": "rebooting", ... $ aws rds wait db-instance-available --db-instance-id instance-6305
命 CloudWatch get-metric-statistics
令會以一分鐘的間隔檢查過去 5 分鐘的EngineUptime
量度。instance-6305
執行個體的執行時間會重設為零,並再次開始向上計數。這個 Linux AWS CLI 範例會使用$()
變數替換,將適當的時間戳記插入 CLI 指令中。它也會使用 Linux sort
命令,依據收集指標的時間排序輸出。該時間戳記值是輸出的每一行中的第三個欄位。
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \ --period 60 --namespace "AWS/RDS" --statistics Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \ | sort -k 3 EngineUptime DATAPOINTS 231.0 2021-03-16T18:19:00+00:00 Seconds DATAPOINTS 291.0 2021-03-16T18:20:00+00:00 Seconds DATAPOINTS 351.0 2021-03-16T18:21:00+00:00 Seconds DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds
叢集的最短執行時間會重設為零,因為叢集中的一個執行個體已重新啟動。叢集的執行時間上限不會重設,因為叢集中至少有一個資料庫執行個體仍然可用。
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \ --period 60 --namespace "AWS/RDS" --statistics Minimum \ --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \ | sort -k 3 EngineUptime DATAPOINTS 63099.0 2021-03-16T18:12:00+00:00 Seconds DATAPOINTS 63159.0 2021-03-16T18:13:00+00:00 Seconds DATAPOINTS 63219.0 2021-03-16T18:14:00+00:00 Seconds DATAPOINTS 63279.0 2021-03-16T18:15:00+00:00 Seconds DATAPOINTS 51.0 2021-03-16T18:16:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \ --period 60 --namespace "AWS/RDS" --statistics Maximum \ --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \ | sort -k 3 EngineUptime DATAPOINTS 63389.0 2021-03-16T18:16:00+00:00 Seconds DATAPOINTS 63449.0 2021-03-16T18:17:00+00:00 Seconds DATAPOINTS 63509.0 2021-03-16T18:18:00+00:00 Seconds DATAPOINTS 63569.0 2021-03-16T18:19:00+00:00 Seconds DATAPOINTS 63629.0 2021-03-16T18:20:00+00:00 Seconds
然後另一個 reboot-db-instance
命令會重新啟動叢集的寫入器執行個體。另一個 wait
命令會暫停,直到寫入器執行個體完成重新啟動為止。
$ aws rds reboot-db-instance --db-instance-identifier instance-1234 { "DBInstanceIdentifier": "instance-1234", "DBInstanceStatus": "rebooting", ... $ aws rds wait db-instance-available --db-instance-id instance-1234
現在,寫入器執行個體的 EngineUptime
指標顯示最近已重新啟動執行個體 instance-1234
。讀取器執行個體 instance-6305
也隨著寫入器執行個體自動重新啟動。這個叢集正在執行 Aurora MySQL 2.09,這不會讓讀取器執行個體在寫入器執行個體重新開機時執行。
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \ --period 60 --namespace "AWS/RDS" --statistics Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-1234 --output text \ | sort -k 3 EngineUptime DATAPOINTS 63749.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 63809.0 2021-03-16T18:23:00+00:00 Seconds DATAPOINTS 63869.0 2021-03-16T18:24:00+00:00 Seconds DATAPOINTS 41.0 2021-03-16T18:25:00+00:00 Seconds DATAPOINTS 101.0 2021-03-16T18:26:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \ --period 60 --namespace "AWS/RDS" --statistics Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \ | sort -k 3 EngineUptime DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds DATAPOINTS 531.0 2021-03-16T18:24:00+00:00 Seconds DATAPOINTS 49.0 2021-03-16T18:26:00+00:00 Seconds
Aurora 重新啟動操作的範例
下列 Aurora MySQL 範例顯示 Aurora 資料庫叢集中讀取器和寫入器資料庫執行個體的重新啟動操作的不同組合。每次重新啟動之後,SQL 查詢會展示叢集中執行個體的執行時間。
尋找 Aurora 叢集的寫入器和讀取器執行個體
在具有多個資料庫執行個體的 Aurora MySQL 叢集中,需要知道哪個是寫入器、哪些是讀取器。寫入器和讀取器執行個體也可以在發生容錯移轉操作時切換角色。因此,在執行任何需要寫入器或讀取器執行個體的操作之前,最好執行如下所示的檢查。在這種情況下,False
的 IsClusterWriter
值識別讀取器執行個體 (instance-6305
和 instance-7448
)。True
值識別寫入器執行個體 instance-1234
。
$ aws rds describe-db-clusters --db-cluster-id tpch100g \ --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \ --output text Cluster: tpch100g Instance: instance-6305 False Instance: instance-7448 False Instance: instance-1234 True
在開始重新啟動的範例之前,寫入器執行個體擁有大約一週的執行時間。這個範例中的 SQL 查詢顯示了檢查執行時間的 MySQL 特定方式。您可以在資料庫應用程式中使用這種技術。如需使用 AWS CLI 和適用於兩個 Aurora 引擎的其他技術,請參閱檢查 Aurora 叢集和執行個體的執行時間。
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u
my-user
-p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status -> where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-08 17:49:06.000000 | 174h 42m| +----------------------------+---------+
重新啟動單一讀取器執行個體
此範例會重新啟動一個讀取器資料庫執行個體。這個執行個體或許因一個巨大的查詢或許多並行連線而過載。其也可能因為網絡問題而落後於寫入器執行個體。開始重新啟動操作之後,範例會使用 wait
命令暫停,直到執行個體變成可用為止。此時,執行個體的執行時間為幾分鐘。
$ aws rds reboot-db-instance --db-instance-identifier instance-6305 { "DBInstance": { "DBInstanceIdentifier": "instance-6305", "DBInstanceStatus": "rebooting", ... } } $ aws rds wait db-instance-available --db-instance-id instance-6305 $ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u
my-user
-p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status -> where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:35:02.000000 | 00h 03m | +----------------------------+---------+
重新啟動讀取器執行個體並不會影響寫入器執行個體的執行時間。它仍然有大約一個星期的執行時間。
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u
my-user
-p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+----------+ | Last Startup | Uptime | +----------------------------+----------+ | 2021-03-08 17:49:06.000000 | 174h 49m | +----------------------------+----------+
重新啟動寫入器執行個體
此範例會重新啟動寫入器執行個體。此叢集正在執行 Aurora MySQL 版本 2.09。因為 Aurora MySQL 版本低於 2.10,重新啟動寫入器執行個體也會重新啟動叢集中的任何讀取器執行個體。
wait
命令會暫停,直到重新啟動完成為止。現在該執行個體的執行時間會重設為零。對於寫入器和讀取器資料庫執行個體,重新啟動操作所用的時間可能大不相同。寫入器和讀取器資料庫執行個體會根據其角色執行不同種類的清理操作。
$ aws rds reboot-db-instance --db-instance-identifier instance-1234 { "DBInstance": { "DBInstanceIdentifier": "instance-1234", "DBInstanceStatus": "rebooting", ... } } $ aws rds wait db-instance-available --db-instance-id instance-1234 $ mysql -h instance-1234.a12345.us-east-1.rds.amazonaws.com -P 3306 -u
my-user
-p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:40:27.000000 | 00h 00m | +----------------------------+---------+
在寫入器資料庫執行個體重新啟動之後,兩個讀取器資料庫執行個體也會重設其執行時間。重新啟動寫入器執行個體也會導致讀取器執行個體重新啟動。這種行為適用於 Aurora PostgreSQL 叢集和 2.10 版本之前的 Aurora MySQL 叢集。
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u
my-user
-p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:40:35.000000 | 00h 00m | +----------------------------+---------+ $ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -umy-user
-p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:40:33.000000 | 00h 01m | +----------------------------+---------+
單獨重新啟動寫入器和讀取器
下列範例顯示執行 2.10 Aurora MySQL 版的叢集。在此 Aurora MySQL 版本及更高版本中,您可以重新啟動寫入器執行個體,而不會造成所有讀取器執行個體的重新啟動。如此一來,當您重新啟動寫入器執行個體時,查詢密集型應用程式就不會遇到任何中斷。您可以稍後重新啟動讀取器執行個體。您可以在查詢流量較低時執行這些重新啟動。您也可以一次重新啟動一個讀取器執行個體。如此,至少一個讀取器執行個體永遠可用於您的應用程式的查詢流量。
下列範例使用名為 cluster-2393
且執行 Aurora MySQL 版本 5.7.mysql_aurora.2.10.0
的叢集。這個叢集有一個名為 instance-9404
的寫入器執行個體,以及三個名為 instance-6772
、instance-2470
和 instance-5138
的讀取器執行個體。
$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \ --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \ --output text Cluster: cluster-2393 Instance: instance-5138 False Instance: instance-2470 False Instance: instance-6772 False Instance: instance-9404 True
使用 uptime
命令檢查每個資料庫執行個體的 mysql
值,會發現每個資料庫執行個體的執行時間大致相同。例如,這裡是 instance-5138
的執行時間。
mysql> SHOW GLOBAL STATUS LIKE 'uptime'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Uptime | 3866 | +---------------+-------+
通過使用 CloudWatch,我們可以獲得相應的正常運行時間信息,而無需實際登錄實例。如此一來,管理員就可以監控資料庫,但無法檢視或變更任何資料表資料。在這種情況下,我們指定跨越五分鐘的時間間隔,並每分鐘檢查執行時間值。不斷增加的執行時間值表明,該期間內未重新啟動執行個體。
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \ --output text | sort -k 3 EngineUptime DATAPOINTS 4648.0 2021-03-17T23:42:00+00:00 Seconds DATAPOINTS 4708.0 2021-03-17T23:43:00+00:00 Seconds DATAPOINTS 4768.0 2021-03-17T23:44:00+00:00 Seconds DATAPOINTS 4828.0 2021-03-17T23:45:00+00:00 Seconds DATAPOINTS 4888.0 2021-03-17T23:46:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \ --output text | sort -k 3 EngineUptime DATAPOINTS 4315.0 2021-03-17T23:42:00+00:00 Seconds DATAPOINTS 4375.0 2021-03-17T23:43:00+00:00 Seconds DATAPOINTS 4435.0 2021-03-17T23:44:00+00:00 Seconds DATAPOINTS 4495.0 2021-03-17T23:45:00+00:00 Seconds DATAPOINTS 4555.0 2021-03-17T23:46:00+00:00 Seconds
現在,我們重新啟動其中一個讀取器執行個體 instance-5138
。我們會等待執行個體在重新啟動後再次變成可用。現在,監控五分鐘間隔的執行時間顯示,執行時間在這段時間內重設為零。最近的執行時間值是在重新啟動完成後的五秒鐘測量。
$ aws rds reboot-db-instance --db-instance-identifier instance-5138 { "DBInstanceIdentifier": "instance-5138", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-5138 $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \ --output text | sort -k 3 EngineUptime DATAPOINTS 4500.0 2021-03-17T23:46:00+00:00 Seconds DATAPOINTS 4560.0 2021-03-17T23:47:00+00:00 Seconds DATAPOINTS 4620.0 2021-03-17T23:48:00+00:00 Seconds DATAPOINTS 4680.0 2021-03-17T23:49:00+00:00 Seconds DATAPOINTS 5.0 2021-03-17T23:50:00+00:00 Seconds
接下來,我們為寫入器執行個體 instance-9404
執行重新啟動。我們會比較寫入器執行個體和其中一個讀取器執行個體的執行時間值。如此,我們可以看到重新啟寫入器並未導致讀取器重新啟動。在 Aurora MySQL 2.10 之前的版本中,所有讀取器的執行時間值將和寫入器在同一時間重設。
$ aws rds reboot-db-instance --db-instance-identifier instance-9404 { "DBInstanceIdentifier": "instance-9404", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-9404 $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \ --output text | sort -k 3 EngineUptime DATAPOINTS 371.0 2021-03-17T23:57:00+00:00 Seconds DATAPOINTS 431.0 2021-03-17T23:58:00+00:00 Seconds DATAPOINTS 491.0 2021-03-17T23:59:00+00:00 Seconds DATAPOINTS 551.0 2021-03-18T00:00:00+00:00 Seconds DATAPOINTS 37.0 2021-03-18T00:01:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \ --output text | sort -k 3 EngineUptime DATAPOINTS 5215.0 2021-03-17T23:57:00+00:00 Seconds DATAPOINTS 5275.0 2021-03-17T23:58:00+00:00 Seconds DATAPOINTS 5335.0 2021-03-17T23:59:00+00:00 Seconds DATAPOINTS 5395.0 2021-03-18T00:00:00+00:00 Seconds DATAPOINTS 5455.0 2021-03-18T00:01:00+00:00 Seconds
若要確定所有的讀取器執行個體具有與寫入器執行個體相同的組態參數變更,請在寫入器之後重新啟動所有讀取器執行個體。這個範例會重新啟動所有讀取器,然後等到所有讀取器都可以使用後再繼續。
$ aws rds reboot-db-instance --db-instance-identifier instance-6772 { "DBInstanceIdentifier": "instance-6772", "DBInstanceStatus": "rebooting" } $ aws rds reboot-db-instance --db-instance-identifier instance-2470 { "DBInstanceIdentifier": "instance-2470", "DBInstanceStatus": "rebooting" } $ aws rds reboot-db-instance --db-instance-identifier instance-5138 { "DBInstanceIdentifier": "instance-5138", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-6772 $ aws rds wait db-instance-available --db-instance-id instance-2470 $ aws rds wait db-instance-available --db-instance-id instance-5138
現在我們可以看到,寫入器資料庫執行個體具有最高的執行時間。此執行個體的執行時間值在整個監控期間穩定增加。讀取器資料庫執行個體都在讀取器之後重新啟動。我們可以看到監控期間內重新啟動每個讀取器以及將其執行時間重設為零的時間點。
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \ --output text | sort -k 3 EngineUptime DATAPOINTS 457.0 2021-03-18T00:08:00+00:00 Seconds DATAPOINTS 517.0 2021-03-18T00:09:00+00:00 Seconds DATAPOINTS 577.0 2021-03-18T00:10:00+00:00 Seconds DATAPOINTS 637.0 2021-03-18T00:11:00+00:00 Seconds DATAPOINTS 697.0 2021-03-18T00:12:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-2470 \ --output text | sort -k 3 EngineUptime DATAPOINTS 5819.0 2021-03-18T00:08:00+00:00 Seconds DATAPOINTS 35.0 2021-03-18T00:09:00+00:00 Seconds DATAPOINTS 95.0 2021-03-18T00:10:00+00:00 Seconds DATAPOINTS 155.0 2021-03-18T00:11:00+00:00 Seconds DATAPOINTS 215.0 2021-03-18T00:12:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \ --output text | sort -k 3 EngineUptime DATAPOINTS 1085.0 2021-03-18T00:08:00+00:00 Seconds DATAPOINTS 1145.0 2021-03-18T00:09:00+00:00 Seconds DATAPOINTS 1205.0 2021-03-18T00:10:00+00:00 Seconds DATAPOINTS 49.0 2021-03-18T00:11:00+00:00 Seconds DATAPOINTS 109.0 2021-03-18T00:12:00+00:00 Seconds
將叢集參數變更套用至 Aurora MySQL 版本 2.10 叢集
下列範例會展示如何將參數變更套用至 Aurora MySQL 2.10 叢集中的所有資料庫執行個體。使用此 Aurora MySQL 版本,您可以單獨地重新啟動寫入器執行個體和所有讀取器執行個體。
此範例會使用 MySQL 組態參數 lower_case_table_names
進行說明。當寫入器和讀取器資料庫執行個體之間的這個參數設定不一致時,查詢可能無法存取以大寫或大小寫混合名稱宣告的資料表。或者,如果兩個資料表名稱僅在大寫和小寫字母方面不同,則查詢可能會存取錯誤的資料表。
此範例會展示如何透過檢查每個執行個體的 IsClusterWriter
屬性來判定叢集中的寫入器和讀取器執行個體。叢集已命名為 cluster-2393
。叢集具有名為 instance-9404
的寫入器執行個體。叢集中的讀取器執行個體名為 instance-5138
和 instance-2470
。
$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \ --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \ --output text cluster-2393 instance-5138 False instance-2470 False instance-9404 True
為了展示改變 lower_case_table_names
參數的影響,我們設定了兩個資料庫叢集參數群組。lower-case-table-names-0
參數群組將此參數設定為 0。lower-case-table-names-1
參數群組將此參數群組設定為 1。
$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-0' \ --db-parameter-group-family aurora-mysql5.7 \ --db-cluster-parameter-group-name lower-case-table-names-0 { "DBClusterParameterGroup": { "DBClusterParameterGroupName": "lower-case-table-names-0", "DBParameterGroupFamily": "aurora-mysql5.7", "Description": "lower-case-table-names-0" } } $ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-1' \ --db-parameter-group-family aurora-mysql5.7 \ --db-cluster-parameter-group-name lower-case-table-names-1 { "DBClusterParameterGroup": { "DBClusterParameterGroupName": "lower-case-table-names-1", "DBParameterGroupFamily": "aurora-mysql5.7", "Description": "lower-case-table-names-1" } } $ aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name lower-case-table-names-0 \ --parameters ParameterName=lower_case_table_names,ParameterValue=0,ApplyMethod=pending-reboot { "DBClusterParameterGroupName": "lower-case-table-names-0" } $ aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name lower-case-table-names-1 \ --parameters ParameterName=lower_case_table_names,ParameterValue=1,ApplyMethod=pending-reboot { "DBClusterParameterGroupName": "lower-case-table-names-1" }
lower_case_table_names
的預設值為 0。使用此參數設定時,資料表 foo
與表格 FOO
不同。此範例會驗證參數是否仍處於其預設設定。然後,此範例會建立三個資料表,它們的名稱僅存在大小寫差異。
mysql> create database lctn; Query OK, 1 row affected (0.07 sec) mysql> use lctn; Database changed mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 0 | +--------------------------+ mysql> create table foo (s varchar(128)); mysql> insert into foo values ('Lowercase table name foo'); mysql> create table Foo (s varchar(128)); mysql> insert into Foo values ('Mixed-case table name Foo'); mysql> create table FOO (s varchar(128)); mysql> insert into FOO values ('Uppercase table name FOO'); mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +---------------------------+ | s | +---------------------------+ | Mixed-case table name Foo | +---------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Uppercase table name FOO | +--------------------------+
接下來,我們將資料庫參數群組與叢集建立關聯,以將 lower_case_table_names
參數設定為 1。此變更只會在重新啟動每個資料庫執行個體後生效。
$ aws rds modify-db-cluster --db-cluster-identifier cluster-2393 \ --db-cluster-parameter-group-name lower-case-table-names-1 { "DBClusterIdentifier": "cluster-2393", "DBClusterParameterGroup": "lower-case-table-names-1", "Engine": "aurora-mysql", "EngineVersion": "5.7.mysql_aurora.2.10.0" }
我們首先為寫入器資料庫執行個體執行重新啟動。然後,我們等待執行個體再次變成可用。此時,我們會連線到寫入器端點,並確認寫入器執行個體具有變更的參數值。SHOW TABLES
命令確認資料庫包含三個不同的資料表。不過,參考名為 foo
Foo
、或 FOO
資料表的查詢皆存取名稱為全小寫的資料表 foo
。
# Rebooting the writer instance $ aws rds reboot-db-instance --db-instance-identifier instance-9404 $ aws rds wait db-instance-available --db-instance-id instance-9404
現在,使用叢集端點的查詢會顯示參數變更的影響。無論查詢中的資料表名稱是大寫、小寫或大小寫混合,SQL 陳述式能存取名稱為全小寫的資料表。
mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 1 | +--------------------------+ mysql> use lctn; mysql> show tables; +----------------+ | Tables_in_lctn | +----------------+ | FOO | | Foo | | foo | +----------------+ mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+
下一個範例顯示與前一個查詢相同的查詢。在此情況下,查詢會使用讀取器端點,並在其中一個讀取器資料庫執行個體上執行。這些執行個體尚未重新啟動。因此,它們仍然具有 lower_case_table_names
參數的原始設定。這表示查詢可以存取每個 foo
、Foo
和 FOO
資料表。
mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 0 | +--------------------------+ mysql> use lctn; mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +---------------------------+ | s | +---------------------------+ | Mixed-case table name Foo | +---------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Uppercase table name FOO | +--------------------------+
接下來,我們重新啟動其中一個讀取器執行個體,並等待它再次變成可用。
$ aws rds reboot-db-instance --db-instance-identifier instance-2470 { "DBInstanceIdentifier": "instance-2470", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-2470
連線到 instance-2470
的執行個體端點時,查詢會顯示新參數有效。
mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 1 | +--------------------------+
此時,叢集中的兩個讀取器執行個體會以不同的 lower_case_table_names
設定執行。因此,叢集的讀取器端點的任何連線都會使用這個無法預期的設定值。請務必立即重新啟動其他讀取器執行個體,以便兩者都具有一致的設定。
$ aws rds reboot-db-instance --db-instance-identifier instance-5138 { "DBInstanceIdentifier": "instance-5138", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-5138
下列範例會確認所有讀取器執行個體具有相同的 lower_case_table_names
參數設定。這些命令會檢查每個讀取器執行個體上的 lower_case_table_names
設定值。然後,使用讀取器端點的相同命令會展示每個與讀取器端點的連線都會使用其中一個讀取器執行個體,但哪一個是無法預測的。
# Check lower_case_table_names setting on each reader instance. $ mysql -h instance-5138.a12345.us-east-1.rds.amazonaws.com \ -u
my-user
-p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-5138 | 1 | +--------------------------+--------------------------+ $ mysql -h instance-2470.a12345.us-east-1.rds.amazonaws.com \ -umy-user
-p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-2470 | 1 | +--------------------------+--------------------------+ # Check lower_case_table_names setting on the reader endpoint of the cluster. $ mysql -h cluster-2393.cluster-ro-a12345.us-east-1.rds.amazonaws.com \ -umy-user
-p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-5138 | 1 | +--------------------------+--------------------------+ # Run query on writer instance $ mysql -h cluster-2393.cluster-a12345.us-east-1.rds.amazonaws.com \ -umy-user
-p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-9404 | 1 | +--------------------------+--------------------------+
隨著參數變更套用至所有位置,我們可以看到設定 lower_case_table_names=1
的效果。無論該資料表被稱為 foo
、Foo
或 FOO
,查詢都會將名稱轉換為 foo
,並在每種情況下存取相同的資料表。
mysql> use lctn; mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+