Replikasi mulai dari titik awal CDC Melakukan replikasi dua arah

Membuat tugas untuk replikasi yang sedang berlangsung menggunakan AWS DMS

Anda dapat membuat AWS DMS tugas yang menangkap perubahan yang sedang berlangsung dari penyimpanan data sumber. Anda dapat melakukan penangkapan ini saat Anda memigrasi data Anda. Anda juga dapat membuat tugas yang menangkap perubahan yang sedang berlangsung setelah menyelesaikan migrasi awal (beban penuh) ke penyimpanan data target yang didukung. Proses ini disebut replikasi atau change data capture (CDC). AWS DMS menggunakan proses ini ketika mereplikasi perubahan yang sedang berlangsung dari penyimpanan data sumber. Proses ini bekerja dengan mengumpulkan perubahan log basis data menggunakan API asli mesin basis data.

catatan

Anda dapat memigrasi tampilan hanya menggunakan tugas beban penuh. Jika tugas Anda adalah tugas hanya CDC atau tugas penuh beban yang dimulai CDC setelah selesai, migrasi hanya mencakup tabel dari sumber. Menggunakan full-load-only tugas, Anda dapat memigrasikan tampilan atau kombinasi tabel dan tampilan. Untuk informasi selengkapnya, lihat Menentukan pemilihan tabel dan transformasi aturan menggunakan JSON.

Setiap mesin sumber memiliki persyaratan konfigurasi khusus untuk mengekspos aliran perubahan ini ke akun pengguna tertentu. Kebanyakan mesin memerlukan beberapa konfigurasi tambahan untuk memungkinkan proses capture mengkonsumsi data perubahan dengan cara yang berarti, tanpa kehilangan data. Sebagai contoh, Oracle membutuhkan penambahan penebangan tambahan, dan MySQL membutuhkan baris-tingkat biner logging (bin logging).

Untuk membaca perubahan yang sedang berlangsung dari basis data sumber, AWS DMS menggunakan tindakan API khusus mesin untuk membaca perubahan dari log transaksi mesin sumber. Berikut ini adalah beberapa contoh bagaimana AWS DMS melakukan itu:

Untuk Oracle, AWS DMS gunakan API Oracle atau LogMiner API pembaca biner (bfile API) untuk membaca perubahan yang sedang berlangsung. AWS DMSmembaca perubahan yang sedang berlangsung dari log pengulangan online atau arsip berdasarkan nomor perubahan sistem (SCN).
Untuk Microsoft SQL Server, AWS DMS menggunakan MS-Replication atau MS-CDC untuk menulis informasi ke log transaksi SQL Server. Itu kemudian menggunakan fungsi fn_dblog() atau fn_dump_dblog() di SQL Server untuk membaca perubahan dalam log transaksi berdasarkan log sequence number (LSN).
Untuk MySQL, AWS DMS membaca perubahan dari log biner berbasis baris (binlog) dan mrmigrasi perubahan tersebut ke target.
Untuk PostgreSQL, AWS DMS meyiapkan slot replikasi logis dan menggunakan plugin test_decoding untuk membaca perubahan dari sumber dan memigrasi mereka ke target.
Untuk Amazon RDS sebagai sumber, kami sarankan memastikan bahwa backup diaktifkan untuk mengatur CDC. Kami juga merekomendasikan untuk memastikan bahwa basis data sumber dikonfigurasi untuk mempertahankan log perubahan untuk waktu yang cukup—24 jam biasanya cukup. Untuk pengaturan khusus untuk setiap titik akhir, lihat berikut ini:
- Amazon RDS for Mengkonfigurasi sumber AWS Oracle yang dikelola untuk AWS DMS Oracle:.
- Amazon RDS untuk MySQL dan Aurora MySQL:. Menggunakan database yang kompatibel dengan MySQL AWS-managed sebagai sumber untuk AWS DMS
- Amazon RDS untuk SQL Server:. Menyiapkan replikasi yang sedang berlangsung pada instance cloud SQL Server DB
- Amazon RDS untuk PostgreSQL dan Aurora PostgreSQL: PostgreSQL secara otomatis menyimpan WAL yang diperlukan.

