Menggunakan basis data yang kompatibel dengan MySQL sebagai sumber untuk AWS DMS

Anda dapat memigrasikan data dari database yang kompatibel dengan MySQL (MySQL, MariaDB, atau Amazon Aurora MySQL) menggunakan Database Migration Service. AWS

Untuk informasi tentang versi MySQL AWS DMS yang mendukung sebagai sumber, lihat. Sumber untuk AWS DMS

Anda dapat menggunakan SSL untuk mengenkripsi koneksi antara titik akhir yang kompatibel dengan MySQL dan instans replikasi. Untuk informasi lebih lanjut tentang penggunaan SSL dengan titik akhir yang kompatibel dengan MySQL, lihat Menggunakan SSL dengan AWS Database Migration Service.

Di bagian berikut, syarat “dikelola sendiri” berlaku untuk setiap basis data yang diinstal baik lokal atau di Amazon EC2. Syarat "terkelola AWS" berlaku untuk basis data apa pun di Amazon RDS, Amazon Aurora, atau Amazon S3.

Untuk detail tambahan tentang bekerja dengan database yang kompatibel dengan MySQL dan AWS DMS, lihat bagian berikut.

Migrasi dari MySQL ke MySQL menggunakan AWS DMS

Untuk migrasi heterogen, tempat Anda bermigrasi dari mesin database selain MySQL ke database MySQL AWS DMS , hampir selalu merupakan alat migrasi terbaik untuk digunakan. Tetapi untuk migrasi homogen, di mana Anda bermigrasi dari database MySQL ke database MySQL, kami sarankan Anda menggunakan proyek migrasi migrasi data homogen. migrasi data homogen menggunakan alat database asli untuk memberikan kinerja dan akurasi migrasi data yang ditingkatkan jika dibandingkan dengan. AWS DMS

Menggunakan database yang kompatibel dengan MySQL sebagai sumber AWS DMS

Sebelum Anda mulai bekerja dengan database MySQL sebagai sumber AWS DMS untuk, pastikan bahwa Anda memiliki prasyarat berikut. Prasyarat ini berlaku untuk sumber yang dikelola sendiri atau yang dikelola sendiri. AWS

Anda harus memiliki akun AWS DMS yang memiliki peran Admin Replikasi. Peran itu memerlukan keistimewaan berikut:

• REPLICATION CLIENT — Hak istimewa ini diperlukan untuk tugas CDC saja. Dengan kata lain, full-load-only tugas tidak memerlukan hak istimewa ini.

• REPLICATION SLAVE — Hak istimewa ini diperlukan untuk tugas CDC saja. Dengan kata lain, full-load-only tugas tidak memerlukan hak istimewa ini.

• SUPER — Hak istimewa ini diperlukan hanya dalam versi MySQL sebelum 5.6.6.

AWS DMS Pengguna juga harus memiliki hak SELECT untuk tabel sumber yang ditunjuk untuk replikasi.

Menggunakan database yang kompatibel dengan MySQL yang dikelola sendiri sebagai sumber AWS DMS

Anda dapat menggunakan basis data yang kompatibel dengan MySQL yang dikelola sendiri berikut sebagai sumber untuk AWS DMS:

• MySQL Community Edition

• MySQL Standard Edition

• MySQL Enterprise Edition

• MySQL Cluster Carrier Grade Edition

• MariaDB Community Edition

• MariaDB Enterprise Edition

• MariaDB Column Store

Untuk menggunakan CDC, pastikan untuk mengaktifkan binary logging. Untuk mengaktifkan binary logging, parameter berikut harus dikonfigurasi di MySQL my.ini (Windows) atau file my.cnf (UNIX).

