重新啟動 Amazon Aurora 資料庫叢集或 Amazon Aurora 資料庫執行個體 - Amazon Aurora
在 Aurora 叢集中重新啟動資料庫執行個體使用讀取可用性功能重新啟動 Aurora 叢集在無讀取可用性的情況下重新啟動 Aurora 叢集檢查 Aurora 叢集和執行個體的執行時間Aurora 重新啟動操作的範例

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

重新啟動 Amazon Aurora 資料庫叢集或 Amazon Aurora 資料庫執行個體

您可能需要重新啟動資料庫叢集或叢集中的某些執行個體，這通常是基於維護原因。例如，假設您修改參數群組內的參數，或將不同的參數群組與您的叢集建立關聯。在這些情況下，您必須重新啟動叢集，才能讓變更生效。同樣地，您可以在叢集中重新啟動一或多個讀取器資料庫執行個體。您可以安排個別執行個體的重新啟動操作，以將整個叢集的停機時間降到最低。

重新啟動叢集中每個資料庫執行個體所需的時間，取決於重新啟動時的資料庫活動。這也取決於您的特定資料庫引擎的復原流程。如果可行，請在開始重新啟動流程之前減少該特定執行個體上的資料庫活動。這樣做可以減少重新啟動資料庫所需的時間。

只有在叢集中的每個資料庫執行個體處於可用狀態時，您才能重新啟動每個資料庫執行個體。資料庫執行個體可能會因多種原因無法使用。其中包括叢集處於停止狀態、有修改套用至執行個體，以及存在維護時段動作，例如版本升級。

重新啟動資料庫執行個體，將重新啟動資料庫引擎流程。重新啟動資料庫執行個體會暫時中斷，在此期間，資料庫執行個體狀態設定為 rebooting (重新啟動中)。

注意

如果資料庫執行個體未使用其關聯資料庫參數群組的最新變更，則會 AWS Management Console 顯示資料庫參數群組的狀態為擱置重新開機。pending-reboot (等待重新啟動) 參數群組狀態不會在下一個維護時段期間造成自動重新啟動。如欲對該資料庫執行個體套用最新參數變更，請手動重新啟動資料庫執行個體。如需參數群組的詳細資訊，請參閱使用參數群組。

在 Aurora 叢集中重新啟動資料庫執行個體

此程序是您在使用 Aurora 執行重新啟動時的最重要操作。許多維護程序涉及以特定順序重新啟動一或多個 Aurora 資料庫執行個體。

重新啟動資料庫執行個體

  1. 登入 AWS Management Console 並開啟 Amazon RDS 主控台，網址為 https://console.aws.amazon.com/rds/。

  2. 在導覽窗格中選擇 Databases (資料庫)，然後選擇您要重新啟動的資料庫執行個體。

  3. 針對 Actions (動作)，選擇 Reboot (重新啟動)。

    Reboot DB Instance (重新啟動資料庫執行個體) 頁面隨即出現。

  4. 選擇 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 -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: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 \
  -u my-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 \
  -u my-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 \
  -u my-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 |
+--------------------------+