Ada dua jenis tugas replikasi yang sedang berlangsung:

Beban penuh ditambah CDC – Tugas memigrasi data yang ada dan kemudian memperbarui basis data target berdasarkan perubahan basis data sumber.
Hanya CDC – Tugas memigrasi perubahan yang sedang berlangsung setelah Anda memiliki data pada basis data target Anda.

Melakukan replikasi mulai dari titik awal CDC

Anda dapat memulai tugas replikasi AWS DMS yang sedang berlangsung (hanya change data capture) dari beberapa titik. Sumber daya yang dimaksud meliputi:

Dari waktu mulai CDC kustom – Anda dapat menggunakan AWS Management Console atau AWS CLI untuk memberikan AWS DMS dengan timestamp di mana Anda ingin replikasi untuk dimulai. AWS DMS kemudian memulai tugas replikasi yang sedang berlangsung dari waktu mulai CDC kustom ini. AWS DMS mengonversi timestamp yang diberikan (dalam UTC) ke titik awal asli, seperti LSN untuk SQL Server atau SCN untuk Oracle. AWS DMS menggunakan metode khusus mesin untuk menentukan di mana untuk memulai tugas migrasi berdasarkan aliran perubahan mesin sumber.

catatan
Hanya dengan menyetel atribut StartFromContext koneksi ke stempel waktu yang diperlukan, Db2 sebagai sumber menawarkan waktu mulai CDC yang disesuaikan.
PostgreSQL sebagai sumber tidak mendukung waktu mulai CDC kustom. Hal ini karena mesin basis data PostgreSQL tidak memiliki cara untuk memetakan timestamp untuk LSN atau SCN seperti yang dilakukan Oracle dan SQL Server.
Dari titik awal CDC asli – Anda juga dapat memulai dari titik asli di log transaksi mesin sumber. Dalam beberapa kasus, Anda mungkin lebih memilih pendekatan ini karena timestamp dapat menunjukkan beberapa titik asli dalam log transaksi. AWS DMS mendukung fitur ini untuk titik akhir sumber berikut:
- Server SQL
- PostgreSQL
- Oracle
- MySQL
- MariaDB

Saat tugas dibuat, AWS DMS tandai titik awal CDC, dan itu tidak dapat diubah. Untuk menggunakan titik awal CDC yang berbeda, buat tugas baru.

Menentukan titik awal CDC asli

Titik awal asli CDC adalah titik di log mesin basis data yang mendefinisikan waktu di mana Anda dapat mulai CDC. Sebagai contoh, misalkan dump data massal telah diterapkan ke target. Anda dapat mencari titik awal asli untuk tugas khusus replikasi yang sedang berlangsung. Untuk menghindari inkonsistensi data, hati-hati memilih titik awal untuk tugas replikasi saja. DMS menangkap transaksi yang dimulai setelah titik awal CDC yang dipilih.

Berikut ini adalah contoh bagaimana Anda dapat menemukan CDC titik awal asli dari mesin sumber yang didukung:

Server SQL

Dalam SQL Server, log sequence number (LSN) memiliki tiga bagian:

Nomor urutan berkas log virtual (VLF)
Mulai offset dari blok log
Nomor slot

Contoh LSN adalah sebagai berikut: 00000014:00000061:0001

Untuk mendapatkan titik awal untuk tugas migrasi SQL Server berdasarkan pengaturan cadangan log transaksi Anda, gunakan fungsi fn_dblog() atau fn_dump_dblog() dalam SQL Server.

Untuk menggunakan titik awal asli CDC dengan SQL Server, buat publikasi pada tabel apa pun yang berpartisipasi dalam replikasi yang sedang berlangsung. AWS DMSmembuat publikasi secara otomatis saat Anda menggunakan CDC tanpa menggunakan titik awal asli CDC.

PostgreSQL

