匯入 MariaDB 的資料考量事項

下列內容包含有關將資料載入 MariaDB 的技術資訊。此內容的目標是熟悉 MariaDB 伺服器架構的使用者。

二進位記錄

啟用二進位記錄可降低資料載入效能，且相較於停用的記錄，需要高達四倍的額外磁碟空間。用於載入資料的交易大小會直接影響系統效能和磁碟空間需求 - 較大的交易需要更多資源。

交易大小

交易大小會影響 MariaDB 資料載入的下列層面：

• 資源使用量

• 磁碟空間使用率

• 繼續程序

• 復原時間

• 輸入格式 （平面檔案或 SQL)

本節會說明交易大小如何影響二進位日誌，並解釋為何要在大型資料載入期間停用此功能。您可以透過設定 Amazon RDS 自動備份保留期來啟用和停用二進位記錄。非零的數值會啟用二進位日誌，而零則會停用此功能。如需詳細資訊，請參閱Backup retention period (備份保留期間)。

本節也說明大型交易對 InnoDB 的影響，以及為什麼保持交易大小較小很重要。

小型交易

若為小型交易，二進位日誌會將載入資料所需的磁碟寫入次數加倍。此效果會嚴重降低其他資料庫作業階段的效能，並增加載入資料所需的時間。經歷的降級部分取決於下列因素：

• 上傳率

• 載入期間發生的其他資料庫活動

• Amazon RDS 資料庫執行個體的容量

二進位日誌也會耗用大約等於載入資料量的磁碟空間，直到備份和移除日誌為止。Amazon RDS 透過經常備份和移除二進位日誌，將此情況降至最低。

大型交易

對於大型交易，二進位日誌記錄會將 IOPS 和磁碟用量增加三倍，原因如下：

• 二進位日誌快取會將交易資料暫時存放在磁碟上。

• 此快取會隨著交易大小而增加，這會耗用磁碟空間。

• 當交易 （遞交或轉返） 完成時，系統會將快取複製到二進位日誌。

此程序會建立三個資料副本：

• 原始資料

• 磁碟上的快取

• 最終二進位日誌項目

每個寫入操作都會產生額外的 IO，進一步影響效能。

因此，相較於停用的記錄，二進位記錄需要三倍的磁碟空間。例如，將 10 GiB 的資料載入為單一交易會建立三個複本：

• 資料表資料的 10 GiB

• 二進位日誌快取為 10 GiB

• 二進位日誌檔案為 10 GiB

所需的暫存磁碟空間總計為 30 GiB。

重要的磁碟空間考量：

• 快取檔案會持續存在，直到工作階段結束或新的交易建立另一個快取為止。

• 二進位日誌會保留到備份為止，可能會長時間保留 20 GiB （快取和日誌）。

如果您使用 LOAD DATA LOCAL INFILE 載入資料，資料復原會建立第四個副本，以防資料庫必須從載入前所做的備份復原。在復原期間，MariaDB 會從二進位日誌擷取資料到一般檔案。MariaDB 接著會執行 LOAD DATA LOCAL INFILE。根據上述範例，對於資料表、快取、日誌和本機檔案，此復原總共需要 40 GiB 或 10 GiB 的暫存磁碟空間。如果沒有至少 40 GiB 的可用磁碟空間，復原會失敗。

最佳化大型資料載入

對於大型資料載入，請停用二進位記錄，以減少額外負荷和磁碟空間需求。您可以將備份保留期設定為 0，以停用二進位記錄。載入完成後，將備份保留期還原至適當的非零值。如需詳細資訊，請參閱 設定表中的 修改 Amazon RDS 資料庫執行個體和 備份保留期間。

注意

如果資料庫執行個體是僅供讀取複本的來源資料庫執行個體，則您無法將備份保留期設定為 0。

在載入資料之前，我們建議您建立資料庫快照。如需詳細資訊，請參閱管理手動備份。

InnoDB

復原記錄和復原選項的下列資訊支援將 InnoDB 交易保持為小型，以最佳化資料庫效能。

了解 InnoDB 復原記錄

復原是一種記錄機制，可啟用交易復原，並支援多版本並行控制 (MVCC)。

對於 MariaDB 10.11 和更低版本，復原日誌存放在 InnoDB 系統資料表空間 （通常是 ibdata1) 中，並保留直到清除執行緒將其移除為止。因此，大型資料載入交易可能會導致系統資料表空間變得相當大，並耗用您無法回收的磁碟空間，除非您重新建立資料庫。

對於所有 MariaDB 版本，清除執行緒必須等待移除任何復原日誌，直到最舊的作用中交易遞交或轉返為止。如果資料庫在載入期間處理其他交易，其復原日誌也會累積且無法移除，即使交易遞交且沒有其他交易需要 MVCC 的復原日誌。在這種情況下，所有交易，包括唯讀交易，都會變慢。此速度變慢是因為所有交易都會存取任何交易變更的所有資料列，而不只是載入交易。實際上，交易必須掃描復原日誌，避免長時間執行的載入交易在復原日誌清除期間遭到清除。這會影響存取修改資料列的任何操作的效能。