Parameter	Nilai
server_id	Atur parameter ini supaya nilainya 1 atau lebih besar.
log-bin	Atur jalur ke berkas log biner, seperti log-bin=E:\MySql_Logs\BinLog. Jangan sertakan ekstensi file.
binlog_format	Atur parameter ini menjadi ROW. Kami merekomendasikan pengaturan ini selama replikasi karena dalam kasus-kasus tertentu ketika binlog_format diatur menjadi STATEMENT, inkonsistensi dapat terjadi ketika mereplikasi data ke target. Mesin basis data juga menulis data yang tidak konsisten yang mirip dengan target ketika binlog_format diatur menjadi MIXED, karena mesin basis data secara otomatis beralih ke logging berbasis STATEMENT yang dapat mengakibatkan penulisan data yang tidak konsisten pada basis data target.
expire_logs_days	Atur parameter ini supaya nilainya 1 atau lebih besar. Untuk mencegah penggunaan ruang disk secara berlebihan, kami sarankan Anda tidak menggunakan nilai default 0.
binlog_checksum	Setel parameter ini NONE untuk DMS versi 3.4.7 atau sebelumnya.
binlog_row_image	Atur parameter ini menjadi FULL.
log_slave_updates	Atur parameter ini menjadi TRUE jika Anda menggunakan MySQL atau MariaDB replika baca sebagai sumber.

Jika sumber Anda menggunakan mesin basis data NDB (clustered), parameter berikut harus dikonfigurasi untuk mengaktifkan CDC pada tabel yang menggunakan mesin penyimpanan. Tambahkan perubahan ini di MySQL my.ini (Windows) atau file my.cnf (UNIX).

Parameter	Nilai
ndb_log_bin	Atur parameter ini menjadi ON. Nilai ini memastikan bahwa perubahan dalam clustered tables tercatat di log biner.
ndb_log_update_as_write	Atur parameter ini menjadi OFF. Nilai ini mencegah penulisan pernyataan UPDATE sebagai pernyataan INSERT dalam log biner.
ndb_log_updated_only	Atur parameter ini menjadi OFF. Nilai ini memastikan bahwa log biner berisi seluruh baris dan bukan hanya kolom yang berubah.

Menggunakan database yang kompatibel dengan MySQL AWS-managed sebagai sumber untuk AWS DMS

Anda dapat menggunakan database yang kompatibel dengan MySQL AWS-managed berikut sebagai sumber untuk: AWS DMS

• MySQL Community Edition

• MariaDB Community Edition

• Edisi yang Kompatibel dengan Amazon Aurora MySQL

Saat menggunakan database yang kompatibel dengan MySQL AWS-managed sebagai sumber AWS DMS, pastikan Anda memiliki prasyarat berikut untuk CDC:

• Untuk mengaktifkan log biner untuk RDS untuk MySQL dan untuk RDS untuk MariaDB, aktifkan backup otomatis pada tingkat instans. Untuk mengaktifkan log biner untuk cluster MySQL Aurora, ubah variabel dalam grup parameter. binlog_format

  Untuk informasi selengkapnya tentang menyiapkan pencadangan otomatis, lihat Bekerja dengan pencadangan otomatis di Panduan Pengguna Amazon RDS.

  Untuk informasi selengkapnya tentang menyiapkan pencatatan biner untuk database Amazon RDS for MySQL, lihat Menyetel format logging biner di Panduan Pengguna Amazon RDS.

  Untuk informasi selengkapnya tentang menyiapkan pencatatan biner untuk klaster MySQL Aurora, lihat Bagaimana cara mengaktifkan pencatatan biner untuk klaster MySQL Amazon Aurora saya? .

• Jika Anda berencana untuk menggunakan CDC, aktifkan logging biner. Untuk informasi selengkapnya tentang menyiapkan pencatatan biner untuk database Amazon RDS for MySQL, lihat Menyetel format logging biner di Panduan Pengguna Amazon RDS.

• Pastikan bahwa log biner tersedia untuk AWS DMS. Karena database yang kompatibel dengan MySQL AWS-managed membersihkan log biner sesegera mungkin, Anda harus menambah lamanya waktu log tetap tersedia. Misalnya, untuk meningkatkan retensi log hingga 24 jam, jalankan perintah berikut.

  
   call mysql.rds_set_configuration('binlog retention hours', 24);
                      