Anda dapat menggunakan pemeriksaan pemulihan CDC untuk basis data sumber PostgreSQL Anda. Nilai titik pemeriksaan ini dihasilkan pada berbagai titik sebagai tugas replikasi yang sedang berlangsung dan berjalan untuk basis data sumber Anda (tugas induk). Untuk informasi lebih lanjut tentang titik pemeriksaan secara umum, lihat Menggunakan titik pemeriksaan sebagai titik awal CDC.

Untuk mengidentifikasi titik pemeriksaan untuk digunakan sebagai titik awal asli Anda, gunakan basis data Anda pg_replication_slots atau detail gambaran umum tugas induk Anda dari AWS Management Console

Untuk menemukan detail gambaran umum untuk tugas induk Anda di konsol

Masuk ke AWS Management Console dan buka konsol AWS DMS di https://console.aws.amazon.com/dms/v2/.

Jika Anda masuk sebagai pengguna IAM, pastikan Anda memiliki izin yang tepat untuk mengakses AWS DMS. Untuk informasi lebih lanjut tentang izin yang diperlukan, lihat Izin IAM diperlukan untuk menggunakan AWS DMS.
Pada panel navigasi, pilih Tugas migrasi basis data.
Pilih tugas induk Anda dari daftar di halaman Tugas migrasi basis data. Melakukan hal ini akan membuka halaman tugas induk Anda, menampilkan detail gambaran umum.
Cari nilai titik pemeriksaan di bawah Change data capture (CDC), Posisi awal change data capture (CDC), dan Titik pemeriksaan pemulihan change data capture (CDC).

Nilai muncul serupa dengan berikut ini.
```
checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0
```
Di sini, komponen 4AF/B00000D0 adalah apa yang Anda butuhkan untuk menentukan titik awal CDC asli ini. Atur parameter API DMS CdcStartPosition ke nilai ini ketika Anda membuat tugas CDC untuk memulai replikasi pada titik awal ini untuk sumber PostgreSQL Anda. Untuk informasi tentang penggunaan AWS CLI untuk membuat tugas CDC ini, lihat Mengaktifkan CDC dengan instans PostgreSQL DB AWS-managed dengan AWS DMS.

Oracle

System change number (SCN) adalah stempel waktu internal yang logis, yang digunakan oleh basis data Oracle. SCN memesan peristiwa yang terjadi dalam basis data, yang diperlukan untuk memenuhi properti ACID transaksi. Oracle database menggunakan SCN untuk menandai lokasi di mana semua perubahan telah ditulis ke disk sehingga tindakan pemulihan tidak berlaku sudah ditulis perubahan. Oracle juga menggunakan SCN untuk menandai titik di mana ada mengulang ada untuk satu set data sehingga pemulihan dapat berhenti.

Untuk mendapatkan SCN saat ini dalam basis data Oracle, jalankan perintah berikut.


SELECT CURRENT_SCN FROM V$DATABASE

Jika Anda menggunakan SCN atau stempel waktu untuk memulai tugas CDC, Anda kehilangan hasil transaksi terbuka dan gagal memigrasikan hasil ini. Transaksi terbuka adalah transaksi yang dimulai sebelum posisi awal tugas dan dilakukan setelah posisi awal tugas. Anda dapat mengidentifikasi SCN dan timestamp untuk memulai tugas CDC pada titik yang mencakup semua transaksi terbuka. Untuk informasi selengkapnya, lihat Transaksi di dokumentasi Oracle online. Dengan versi 3.5.1 dan yang lebih tinggi, AWS DMS mendukung transaksi terbuka untuk tugas khusus CDC menggunakan pengaturan openTransactionWindow titik akhir jika Anda menggunakan SCN atau Timestamp untuk memulai tugas.

Saat menggunakan openTransactionWindow pengaturan, Anda harus menyediakan jendela, dalam beberapa menit, untuk menangani transaksi terbuka. AWS DMSmenggeser posisi penangkapan dan menemukan posisi baru untuk memulai pengambilan data. AWS DMSmenggunakan posisi awal baru untuk memindai setiap transaksi terbuka dari redo Oracle yang diperlukan atau log redo yang diarsipkan.

