View a markdown version of this page

Menggunakan MySQL-compatible database sebagai sumber untuk AWS DMS - AWS Layanan Migrasi Database
Migrasi MySQL ke MySQLMenggunakan MySQL sebagai sumberMenggunakan MySQL yang dikelola sendiri sebagai sumberMenggunakan AWS-managed MySQL sebagai sumberSumber Aurora MySQL 8.4Keterbatasan pada MySQL sebagai sumberDukungan untuk transaksi XAPengaturan titik akhirJenis data sumber untuk MySQL

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

Menggunakan MySQL-compatible database sebagai sumber untuk AWS DMS

Anda dapat memigrasikan data dari MySQL-compatible database apa pun (MySQL, MariaDB, atau Amazon Aurora MySQL) menggunakan Layanan Migrasi AWS Database.

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

Anda dapat menggunakan SSL untuk mengenkripsi koneksi antara MySQL-compatible titik akhir dan instance replikasi. Untuk informasi selengkapnya tentang menggunakan SSL dengan MySQL-compatible titik akhir, lihatMenggunakan 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 MySQL-compatible database dan AWS DMS, lihat bagian berikut.

catatan

Saat mengonfigurasi aturan pemetaan AWS Database Migration Service (AWS DMS), penting untuk menghindari penggunaan wildcard (%) untuk nama database atau skema. Sebagai gantinya, Anda harus secara eksplisit menentukan hanya database yang dibuat pengguna yang perlu dimigrasikan. Menggunakan karakter wildcard mencakup semua database dalam proses migrasi, termasuk database sistem yang tidak diperlukan pada instance target. Karena pengguna master MySQL Amazon RDS tidak memiliki izin yang diperlukan untuk mengimpor data ke database sistem target, upaya untuk memigrasikan database sistem ini gagal.

Migrasi dari MySQL ke MySQL menggunakan AWS DMS

Untuk migrasi heterogen, di mana Anda bermigrasi dari mesin database selain MySQL ke database MySQL, hampir selalu AWS DMS 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 yang homogen. migrasi data homogen menggunakan alat database asli untuk memberikan kinerja dan akurasi migrasi data yang lebih baik jika dibandingkan dengan. AWS DMS

Menggunakan MySQL-compatible database apa pun sebagai sumber untuk AWS DMS

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

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, tugas beban penuh saja tidak memerlukan hak istimewa ini.

    catatan

    Untuk MariaDB versi 10.5.2+, Anda dapat menggunakan BINLOG MONITOR - ini adalah pengganti untuk KLIEN REPLIKASI.

  • REPLICATION SLAVE — Hak istimewa ini diperlukan untuk tugas CDC saja. Dengan kata lain, tugas beban penuh saja tidak memerlukan hak istimewa ini.

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

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

Berikan hak istimewa berikut jika Anda menggunakan penilaian MySQL-specific premigrasi:

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
grant select on performance_schema.replication_connection_status to <dms_user>;  #Required for primary instance validation - MySQL version 5.7 and higher only

Jika Anda menggunakan sumber RDS dan berencana untuk menjalankan penilaian MySQL-specific premigrasi, tambahkan izin berikut:

grant select on mysql.rds_configuration to <dms_user>;  #Required for binary log retention check

Jika parameter BatchEnable true diperlukan untuk memberikan:

grant create temporary tables on `<schema>`.* to <dms_user>;

Menggunakan MySQL-compatible database yang dikelola sendiri sebagai sumber AWS DMS

Anda dapat menggunakan MySQL-compatible database 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

atau

binlog_expire_logs_seconds

Parameter expire_logs_days tidak digunakan lagi sejak MySQL 8.0 dan dihapus di MySQL 8.4. Untuk informasi selengkapnya, lihat Vari abel Server dan Status dan Opsi Ditambahkan, Tidak Digunakan, atau Dihapus di MySQL 8.4 sejak 8.0.

