

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Opsi migrasi untuk database MySQL dan MariaDB besar
<a name="migration-options"></a>

Anda dapat memilih dari berbagai pilihan untuk bermigrasi dari database MySQL atau MariaDB lokal ke Amazon Relational Database Service (Amazon RDS) atau instans database Amazon Aurora MySQL. Memilih pendekatan dan alat migrasi yang tepat sangat penting untuk migrasi yang sukses, dan dalam panduan ini, Anda mengevaluasi opsi berdasarkan kegunaan, ukuran data, dan persyaratan waktu henti Anda.

Berikut ini adalah alat dan pendekatan migrasi umum yang tersedia untuk memigrasikan database MySQL multi-terabyte yang dikelola sendiri secara efisien ke instans database Amazon RDS, Aurora, atau Amazon Elastic Compute Cloud (Amazon EC2):
+ [Percona XtraBackup](percona-xtrabackup.md)(Fisik)
+ [MyDumper](mydumper.md)(Logis)
+ [mysqldump dan mysqlpump](mysqldump-and-mysqlpump.md)(Logis)
+ [Pisahkan cadangan](split-backup.md)(Fisik, logis, atau keduanya)

Berikut ini adalah alat dan pendekatan migrasi umum yang tersedia untuk memigrasikan database multi-terabyte yang kompatibel dengan MySQL (seperti MariaDB) secara efisien ke instans database Amazon RDS, Aurora, atau Amazon EC2:
+ [MyDumper](mydumper.md)(Logis)
+ [mysqldump dan mysqlpump](mysqldump-and-mysqlpump.md)(Logis)
+ [Pisahkan cadangan](split-backup.md)(Fisik, logis, atau keduanya)

Untuk setiap alat migrasi, ada beberapa pendekatan yang dapat Anda gunakan untuk mentransfer file cadangan database besar ke file AWS Cloud. Opsi disediakan untuk setiap alat, dan Anda juga dapat menggunakan Amazon S3 File Gateway. Untuk informasi selengkapnya, lihat [Menggunakan Amazon S3 File Gateway untuk mentransfer file cadangan](amazon-s3-file-gateway.md) dalam panduan ini.

# Percona XtraBackup
<a name="percona-xtrabackup"></a>

**penting**  
Percona tidak XtraBackup didukung untuk MariaDB versi 10.3 atau yang lebih baru dan hanya didukung sebagian untuk versi 10.1 dan 10.2.

[Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/index.html) adalah perangkat lunak cadangan hangat sumber terbuka umum untuk MySQL dan MariaDB yang membuat cadangan non-pemblokiran untuk mesin penyimpanan InnoDB dan XtraDB. Ia bekerja dengan server MySQL atau MariaDB. Untuk informasi lebih lanjut tentang alat dan beberapa fitur dan manfaatnya, lihat [Tentang Percona XtraBackup di dokumentasi Percona](https://docs.percona.com/percona-xtrabackup/8.0/about-xtrabackup.html). XtraBackup 

Alat ini menggunakan pendekatan migrasi fisik. Ini langsung menyalin direktori data MySQL atau MariaDB dan file di dalamnya. Untuk database besar, seperti yang lebih besar dari 100 GB, ini dapat memberikan waktu pemulihan yang jauh lebih baik daripada beberapa alat lainnya. Anda membuat cadangan database sumber lokal, memigrasikan file cadangan ke cloud, lalu memulihkan cadangan pada instans database target yang baru.

Diagram berikut menunjukkan langkah-langkah tingkat tinggi yang terlibat dalam migrasi database dengan menggunakan file cadangan XtraBackup Percona. Bergantung pada ukuran file cadangan, ada dua opsi yang tersedia untuk mentransfer cadangan ke bucket Amazon Simple Storage Service (Amazon S3) di bucket. AWS Cloud



![\[Diagram migrasi XtraBackup file Percona dan memulihkannya pada instance DB. AWS\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/percona-xtrabackup-migration-aws.png)


Berikut ini adalah langkah-langkah untuk menggunakan Percona XtraBackup untuk memigrasikan database ke: AWS Cloud

1. Instal Percona XtraBackup di server lokal. [Jika Anda menggunakan Amazon Aurora MySQL versi 2 atau Amazon RDS, lihat Menginstal Percona 2.4. XtraBackup](https://docs.percona.com/percona-xtrabackup/2.4/installation.html) Jika Anda menggunakan Amazon Aurora MySQL versi 3, lihat Menginstal Percona 8.0 di dokumentasi [ XtraBackupPercona](https://docs.percona.com/percona-xtrabackup/8.0/installation.html). XtraBackup

1. Buat cadangan lengkap dari sumber MySQL atau database MariaDB. Untuk petunjuk untuk Percona XtraBackup 2.4, lihat Cadangan [lengkap](https://docs.percona.com/percona-xtrabackup/2.4/backup_scenarios/full_backup.html). Untuk petunjuk untuk Percona XtraBackup 8.0, lihat [Membuat cadangan lengkap](https://docs.percona.com/percona-xtrabackup/8.0/create-full-backup.html).

1. Transfer file cadangan melalui internet dengan menggunakan layanan atau alat yang disetujui di organisasi Anda, seperti berikut ini:
   + [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
   + [AWS Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/client-vpn-user-what-is.html)
   + [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
   + [Amazon S3 File Gateway](https://docs.aws.amazon.com/filegateway/latest/files3/what-is-file-s3.html) (Untuk informasi lebih lanjut, lihat [Menggunakan Amazon S3 File Gateway untuk mentransfer file cadangan](amazon-s3-file-gateway.md) di panduan ini.)
   + [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/getting-started/hands-on/backup-to-s3-cli/)

1. Dari bucket Amazon S3, pulihkan file cadangan ke instance database target. Untuk petunjuk, lihat yang berikut ini:
   + Untuk Edisi yang kompatibel dengan Aurora MySQL, lihat Memigrasi [data dari MySQL menggunakan bucket Amazon S3 dalam dokumentasi Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.Restore).
   + Untuk Amazon RDS for MySQL atau Amazon EC2, [lihat Mengimpor data ke instans MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.Other.html) DB.
   + Untuk Amazon RDS for MariaDB atau Amazon EC2, [lihat Mengimpor data ke instans MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MariaDB.Procedural.Importing.html).

1. (Opsional) Anda dapat mengatur replikasi antara database sumber dan instance database target. Anda dapat menggunakan replikasi log biner (binlog) untuk mengurangi waktu henti. Untuk informasi selengkapnya, lihat berikut ini:
   + [Mengatur konfigurasi sumber replikasi](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) dalam dokumentasi MySQL
   + Untuk Amazon Aurora, lihat yang berikut ini:
     + [Menyinkronkan cluster DB MySQL Amazon Aurora dengan database MySQL menggunakan replikasi dalam](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) dokumentasi Aurora
     + [Menggunakan replikasi binlog di Amazon Aurora dalam](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) dokumentasi Aurora
   + Untuk Amazon RDS, lihat yang berikut ini:
     + [Bekerja dengan replikasi MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) dalam dokumentasi Amazon RDS
     + [Bekerja dengan replikasi MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) dalam dokumentasi Amazon RDS
   + Untuk Amazon EC2, lihat yang berikut ini:
     + [Menyiapkan Replikasi Berbasis Posisi File Log Biner](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) dalam dokumentasi MySQL
     + [Menyiapkan Replika](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) dalam dokumentasi MySQL
     + [Menyiapkan Replikasi](https://mariadb.com/kb/en/setting-up-replication/) dalam dokumentasi MariaDB

## Keuntungan
<a name="advantages-percona-xtrabackup"></a>
+ Karena Percona XtraBackup menggunakan pendekatan migrasi fisik, proses pemulihan biasanya lebih cepat daripada alat yang menggunakan pendekatan migrasi logis. Ini karena kinerjanya dibatasi oleh disk atau throughput jaringan daripada sumber daya komputasi yang diperlukan untuk pemrosesan data.
+ Karena proses pemulihan adalah salinan langsung file dari bucket S3 ke instance database target, file Percona biasanya memulihkan lebih cepat daripada XtraBackup file cadangan yang dibuat dengan alat lain.
+ Percona mudah beradaptasi XtraBackup . Misalnya, mendukung beberapa utas untuk membantu Anda menyalin file lebih cepat dan mendukung kompresi untuk mengurangi ukuran cadangan.

## Batasan
<a name="limitations-percona-xtrabackup"></a>
+ Pencadangan offline tidak dimungkinkan karena Percona XtraBackup harus memiliki akses ke server database sumber.
+ Percona hanya XtraBackup dapat digunakan pada sistem dengan arsitektur sistem yang identik. Misalnya, tidak mungkin mengembalikan cadangan database sumber yang berjalan di Intel untuk Windows Server ke server target ARM untuk Linux.
+ Percona XtraBackup tidak didukung untuk MariaDB versi 10.3 atau yang lebih baru, dan hanya didukung sebagian untuk MariaDB versi 10.2 dan versi 10.1. Untuk informasi lebih lanjut, lihat [ XtraBackup Ikhtisar Percona: Kompatibilitas dengan MariaDB di basis pengetahuan MariaDB](https://mariadb.com/kb/en/percona-xtrabackup-overview/#compatibility-with-mariadb).
+ Anda tidak dapat menggunakan Percona XtraBackup untuk memulihkan database MariaDB sumber ke instance database MySQL target, seperti Amazon RDS for MySQL atau Aurora MySQL yang kompatibel.
+ Total volume data dan jumlah objek yang dapat Anda simpan dalam bucket S3 tidak terbatas, namun ukuran file maksimum adalah 5 TB. Jika file cadangan Anda melebihi 5 TB, Anda dapat membaginya menjadi beberapa file yang lebih kecil.
+ Saat `innodb_file_per_table` pengaturan dimatikan, Percona XtraBackup tidak mendukung cadangan sebagian yang menggunakan`--tables`,,,, `--tables-exclude``--tables-file`, `--databases` atau. `--databases-exclude` `--databases-file` Untuk informasi selengkapnya tentang Percona XtraBackup versi 2.4, lihat Pencadangan [sebagian](https://docs.percona.com/percona-xtrabackup/2.4/innobackupex/partial_backups_innobackupex.html). Untuk informasi selengkapnya tentang Percona XtraBackup versi 8.0, lihat [Membuat cadangan sebagian](https://docs.percona.com/percona-xtrabackup/8.0/create-partial-backup.html).

## Praktik terbaik
<a name="best-practices-percona-xtrabackup"></a>
+ Untuk meningkatkan kinerja proses pencadangan, lakukan hal berikut:
  + Salin beberapa file secara paralel dengan menggunakan [--parallel=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-parallel) <threads>
  + Kompres beberapa file secara paralel dengan menggunakan [--compress-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-compress-threads) <threads>
  + Meningkatkan memori dengan menggunakan [--use-memory=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-use-memory) <size>
  + [Enkripsi beberapa file secara paralel dengan menggunakan --encrypt-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-encrypt-threads) <threads>
+ Pastikan bahwa ada cukup ruang pada server sumber untuk mengambil file backup database.
+ Hasilkan cadangan database dengan file format Percona xbstream (.xbstream). Untuk informasi lebih lanjut, lihat [Ikhtisar biner xbstream di dokumentasi](https://docs.percona.com/percona-xtrabackup/8.0/xbstream-binary-overview.html) XtraBackup Percona.

# MyDumper
<a name="mydumper"></a>

[MyDumper](https://github.com/mydumper/mydumper#what-is-mydumper)(GitHub) adalah alat migrasi logis sumber terbuka yang terdiri dari dua utilitas:
+ MyDumper mengekspor cadangan database MySQL yang konsisten. Ini mendukung pencadangan database dengan menggunakan beberapa thread paralel, hingga satu utas per inti CPU yang tersedia.
+ myloader membaca file cadangan yang dibuat oleh MyDumper, menghubungkan ke instance database target, dan kemudian mengembalikan database.

Diagram berikut menunjukkan langkah-langkah tingkat tinggi yang terlibat dalam migrasi database dengan menggunakan MyDumper file cadangan. Diagram arsitektur ini mencakup tiga opsi untuk memigrasikan file cadangan dari pusat data lokal ke instans EC2 di. AWS Cloud



![\[Diagram migrasi file MyDumper cadangan dan menggunakan myloader untuk mengembalikannya pada instance AWS DB.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mydumper-myloader-migration-aws.png)


Berikut ini adalah langkah-langkah yang digunakan MyDumper untuk memigrasikan database ke AWS Cloud:

1. Instal MyDumper dan myloader. Untuk petunjuk, lihat [Cara menginstal mydumper/myloader](https://github.com/mydumper/mydumper#how-to-install-mydumpermyloader) (). GitHub

1. Gunakan MyDumper untuk membuat cadangan dari sumber MySQL atau database MariaDB. Untuk petunjuk, lihat [Cara menggunakan MyDumper](https://github.com/mydumper/mydumper#how-to-use-mydumper).

1. Pindahkan file cadangan ke instans EC2 AWS Cloud dengan menggunakan salah satu pendekatan berikut:

   **Pendekatan 3A** — Pasang sistem file [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) [Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) ke server lokal yang menjalankan instance database Anda. Anda dapat menggunakan AWS Direct Connect atau Site-to-Site VPN membuat koneksi. Anda dapat langsung mencadangkan database ke berbagi file yang dipasang, atau Anda dapat melakukan pencadangan dalam dua langkah dengan mencadangkan database ke sistem file lokal dan kemudian mengunggahnya ke volume FSx atau EFS yang dipasang. Selanjutnya, pasang sistem file Amazon FSx atau Amazon EFS, yang juga dipasang di server lokal, pada instans EC2.

   **Pendekatan 3B** — Gunakan REST API AWS CLI, AWS SDK, atau Amazon S3 untuk memindahkan file cadangan secara langsung dari server lokal ke bucket S3. Jika bucket S3 target berada jauh dari pusat data, Anda dapat menggunakan [Amazon S3 Transfer Acceleration untuk mentransfer](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) file lebih cepat. Wilayah AWS Gunakan sistem file [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) untuk memasang bucket S3 pada instans EC2.

   **Pendekatan 3C** — Instal AWS DataSync agen di pusat data lokal, lalu gunakan [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)untuk memindahkan file cadangan ke bucket Amazon S3. Gunakan sistem file [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) untuk memasang bucket S3 pada instans EC2.
**catatan**  
Anda juga dapat menggunakan Amazon S3 File Gateway untuk mentransfer file cadangan database besar ke bucket S3 di file. AWS Cloud Untuk informasi selengkapnya, lihat [Menggunakan Amazon S3 File Gateway untuk mentransfer file cadangan](amazon-s3-file-gateway.md) dalam panduan ini.

1. Gunakan myloader untuk memulihkan cadangan pada instance database target. Untuk petunjuk, lihat [penggunaan myloader](https://github.com/mydumper/mydumper_docs/blob/0e5cd71a5549c8a5de0105adf4d5f95953eadb67/myloader_usage.rst) (GitHub).

1. (Opsional) Anda dapat mengatur replikasi antara database sumber dan instance database target. Anda dapat menggunakan replikasi log biner (binlog) untuk mengurangi waktu henti. Untuk informasi selengkapnya, lihat berikut ini:
   + [Mengatur konfigurasi sumber replikasi](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) dalam dokumentasi MySQL
   + Untuk Amazon Aurora, lihat yang berikut ini:
     + [Menyinkronkan cluster DB MySQL Amazon Aurora dengan database MySQL menggunakan replikasi dalam](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) dokumentasi Aurora
     + [Menggunakan replikasi binlog di Amazon Aurora dalam](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) dokumentasi Aurora
   + Untuk Amazon RDS, lihat yang berikut ini:
     + [Bekerja dengan replikasi MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) dalam dokumentasi Amazon RDS
     + [Bekerja dengan replikasi MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) dalam dokumentasi Amazon RDS
   + Untuk Amazon EC2, lihat yang berikut ini:
     + [Menyiapkan Replikasi Berbasis Posisi File Log Biner](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) dalam dokumentasi MySQL
     + [Menyiapkan Replika](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) dalam dokumentasi MySQL
     + [Menyiapkan Replikasi](https://mariadb.com/kb/en/setting-up-replication/) dalam dokumentasi MariaDB

## Keuntungan
<a name="advantages-mydumper"></a>
+ MyDumper mendukung paralelisme dengan menggunakan multi-threading, yang meningkatkan kecepatan operasi pencadangan dan pemulihan.
+ MyDumper menghindari rutinitas konversi set karakter yang mahal, yang membantu memastikan kode sangat efisien.
+ MyDumper menyederhanakan tampilan data dan parsing dengan menggunakan dumping file terpisah untuk tabel dan metadata.
+ MyDumper memelihara snapshot di semua thread dan menyediakan posisi akurat log primer dan sekunder.
+ Anda dapat menggunakan Perl Compatible Regular Expressions (PCRE) untuk menentukan apakah akan menyertakan atau mengecualikan tabel atau database.

## Batasan
<a name="limitations-mydumper"></a>
+ Anda dapat memilih alat yang berbeda jika proses transformasi data Anda memerlukan file dump menengah dalam format datar, bukan format SQL.
+ myloader tidak mengimpor akun pengguna database secara otomatis. Jika Anda memulihkan cadangan ke Amazon RDS atau Aurora, buat ulang pengguna dengan izin yang diperlukan. Untuk informasi selengkapnya, lihat [Menguasai hak istimewa akun pengguna](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.MasterAccounts.html) di dokumentasi Amazon RDS. Jika memulihkan cadangan ke instans database Amazon EC2, Anda dapat mengekspor akun pengguna database sumber secara manual dan mengimpornya ke instans EC2.

## Praktik terbaik
<a name="best-practices-mydumper"></a>
+ Konfigurasikan MyDumper untuk membagi setiap tabel menjadi segmen, seperti 10.000 baris di setiap segmen, dan tulis setiap segmen dalam file terpisah. Ini memungkinkan untuk mengimpor data secara paralel nanti.
+ Jika Anda menggunakan mesin InnoDB, gunakan `--trx-consistency-only` opsi untuk meminimalkan penguncian.
+ Menggunakan MyDumper untuk mengekspor database dapat menjadi read-intensive, dan prosesnya dapat berdampak pada kinerja keseluruhan database produksi. Jika Anda memiliki contoh database replika, jalankan proses ekspor dari replika. Sebelum Anda menjalankan ekspor dari replika, hentikan thread SQL replikasi. Ini membantu proses ekspor berjalan lebih cepat.
+ Jangan mengekspor database selama jam kerja puncak. Menghindari jam sibuk dapat menstabilkan kinerja database produksi utama Anda selama ekspor database.
+ Amazon RDS for MySQL tidak mendukung plugin. `keyring_aws` Untuk informasi selengkapnya, lihat [Masalah dan batasan yang diketahui](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.KnownIssuesAndLimitations.html#MySQL.Concepts.Limits.KeyRing). Untuk memigrasikan tabel terenkripsi lokal ke instans Amazon RDS, dalam skrip cadangan, Anda harus menghapus atau dari sintaks. `ENCRYPTION` `DEFAULT ENCRYPTION` `CREATE TABLE` Untuk enkripsi saat istirahat, Anda dapat menggunakan kunci AWS Key Management Service (AWS KMS). Untuk informasi selengkapnya, lihat [Mengenkripsi sumber daya Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html).

# mysqldump dan mysqlpump
<a name="mysqldump-and-mysqlpump"></a>

[mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) dan [mysqlpump adalah alat cadangan database asli untuk MySQL](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html). MariaDB mendukung mysqldump tetapi tidak mendukung mysqlpump. Kedua alat ini membuat backup logis dan merupakan bagian dari program klien MySQL. mysqldump mendukung pemrosesan single-threaded. mysqlpump mendukung pemrosesan paralel database dan objek dalam database, untuk mempercepat proses dump. Itu diperkenalkan di MySQL versi 5.7.8. mysqlpump telah dihapus di MySQL versi 8.4.

Diagram berikut menunjukkan langkah-langkah tingkat tinggi yang terlibat dalam migrasi database dengan menggunakan file cadangan mysqldump atau mysqlpump.



![\[Diagram migrasi file cadangan mysqldump atau mysqlpump dan memulihkannya pada instance DB. AWS\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mysqldump-mysqlpump-migration-aws.png)


Berikut ini adalah langkah-langkah untuk menggunakan mysqldump atau mysqlpump untuk memigrasikan database ke: AWS Cloud

1. Instal MySQL Shell di server lokal. Untuk petunjuk, lihat [Menginstal MySQL Shell dalam dokumentasi MySQL](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-install-linux-quick.html). Ini menginstal mysqldump dan mysqlpump.

1. Menggunakan mysqldump atau mysqlpump, buat cadangan sumber, database lokal. [Untuk petunjuk, lihat [mysqldump dan mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html)[di dokumentasi MySQL](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html), atau lihat Membuat Backup dengan mysqldump dalam dokumentasi MariaDB.](https://mariadb.com/kb/en/making-backups-with-mysqldump/) [Untuk informasi selengkapnya tentang menjalankan program MySQL dan menentukan opsi, lihat Menggunakan program MySQL.](https://dev.mysql.com/doc/refman/8.0/en/programs-using.html)

1. Pindahkan file cadangan ke instans EC2 AWS Cloud dengan menggunakan salah satu pendekatan berikut:

   **Pendekatan** **3A** — Pasang sistem file [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) [Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) ke server lokal yang menjalankan instance database Anda. Anda dapat menggunakan AWS Direct Connect atau Site-to-Site VPN membuat koneksi. Anda dapat langsung mencadangkan database ke berbagi file yang dipasang, atau Anda dapat melakukan pencadangan dalam dua langkah dengan mencadangkan database ke sistem file lokal dan kemudian mengunggahnya ke volume FSx atau EFS yang dipasang. Selanjutnya, pasang sistem file Amazon FSx atau Amazon EFS, yang juga dipasang di server lokal, pada instans EC2.

   **Pendekatan 3B** — Gunakan REST API AWS CLI, AWS SDK, atau Amazon S3 untuk memindahkan file cadangan secara langsung dari server lokal ke bucket S3. Jika bucket S3 target berada jauh dari pusat data, Anda dapat menggunakan [Amazon S3 Transfer Acceleration untuk mentransfer](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) file lebih cepat. Wilayah AWS Gunakan sistem file [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) untuk memasang bucket S3 pada instans EC2.

   **Pendekatan 3C** — Instal AWS DataSync agen di pusat data lokal, lalu gunakan [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)untuk memindahkan file cadangan ke bucket Amazon S3. Gunakan sistem file [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) untuk memasang bucket S3 pada instans EC2.
**catatan**  
Anda juga dapat menggunakan Amazon S3 File Gateway untuk mentransfer file cadangan database besar ke bucket S3 di file. AWS Cloud Untuk informasi selengkapnya, lihat [Menggunakan Amazon S3 File Gateway untuk mentransfer file cadangan](amazon-s3-file-gateway.md) dalam panduan ini.

1. Gunakan metode pemulihan asli untuk memulihkan cadangan pada database target. Untuk petunjuknya, lihat [Memuat Ulang Pencadangan Format SQL](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html) dalam dokumentasi MySQL, atau lihat [Memulihkan](https://mariadb.com/kb/en/restoring-data-from-dump-files/) Data dari File Dump dalam dokumentasi MariaDB.

1. (Opsional) Anda dapat mengatur replikasi antara database sumber dan instance database target. Anda dapat menggunakan replikasi log biner (binlog) untuk mengurangi waktu henti. Untuk informasi selengkapnya, lihat berikut ini:
   + [Mengatur konfigurasi sumber replikasi](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) dalam dokumentasi MySQL
   + Untuk Amazon Aurora, lihat yang berikut ini:
     + [Menyinkronkan cluster DB MySQL Amazon Aurora dengan database MySQL menggunakan replikasi dalam](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) dokumentasi Aurora
     + [Menggunakan replikasi binlog di Amazon Aurora dalam](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) dokumentasi Aurora
   + Untuk Amazon RDS, lihat yang berikut ini:
     + [Bekerja dengan replikasi MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) dalam dokumentasi Amazon RDS
     + [Bekerja dengan replikasi MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) dalam dokumentasi Amazon RDS
   + Untuk Amazon EC2, lihat yang berikut ini:
     + [Menyiapkan Replikasi Berbasis Posisi File Log Biner](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) dalam dokumentasi MySQL
     + [Menyiapkan Replika](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) dalam dokumentasi MySQL
     + [Menyiapkan Replikasi](https://mariadb.com/kb/en/setting-up-replication/) dalam dokumentasi MariaDB

## Keuntungan
<a name="advantages-mysqlpump-mysqldump"></a>
+ mysqldump dan mysqlpump termasuk dalam instalasi MySQL Server
+ File cadangan yang dihasilkan oleh alat-alat ini dalam format yang lebih mudah dibaca.
+ Sebelum memulihkan file cadangan, Anda dapat memodifikasi file.sql yang dihasilkan dengan menggunakan editor teks standar.
+ Anda dapat membuat cadangan tabel, database, atau bahkan pemilihan data tertentu.
+ mysqldump dan mysqlpump adalah arsitektur mesin independen.

## Batasan
<a name="limitations-mysqlpump-mysqldump"></a>
+ mysqldump adalah proses pencadangan single-threaded. Kinerja untuk mengambil cadangan baik untuk database kecil, tetapi bisa menjadi tidak efisien ketika ukuran cadangan lebih besar dari 10 GB.
+ Backup file dalam format logis sangat banyak, terutama ketika disimpan sebagai teks, dan sering lambat untuk membuat dan memulihkan.
+ Pemulihan data bisa lambat karena menerapkan kembali pernyataan SQL dalam instans DB target melibatkan pemrosesan disk I/O dan CPU intensif untuk penyisipan, pembuatan indeks, dan penegakan batasan integritas referensial.
+ Utilitas mysqlpump tidak didukung untuk versi MySQL lebih awal dari 5.7.8 atau untuk versi 8.4 dan yang lebih baru.
+ Secara default, mysqlpump tidak mengambil cadangan dari database sistem, seperti atau. `performance_schema` `sys` Untuk membuat cadangan bagian dari database sistem, beri nama secara eksplisit di baris perintah.
+ mysqldump tidak mencadangkan pernyataan InnoDB. `CREATE TABLESPACE`

**catatan**  
Cadangan pernyataan CREATE TABLESPACE dan database sistem hanya berguna ketika Anda memulihkan cadangan database MySQL atau MariaDB ke instance EC2. Cadangan ini tidak digunakan untuk Amazon RDS atau Aurora.

## Praktik terbaik
<a name="best-practices-mysqlpump-mysqldump"></a>
+ Ketika Anda memulihkan cadangan database, nonaktifkan pemeriksaan kunci, seperti`FOREIGN_KEY_CHECKS`, pada tingkat sesi dalam database target. Ini meningkatkan kecepatan restorasi.
+ Pastikan pengguna database memiliki [hak istimewa](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html) yang cukup untuk membuat dan memulihkan cadangan.

# Pisahkan cadangan
<a name="split-backup"></a>

Strategi *pencadangan terpisah* adalah ketika Anda memigrasikan server database besar dengan membagi cadangan menjadi beberapa bagian. Anda dapat menggunakan pendekatan yang berbeda untuk memigrasikan setiap bagian cadangan. Ini bisa menjadi pilihan terbaik untuk kasus penggunaan berikut:
+ **Server database besar tetapi database individu kecil** — Ini adalah pendekatan yang baik ketika ukuran total server database berlipat ganda TBs tetapi ukuran masing-masing individu, database pengguna independen kurang dari 1 TB. Untuk mengurangi periode migrasi secara keseluruhan, Anda dapat memigrasikan database individual secara terpisah dan paralel.

  Mari kita gunakan contoh server database 2 TB lokal. Server ini terdiri dari empat database yang masing-masing 0,5 TB. Anda dapat mengambil cadangan dari setiap database individu secara terpisah. Saat memulihkan cadangan, Anda dapat memulihkan semua database pada instance secara paralel, atau jika database independen, Anda dapat memulihkan setiap cadangan pada instance terpisah. Ini adalah praktik terbaik untuk memulihkan database independen pada instance terpisah, alih-alih memulihkannya pada instance yang sama. Untuk informasi selengkapnya, lihat Praktik terbaik dalam panduan ini.
+ **Server database besar tetapi tabel database individu kecil** — Ini adalah pendekatan yang baik ketika ukuran total server database berlipat ganda TBs tetapi ukuran setiap tabel database independen kurang dari 1 TB. Untuk mengurangi periode migrasi secara keseluruhan, Anda dapat memigrasikan tabel independen satu per satu.

  Mari kita gunakan contoh database pengguna tunggal yaitu 1 TB, dan itu adalah satu-satunya database di server database lokal. Ada 10 tabel dalam database, dan masing-masing 100 GB. Anda dapat mengambil cadangan dari masing-masing tabel secara terpisah. Saat memulihkan cadangan, Anda dapat mengembalikan semua tabel pada instance secara paralel.
+ **Database berisi tabel beban kerja transaksional dan non-transaksional** — Mirip dengan kasus penggunaan sebelumnya, Anda dapat menggunakan pendekatan cadangan terpisah ketika Anda memiliki tabel beban kerja transaksional dan non-transaksional dalam database yang sama.

  Mari kita gunakan contoh database 2 TB yang terdiri dari 0,5 TB tabel beban kerja kritis yang digunakan untuk pemrosesan transaksi online (OLTP) dan tabel 1,5 TB tunggal yang digunakan untuk pengarsipan data lama. Anda dapat mengambil cadangan semua objek database kecuali tabel arsip sebagai transaksi tunggal dan cadangan yang konsisten. Kemudian, Anda hanya mengambil cadangan terpisah dari tabel arsip. Untuk cadangan tabel arsip, Anda juga dapat mempertimbangkan untuk mengambil beberapa backup paralel dengan menggunakan kondisi untuk membagi jumlah baris dalam file cadangan. Berikut ini adalah contohnya:

  ```
  mysqldump -p your_db1 --tables your_table1 --where="column1 between 1 and 1000000 " > your_table1_part1.sql
  mysqldump -p your_db1 --tables your_table1 --where="column1 between 1000001 and 2000000 " > your_table1_part2.sql
  mysqldump -p your_db1 --tables your_table1 --where="column1 > 2000000 " > your_table1_part3.sql
  ```

  Saat memulihkan file cadangan, Anda dapat mengembalikan cadangan beban kerja transaksional dan cadangan tabel arsip secara paralel.
+ **Batasan sumber daya komputasi** — Jika sumber daya komputasi terbatas di server lokal, seperti CPU, memori, atau I/O disk, hal ini dapat memengaruhi stabilitas dan kinerja saat mengambil cadangan. Alih-alih mengambil cadangan lengkap, Anda dapat membaginya menjadi beberapa bagian.

  Misalnya, server produksi lokal mungkin penuh dengan beban kerja dan memiliki sumber daya CPU yang terbatas. Jika Anda mengambil cadangan tunggal dari database multi-terabyte di server ini, ia dapat mengkonsumsi sumber daya CPU tambahan dan berdampak buruk pada server produksi. Alih-alih mengambil cadangan database lengkap, bagilah cadangan menjadi beberapa bagian, seperti masing-masing 2-3 tabel.