MySQL

Sebelum rilis MySQL versi 5.6.3, log sequence number (LSN) untuk MySQL adalah integer yang tidak diberi tanda 4-byte. Dalam MySQL versi 5.6.3, ketika batas ukuran file log redo meningkat dari 4 GB ke 512 GB, LSN menjadi integer yang tidak diberi tanda 8-byte. Peningkatan mencerminkan bahwa byte tambahan yang diperlukan untuk menyimpan informasi ukuran tambahan. Aplikasi yang dibangun di atas MySQL 5.6.3 atau lebih tinggi yang menggunakan nilai LSN harus menggunakan variabel 64-bit daripada 32-bit untuk menyimpan dan membandingkan nilai LSN. Untuk informasi selengkapnya tentang MySQL LSN, lihat Dokumentasi MySQL.

Untuk mendapatkan LSN saat ini dalam basis data MySQL, jalankan perintah berikut.


mysql> show master status;

Kueri mengembalikan nama file binlog, posisi, dan beberapa nilai lainnya. Titik awal CDC asli adalah kombinasi dari nama file binlogs dan posisi, misalnya mysql-bin-changelog.000024:373. Dalam contoh ini, mysql-bin-changelog.000024 adalah nama file binlogs dan 373 adalah posisi di mana AWS DMS perlu mulai menangkap perubahan.

Menggunakan titik pemeriksaan sebagai titik awal CDC

Tugas replikasi yang sedang berlangsung memigrasi perubahan, dan AWS DMS meng-cache informasi titik pemeriksaan yang khusus untuk AWS DMS dari waktu ke waktu. Titik pemeriksaan yang diciptakan AWS DMS berisi informasi sehingga mesin replikasi tahu titik pemulihan untuk aliran perubahan. Anda dapat menggunakan titik pemeriksaan untuk kembali di timeline perubahan dan memulihkan tugas migrasi yang gagal. Anda juga dapat menggunakan titik pemeriksaan untuk memulai tugas replikasi lain yang sedang berlangsung untuk target lain pada titik tertentu dalam suatu waktu.

Anda bisa mendapatkan informasi pos pemeriksaan dengan salah satu dari tiga cara berikut:

Jalankan operasi API DescribeReplicationTasks dan lihat hasilnya. Anda dapat memfilter informasi berdasarkan tugas dan mencari pos pemeriksaan. Anda dapat mengambil pos pemeriksaan terbaru ketika tugas dalam keadaan berhenti atau gagal. Informasi ini hilang jika tugas dihapus.
Melihat tabel metadata bernama awsdms_txn_state pada instans target. Anda dapat meng-kueri tabrel untuk mendapatkan informasi titik pemeriksaan. Untuk membuat tabel metadata, atur parameter TaskRecoveryTableEnabled untuk Yes saat Anda membuat tugas. Pengaturan ini menyebabkan AWS DMS untuk terus menulis informasi titik pemeriksaan ke tabel metadata target. Informasi ini akan hilang jika tugas dihapus.

Misalnya, hal berikut ini adalah sampel titik pemeriksaan dalam tabel metadata: checkpoint:V1#34#00000132/0F000E48#0#0#*#0#121
Dari panel navigasi, pilih Tugas migrasi database, dan pilih tugas induk Anda dari daftar yang muncul di halaman Tugas migrasi database. Halaman tugas induk Anda terbuka, menampilkan detail ikhtisar. Cari nilai titik pemeriksaan di bawah Change data capture (CDC), Posisi awal change data capture (CDC), dan Titik pemeriksaan pemulihan change data capture (CDC). Nilai pos pemeriksaan tampak mirip dengan yang berikut:

checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

Menghentikan tugas pada titik waktu komit atau server

Dengan diperkenalkannya titik awal CDC asli, AWS DMS juga dapat menghentikan tugas di titik-titik berikut:

Waktu komit pada sumber
Waktu server pada instans replikasi

