Aurora 我的SQL就地升級教程 - Amazon Aurora
尋找升級失敗的原因Aurora 疑難排解我的SQL就地升級Aurora 的升級後清理我的SQL版本 3

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

Aurora 我的SQL就地升級教程

下列 Linux 範例顯示如何使用 AWS CLI來執行就地升級程序的一般步驟。

第一個範例會建立執行 2.x 版本的 Aurora MySQL. 叢集包含寫入器資料庫執行個體和讀取器資料庫執行個體。wait db-instance-available 命令會暫停，直至寫入器資料庫執行個體可供使用為止。這正是叢集準備好升級之時。

aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
  --db-cluster-version 5.7.mysql_aurora.2.10.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
  --db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1

您可以升級叢集的 Aurora My SQL 3.x 版本，以取決於叢集目前執行的 2.x 版本以及叢集所 AWS 區域 在的位置。使用第一個命令 --output text，只是顯示可用的目標版本。第二個命令顯示響應的完整JSON輸出。在該回應中，您可以查看詳細資訊，例如用於 engine 參數的 aurora-mysql 值。您還可以查看升級至 3.02.0 代表主要版本升級的事實。

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2

aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --query '*[].[ValidUpgradeTarget]'
...
{
    "Engine": "aurora-mysql",
    "EngineVersion": "8.0.mysql_aurora.3.02.0",
    "Description": "Aurora MySQL 3.02.0 (compatible with MySQL 8.0.23)",
    "AutoUpgrade": false,
    "IsMajorVersionUpgrade": true,
    "SupportedEngineModes": [
        "provisioned"
    ],
    "SupportsParallelQuery": true,
    "SupportsGlobalDatabases": true,
    "SupportsBabelfish": false
},
...

此範例說明，如果您輸入的目標版本編號不是叢集的有效升級目標，Aurora 不會執行升級。Aurora 也不會執行主要版本升級，除非您包含 --allow-major-version-upgrade 參數。如此一來，您就不會意外執行可能需要對應用程式的程式碼進行大量測試和變更的升級。

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.10.2 with requested version 5.7.mysql_aurora.2.09.2.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --apply-immediately --allow-major-version-upgrade
{
  "DBClusterIdentifier": "mynewdbcluster",
  "Status": "available",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.2"
}

叢集和相關資料庫執行個體的狀態需要一段時間才能變更為 upgrading。叢集和資料庫執行個體的版本編號只有在升級完成時才會變更。同樣，您可以使用寫入器資料庫執行個體的 wait db-instance-available 命令，等到升級完成後再繼續進行。

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.10.2

aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
  --query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
    "DBInstanceIdentifier": "mynewdbcluster-instance1",
    "DBInstanceStatus": "upgrading"
}

aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1

此時，叢集的版本編號符合針對升級指定的版本編號。

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].[EngineVersion]' --output text

8.0.mysql_aurora.3.02.0

上述範例透過指定 --apply-immediately 參數立即執行升級。若要讓升級在方便的時間，當叢集不忙碌時發生，您可以指定 --no-apply-immediately 參數。這樣做會在叢集的下一個維護時段期間啟動升級。維護時段會定義維護操作可以開始的期間。長時間執行的操作可能無法在維護時段完成。因此，即使您預期升級可能需要很長時間，也不需要定義較大的維護時段。

下列範例會升級最初執行 Aurora My SQL 版本 2.10.2 的叢集。在 describe-db-engine-versions 輸出中，False 和 True 值表示 IsMajorVersionUpgrade 屬性。從 2.10.2 版開始，您可以升級至其他 2.* 版本。這些升級不會視為主要版本升級，因此不需要就地升級。就地升級僅適用於升級至清單中顯示的 3.* 版。

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2

aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text

5.7.mysql_aurora.2.10.3 False
5.7.mysql_aurora.2.11.0 False
5.7.mysql_aurora.2.11.1 False
8.0.mysql_aurora.3.01.1 True
8.0.mysql_aurora.3.02.0 True
8.0.mysql_aurora.3.02.2 True


aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --no-apply-immediately --allow-major-version-upgrade
...

在沒有指定維護時段的情況下建立叢集時，Aurora 會隨機挑選一週中的一天。在這種情況下，modify-db-cluster 命令會在週一提交。因此，我們將維護時段變更為週二上午。所有時間均以UTC時區表示。tue:10:00-tue:10:30 時段對應於太平洋時間上午 2:00-2:30。維護時段中的變更會立即生效。

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "sat:08:20-sat:08:50"
    ]
]

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "tue:10:00-tue:10:30"
    ]
]