Gunakan expire_logs_days parameter untuk MySQL 5.x. Kami menyarankan Anda menyetel parameter ini ke 1 atau lebih besar, lihat Opsi dan Variabel Pencatatan Biner.

Gunakan binlog_expire_logs_seconds parameter untuk MySQL 8.0 dan yang lebih baru. Kami menyarankan Anda mengatur parameter ini ke nilai 86400 detik (1 hari) atau lebih besar. Lihat Opsi dan Variabel Pencatatan Biner.

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 Anda menggunakan replika baca MySQL atau MariaDB sebagai sumber untuk tugas migrasi DMS menggunakan Migrasi data yang ada dan mereplik asi mode perubahan yang sedang berlangsung, ada kemungkinan kehilangan data. DMS tidak akan menulis transaksi selama beban penuh atau CDC dalam kondisi berikut:

  • Transaksi telah dikomitmen ke instance utama sebelum tugas DMS dimulai.

  • Transaksi belum dikomitmen 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

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 AWS- MySQL-compatible database yang dikelola sebagai sumber untuk AWS DMS

Anda dapat menggunakan MySQL-compatible database AWS-managed berikut sebagai sumber untuk: AWS DMS

  • MySQL Community Edition

  • MariaDB Community Edition

  • MySQL-Compatible Edisi Amazon Aurora

Saat menggunakan MySQL-compatible database yang AWS dikelola -sebagai sumber untuk AWS DMS, pastikan Anda memiliki prasyarat berikut untuk CDC:

  • Untuk mengaktifkan log biner untuk RDS untuk MySQL dan untuk RDS untuk MariaDB, aktifkan pencadangan otomatis di tingkat instance. Untuk mengaktifkan log biner untuk cluster Aurora MySQL, ubah variabel binlog_format dalam grup parameter.

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

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

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

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

  • Pastikan log biner tersedia untuk AWS DMS. Karena AWS MySQL-compatible database yang dikelola 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

    Pada MySQL atau MariaDB, binlog_format 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 DML (Data Manipulation Language). Memaksa database Anda untuk memulai ulang semua sesi setelah mengubah binlog_format ROW parameter untuk memastikan bahwa database Anda menulis semua perubahan database sumber berikutnya menggunakan format yang benar, sehingga AWS DMS dapat menangkap perubahan tersebut dengan benar.

  • Atur parameter binlog_row_image ke "Full".

  • Setel binlog_checksum parameter "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 replika baca Amazon RDS MySQL atau Amazon RDS MariaDB sebagai sumber, aktifkan pencadangan pada replika baca, dan pastikan log_slave_updates parameter disetel ke. TRUE

Untuk informasi selengkapnya tentang perubahan keamanan Aurora MySQL 8.4, lihat Keamanan dengan Amazon Aurora MySQL dan Manajemen Kata Sandi dengan Amazon Aurora dan Manajer Rahasia di Panduan Pengguna Amazon Aurora.

Pertimbangan untuk sumber Aurora MySQL 8.4

Aurora MySQL 8.4 memperkenalkan perubahan keamanan yang dapat mempengaruhi konektivitas titik akhir AWS DMS sumber. Tinjau hal berikut sebelum memutakhirkan sumber Aurora MySQL Anda ke versi 8.4.

Penegakan TLS

Aurora MySQL 8.4 require_secure_transport diatur ON secara default, artinya semua koneksi harus menggunakan TLS. Jika titik akhir AWS DMS sumber Anda terhubung ke Aurora MySQL 8.4 dan mode SSL diatur ke none, koneksi akan ditolak. Jika mode SSL titik akhir Anda diset el ke none, Anda akan menerima kesalahan berikut:MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. Setel mode SSL titik akhir untuk verify-ca atau verify-full. Kedua mode memerlukan sertifikat CA. Atau, atur require_secure_transport ke OFF grup parameter cluster Aurora Anda untuk mengizinkan koneksi yang tidak dienkripsi.

catatan