Anda dapat mengubah tugas dan mengatur waktu di UTC untuk berhenti sesuai kebutuhan. Tugas secara otomatis berhenti berdasarkan komit atau server waktu yang Anda tetapkan. Atau, jika Anda mengetahui waktu yang tepat untuk menghentikan tugas migrasi pada pembuatan tugas, Anda dapat mengatur waktu berhenti saat membuat tugas.

catatan

Diperlukan waktu hingga 40 menit untuk menginisialisasi semua sumber daya saat pertama kali Anda memulai replikasi Tanpa AWS DMS Server baru. Perhatikan bahwa server_time opsi ini hanya berlaku setelah inisialisasi sumber daya selesai.

Melakukan replikasi dua arah

Anda dapat menggunakan tugas AWS DMS untuk melakukan replikasi dua arah antara dua sistem. Dalam replikasi dua arah, Anda mereplikasi data dari tabel yang sama (atau set tabel) antara dua sistem di kedua arah.

Sebagai contoh, Anda dapat menyalin tabel EMPLOYEE dari basis data A ke basis data B dan mereplikasi perubahan ke tabel dari basis data A ke basis data B. Anda juga dapat mereplikasi perubahan ke tabel EMPLOYEE dari basis data B kembali ke A. Dengan demikian, Anda melakukan replikasi dua arah.

catatan

Replikasi AWS DMS dua arah tidak dimaksudkan sebagai solusi multi-master penuh termasuk simpul primer, resolusi konflik, dan sebagainya.

Menggunakan replikasi dua arah untuk situasi di mana data pada node yang berbeda dipisahkan secara operasional. Dengan kata lain, misalkan Anda memiliki elemen data diubah oleh aplikasi yang beroperasi pada node A, dan bahwa node A melakukan replikasi dua arah dengan node B. elemen data pada node A tidak pernah diubah oleh aplikasi yang beroperasi pada node B.

AWS DMSmendukung replikasi dua arah pada mesin database ini:

Oracle
SQL Server
MySQL
PostgreSQL
Edisi yang kompatibel dengan Amazon Aurora MySQL
yang kompatibel dengan Aurora PostgreSQL

Membuat tugas replikasi dua arah

Untuk mengaktifkanAWS DMSdua arah replikasi, mengkonfigurasi sumber dan target akhir untuk kedua database (A dan B). Sebagai contoh, mengkonfigurasi titik akhir sumber untuk database A, titik akhir sumber untuk database B, titik akhir target untuk database A, dan titik akhir target untuk database B.

Kemudian membuat dua tugas: satu tugas untuk sumber A untuk memindahkan data ke target B, dan tugas lain untuk sumber B untuk memindahkan data ke target A. juga, pastikan bahwa setiap tugas dikonfigurasi dengan pencegahan loopback. Melakukan hal ini mencegah perubahan identik dari yang diterapkan ke target dari kedua tugas, sehingga merusak data untuk setidaknya satu dari mereka. Untuk informasi selengkapnya, lihat Mencegah loopback.

Untuk pendekatan termudah, mulai dengan dataset identik pada kedua database A dan database B. kemudian membuat dua CDC hanya tugas, satu tugas untuk mereplikasi data dari A ke B, dan tugas lain untuk mereplikasi data dari B ke A.

Untuk menggunakanAWS DMSuntuk instantiate dataset baru (database) pada node B dari node A, lakukan hal berikut:

Menggunakan beban penuh dan CDC tugas untuk memindahkan data dari database A ke B. Pastikan bahwa tidak ada aplikasi memodifikasi data pada database B selama waktu ini.
Ketika beban penuh selesai dan sebelum aplikasi diperbolehkan untuk memodifikasi data pada database B, perhatikan waktu atau CDC mulai posisi database B. untuk petunjuk, lihatMelakukan replikasi mulai dari titik awal CDC.
Membuat CDC hanya tugas yang bergerak data dari database B kembali ke A menggunakan ini mulai waktu atau CDC mulai posisi.

catatan