• Atur parameter binlog_format menjadi "ROW".

  catatan

  Di MySQL atau binlog_format MariaDB, adalah parameter dinamis, jadi Anda tidak perlu reboot untuk membuat nilai baru berlaku. Namun, nilai baru hanya akan berlaku untuk sesi baru. Jika Anda beralih binlog_format ke ROW untuk tujuan replikasi, database Anda masih dapat membuat log biner berikutnya menggunakan MIXED format, jika sesi tersebut dimulai sebelum Anda mengubah nilainya. Ini dapat AWS DMS mencegah menangkap semua perubahan pada database sumber dengan benar. Saat Anda mengubah binlog_format pengaturan pada database MariaDB atau MySQL, pastikan untuk memulai ulang database untuk menutup semua sesi yang ada, atau memulai ulang aplikasi apa pun yang melakukan operasi DHTML (Data Manipulation Language). Memaksa database Anda untuk memulai ulang semua sesi setelah mengubah binlog_format parameter ROW akan memastikan bahwa database Anda menulis semua perubahan basis data sumber berikutnya menggunakan format yang benar, sehingga AWS DMS dapat menangkap perubahan tersebut dengan benar.

• Atur parameter binlog_row_image ke "Full".

• Atur binlog_checksum parameter ke "NONE" untuk DMS versi 3.4.7 atau sebelumnya. Untuk informasi selengkapnya tentang pengaturan parameter di Amazon RDS MySQL, lihat Menggunakan backup otomatis dalam Panduan Pengguna Amazon RDS.

• Jika Anda menggunakan Amazon RDS MySQL atau Amazon RDS MariaDB baca replika sebagai sumber, aktifkan cadangan pada replika baca, dan pastikan parameter disetel ke. log_slave_updates TRUE

Batasan dalam menggunakan database MySQL sebagai sumber AWS DMS

Ketika menggunakan basis data MySQL sebagai sumber, pertimbangkan hal berikut:

• Change data capture (CDC) tidak didukung untuk Amazon RDS MySQL 5.5 atau versi yang lebih rendah. Untuk Amazon RDS MySQL, Anda harus menggunakan versi 5.6, 5.7, atau 8.0 untuk mengaktifkan CDC. CDC didukung untuk sumber MySQL 5.5 yang dikelola sendiri.

• Untuk CDC, CREATE TABLE, ADD COLUMN, dan DROP COLUMN mengubah jenis data kolom, dan renaming a columndidukung. Namun, DROP TABLE, RENAME TABLE, dan pembaruan yang dibuat untuk atribut lainnya, seperti nilai default kolom, nullabilitas kolom, set karakter dan sebagainya, tidak didukung.

• Untuk tabel yang dipartisi pada sumber, saat Anda mengatur mode persiapan tabel Target ke Drop tabel pada target, AWS DMS buat tabel sederhana tanpa partisi apa pun pada target MySQL. Untuk memirasi tabel yang dipartisi ke tabel yang dipartisi pada target, buatlah terlebih dahulu tabel yang dipartisi pada basis data MySQL target.

• Menggunakan pernyataan ALTER TABLE table_name ADD COLUMN column_name untuk menambahkan kolom ke awal (FIRST) atau tengah tabel (AFTER) tidak didukung. Kolom selalu ditambahkan ke akhir tabel.

• CDC tidak didukung ketika nama tabel memuat huruf besar dan huruf kecil, dan mesin sumber di-host pada sistem operasi dengan nama file yang tidak peka kapital. Contohnya adalah Microsoft Windows atau OS X menggunakan HFS+.

• Anda dapat menggunakan Aurora MySQL Edition Serverless v1 yang kompatibel dengan Aurora untuk muatan penuh, tetapi Anda tidak dapat menggunakannya untuk CDC. Ini karena Anda tidak dapat mengaktifkan prasyarat untuk MySQL. Untuk informasi lebih lanjut, lihat Kelompok parameter dan Aurora Serverless v1.

  Aurora MySQL yang kompatibel dengan Edition Serverless v2 mendukung CDC.

• Atribut AUTO_INCREMENT pada kolom tidak bermigrasi ke kolom basis data target.