Aurora MySQL 8.4 hanya mendukung suite sandi GCM untuk TLS 1.2. Semua CBC-mode sandi telah dihapus. AWS DMS menggunakan TLS 1.2 untuk titik akhir MySQL dan Aurora MySQL dan akan menegosiasikan secara otomatis sandi GCM yang didukung. Jika Anda memiliki konfigurasi sandi khusus, pastikan konfigurasi tersebut menyertakan salah satu sandi yang didukung berikut: ECDHE-RSA-AES128-GCM-SHA256,, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES128-GCM-SHA256 atau. ECDHE-ECDSA-AES256-GCM-SHA384

catatan

AWS DMS tidak mendukung TLS 1.3 untuk titik akhir MySQL. Ini tidak mempengaruhi konektivitas ke Aurora MySQL 8.4, karena Aurora MySQL 8.4 terus mendukung TLS 1.2.

Otentikasi (Aurora MySQL dan RDS untuk MySQL 8.4)

Aurora MySQL 8.4 menggantikan default_authentication_plugin parameter denganauthentication_policy, yang default ke*:caching_sha2_password. Pengguna database yang ada mempertahankan plugin otentikasi mereka saat ini setelah peningkatan. Jika Anda membuat pengguna AWS DMS titik akhir baru setelah memutakhirkan, mereka akan menggunakan caching_sha2_password secara default kecuali Anda menyet authentication_policy el ke *:mysql_native_password dalam grup parameter cluster Anda.

Reset kata sandi pengguna utama

Setelah memutakhirkan ke Aurora MySQL 8.4, mengatur ulang kata sandi pengguna master melalui Konsol Manajemen AWS, CLI, atau melalui rotasi Secrets Manager mengatur plugin otentikasi pengguna master ke default yang ditentukan oleh parameter. authentication_policy Jika authentication_policy disetel ke nilai defaultnya (*:caching_sha2_password), plugin otentikasi pengguna master berubah dari mysql_native_password ke caching_sha2_password pada pengaturan ulang kata sandi berikutnya.

Jika titik akhir AWS DMS sumber Anda menggunakan akun pengguna utama, verifikasi konektivitas setelah pengaturan ulang kata sandi. Untuk menghindari perubahan plugin otentikasi, salah satunya:

  • Set authentication_policy el ke *:mysql_native_password dalam grup parameter cluster Anda sebelum mengatur ulang kata sandi, atau

  • Buat pengguna AWS DMS titik akhir khusus dengan plugin otentikasi yang ditentukan secara eksplisit (disarankan). Misalnya: CREATE USER 'dms_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