InnoDB 交易復原選項

雖然 InnoDB 最佳化遞交操作，但大型交易轉返速度緩慢。為了加快復原速度，請執行point-in-time復原或還原資料庫快照。如需詳細資訊，請參閱時間點復原及還原至資料庫執行個體。

資料匯入格式

MariaDB 支援兩種資料匯入格式：平面檔案和 SQL。檢閱每個格式的相關資訊，以判斷符合您需求的最佳選項。

一般檔案

對於小型交易，請使用 載入一般檔案LOAD DATA LOCAL INFILE。相較於使用 SQL，此資料匯入格式可提供下列優點：

• 減少網路流量

• 降低資料傳輸成本

• 減少資料庫處理開銷

• 處理速度更快

LOAD DATA LOCAL INFILE 會將整個一般檔案載入為一筆交易。保持個別檔案的大小較小，以獲得下列優點：

• 恢復功能 – 您可以追蹤哪些檔案已載入。如果在載入期間發生問題，您可以挑選離開的位置。您可能需要將一些資料重新傳輸到 Amazon RDS，但使用小型檔案時，重新傳輸的數量最少。

• 平行資料載入 – 如果您有足夠的 IOPS 和網路頻寬進行單一檔案載入，平行載入可以節省時間。

• 負載速率控制 – 如果您的資料負載對其他程序造成負面影響，您可以透過增加檔案之間的間隔來控制負載速率。

大型交易可減少使用 LOAD DATA LOCAL INFILE 匯入資料的好處。當您無法將大量資料分解為較小的檔案時，請考慮使用 SQL。

SQL

相較於一般檔案，SQL 具有一個主要優勢：您可以輕鬆保持交易大小較小。不過，SQL 可能需要比一般檔案更長的載入時間。此外，在失敗之後，可能很難判斷要繼續的位置，您無法重新啟動 mariadb-dump 檔案。如果在載入 mariadb-dump 檔案時發生失敗，您必須先修改或取代檔案，才能繼續載入。或者，在您修正失敗原因之後，您可以還原至載入前的時間點並重新傳送檔案。如需詳細資訊，請參閱時間點復原。

針對資料庫檢查點使用 Amazon RDS 資料庫快照

如果您在沒有二進位記錄的情況下長時間載入資料，例如數小時或數天，請使用資料庫快照來提供資料安全的定期檢查點。每個資料庫快照都會建立資料庫執行個體的一致複本，做為系統故障或資料損毀事件期間的復原點。由於資料庫快照速度很快，因此經常檢查點對負載效能的影響最小。您可以刪除先前的資料庫快照，而不會影響資料庫耐久性或復原功能。如需資料庫快照的詳細資訊，請參閱 管理手動備份。

縮短資料庫載入時間

以下項目是減少載入時間的其他秘訣：

• 在將資料載入 MariaDB 資料庫之前建立所有次要索引。與其他資料庫系統不同，MariaDB 會在新增或修改次要索引時重建整個資料表。此程序會建立新的資料表，其中包含索引變更、複製所有資料，以及捨棄原始資料表。

• 依主索引鍵順序載入資料。對於 InnoDB 資料表，這可以減少 75%–80% 的載入時間，並將資料檔案大小減少 50%。

• 將 foreign_key_checks設定為 以停用外部金鑰限制0。對於使用 載入的平面檔案，這通常是必要的LOAD DATA LOCAL INFILE。對於任何載入，停用外部金鑰檢查可加速資料載入。載入完成後，將 foreign_key_checks設定為 1並驗證資料，以重新啟用限制條件。

• 除非接近資源限制，否則請平行載入資料。若要跨多個資料表區段啟用並行載入，請在適當時使用分割的資料表。

• 為了降低 SQL 執行開銷， 會將多個INSERT陳述式合併為單一多值INSERT操作。 會自動mariadb-dump實作此最佳化。

• 將 innodb_flush_log_at_trx_commit設定為 ，以減少 InnoDB 日誌 IO 操作0。載入完成後，還原innodb_flush_log_at_trx_commit至 1。

  警告

  innodb_flush_log_at_trx_commit 將 設定為 0會導致 InnoDB 每秒排清其日誌，而不是在每次遞交時排清日誌。此設定可提高效能，但可能會在系統故障期間造成交易遺失的風險。

• 如果您要將資料載入至沒有僅供讀取複本的資料庫執行個體，請將 sync_binlog設定為 0。載入完成後，還原sync_binlog parameter至 1。

• 在將資料庫執行個體轉換為異地同步備份部署之前，將資料載入單一可用區資料庫執行個體。如果資料庫執行個體已經使用異地同步備份部署，我們不建議切換到單一異地同步備份部署以進行資料載入。這樣做只會提供邊際改善