Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
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, istilah “dikelola sendiri” berlaku untuk database apa pun yang diinstal baik lokal maupun 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.
Topik
Menggunakan database yang kompatibel dengan MySQL sebagai sumber AWS DMS
Menggunakan database yang kompatibel dengan MySQL yang dikelola sendiri sebagai sumber AWS DMS
Menggunakan database yang kompatibel dengan MySQL AWS-managed sebagai sumber AWS DMS
Batasan dalam menggunakan database MySQL sebagai sumber AWS DMS
Pengaturan titik akhir saat menggunakan MySQL sebagai sumber AWS DMS
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.
Berikan hak istimewa berikut jika Anda menggunakan penilaian premi khusus MySQL.
grant select on mysql.user to <dms_user>;
grant select on mysql.db to <dms_user>;
grant select on mysql.tables_priv to <dms_user>;
grant select on mysql.role_edges to <dms_user> #only for MySQL version 8.0.11 and higher
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 |
---|---|
|
Atur parameter ini supaya nilainya 1 atau lebih besar. |
|
Atur jalur ke berkas log biner, seperti |
|
Atur parameter ini menjadi |
|
Atur parameter ini supaya nilainya 1 atau lebih besar. Untuk mencegah penggunaan ruang disk secara berlebihan, kami sarankan Anda tidak menggunakan nilai default 0. |
|
Setel parameter ini |
|
Atur parameter ini menjadi |
|
Atur parameter ini menjadi |
Jika Anda menggunakan replika baca MySQL atau MariaDB sebagai sumber untuk tugas migrasi DMS menggunakan Migrasi data yang ada dan mereplikasi mode perubahan yang sedang berlangsung, ada kemungkinan kehilangan data. DMS tidak akan menulis transaksi selama full load atau CDC dalam kondisi berikut:
Transaksi telah dilakukan pada instance utama sebelum tugas DMS dimulai.
Transaksi belum dilakukan ke replika sampai setelah tugas DMS dimulai, karena jeda antara instance utama dan replika.
Semakin lama jeda antara instance utama dan replika, semakin besar potensi kehilangan data.
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 |
---|---|
|
Atur parameter ini menjadi |
|
Atur parameter ini menjadi |
|
Atur parameter ini menjadi |
Menggunakan database yang kompatibel dengan MySQL AWS-managed sebagai sumber 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 pencatatan 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 pencatatan 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 beralihbinlog_format
keROW
untuk tujuan replikasi, database Anda masih dapat membuat log biner berikutnya menggunakanMIXED
format, jika sesi tersebut dimulai sebelum Anda mengubah nilainya. Ini dapat AWS DMS mencegah menangkap semua perubahan pada database sumber dengan benar. Saat Anda mengubahbinlog_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 mengubahbinlog_format
parameterROW
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
, danDROP COLUMN
mengubah jenis data kolom, danrenaming a column
didukung. 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
untuk menambahkan kolom ke awal (FIRST) atau tengah tabel (AFTER) tidak didukung. Kolom selalu ditambahkan ke akhir tabel.table_name
ADD COLUMNcolumn_name
-
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 beban 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 LOBs (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 atau lebih tinggi Untuk informasi selengkapnya, lihat berikut. Support untuk transaksi XA
-
AWS DMS tidak digunakan GTIDs untuk replikasi, bahkan jika data sumber mengandungnya.
-
AWS DMS tidak mendukung log biner yang disempurnakan Aurora MySQL.
-
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 (
VIRTUAL
danGENERATED 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 tugasTRUNCATE_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.
-
Karena keterbatasan MySQL internal AWS DMS , dapat BINLOGs memproses tidak lebih besar dari ukuran 4GB. BINLOGs lebih besar dari 4GB dapat mengakibatkan kegagalan tugas DMS atau perilaku tak terduga lainnya. Anda harus mengurangi ukuran transaksi untuk menghindari BINLOGs lebih besar dari 4GB.
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 deafult. 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 atau lebih tinggi.
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 '{"
JSON.EndpointSetting"
:
"value"
, ...
}'
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: 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: |
ServerTimezone |
Menentukan zona waktu untuk basis data sumber MySQL. Contoh: |
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: |
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: Contoh: |
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 Nilai default: Contoh: |
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 Nilai default: Contoh: |
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 (seperti 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 () Di sini, |
SET |
WSTRING () Di sini, |
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.