Hanya satu tugas dalam pasangan dua arah dapat beban penuh dan CDC.

Mencegah loopback

Untuk menunjukkan mencegah loopback, anggaplah bahwa dalam T1 tugasAWS DMSmembaca log perubahan dari sumber database A dan menerapkan perubahan untuk menargetkan database B.

Berikutnya, tugas kedua, T2, membaca perubahan log dari sumber database B dan berlaku mereka kembali ke target database A. sebelum T2 melakukan ini, DMS harus memastikan bahwa perubahan yang sama dibuat untuk menargetkan database B dari sumber database A tidak dibuat untuk sumber database A. dengan kata lain, DMS harus memastikan bahwa perubahan ini aren tidak bergema (dilingkarkan) kembali ke basis data target A. jika tidak, data dalam database A dapat rusak.

Untuk mencegah loopback perubahan, tambahkan pengaturan tugas berikut untuk setiap tugas replikasi dua arah. Melakukan hal ini memastikan bahwa loopback data korupsi tidak terjadi di kedua arah.


{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": Boolean,
    "SourceSchema": String,
    "TargetSchema": String
  },

. . .
}

ParameterLoopbackPreventionSettingsmenentukan jika transaksi baru atau gema dari tugas replikasi berlawanan. SaatAWS DMSmenerapkan transaksi ke database target, itu update tabel DMS (awsdms_loopback_prevention) dengan indikasi perubahan. Sebelum menerapkan setiap transaksi ke target, DMS mengabaikan setiap transaksi yang mencakup referensi keawsdms_loopback_preventionTabel. Oleh karena itu, tidak berlaku perubahan.

Termasuk pengaturan tugas ini dengan setiap replikasi tugas dalam pasangan dua arah. Pengaturan ini memungkinkan pencegahan loopback. Mereka juga menentukan skema untuk setiap sumber dan target database dalam tugas yang mencakupawsdms_loopback_preventiontabel untuk setiap titik akhir.

Untuk membolehkan setiap tugas untuk mengenal pasti gema itu dan membuangnya, tetapkanEnableLoopbackPreventionketrue. Untuk menentukan skema pada sumber yang mencakupawsdms_loopback_prevention, aturSourceSchemauntuk nama untuk skema tersebut dalam database sumber. Untuk menentukan skema pada target yang mencakup tabel yang sama, mengaturTargetSchemanama untuk skema tersebut dalam database target.

Dalam contoh berikut,SourceSchemadanTargetSchemapengaturan untuk replikasi tugas T1 dan replikasi berlawanan T2 tugas ditentukan dengan pengaturan berlawanan.

Tetapan untuk tugas T1 adalah seperti berikut.


{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "LOOP-DATA",
    "TargetSchema": "loop-data"
  },

. . .
}

Pengaturan untuk tugas yang berlawanan T2 adalah sebagai berikut.


{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "loop-data",
    "TargetSchema": "LOOP-DATA"
  },

. . .
}

catatan

Ketika menggunakanAWS CLI, gunakan hanyacreate-replication-taskataumodify-replication-taskperintah untuk mengkonfigurasiLoopbackPreventionSettingsdalam tugas replikasi dua arah Anda.

Batasan replikasi dua arah

Replikasi dua arah untukAWS DMSmemiliki batasan sebagai berikut:

Pencegahan loopback hanya melacak data language manipulation language (DLL) pernyataan.AWS DMStidak mendukung pencegah data definition language (DDL) loopback. Untuk melakukannya, konfigurasi salah satu tugas dalam pasangan dua arah untuk memfilter pernyataan DDL.
Tugas yang menggunakan pencegahan loopback tidak mendukung perubahan dalam batch. Untuk mengkonfigurasi tugas dengan pencegahan loopback, pastikan untuk mengaturBatchApplyEnabledkefalse.
DMS dua arah replikasi tidak termasuk konflik deteksi atau resolusi. Untuk mendeteksi inkonsistensi data, menggunakan validasi data pada kedua tugas.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Membuat beberapa tugas

Mengubah tugas