Batasan penggunaan database MySQL sebagai sumber untuk 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, ketika Anda mengatur mode persiapan tabel Target ke Drop tabel pada target, AWS DMS membuat 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 ALTER TABLE table_name ADD COLUMN column_name pernyataan untuk menambahkan kolom ke awal (PERTAMA) atau tengah tabel (SETELAH) tidak didukung untuk target relasional. Kolom selalu ditambahkan ke akhir tabel. Jika targetnya adalah Amazon S3 atau Amazon Kinesis Data Streams, penambahan kolom menggunakan FIRST atau AFTER didukung.

  • 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-Compatible Edition Serverless v1 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-Compatible 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. Misalnya, CDC tidak berfungsi saat 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 adalah Migrasikan data yang ada —hanya beban penuh.

  • Jika MySQL-compatible sumber dihentikan selama pemuatan penuh, AWS DMS tugas 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 Jangan sertakan kolom LOB dipilih di konsol tugas). Dalam kasus ini, AWS DMS tidak memigrasikan kolom MEDIUMBLOB, LONGBLOB, MEDIUMTEXT, dan LONGTEXT 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 Amazon RDS Aurora MySQL, titik akhir sumber RDS Aurora MySQL harus berupa read/write instance, 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, setel skipTableSuspensionForPartitionDdl ketrue.

  • 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 lebih lanjut, lihat berikut. Dukungan untuk transaksi XA

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

  • AWS DMS tidak mendukung log biner yang ditingkatkan 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 bertingkat pada tabel anak. Akibatnya, tidak AWS DMS dapat mereplikasi perubahan yang sesuai pada tabel anak. Untuk informasi selengkapnya, lihat Indeks, Kunci Asing, atau Pembaruan atau Penghapusan Cascade Tidak Dimigrasi.

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

    • Pre-create tabel target di database target, dan buat AWS DMS tugas dengan pengaturan tugas DO_NOTHING atau TRUNCATE_BEFORE_LOAD beban penuh.

    • Tambahkan aturan transformasi untuk menghapus kolom yang dihitung dari lingkup tugas. Untuk informasi tentang aturan transformasi, lihatAturan dan tindakan transformasi.

  • Karena keterbatasan internal MySQL, AWS DMS dapat memproses BinLogs tidak lebih besar dari ukuran 4GB. BinLogs yang lebih besar dari 4GB dapat mengakibatkan kegagalan tugas DMS atau perilaku tak terduga lainnya. Anda harus mengurangi ukuran transaksi untuk menghindari BinLog yang lebih besar dari 4GB.

  • AWS DMS tidak mendukung back-ticks (`) atau tanda kutip tunggal (') dalam skema, tabel, dan nama kolom.

  • AWS DMS tidak memigrasikan data dari kolom tak terlihat di database sumber Anda. Untuk menyertakan kolom ini dalam lingkup migrasi Anda, gunakan pernyataan ALTER TABLE untuk membuat kolom ini terlihat.

Dukungan untuk transaksi XA

Transaksi Extended Architecture (XA) adalah transaksi yang dapat digunakan untuk mengelompokkan serangkaian operasi dari beberapa sumber daya transaksional ke dalam 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 defaultTRUE. Untuk mulai mereplikasi dari sumber yang memiliki transaksi XA, lakukan hal berikut:

  • Pastikan pengguna AWS DMS titik akhir memiliki izin berikut:

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

  • Setel 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 titik akhir untuk mengonfigurasi database sumber MySQL Anda mirip dengan menggunakan atribut koneksi tambahan. Anda menentukan pengaturan saat 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 titik akhir yang dapat Anda gunakan dengan MySQL sebagai sumber.

Nama Deskripsi

ConnectionTimeout

Gunakan atribut koneksi tambahan (ECA) ini untuk mengatur batas waktu koneksi titik akhir untuk instance MySQL, dalam detik. Nilai bawaannya adalah 10 detik. Contoh ECA:ConnectionTimeout=30.
EventsPollInterval

Menentukan seberapa sering untuk memeriksa log biner untuk yang baru changes/events ketika database tidak aktif.

Nilai default: 5

Nilai yang valid: 1–60.

Contoh: --my-sql-settings '{"EventsPollInterval": 5}'

Dalam contoh, AWS DMS periksa perubahan dalam log biner setiap lima detik.
ExecuteTimeout

Untuk AWS DMS versi 3.4.7 dan yang lebih tinggi, tetapkan batas waktu pernyataan klien untuk titik akhir sumber MySQL, dalam 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 skrip untuk dijalankan segera setelah AWS DMS terhubung ke titik akhir. 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"}'
CleanSourceMetadataOnMismatch

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 '{"CleanSourceMetadataOnMismatch": 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, menyetel ini untuk true melewatkan suspensi tabel untuk perubahan DDL partisi selama CDC. AWS DMS mengabaikan DDL terkait tabel partisi, 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 menggunakan AWS DMS dan pemetaan default dari AWS DMS 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 AWS DMS tipe 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 TANPA TANDA TANGAN

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 tanda kurung direplikasi tanpa milidetik. DATETIME dengan nilai tanda kurung 1 hingga 5 (sepertiDATETIME(5)) direplikasi dengan milidetik.

Saat mereplikasi kolom DATETIME, waktu 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 dalam rentang 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.23 hingga 1.79E+308 E-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

STRING (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 nilai terpanjang dalam ENUM.

SET

WSTRING () length

Di sini, length adalah panjang total 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.