下列範例顯示如何取得升級產生事件的報告。--duration 引數代表擷取事件資訊的分鐘數。此引數是必要的，因為依預設describe-events只會傳回最後一小時的事件。

aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
    "Events": [
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "DB cluster created",
            "EventCategories": [
                "creation"
            ],
            "Date": "2022-11-17T01:24:11.093000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing online pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T22:57:08.450000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T22:57:59.519000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:00:22.318000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Cloning volume.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:01:45.428000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:02:25.141000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:06:23.036000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Upgrading database objects.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:06:48.208000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster major version has been upgraded",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:10:28.999000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        }
    ]
}

尋找升級失敗的原因

在上一個教程中，從 Aurora 我的SQL版本 2 升級到版本 3 成功。但是，如果升級失敗，您會想知道為什麼。

您可以通過使用命describe-events AWS CLI 令來查看數據庫集群事件開始。此範例顯示過去 10 小時的事件。mydbcluster

aws rds describe-events \
    --source-type db-cluster \
    --source-identifier mydbcluster \
    --duration 600

在這種情況下，我們有升級預先檢查失敗。

{
    "Events": [
        {
            "SourceIdentifier": "mydbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster engine version upgrade started.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2024-04-11T13:23:22.846000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
        },
        {
            "SourceIdentifier": "mydbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the  
             upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see 
             https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Troubleshooting.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2024-04-11T13:23:24.373000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
        }
    ]
}

若要診斷問題的確切原因，請檢查寫入器資料庫執行個體的資料庫記錄。當 Aurora 的SQL升級失敗時，寫入器執行個體會包含名稱為的記錄檔upgrade-prechecks.log。此範例說明如何偵測該日誌是否存在，然後將其下載為本機檔案進行檢查。

aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
    --query '*[].[LogFileName]' --output text

error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log

aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
    --log-file-name upgrade-prechecks.log \
    --starting-token 0 \
    --output text >upgrade_prechecks.log

檔upgrade-prechecks.log案為格JSON式。我們使用該--output text選項下載它，以避免在另一個JSON包裝中編碼JSON輸出。對於 Aurora 我的SQL版本 3 升級，此日誌始終包含某些信息和警告消息。它只會在升級失敗時包含錯誤訊息。如果升級成功，則根本不會產生日誌檔案。

若要摘要所有錯誤並顯示相關聯的物件和描述欄位，您可以對upgrade-prechecks.log檔案的內容執行指令grep -A 2 '"level": "Error"'。這麼做會顯示每個錯誤行及其後兩行。其中包含對應資料庫物件的名稱，以及如何修正問題的指引。

$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'

"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."

在此範例中，您可以在有問題的資料表上執行下列SQL命令來嘗試修正問題，或者您可以重新建立沒有懸置索引的資料表。

OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;

然後重試升級。

Aurora 疑難排解我的SQL就地升級

使用下列提示可協助疑難排解 Aurora My SQL 就地升級的問題。這些提示不適用於 Aurora Serverless 資料庫叢集。

就地升級被取消或緩慢的原因 Effect 允許在維護時段完成就地升級的解決方案
尚未修補關聯的 Aurora 跨區域複本 Aurora 會取消升級。 升級 Aurora 跨區域複本，然後再試一次。
叢集的 XA 交易處於準備狀態 Aurora 會取消升級。 遞交或復原所有準備好的 XA 交易。
群集正在處理任何數據定義語言（DDL）語句 Aurora 會取消升級。 在所有DDL陳述式完成之後，請考慮等待並執行升級。
叢集中的多行有未遞交的變更 升級可能需要很長時間。

升級程序會復原未遞交的變更。此條件的指標為 TRX_ROWS_MODIFIED 資料表 INFORMATION_SCHEMA.INNODB_TRX 中的值。

僅在遞交或復原所有大型交易之後，才考慮執行升級。
叢集具有大量的復原記錄 升級可能需要很長時間。

即使未遞交的交易不會影響大量的資料列，也可能會涉及大量資料。例如，您插入的可能很大BLOBs。Aurora 不會自動偵測或產生這種交易活動的事件。此條件的指標是歷史記錄列表長度（HLL）。升級程序會復原未遞交的變更。