• Menangkap perubahan ketika log biner tidak disimpan di penyimpanan blok standar tidak didukung. Sebagai contoh, CDC tidak bekerja ketika log biner disimpan di Amazon S3.

• AWS DMS membuat tabel target dengan mesin penyimpanan InnoDB secara default. Jika Anda perlu menggunakan mesin penyimpanan selain InnoDB, Anda harus secara manual membuat tabel dan bermigrasi ke mesin tersebut menggunakan mode do nothing.

• Anda tidak dapat menggunakan replika Aurora MySQL sebagai sumber AWS DMS kecuali mode tugas migrasi DMS Anda Migrasikan data yang ada —hanya memuat penuh.

• Jika sumber yang kompatibel dengan MySQL berhenti selama beban penuh, tugas AWS DMS tidak berhenti dengan kesalahan. Tugas berhasil berakhir, tetapi target mungkin tidak sinkron dengan sumber. Jika hal ini terjadi, ulang kembali tugas atau muat ulang tabel yang terpengaruh.

• Indeks yang dibuat pada porsi nilai kolom tidak bermigrasi. Sebagai contoh, indeks CREATE INDEX first_ten_chars ON pelanggan (name(10)) tidak dibuat pada target.

• Dalam beberapa kasus, tugas dikonfigurasi untuk tidak mereplikasi LOB (” SupportLobs "salah dalam pengaturan tugas atau kolom Jangan sertakan LOB dipilih di konsol tugas). Dalam kasus ini, AWS DMS tidak memigrasikan kolom MEDIUMBLOB, LONGBLOB, MEDIUMTEXT, dan LONGTEXT apa pun ke target.

  Kolom BLOB, TINYBLOB, TEXT, dan TINYTEXT tidak terpengaruh dan dimigrasi ke target.

• Tabel data temporal atau tabel sistem-versi tidak didukung pada sumber MariaDB dan basis data target.

• Jika bermigrasi antara dua cluster MySQL Amazon RDS Aurora, titik akhir sumber MySQL RDS Aurora harus berupa instance baca/tulis, bukan instance replika.

• AWS DMS saat ini tidak mendukung migrasi tampilan untuk MariaDB.

• AWS DMS tidak mendukung perubahan DDL untuk tabel yang dipartisi untuk MySQL. Untuk melewati suspensi tabel untuk perubahan DDL partisi selama CDC, atur skipTableSuspensionForPartitionDdl ke. true

• AWS DMS hanya mendukung transaksi XA di versi 3.5.0 dan lebih tinggi. Versi sebelumnya tidak mendukung transaksi XA. AWS DMS tidak mendukung transaksi XA di MariaDB versi 10.6. Untuk informasi lebih lanjut, lihat Support untuk transaksi XA berikut ini.

• AWS DMS tidak menggunakan GTID untuk replikasi, bahkan jika data sumber mengandungnya.

• AWS DMS tidak mendukung kompresi transaksi log biner.

• AWS DMS tidak menyebarkan peristiwa ON DELETE CASCADE dan ON UPDATE CASCADE untuk database MySQL menggunakan mesin penyimpanan InnoDB. Untuk peristiwa ini, MySQL tidak menghasilkan peristiwa binlog untuk mencerminkan operasi cascaded pada tabel anak. Akibatnya, tidak AWS DMS dapat mereplikasi perubahan yang sesuai ke tabel anak. Untuk informasi selengkapnya, lihat Indeks, Kunci Asing, atau Pembaruan atau Penghapusan Cascade Tidak Dimigrasi.

• AWS DMS tidak menangkap perubahan pada kolom yang dihitung (VIRTUALdanGENERATED ALWAYS). Untuk mengatasi batasan ini, lakukan hal berikut:

  • Pra-buat tabel target dalam database target, dan buat AWS DMS tugas dengan DO_NOTHING atau pengaturan tugas TRUNCATE_BEFORE_LOAD beban penuh.

  • Tambahkan aturan transformasi untuk menghapus kolom yang dihitung dari cakupan tugas. Untuk informasi tentang aturan transformasi, lihat Aturan dan tindakan transformasi.

Support untuk transaksi XA

Transaksi Extended Architecture (XA) adalah transaksi yang dapat digunakan untuk mengelompokkan serangkaian operasi dari beberapa sumber daya transaksional menjadi satu transaksi global yang andal. Transaksi XA menggunakan protokol komit dua fase. Secara umum, menangkap perubahan saat ada transaksi XA terbuka dapat menyebabkan hilangnya data. Jika database Anda tidak menggunakan transaksi XA, Anda dapat mengabaikan izin ini dan konfigurasi IgnoreOpenXaTransactionsCheck dengan menggunakan nilai tuli. TRUE Untuk mulai mereplikasi dari sumber yang memiliki transaksi XA, lakukan hal berikut:

• Pastikan bahwa pengguna AWS DMS endpoint memiliki izin berikut:

  grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';

• Atur pengaturan titik akhir IgnoreOpenXaTransactionsCheck kefalse.

catatan

AWS DMS tidak mendukung transaksi XA pada MariaDB Source DB versi 10.6.

Pengaturan titik akhir saat menggunakan MySQL sebagai sumber AWS DMS

Anda dapat menggunakan pengaturan endpoint untuk mengkonfigurasi database sumber MySQL Anda mirip dengan menggunakan atribut koneksi tambahan. Anda menentukan pengaturan saat Anda membuat titik akhir sumber menggunakan AWS DMS konsol, atau dengan menggunakan create-endpoint perintah di AWS CLI, dengan sintaks --my-sql-settings '{"EndpointSetting": "value", ...}' JSON.

Tabel berikut menunjukkan pengaturan endpoint yang dapat Anda gunakan dengan MySQL sebagai sumber.

Nama	Deskripsi
EventsPollInterval	Menentukan seberapa sering memeriksa log biner untuk perubahan/peristiwa baru ketika basis data diam. Nilai default: 5 Nilai yang valid: 1–60. Contoh: --my-sql-settings '{"EventsPollInterval": 5}' Dalam contoh, AWS DMS memeriksa perubahan dalam log biner setiap lima detik.
ExecuteTimeout	Untuk AWS DMS versi 3.4.7 dan yang lebih tinggi, menetapkan batas waktu pernyataan klien untuk titik akhir sumber MySQL, dalam hitungan detik. Nilai default: 60 Contoh: --my-sql-settings '{"ExecuteTimeout": 1500}'
ServerTimezone	Menentukan zona waktu untuk basis data sumber MySQL. Contoh: --my-sql-settings '{"ServerTimezone": "US/Pacific"}'
AfterConnectScript	Menentukan script untuk menjalankan segera setelah AWS DMS menghubungkan ke endpoint. Tugas migrasi terus berjalan terlepas jika pernyataan SQL berhasil atau gagal. Nilai yang valid: Satu atau lebih pernyataan SQL yang valid, yang dimulai dengan titik koma. Contoh: --my-sql-settings '{"AfterConnectScript": "ALTER SESSION SET CURRENT_SCHEMA=system"}'
CleanSrcMetadataOnMismatch	Membersihkan dan membuat kembali tabel metadata informasi pada instans replikasi ketika terjadi ketidakcocokan. Misalnya, dalam situasi di mana menjalankan alter DDL di tabel dapat mengakibatkan informasi yang berbeda mengenai tabel cache dalam instans replikasi. .Boolean Nilai default: false Contoh: --my-sql-settings '{"CleanSrcMetadataOnMismatch": false}'
skipTableSuspensionForPartitionDdl	AWS DMS tidak mendukung perubahan DDL untuk tabel yang dipartisi untuk MySQL. Untuk AWS DMS versi 3.4.6 dan yang lebih tinggi, atur ini untuk true melewatkan suspensi tabel untuk perubahan DDL partisi selama CDC. AWS DMS mengabaikan partitioned-table-related DDL, dan terus memproses perubahan log biner lebih lanjut. Nilai default: false Contoh: --my-sql-settings '{"skipTableSuspensionForPartitionDdl": true}'
IgnoreOpenXaTransactionsCheck	Untuk AWS DMS versi 3.5.0 dan yang lebih tinggi, tentukan apakah tugas harus mengabaikan transaksi XA terbuka saat memulai. Setel ini ke false jika sumber Anda memiliki transaksi XA. Nilai default: true Contoh: --my-sql-settings '{"IgnoreOpenXaTransactionsCheck": false}'

Jenis data sumber untuk MySQL

Tabel berikut menunjukkan tipe data sumber database MySQL yang didukung saat AWS DMS menggunakan dan pemetaan AWS DMS default dari tipe data.

Untuk informasi tentang cara melihat jenis data yang dipetakan dalam target, lihat bagian titik akhir target yang Anda gunakan.

Untuk informasi tambahan tentang tipe AWS DMS data, lihatTipe data untuk AWS Database Migration Service.

Tipe data MySQL	AWS DMS tipe data
INT	INT4
BIGINT	INT8
MEDIUMINT	INT4
TINYINT	INT1
SMALLINT	INT2
UNSIGNED TINYINT	UINT1
UNSIGNED SMALLINT	UINT2
MEDIUMINT YANG TIDAK DITANDATANGANI	UINT4
INT TIDAK DITANDATANGANI	UINT4
UNSIGNED BIGINT	UINT8
DECIMAL(10)	NUMERIC (10,0)
BINARY	BYTES(1)
BIT	BOOLEAN
BIT(64)	BYTES(8)
BLOB	BYTE (65535)
LONGBLOB	BLOB
MEDIUMBLOB	BLOB
TINYBLOB	BYTES(255)
DATE	DATE
DATETIME	DATETIME DATETIME tanpa nilai kurung direplikasi tanpa milidetik. DATETIME dengan nilai kurung 1 sampai 5 (sepertiDATETIME(5)) direplikasi dengan milidetik. Saat mereplikasi kolom DATETIME, waktunya tetap sama pada target. Itu tidak dikonversi ke UTC.
TIME	STRING
TIMESTAMP	DATETIME Saat mereplikasi kolom TIMESTAMP, waktu dikonversi ke UTC pada target.
YEAR	INT2
DOUBLE	REAL8
FLOAT	REAL(DOUBLE) Jika nilai FLOAT tidak berada dalam kisaran berikut, gunakan transformasi untuk memetakan FLOAT ke STRING. Untuk informasi lebih lanjut tentang transformasi, lihat Aturan dan tindakan transformasi. Rentang FLOAT yang didukung adalah -1.79E+308 hingga -2.23E-308, 0, dan 2.23E-308 hingga 1.79E+308
VARCHAR (45)	WSTRING (45)
VARCHAR (2000)	WSTRING (2000)
VARCHAR (4000)	WSTRING (4000)
VARBINARY (4000)	BYTES (4000)
VARBINARY (2000)	BYTE (2000)
CHAR	WSTRING
TEXT	WSTRING
LONGTEXT	NCLOB
MEDIUMTEXT	NCLOB
TINYTEXT	WSTRING (255)
GEOMETRY	BLOB
POINT	BLOB
LINESTRING	BLOB
POLYGON	BLOB
MULTIPOINT	BLOB
MULTILINESTRING	BLOB
MULTIPOLYGON	BLOB
GEOMETRYCOLLECTION	BLOB
ENUM	WSTRING (length) Di sini, length adalah panjang dari nilai terpanjang di ENUM.
SET	WSTRING (length) Di sini, length adalah total panjang semua nilai dalam SET, termasuk koma.
JSON	CLOB

catatan

Dalam beberapa kasus, Anda mungkin menentukan jenis data DATETIME dan TIMESTAMP dengan nilai “nol” (yaitu 0000-00-00). Jika demikian, pastikan bahwa basis data target dalam tugas replikasi mendukung nilai-nilai “nol” untuk jenis data DATETIME dan TIMESTAMP. Jika tidak, nilai-nilai ini dicatat sebagai null pada target.