engine=innodb, algorithm=copy;
```
在下列各節中，設定複寫、停止複寫、擴展資料庫的讀取、最佳化 binlog 複寫，以及設定增強型 binlog。
**Topics**
+ [設定 Aurora MySQL 的二進位日誌複寫](AuroraMySQL.Replication.MySQL.SettingUp.md)
+ [停止 Aurora MySQL 的二進位日誌複寫](AuroraMySQL.Replication.MySQL.Stopping.md)
+ [使用 Amazon Aurora 為 MySQL 資料庫擴展讀取](AuroraMySQL.Replication.ReadScaling.md)
+ [最佳化 Aurora MySQL 的二進位日誌複寫](binlog-optimization.md)
+ [設定 Aurora MySQL 的增強型 binlog](AuroraMySQL.Enhanced.binlog.md)
# 設定 Aurora MySQL 的二進位日誌複寫
使用 Aurora MySQL 設定 MySQL 複寫涉及下列詳細討論的步驟：
**Contents**
+ [1. 在複寫來源上開啟二進位日誌](#AuroraMySQL.Replication.MySQL.EnableBinlog)
+ [2. 在複寫來源上保留二進位日誌，直到不再需要為止](#AuroraMySQL.Replication.MySQL.RetainBinlogs)
+ [3. 建立複寫來源的複製或傾印](#AuroraMySQL.Replication.MySQL.CreateSnapshot)
+ [4. 將傾印載入複本目標 (如有需要)](#AuroraMySQL.Replication.MySQL.LoadSnapshot)
+ [5. 在複製來源上建立複寫使用者](#AuroraMySQL.Replication.MySQL.CreateReplUser)
+ [6. 在複本目標上開啟複寫](#AuroraMySQL.Replication.MySQL.EnableReplication)
+ [設定位置以停止僅供讀取複本的複寫作業](#AuroraMySQL.Replication.StartReplicationUntil)
+ [7. 監控複本](#AuroraMySQL.Replication.MySQL.Monitor)
+ [同步複寫來源和目標之間的密碼](#AuroraMySQL.Replication.passwords)
## 1. 在複寫來源上開啟二進位日誌
在以下尋找如何在資料庫引擎的複寫來源上開啟二進位日誌的相關指示。
| 資料庫引擎 | 指示 |
| --- | --- |
| Aurora MySQL | **在 Aurora MySQL 資料庫叢集上開啟二進位日誌** 建議將 `binlog_format` 資料庫叢集參數設為 `ROW`、`STATEMENT` 或 `MIXED`. `MIXED`，除非您需要特定的 binlog 格式。(預設值為 `OFF`。) 若要變更 `binlog_format` 參數，請建立自訂資料庫叢集參數群組，並將該自訂參數群組與您的資料庫叢集建立關聯。您無法變更預設資料庫叢集參數群組中的參數。 如果您要將 `binlog_format` 參數從 `OFF` 變更為另一個值，請將 Aurora 資料庫叢集重新開機，變更才能生效。 如需詳細資訊，請參閱[Amazon Aurora 資料庫叢集和資料庫執行個體參數](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups)及[Amazon Aurora 的參數群組](USER_WorkingWithParamGroups.md)。 |
| RDS for MySQL | **在 Amazon RDS 資料庫執行個體上開啟二進位日誌** 您不可以直接為 Amazon RDS 資料庫執行個體開啟二進位日誌，但您可以透過以下其中一個方式開啟它： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (外部) | **設定加密複寫** 若要使用 Aurora MySQL 第 2 版安全地複寫資料，您可以使用加密複寫。 如果您不需要使用加密複寫，可以略過這些步驟。 下列是使用加密複寫的先決條件： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) 在加密複寫期間，Aurora MySQL 資料庫叢集充當 MySQL 資料庫伺服器的用戶端。Aurora MySQL 用戶端的憑證和金鑰位於 .pem 格式的檔案中。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **在外部 MySQL 資料庫上開啟二進位日誌** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 2. 在複寫來源上保留二進位日誌，直到不再需要為止
使用 MySQL 二進位日誌複寫時，Amazon RDS 不會管理複寫程序。因此，您需要確保會保留複寫來源上的 binlog 檔案，直到變更已套用至複本後為止。此維護可協助您在發生故障時將您的來源資料庫還原。
使用以下保留資料庫引擎二進位日誌的相關指示。
| 資料庫引擎 | 指示 |
| --- | --- |
| Aurora MySQL | **在 Aurora MySQL 資料庫叢集上保留二進位日誌** 您無法存取 Aurora MySQL 資料庫叢集的 binlog 檔案。因此，您必須選擇要在複寫來源上保留 binlog 檔案的足夠時間範圍，以確保在 Amazon RDS 刪除 binlog 檔案之前，變更已套用至複本。您可以在 Aurora MySQL 資料庫叢集上保留 binlog 檔案最多 90 天。 如果您要將使用 MySQL 資料庫或 RDS for MySQL 資料庫執行個體的複寫設定為複本，並且要為其建立複本的資料庫非常大，請選擇較大的時間範圍來保留二進位日誌檔案，直到要複寫資料庫的初始複製完成，且複本延遲已到達 0 為止。 若要設定二進位日誌保留時間範圍，請使用 [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) 程序，並指定 `'binlog retention hours'`組態參數加上資料庫叢集上保留 binlog 檔案的時數。Aurora MySQL 2.11.0 版和更新版本以及第 3 版的最大值是 2160 (90 天)。 下列範例會將 binlog 檔案的保留期間設定為 6 天： CALL mysql.rds_set_configuration('binlog retention hours', 144); 複寫開始之後，您可以在複本上執行 `SHOW SLAVE STATUS` (Aurora MySQL 第 2 版) 或 `SHOW REPLICA STATUS` (Aurora MySQ 第 3 版) 命令並檢查 `Seconds behind master` 欄位，來確認變更已套用至複本。如果 `Seconds behind master` 欄位為 0，則沒有複本延遲。沒有複本延遲時，請減少保留 binlog 檔案的時間長度，方法是將 `binlog retention hours` 組態參數設定為較小的時間範圍。 如果未指定此設定，Aurora MySQL 的預設值為 24 (1 天)。 如果您指定 `'binlog retention hours'` 的值大於最大值，則 Aurora MySQL 會使用最大值。 |
| RDS for MySQL | **在 Amazon RDS 資料庫執行個體上保留二進位日誌** 您可以在 Amazon RDS 資料庫執行個體上保留二進位日誌檔案，方法是如同 Aurora MySQL 資料庫叢集一般設定 binlog 保留時數，如前一列中所述。 您也可以透過為資料庫執行個體建立僅供讀取複本，在 Amazon RDS 資料庫執行個體上保留 binlog 檔案。這個僅供讀取複本是暫時性的，並專為保留 binlog 檔案目的使用。建立了僅供讀取複本之後，請在僅供讀取複本上呼叫 [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) 預存程序。複寫停用時，Amazon RDS 不會刪除複寫來源上的任何 binlog 檔案。設定使用永久複本的複寫之後，當複寫來源與永久複本之間的複本延遲 (`Seconds behind master` 欄位) 到達 0 時，您可以刪除僅供讀取複本。 |
| MySQL (外部) | **在外部 MySQL 資料庫上保留二進位日誌** 因為外部 MySQL 資料庫上的 binlog 檔案不是由 Amazon RDS 管理，系統會保留這些檔案直到您刪除它們為止。 複寫開始之後，您可以在複本上執行 `SHOW SLAVE STATUS` (Aurora MySQL 第 2 版) 或 `SHOW REPLICA STATUS` (Aurora MySQ 第 3 版) 命令並檢查 `Seconds behind master` 欄位，來確認變更已套用至複本。如果 `Seconds behind master` 欄位為 0，則沒有複本延遲。沒有複本延遲時，您可以刪除舊的 binlog 檔案。 |
## 3. 建立複寫來源的複製或傾印
您可以使用複寫來源的快照、複製或傾印，將資料的基準複製載入到複本上。然後，您會從該點開始複寫。
使用以下為資料庫引擎建立複寫來源複製或傾印的相關指示。
| 資料庫引擎 | 指示 |
| --- | --- |
| Aurora MySQL | **建立 Aurora MySQL 資料庫叢集的複製** 使用下列其中一種方法： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **判斷 binlog 檔案名稱和位置** 使用下列其中一種方法： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **建立 Aurora MySQL 資料庫叢集的傾印** 如果您的複本目標是外部 MySQL 資料庫或 RDS for MySQL 資料庫執行個體，則必須從 Aurora 資料庫叢集建立傾印檔案。 請確保對您所建立來源資料庫叢集的複本執行 `mysqldump` 命令。這是為了避免在建立傾印時的鎖定考量。如果直接在來源資料庫叢集上取得傾印，則需要鎖定來源資料表，以防止傾印進行時同時寫入它們。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **建立 Amazon RDS 資料庫執行個體的快照** 建立 Amazon RDS 資料庫執行個體的僅供讀取複本。如需詳細資訊，請參閱《Amazon Relational Database Service 使用者指南》**中的[建立僅供讀取複本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create)。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (外部) | **建立外部 MySQL 資料庫的快照或傾印** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 4. 將傾印載入複本目標 (如有需要)
如果您計劃從位於 Amazon RDS 外部的 MySQL 資料庫傾印載入資料，那麼，您可能需要建立供複製傾印檔案的 EC2 執行個體。然後，您可以從該 EC2 執行個體將資料載入資料庫叢集或資料庫執行個體。使用此方法，您可以在將傾印檔案複製到 EC2 執行個體之前加以壓縮，以便減少與複製資料至 Amazon RDS 相關聯的網路成本。您也可以加密一或多個傾印檔案，以於網路間傳輸資料時加以保護。
**注意**
如果您建立新的 Aurora MySQL 資料庫叢集作為複本目標，則不需要載入傾印檔案：
您可以從資料庫叢集快照進行還原來建立新的資料庫叢集。如需詳細資訊，請參閱[從資料庫叢集快照還原](aurora-restore-snapshot.md)。
您可以複製來源資料庫叢集來建立新的資料庫叢集。如需詳細資訊，請參閱[複製 Amazon Aurora 資料庫叢集的一個磁碟區](Aurora.Managing.Clone.md)。
您可以將資料從資料庫執行個體快照遷移到新的資料庫叢集。如需詳細資訊，請參閱[將資料遷移至 Amazon Aurora MySQL 資料庫叢集](AuroraMySQL.Migrating.md)。
使用以下為資料庫引擎將複寫來源的傾印載入複寫目標的相關指示。
| 資料庫引擎 | 指示 |
| --- | --- |
| Aurora MySQL | **將傾印載入至 Aurora MySQL 資料庫叢集** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **將傾印載入至 Amazon RDS 資料庫執行個體** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (外部) | **將傾印載入外部 MySQL 資料庫** 您無法將資料庫快照或資料庫叢集快照載入至外部 MySQL 資料庫。而是必須使用來自 `mysqldump` 命令的輸出。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 5. 在複製來源上建立複寫使用者
在僅供複寫使用的資源上建立使用者 ID。下列範例適用於 RDS for MySQL 或外部 MySQL 來源資料庫。
```
mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';
```
對於 Aurora MySQL 來源資料庫，`skip_name_resolve` 資料庫叢集參數設定為 `1` (`ON`) 且無法修改，因此您必須使用主機的 IP 位址，而非網域名稱。如需詳細資訊，請參閱 MySQL 文件中的 [skip\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_skip_name_resolve)。
```
mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';
```
使用者需要 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 權限。授予這些權限給該使用者。
如果需要使用加密複寫，請對複寫使用者要求 SSL 連接。例如，您可以使用以下其中一個陳述式來對使用者帳戶 `repl_user` 要求 SSL 連線。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';
```
```
GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
```
**注意**
如果未包含 `REQUIRE SSL`，則複寫連線可能會以無訊息方式回復為未加密的連線。
## 6. 在複本目標上開啟複寫
開啟複寫之前，建議您手動取得 Aurora MySQL 資料庫叢集的快照或 RDS for MySQL 資料庫執行個體複本目標。如果發生問題，而您需要使用資料庫叢集或資料庫執行個體複本目標重新建立複寫，則可以從此快照還原資料庫叢集或資料庫執行個體，而不需再次將資料匯入至複本目標。
使用以下開啟資料庫引擎複寫功能的相關指示。
| 資料庫引擎 | 指示 |
| --- | --- |
| Aurora MySQL | **從 Aurora MySQL 資料庫叢集開啟複寫** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) 若要使用 SSL 加密，請將最終值設定為 `1`，而不是 `0`。 |
| RDS for MySQL | **從 Amazon RDS 資料庫執行個體開啟複寫** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) 若要使用 SSL 加密，請將最終值設定為 `1`，而不是 `0`。 |
| MySQL (外部) | **從外部 MySQL 資料庫開啟複寫** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
如果複寫失敗，可能會導致複本上的非預期輸入/輸出大幅增加，進而降低效能。如果複寫失敗或不再需要複寫，可以執行 [mysql.rds\$1reset\$1external\$1master (Aurora MySQL 第 2 版)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) 或 [mysql.rds\$1reset\$1external\$1source (Aurora MySQL 第 3 版)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) 預存程序來移除複寫組態。
### 設定位置以停止僅供讀取複本的複寫作業
在 Aurora MySQL 3.04 版及更新版本中，您可以使用 [mysql.rds\$1start\$1replication\$1until(Aurora MySQL 第 3 版）](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) 預存程序開始複寫，然後在指定的二進位日誌檔案位置讓它停止。
**啟動僅供讀取複本的複寫作業，並在特定位置停止複寫**
1. 透過 MySQL 用戶端，以主要使用者的身分連接至複本 Aurora MySQL 資料庫叢集。
1. 執行 [mysql.rds\$1start\$1replication\$1until(Aurora MySQL 第 3 版）](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) 預存程序。
以下範例會啟動複寫並複寫變更，直到達到 `120` 二進位日誌檔案中的位置 `mysql-bin-changelog.000777` 為止。若要使用災難復原功能，請在發生損毀前將位置預設為 `120`。
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
達到停止點時，複寫作業即會自動停止。而且，系統還會產生以下 RDS 事件：`Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure`。
如果您使用 GTID 式複寫，請使用 [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL 第 3 版）](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) 預存程序，而非 [mysql.rds\$1start\$1replication\$1until(Aurora MySQL 第 3 版）](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) 預存程序。如需 GTID 式複寫的詳細資訊，請參閱[使用 GTID 式複寫](mysql-replication-gtid.md)。
## 7. 監控複本
設定使用 Aurora MySQL 資料庫叢集的 MySQL 複寫時，當 Aurora MySQL 資料庫叢集為複本目標時，您必須監控其容錯移轉事件。若發生容錯移轉，則屬於複本目標的資料庫叢集可能會以不同的網路地址，在新主機上重新建立。如需如何監控容錯移轉事件的資訊，請參閱[使用 Amazon RDS 事件通知](USER_Events.md)。
您也可以監控複本目標落後複寫來源的程度，方法是連接至複本目標並執行 `SHOW SLAVE STATUS` (Aurora MySQL 第 2 版) 或 `SHOW REPLICA STATUS` (Aurora MySQL 第 3 版) 命令。在命令輸出中，`Seconds Behind Master` 欄位會告知您複本目標落後於來源的程度。
**重要**
若您升級資料庫叢集並指定自訂參數群組，請務必在升級完成後手動重新啟動叢集。這樣做可讓叢集使用您的新自訂參數設定，並重新開始 binlog 複寫。
## 同步複寫來源和目標之間的密碼
當您使用 SQL 陳述式變更複寫來源上的使用者帳戶和密碼時，這些變更會自動複寫到複寫目標。
如果您使用 AWS 管理主控台 AWS CLI、 或 RDS API 變更複寫來源上的主密碼，這些變更不會自動複寫到複寫目標。如果您要同步來源系統和目標系統之間的主要使用者和主要密碼，則必須自行對複寫目標進行相同的變更。
# 停止 Aurora MySQL 的二進位日誌複寫
若要停止 MySQL 資料庫執行個體、外部 MySQL 資料庫，或另一個 Aurora 資料庫叢集的二進位日誌複寫，請遵循這些步驟，本主題後面將詳細討論此部分。
[1. 在複本目標上停止二進位日誌複寫](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication)
[2. 在複寫來源上關閉二進位日誌](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging)
## 1. 在複本目標上停止二進位日誌複寫
請遵循下列指示，為資料庫引擎停止二進位日誌複寫。
| 資料庫引擎 | 指示 |
| --- | --- |
| Aurora MySQL | **在 Aurora MySQL 資料庫叢集複本目標上停止二進位日誌複寫** 連接至屬於複本目標的 Aurora 資料庫叢集，並呼叫 [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) 程序。 |
| RDS for MySQL | **在 Amazon RDS 資料庫執行個體上停止二進位日誌複寫** 連接至屬於複本目標的 RDS 資料庫執行個體，並呼叫 [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) 程序。 |
| MySQL (外部) | **在外部 MySQL 資料庫上停止二進位日誌複寫** 連線到 MySQL 資料庫並執行 `STOP SLAVE` (第 5.7 版) 或 `STOP REPLICA` (第 8.0 版) 命令。 |
## 2. 在複寫來源上關閉二進位日誌
請遵循下表指示，為資料庫引擎關閉複寫來源上的二進位日誌。
| 資料庫引擎 | 指示 |
| --- | --- |
| Aurora MySQL | **在 Amazon Aurora 資料庫叢集上關閉二進位日誌** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| RDS for MySQL | **在 Amazon RDS 資料庫執行個體上關閉二進位日誌** 您不可以直接為 Amazon RDS 資料庫執行個體關閉二進位日誌，但您可以透過以下方式關閉它： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| MySQL (外部) | **在外部 MySQL 資料庫上關閉二進位日誌** 連接至 MySQL 資料庫並呼叫 `STOP REPLICATION` 命令。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
# 使用 Amazon Aurora 為 MySQL 資料庫擴展讀取
您可以使用 Amazon Aurora 搭配 MySQL 資料庫執行個體來利用 Amazon Aurora 的讀取擴展功能，並為 MySQL 資料庫執行個體擴展讀取工作負載。若要使用 Aurora 來讀取擴展 MySQL 資料庫執行個體，請建立 Amazon Aurora MySQL 資料庫叢集，並讓它成為您 MySQL DB 執行個體的讀取複本。這可套用至 RDS for MySQL 資料庫執行個體，或在 Amazon RDS 外部執行的 MySQL 資料庫。
如需建立 Amazon Aurora 資料庫叢集的詳細資訊，請參閱[建立 Amazon Aurora 資料庫叢集](Aurora.CreateInstance.md)。
設定 MySQL 資料庫執行個體與 Amazon Aurora 資料庫叢集之間的複寫時，務必遵循這些準則：
+ 參考 Amazon Aurora MySQL 資料庫叢集時，請使用 Amazon Aurora 資料庫叢集端點地址。如果發生容錯移轉，則提升至 Aurora MySQL 資料庫叢集主要執行個體的 Aurora 複本，將繼續使用資料庫叢集端點地址。
+ 直到您已驗證二進位日誌已套用至 Aurora 複本前，都要將二進位日誌保存在寫入器執行個體上。如此一來，發生故障時，您就可以還原寫入器執行個體。
**重要**
使用自我管理的複寫時，您需負責監控和解決可能發生的任何複寫問題。如需詳細資訊，請參閱[診斷和解決僅供讀取複本之間的延遲](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag)。
**注意**
在 Aurora MySQL 資料庫叢集上啟動複寫功能所需的許可受到限制，並無法供 Amazon RDS 主要使用者使用。因此，您必須使用 [mysql.rds\$1set\$1external\$1master (Aurora MySQL 第 2 版)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) 或 [mysql.rds\$1set\$1external\$1source (Aurora MySQL 第 3 版)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) 和 [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) 程序，設定 Aurora MySQL 資料庫叢集與 MySQL 資料庫執行個體之間的複寫。
## 啟動外部來源執行個體與 Aurora MySQL 資料庫叢集之間的複寫
1. 將來源 MySQL 資料庫執行個體設成唯讀：
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. 在來源 MySQL 資料庫執行個體上執行 `SHOW MASTER STATUS` 命令，以確定二進位記錄檔的位置。您會獲得類似下列範例的輸出結果：
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
1. 使用 `mysqldump`，從外部 MySQL 資料庫執行個體將資料庫複製到 Amazon Aurora MySQL 資料庫叢集。若為非常大型的資料庫，您可能想要使用《Amazon Relational Database Service 使用者指南》**中[將資料匯入至 Amazon RDS for MySQL 資料庫，並減少停機時間](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html)中的程序。
對於 Linux、macOS 或 Unix：
```
mysqldump \
--databases \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-p local_password | mysql \
--host aurora_cluster_endpoint_address \
--port 3306 \
-u RDS_user_name \
-p RDS_password
```
在 Windows 中：
```
mysqldump ^
--databases ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-p local_password | mysql ^
--host aurora_cluster_endpoint_address ^
--port 3306 ^
-u RDS_user_name ^
-p RDS_password
```
**注意**
請注意 `-p` 選項與輸入的密碼之間不能有空格。
在 `--host` 命令中，使用 `--user (-u)`、`--port`、`-p` 和 `mysql` 選項來指定主機名稱、使用者名稱、連接埠和密碼，以連接至 Aurora 資料庫叢集。主機名稱是來自 Amazon Aurora 資料庫叢集端點的 DNS 名稱，例如 `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`。您可在 Amazon RDS 管理主控台中的叢集詳細資訊中，找到端點值。
1. 將來源 MySQL 資料庫執行個體重新設為可寫入：
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
如需如何製作備份以搭配複寫作業使用的詳細資訊，請參閱 MySQL 文件中的 [http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html](http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html)。
1. 在 Amazon RDS 管理主控台，將託管來源 MySQL 資料庫之伺服器的 IP 地址，新增至 Amazon Aurora 資料庫叢集的 VPC 安全群組。如需有關修改 VPC 安全群組的詳細資訊，請參閱《Amazon Virtual Private Cloud 使用者指南》**中的 [VPC 安全群組](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)。
您可能還需要設定本機網路，以允許來自 Amazon Aurora 資料庫叢集之 IP 地址的連線，這樣就能與來源 MySQL 執行個體通訊。若要找出 Amazon Aurora 資料庫叢集的 IP 地址，請使用 `host` 命令。
```
host aurora_endpoint_address
```
主機名稱是來自 Amazon Aurora 資料庫叢集端點的 DNS 名稱。
1. 使用您選擇的用戶端，連接至外部 MySQL 執行個體，並建立用於複寫的 MySQL 使用者。此帳戶只供複寫作業使用，務必限制其存取您的網域，以提升安全性。以下是範例。
```
CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password';
```
1. 若為外部 MySQL 執行個體，請將 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 權限授予複寫使用者。舉例來說，若要將所有資料庫的 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 權限授予您網域中的「`repl_user`」使用者，請發出下列命令。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'
IDENTIFIED BY 'password';
```
1. 設定複寫之前，手動取得要成為讀取複本之 Aurora MySQL 資料庫叢集的快照。如果您需要對資料庫叢集重新建立複寫做為讀取複本，您可以從這個快照還原 Aurora MySQL 資料庫叢集，而不需從 MySQL 資料庫執行個體匯入資料至新的 Aurora MySQL 資料庫叢集。
1. 將 Amazon Aurora 資料庫叢集變成複本。以主要使用者身分連接至 Amazon Aurora 資料庫叢集，然後使用 [mysql.rds\$1set\$1external\$1master (Aurora MySQL 第 2 版)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) 或 [mysql.rds\$1set\$1external\$1source (Aurora MySQL 第 3 版)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) 和 [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) 程序，將來源 MySQL 資料庫辨識為複寫來源。
使用您在步驟 2 中所確定的 binlog 檔案名稱與位置。下列是 範例。
```
For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
```
1. 在 Amazon Aurora 資料庫叢集上，呼叫 [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) 程序以開始複寫。
```
CALL mysql.rds_start_replication;
```
建立來源 MySQL 資料庫執行個體與 Amazon Aurora 資料庫叢集之間的複寫之後，您可以將 Aurora 複本新增至 Amazon Aurora 資料庫叢集。您接著可以連接至 Aurora 複本來讀取擴展您的資料。如需建立 Aurora 複本的詳細資訊，請參閱[將 Aurora 複本新增至資料庫叢集](aurora-replicas-adding.md)。
# 最佳化 Aurora MySQL 的二進位日誌複寫
接下來，您可以學習如何最佳化二進位日誌複寫效能，並對 Aurora MySQL 中的相關問題進行疑難排解。
**提示**
本討論假設您熟悉 MySQL 二進位日誌複寫機制及其運作方式。如需背景資訊，請參閱 MySQL 文件中的[複寫實作](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html)。
## 多執行緒二進位日誌複寫
使用多執行緒二進位日誌複寫，SQL 執行緒會從轉送日誌讀取事件，並將它們排入佇列，以供 SQL 工作者執行緒套用。SQL 工作者執行緒是由協調器執行緒管理。可能的話，會平行套用二進位日誌事件。平行處理的程度取決於版本、參數、結構描述設計和工作負載特性等因素。
Aurora MySQL 第 3 版和 Aurora MySQL 第 2.12.1 版及更新版本支援多執行緒二進位日誌複寫。若要讓多執行緒複本有效平行處理 binlog 事件，您必須設定多執行緒二進位日誌複寫的來源，且來源必須使用內含其二進位日誌檔案上平行處理資訊的版本。
將 Aurora MySQL 資料庫執行個體設定為使用二進位日誌複寫時，複本執行個體預設會使用低於 3.04 版 Aurora MySQL 的單一執行緒複寫。若要啟用多執行緒複寫，您可以在自訂參數群組中將 `replica_parallel_workers` 參數更新為大於 `1` 的值。
對於 Aurora MySQL 3.04 版及更新版本，複寫預設為多執行緒，且 `replica_parallel_workers` 會設為 `4`。您可以在自訂參數群組中修改此參數。
若要提高資料庫的彈性，以防止意外停止，建議您在來源啟用 GTID 複寫，然後允許在複本的 GTID。若要允許 GTID 複寫，請在來源和複本將 `gtid_mode` 設為 `ON_PERMISSIVE`。如需 GTID 式複寫的詳細資訊，請參閱[使用 GTID 式複寫](mysql-replication-gtid.md)。
下列組態選項可協助您微調多執行緒複寫。如需用法資訊，請參閱《MySQL 參考手冊》**中的[複寫和二進位記錄選項和變數](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html)。如需多執行緒複寫的詳細資訊，請參閱 MySQL 部落格[使用寫入集型相依性追蹤改善平行套用者**](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/)。
最佳參數值取決於幾個因素。例如，二進位日誌複寫的效能會受到資料庫工作負載特性和複本執行所在的資料庫執行個體類別影響。因此，建議您在將新參數設定套用至生產執行個體之前，先徹底測試這些組態參數的所有變更：
+ `binlog_format recommended value`：設定為 `ROW`
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_transaction_dependency_history_size`
+ `binlog_transaction_dependency_tracking`：建議值為 `WRITESET`
+ `replica_preserve_commit_order`
+ `replica_parallel_type`：建議值為 `LOGICAL_CLOCK`
+ `replica_parallel_workers`
+ `replica_pending_jobs_size_max`
+ `transaction_write_set_extraction`：建議值為 `XXHASH64`
結構描述和工作負載特性是影響平行複寫的因素。最常見的因素如下。
+ 沒有主索引鍵：RDS 無法為沒有主索引鍵的資料表建立寫入集相依性。使用 `ROW` 格式時，單一多列陳述式可以透過來源的單一完整資料表掃描來完成，但在複本會導致每修改一列就執行一次完整資料表掃描。缺少主索引鍵會大幅減少複寫輸送量。
+ 存在外部索引鍵：如果存在外部索引鍵，Amazon RDS 就無法使用寫入集相依性，來平行處理具有 FK 關係的資料表。
+ 交易大小：如果單一交易跨越數十或數百 MB 或 GB，協調器執行緒和其中一個工作者執行緒可能會需要很長的時間，才能處理該交易。在此期間，所有其他工作者執行緒可能會在完成其先前交易的處理後保持閒置狀態。
在 Aurora MySQL 第 3.06 版及更新版本中，當複寫具有多個次要索引的大型資料表的交易時，您就可以改善二進位日誌複本的效能。此功能會導入執行緒集區，以在 binlog 複本平行套用次要索引變更。此功能由 `aurora_binlog_replication_sec_index_parallel_workers` 資料庫叢集參數所控制，該參數會控制可用於套用次要索引變更的平行執行緒總數。依預設，參數會設為 `0` (停用)。啟用此功能不需要重新啟動執行個體。若要啟用此功能，請停止持續複寫、設定所需的平行工作者執行緒數量，然後再次開始複寫。
## 最佳化 binlog 複寫
在 Aurora MySQL 2.10 及更高版本中，Aurora 會自動將名為 binlog 輸入/輸出快取的最佳化套用至二進位日誌複寫。藉由快取最近遞交的 binlog 事件，此最佳化旨在改善 binlog 傾印執行緒效能，同時限制 binlog 來源執行個體上對前景交易的影響。
**注意**
此功能所使用的記憶體與 MySQL `binlog_cache` 設定無關。
此功能不適用於使用 `db.t2` 和 `db.t3` 執行個體類別的 Aurora 資料庫執行個體。
您不需要調整任何組態參數，即可開啟此最佳化。特別是如果您在 Aurora MySQL 的較舊版本中，將組態參數 `aurora_binlog_replication_max_yield_seconds` 調整為非零值，請將其設定回零以取得目前可用的版本。
這些狀態變數 `aurora_binlog_io_cache_reads` 和 `aurora_binlog_io_cache_read_requests` 可協助您監控從 binlog 輸入/輸出快取讀取資料的頻率。
+ `aurora_binlog_io_cache_read_requests` 顯示對快取發起的 binlog 輸入/輸出讀取要求的次數。
+ `aurora_binlog_io_cache_reads` 顯示從快取擷取資訊的 binlog 輸入/輸出讀取次數。
下列 SQL 查詢會計算利用快取資訊的 binlog 讀取要求百分比。在這種情況下，比例越接近 100 越好。
```
mysql> SELECT
(SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
/ (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
* 100
as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
| 99.99847949080622 |
+---------------------------+
```
binlog 輸入/輸出快取功能也包含與 binlog 傾印執行緒相關的新指標。「傾印執行緒」**是新的 binlog 複本連線到 binlog 來源執行個體時所建立的執行緒。
傾印執行緒指標會每隔 60 秒列印至資料庫日誌，字首為 `[Dump thread metrics]`。此指標包括每個 binlog 複本的資訊，例如 `Secondary_id`、`Secondary_uuid`、binlog 檔案名稱，以及每個複本正在讀取的位置。此指標也包括 `Bytes_behind_primary`，表示複寫來源與複本之間的距離 (以位元組為單位)。此指標會測量複本輸入/輸出執行緒的延遲。該圖與複本 SQL 套用者執行緒的延遲不同，此執行緒由 binlog 複本上的 `seconds_behind_master` 指標表示。您可以透過檢查距離是否減少或增加，判斷 binlog 複本是趕上還是落後於來源。
## 記憶體中轉送日誌
在 Aurora MySQL 第 3.10 版及更新版本中，Aurora 推出名為記憶體中轉送日誌的最佳化，以改善複寫輸送量。此最佳化透過快取記憶體中所有中繼轉送日誌內容，來增強轉送日誌 I/O 效能。因此，其透過盡可能減少儲存體 I/O 操作來減少遞交延遲，因為轉送日誌內容仍可在記憶體中輕鬆存取。
根據預設，當複本符合下列任何組態時，系統會自動為 Aurora 受管複寫案例 (包括藍/綠部署、Aurora-Aurora 複寫和跨區域複本) 啟用記憶體中轉送日誌功能：
+ 單執行緒複寫模式 (replica\$1parallel\$1workers = 0)
+ 啟用 GTID 模式的多執行緒複寫：
+ 自動定位已啟用
+ 複本的 GTID 模式設為 ON
+ 以檔案為基礎的複寫搭配 replica\$1preserve\$1commit\$1order = ON
大於 t3.large 的執行個體類別支援記憶體中轉送日誌功能，但無法在 Aurora Serverless 執行個體上使用。轉送日誌循環緩衝區的固定大小為 128 MB。若要監控此功能的記憶體使用量，您可以執行下列查詢：
```
SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';
```
記憶體中轉送日誌功能是由 aurora\$1in\$1memory\$1relaylog 參數控制，您可在資料庫叢集或執行個體層級設定該參數。您可以動態啟用或停用此功能，而無需重新啟動執行個體：
1. 停止持續複寫
1. 在參數群組中將 aurora\$1in\$1memory\$1relaylog 設定為 ON (啟用) 或 OFF (停用)
1. 重新啟動複寫
範例：
```
CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;
```
即使將 aurora\$1in\$1memory\$1relaylog 設定為 ON，在特定情況下，記憶體中轉送日誌功能仍可能遭停用。若要驗證功能的目前狀態，您可以使用下列命令：
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';
```
如果此功能意外停用，您可以透過執行下列動作來識別原因：
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';
```
此命令會傳回訊息，說明此功能目前停用的原因。
# 設定 Aurora MySQL 的增強型 binlog
增強型 Binlog 可減少開啟 Binlog 所造成的運算效能額外負荷，在某些情況下最高可達 50%。使用增強型 Binlog，此額外負荷可以減少至大約 13%。為了減少額外負荷，增強型 Binlog 會將二進位和交易日誌平行寫入至儲存體，這會將交易認可時寫入的資料降到最低。
相較於社群 MySQL Binlog，使用增強型 Binlog 還可以改善重新啟動和容錯移轉後的資料庫復原時間，最高可達 99％。增強型 Binlog 與現有的 Binlog 型工作負載相容，而且您與其互動的方式同於與社群 MySQL Binlog 互動的方式。
增強型 binlog 可在 Aurora MySQL 3.03.1 版及更新版本上使用。
**Topics**
+ [設定增強型 Binlog 參數](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)
+ [其他相關參數](#AuroraMySQL.Enhanced.binlog.other.parameters)
+ [增強型 Binlog 與社群 MySQL Binlog 之間的差異](#AuroraMySQL.Enhanced.binlog.differences)
+ [增強型 Binlog 的 Amazon CloudWatch 指標](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics)
+ [增強型 Binlog 限制](#AuroraMySQL.Enhanced.binlog.limitations)
## 設定增強型 Binlog 參數
您可以透過開啟/關閉增強型 Binlog 參數，在社群 MySQL Binlog 與增強型 Binlog 之間切換。現有的 Binlog 取用者可以繼續讀取和取用 Binlog 檔案，而不會在 Binlog 檔案序列中有任何間隙。
若要開啟增強型 binlog，請設定下列參數：
| 參數 | 預設 | 描述 |
| --- | --- | --- |
| binlog\$1format | – | 將 binlog\$1format 參數設定為您選擇的二進位記錄格式，以開啟增強型 Binlog。確定 binlog\$1format parameter 未設定為 OFF。如需詳細資訊，請參閱[設定 Aurora MySQL 二進位記錄](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html)。 |
| aurora\$1enhanced\$1binlog | 0 | 將此參數的值設定為與 Aurora MySQL 叢集相關聯之資料庫叢集參數群組中的 1。當您變更此參數的值時，必須在 DBClusterParameterGroupStatus 值顯示為 pending-reboot 時重新啟動寫入器執行個體。 |
| binlog\$1backup | 1 | 關閉此參數以開啟增強型 Binlog。若要這樣做，請將此參數的值設定為 0。 |
| binlog\$1replication\$1globaldb | 1 | 關閉此參數以開啟增強型 Binlog。若要這樣做，請將此參數的值設定為 0。 |
**重要**
僅在使用增強型 Binlog 時，您才能關閉 `binlog_backup` 和 `binlog_replication_globaldb` 參數。
若要關閉增強型 binlog，請設定下列參數：
| 參數 | 描述 |
| --- | --- |
| aurora\$1enhanced\$1binlog | 將此參數的值設定為與 Aurora MySQL 叢集相關聯之資料庫叢集參數群組中的 0。每當您變更此參數的值時，就必須在 DBClusterParameterGroupStatus 值顯示為 pending-reboot 時重新啟動寫入器執行個體。 |
| binlog\$1backup | 在您關閉增強型 Binlog 時開啟此參數。若要這樣做，請將此參數的值設定為 1。 |
| binlog\$1replication\$1globaldb | 在您關閉增強型 Binlog 時開啟此參數。若要這樣做，請將此參數的值設定為 1。 |
若要檢查增強型 Binlog 是否已開啟，請在 MySQL 用戶端中使用下列命令：
```
mysql>show status like 'aurora_enhanced_binlog';
+------------------------+--------+
| Variable_name | Value |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)
```
當增強型 Binlog 開啟時，輸出會針對 `aurora_enhanced_binlog` 顯示 `ACTIVE`
## 其他相關參數
當您開啟增強型 Binlog 時，下列參數會受到影響：
+ `max_binlog_size` 參數可見，但無法修改。當增強型 Binlog 開啟時，它的預設值 `134217728` 會自動調整為 `268435456`。
+ 與社群 MySQL Binlog 不同，當增強型 Binlog 開啟時，`binlog_checksum` 不會充當動態參數。若要使對此參數所做的變更生效，您必須手動重新啟動資料庫叢集，即使 `ApplyMethod` 為 `immediate` 也是如此。
+ 增強型 Binlog 開啟時，您在 `binlog_order_commits` 參數上設定的值不會影響認可的順序。認可總是排序，沒有任何進一步的效能隱憂。
## 增強型 Binlog 與社群 MySQL Binlog 之間的差異
相較於社群 MySQL binlog，增強型 binlog 會以不同方式與複本，備份和 Aurora 全球資料庫互動。建議您在使用增強型 Binlog 之前先了解下列差異。
+ 來源資料庫叢集中的增強型 binlog 檔案無法在複製的資料庫叢集上使用。
+ Aurora 備份中不包含增強型 binlog 檔案。因此，在還原資料庫叢集之後，儘管在其上設定了任何保留期間，仍無法使用來源資料庫叢集中的增強型 Binlog 檔案。
+ 與 Aurora 全球資料庫搭配使用時，主要資料庫叢集的增強型 Binlog 檔案不會複寫至次要區域中的資料庫叢集。
****範例****
下列範例說明增強型 Binlog 與社群 MySQL Binlog 之間的差異。
**在還原或複製的資料庫叢集上**
當增強型 Binlog 開啟時，在已還原或複製的資料庫叢集中無法使用歷史 Binlog 檔案。在還原或複製操作之後，如果開啟了 Binlog，新的資料庫叢集會開始寫入自己的 Binlog 檔案序列，從 1 (mysql-bin-changelog.000001) 開始。
若要在還原或複製操作之後開啟增強型 Binlog，請在還原或複製的資料庫叢集上設定所需的資料庫叢集參數。如需更多詳細資訊，請參閱 [設定增強型 Binlog 參數](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)。
**Example 範例：增強型 binlog 開啟時所執行的複製或還原操作**
來源資料庫叢集：
```
mysql> show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No |
| mysql-bin-changelog.000003 | 156 | No |
| mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
在還原或複製的資料庫叢集上，增強型 Binlog 開啟時，不會備份 Binlog 檔案。為了避免 Binlog 資料中的不連續性，在開啟增強型 Binlog 之前寫入的 Binlog 檔案也無法使用。
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No | --> New sequence of Binlog files
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Example 範例：增強型 binlog 關閉時所執行的複製或還原操作**
來源資料庫叢集：
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
增強型 binlog 會在 `mysql-bin-changelog.000003` 之後停用。在還原或複製的資料庫叢集上，可以使用在關閉增強型 Binlog 之後寫入的 Binlog 檔案。
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**在 Amazon Aurora 全球資料庫上**
在 Amazon Aurora 全球資料庫上，主要資料庫叢集的 Binlog 資料不會複寫到次要資料庫叢集。在跨區域容錯移轉程序之後，Binlog 資料無法在新提升的主要資料庫叢集中使用。如果開啟了 Binlog，新提升的資料庫叢集會啟動自己的 Binlog 檔案序列，從 1 (mysql-bin-changelog.000001) 開始。
若要在容錯移轉之後開啟增強型 Binlog，您必須在次要資料庫叢集上設定所需的資料庫叢集參數。如需更多詳細資訊，請參閱 [設定增強型 Binlog 參數](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)。
**Example 範例：開啟增強型 binlog 時，便會執行全球資料庫容錯移轉操作**
舊的主要資料庫叢集 (容錯移轉前)：
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No |
| mysql-bin-changelog.000003 | 156 | No |
| mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog enabled
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
新的主要資料庫叢集 (容錯移轉後)：
開啟增強型 Binlog 時，Binlog 檔案不會複寫到次要區域。為了避免 Binlog 資料中的不連續性，無法使用在開啟增強型 Binlog 之前寫入的 Binlog 檔案。
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No | --> Fresh sequence of Binlog files
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Example 範例：關閉增強型 binlog 時，便會執行全球資料庫容錯移轉操作**
來源資料庫叢集：
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
**還原或複製的資料庫叢集：**
增強型 binlog 會在 `mysql-bin-changelog.000003` 之後停用。在關閉增強型 Binlog 之後寫入的 Binlog 檔案會被複寫，並可在新提升的資料庫叢集中使用。
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
3 rows in set (0.00 sec)
```
## 增強型 Binlog 的 Amazon CloudWatch 指標
只在開啟增強型 Binlog 時，才會發佈下列 Amazon CloudWatch 指標。
| CloudWatch 指標 | 描述 | 個單位 |
| --- | --- | --- |
| ChangeLogBytesUsed | 增強型 Binlog 使用的儲存體數量。 | 位元組 |
| ChangeLogReadIOPs | 增強型 Binlog 中 5 分鐘間隔內執行的讀取 I/O 操作次數。 | 每 5 分鐘計數 |
| ChangeLogWriteIOPs | 增強型 Binlog 中 5 分鐘間隔內執行的寫入磁碟 I/O 操作次數。 | 每 5 分鐘計數 |
## 增強型 Binlog 限制
當增強型 Binlog 開啟時，下列限制適用於 Amazon Aurora 資料庫叢集。
+ 僅在 Aurora MySQL 3.03.1 版及更新版本上，才支援增強型 binlog。
+ 在主要資料庫叢集上寫入的增強型 Binlog 檔案不會複製到複製或還原的資料庫叢集。
+ 與 Amazon Aurora 全球資料庫搭配使用時，主要資料庫叢集的增強型 Binlog 檔案不會複寫至次要資料庫叢集。因此，在容錯移轉程序之後，無法在新的主要資料庫叢集中使用歷史 Binlog 資料。
+ 系統會忽略下列 Binlog 組態參數：
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_max_flush_queue_time`
+ 您無法捨棄或重新命名資料庫中損毀的資料表。若要捨棄這些資料表，您可以聯絡 支援。
+ 開啟增強型 Binlog 時，會停用 Binlog I/O 快取。如需更多詳細資訊，請參閱 [最佳化 Aurora MySQL 的二進位日誌複寫](binlog-optimization.md)。
**注意**
增強型 Binlog 提供與 Binlog I/O 快取類似的讀取效能改進，以及更好的寫入效能改進。
+ 不支援恢復功能。無法在下列情況下的資料庫叢集中開啟增強型 Binlog：
+ 目前已啟用恢復功能的資料庫叢集。
+ 先前已啟用但現在已停用恢復功能的資料庫叢集。
+ 從來源資料庫叢集或已啟用恢復功能的快照中還原的資料庫叢集。
# 使用 GTID 式複寫
接下來，您可以了解如何在 Aurora MySQL 叢集和外部來源間搭配使用全域交易識別符 (GTID) 與二進位日誌 (binlog) 複寫。
**注意**
若為 Aurora，您僅可對會在外部 MySQL 資料庫間進行 binlog 複寫的 Aurora MySQL 叢集使用這項功能。其他資料庫可能是 Amazon RDS MySQL 執行個體、內部部署的 MySQL 資料庫，或是位於不同 AWS 區域 中的 Aurora 資料庫叢集。若要了解如何設定該類型的複寫作業，請參閱[Aurora 與 MySQL 之間或 Aurora 與另一個 Aurora 資料庫叢集之間的複寫 (二進位複寫)](AuroraMySQL.Replication.MySQL.md)。
如果您是使用 binlog 複寫，且不熟悉如何在 MySQL 使用 GTID 式複寫，則可參閱 MySQL 文件中的[使用全域交易識別符的複寫](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html)。
Aurora MySQL 第 2 版和第 3 版不支援 GTID 型複寫。
**Topics**
+ [全域交易識別符 (GTID) 的概觀](#mysql-replication-gtid.overview)
+ [GTID 式複寫的參數](#mysql-replication-gtid.parameters)
+ [為 Aurora MySQL 叢集啟用 GTID 式複寫](mysql-replication-gtid.configuring-aurora.md)
+ [為Aurora MySQL 資料庫叢集停用 GTID 式複寫](mysql-replication-gtid.disabling.md)
## 全域交易識別符 (GTID) 的概觀
「全域交易識別符 (GTID)」**是系統為遞交的 MySQL 交易所產生的唯一識別符。GTID 能讓 binlog 複寫的操作更簡單，也更容易進行故障診斷。
**注意**
當 Aurora 在叢集中的資料庫執行個體間同步資料時，該複寫機制並不會用到二進位日誌 (binlog)。在 Aurora MySQL 中，唯有您同時使用 binlog 複寫功能來複寫資料至外部 MySQL 相容資料庫的 Aurora MySQL 資料庫叢集，或從中複寫資料的情況下，才能套用 GTID 式複寫。
進行 binlog 複寫作業時，MySQL 會使用兩種不同類型的交易：
+ GTID 交易** – 透過 GTID 識別的交易。
+ 匿名交易** – 未指派 GTID 的交易。
在複寫組態中，全部的資料庫執行個體都有各自不同的 GTID。GTID 可簡化複寫組態，因為使用時不需要參照日誌檔案位置。GTID 也使得追蹤複寫的交易更容易，而且可決定來源執行個體和複本是否一致。
一般而言，當您從外部 MySQL 相容資料庫複寫至 Aurora 叢集時，即可對 Aurora 叢集使用 GTID 式複寫。您可以設定這個複寫組態，將其做為從現場部署資料庫或 Amazon RDS 資料庫到 Aurora MySQL 遷移流程的一部分。如果外部資料庫已使用 GTID，則可為 Aurora 叢集啟用 GTID 式複寫功能，藉此簡化複寫程序。
若要為 Aurora MySQL 叢集設定 GTID 式複寫，您首先要在資料庫叢集參數群組中設定相關的組態參數。接著，請建立該參數群組與叢集間的關聯。
## GTID 式複寫的參數
使用以下參數來設定 GTID 式複寫。
| 參數 | 有效值 | 描述 |
| --- | --- | --- |
| `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` 指定新交易是匿名交易 (也就是沒有 GTID)，而且交易必須是匿名交易才能複寫。 `OFF_PERMISSIVE` 指定新交易是匿名交易，但全部交易都可以複寫。 `ON_PERMISSIVE` 指定新交易是 GTID 交易，而且全部交易都可以複寫。 `ON` 指定新交易是 GTID 交易，而且交易必須是 GTID 交易才能複寫。 |
| `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF` 允許交易違反 GTID 一致性。 `ON` 可避免交易違反 GTID 一致性。 `WARN` 允許交易違反 GTID 一致性，但會在出現違反行為時產生警告。 |
**注意**
在 AWS 管理主控台 中，`gtid_mode` 參數會顯示為 `gtid-mode`。
進行 GTID 式複寫時，您可以使用下列設定來配置 Aurora MySQL 資料庫叢集的資料庫叢集參數群組：
+ `ON` 和 `ON_PERMISSIVE` 僅適用於從 Aurora MySQL 叢集進行的傳出複寫作業。這兩個值都會導致 Aurora 資料庫叢集使用 GTID 來執行複寫至外部資料庫的交易。如果設定 `ON`，外部資料庫需同時使用 GTID 式複寫。如果設定 `ON_PERMISSIVE`，則外部資料庫不一定要使用 GTID 式複寫。
+ 若設定 `OFF_PERMISSIVE`，表示 Aurora 資料庫叢集可接受來自外部資料庫的傳入複寫作業。無論外部資料庫是否使用 GTID 式複寫，此值都能實現這項功能。
+ 若設定 `OFF`，表示唯有在外部資料庫未使用 GTID 式複寫的情況下，Aurora 資料庫叢集才能接受來自該資料庫的傳入複寫作業。
**提示**
傳入複寫是 Aurora MySQL 叢集最常見的 binlog 複寫案例。如果要進行傳入複寫，建議您將 GTID 模式設定為 `OFF_PERMISSIVE`。該設定可允許來自外部資料庫的傳入複寫作業，不管複寫來源的 GTID 設定為何都是如此。
如需參數群組的詳細資訊，請參閱[Amazon Aurora 的參數群組](USER_WorkingWithParamGroups.md)。
# 為 Aurora MySQL 叢集啟用 GTID 式複寫
當 Aurora MySQL 資料庫叢集的 GTID 式複寫處於啟用狀態時，即可將 GTID 設定套用至傳入和傳出 binlog 複寫作業。
**為 Aurora MySQL 叢集啟用 GTID 式複寫**
1. 使用以下參數設定來建立或編輯資料庫叢集參數群組：
+ `gtid_mode` – `ON` 或 `ON_PERMISSIVE`
+ `enforce_gtid_consistency` – `ON`
1. 建立該資料庫叢集參數群組與 Aurora MySQL 叢集間的關聯。若要執行此作業，請遵循[Amazon Aurora 的參數群組](USER_WorkingWithParamGroups.md)中的程序。
1. (選用) 指定如何將 GTID 指派給不包含 GTID 的交易。若要這樣做，請呼叫 [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL 第 3 版)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions) 中的預存程序。
# 為Aurora MySQL 資料庫叢集停用 GTID 式複寫
您可以為 Aurora MySQL 資料庫叢集停用 GTID 式複寫。如此一來，Aurora 叢集就無法透過採用 GTID 式複寫的外部資料庫執行傳入或傳出 binlog 複寫作業。
**注意**
在下列程序中，「僅供讀取複本」**指的是 Aurora 組態中的複寫目標，其會在外部資料庫間進行 binlog 複寫。僅供讀取複本並不是指唯讀 Aurora 複本資料庫執行個體。舉例來說，Aurora 叢集接受來自外部來源的傳入複寫作業時，Aurora 主要執行個體會以僅供讀取複本運作，供 binlog 複寫。
如需本節中提及的預存程序詳細資訊，請參閱 [Aurora MySQL 預存程序參考](AuroraMySQL.Reference.StoredProcs.md)。
**為 Aurora MySQL 資料庫叢集 停用 GTID 式複寫**
1. 在 Aurora 複本，執行下列程序：
對於第 3 版
```
CALL mysql.rds_set_source_auto_position(0);
```
對於第 2 版
```
CALL mysql.rds_set_master_auto_position(0);
```
1. 將 `gtid_mode` 重設為 `ON_PERMISSIVE`。
1. 確定與 Aurora MySQL 叢集相關聯的資料庫叢集參數群組有設定為 `gtid_mode` 的 `ON_PERMISSIVE`。
如需使用參數群組設定組態參數的詳細資訊，請參閱[Amazon Aurora 的參數群組](USER_WorkingWithParamGroups.md)。
1. 重新啟動 Aurora MySQL 資料庫叢集。
1. 將 `gtid_mode` 重設為 `OFF_PERMISSIVE`。
1. 確定與 Aurora MySQL 叢集相關聯的資料庫叢集參數群組有設定為 `gtid_mode` 的 `OFF_PERMISSIVE`。
1. 重新啟動 Aurora MySQL 資料庫叢集。
1. 等待系統將全部的 GTID 交易套用至 Aurora 主要執行個體。若要檢查這些設定是否已套用，請執行下列步驟：
1. 在 Aurora 主要執行個體上，執行 `SHOW MASTER STATUS` 命令。
輸出內容應會與下列輸入類似。
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
請注意輸出中的檔案和位置。
1. 對於每個僅供讀取複本，在上一步中使用來源執行個體的檔案和位置資訊來執行下列查詢：
對於第 3 版
```
SELECT SOURCE_POS_WAIT('file', position);
```
對於第 2 版
```
SELECT MASTER_POS_WAIT('file', position);
```
例如，如果檔案名稱是 `mysql-bin-changelog.000031`，而且位置是 `107`，則執行下列陳述式：
對於第 3 版
```
SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107);
```
對於第 2 版
```
SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107);
```
1. 重設 GTID 參數，以停用 GTID 式複寫。
1. 確定與 Aurora MySQL 叢集相關聯的資料庫叢集參數群組有下列參數設定：
+ `gtid_mode` – `OFF`
+ `enforce_gtid_consistency` – `OFF`
1. 重新啟動 Aurora MySQL 資料庫叢集。