您可以從SHOW ENGINE INNODB STATUSSQL命令HLL中檢查輸出，或直接使用以下SQL查詢：

SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

您還可以在 Amazon 中監視RollbackSegmentHistoryListLength指標 CloudWatch。

請考慮只在較小之後HLL執行升級。
叢集正在遞交大型二進位日誌交易 升級可能需要很長時間。

升級程序會等到套用二進位日誌變更之後。在此期間可能會啟動更多交易或DDL陳述式，進一步降低升級程序的速度。

在叢集不忙於產生二進位日誌複寫變更時排程升級程序。Aurora 不會自動偵測或產生此條件的事件。
因檔案移除或損毀所導致的結構描述不一致 Aurora 會取消升級。

將臨時表的默認存儲引擎從我的更改ISAM為 InnoDB。執行以下步驟：

  1. 將 default_tmp_storage_engine 資料庫參數修改為 InnoDB。

  2. 重新啟動資料庫叢集。

  3. 重新啟動後，請確認 default_tmp_storage_engine 資料庫參數已設定為 InnoDB。使用下列命令：

    show global variables like 'default_tmp_storage_engine';

  4. 請確定不要建立任何使用我的ISAM儲存引擎的暫存資料表。我們建議您暫停任何資料庫工作負載，且勿建立任何新的資料庫連線，因為即將進行升級。

  5. 請再次嘗試就地升級。
主要使用者已刪除 Aurora 會取消升級。
重要

請勿刪除主要使用者。

但是，如果由於某種原因，您應該碰巧刪除主用戶，請使用以下SQL命令將其還原：

CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, 
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, 
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;

如需疑難排解造成升級預先檢查失敗的問題的詳細資訊，請參閱下列部落格：

您可以使用下列步驟，對以上資料表中的某些條件執行自己的檢查。如此一來，在您知道資料庫處於升級可以順利且快速完成的狀態時，即可排程升級。

  • 您可以執行 XA RECOVER 陳述式，來檢查開啟的 XA 交易。您隨後可以遞交或復原 XA 交易，再開始升級。

  • 您可以執行DDL陳述式並在輸出中尋找CREATE、、DROPALTERRENAME、和TRUNCATE陳述式來檢查陳述式。SHOW PROCESSLIST在開始升級之前，允許所有DDL陳述式完成。

  • 您可以查詢 INFORMATION_SCHEMA.INNODB_TRX 資料表，檢查未遞交列的總數。該資料表包含每項交易的一個資料列。TRX_ROWS_MODIFIED 資料欄包含交易修改或插入的列數。

  • 您可以執行 SHOW ENGINE INNODB STATUS SQL 陳述式，然後在輸出中尋找 History list length，來檢查 InnoDB 歷史記錄清單的長度。您還可以直接執行下列查詢來檢查值：

    SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

    歷史記錄列表的長度對應於數據庫存儲的還原信息量來實現多版本並發控制（）MVCC。

Aurora 的升級後清理我的SQL版本 3

將任何 Aurora 我的SQL版本 2 叢集升級至 Aurora 我的SQL版本 3 後，您可以執行下列其他清理動作：

  • 建立任何自訂參數SQL群組的新 My 8.0 相容版本。將任何必要的自訂參數值套用至新的參數群組。

  • 更新任何 CloudWatch 警示、設定指令碼等，以針對名稱受到包含性語言變更影響的任何量度使用新名稱。如需這類指標的清單，請參閱 Aurora 的包容性語言更改我的SQL版本 3。

  • 更新任何 AWS CloudFormation 範本，以針對名稱受到包容性語言變更影響的任何組態參數使用新名稱。如需這類參數的清單，請參閱 Aurora 的包容性語言更改我的SQL版本 3。

空間索引

升級至 Aurora My SQL 版本 3 之後，請檢查是否需要卸除或重新建立與空間索引相關的物件和索引。在 My SQL 8.0 之前，Aurora 可以使用不包含空間資源識別碼 (SRID) 的索引來最佳化空間查詢。Aurora 我的SQL版本 3 只使用空間索引包含SRIDs. 在升級期間，Aurora 會自動捨棄任何空間索引，SRIDs而不會在資料庫記錄檔中列印警告訊息。如果您發現此類警告訊息，請在升級SRIDs後使用建立新的空間索引。有關 My SQL 8.0 中空間函數和數據類型的更改的更多信息，請參閱我的SQL參考手冊中的 My SQL 8.0 中的更改。