Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # AWS Validasi data DMS **Topics** + [Statistik tugas replikasi](#CHAP_Validating.TaskStatistics) + [Statistik tugas replikasi dengan Amazon CloudWatch](#CHAP_Validating.TaskStatistics.CloudWatch) + [Memvalidasi ulang tabel selama pengerjaan tugas](#CHAP_Validating.Revalidating) + [Menggunakan editor JSON untuk memodifikasi aturan validasi](#CHAP_Validating.JSONEditor) + [Tugas hanya validasi](#CHAP_Validating.ValidationOnly) + [Pemecahan masalah](#CHAP_Validating.Troubleshooting) + [Kinerja Validasi Pergeseran Merah](#CHAP_Validating.Redshift) + [Validasi data yang disempurnakan untuk AWS Database Migration Service](#CHAP_Validating_Enhanced) + [Batasan](#CHAP_Validating.Limitations) + [Validasi data target Amazon S3](CHAP_Validating_S3.md) + [AWS DMS sinkronisasi ulang data](CHAP_Validating.DataResync.md) AWS DMS memberikan dukungan untuk validasi data untuk memastikan bahwa data Anda dimigrasi secara akurat dari sumber ke target. Jika diaktifkan, validasi dimulai segera setelah beban penuh dilakukan untuk sebuah tabel. Validasi membandingkan perubahan tambahan untuk tugas yang CDC-nya diaktifkan saat terjadi. Selama validasi data, AWS DMS membandingkan setiap baris di sumber dengan baris yang sesuai pada target, memverifikasi baris berisi data yang sama, dan melaporkan ketidakcocokan apa pun. Untuk menyelesaikan AWS DMS masalah ini, kueri yang tepat untuk mengambil data. Perhatikan bahwa kueri ini akan mengonsumsi sumber daya tambahan pada sumber dan target serta sumber daya jaringan tambahan. Untuk tugas CDC saja dengan validasi diaktifkan, semua data yang sudah ada sebelumnya dalam tabel divalidasi sebelum memulai validasi data baru. Validasi data bekerja dengan database sumber berikut di mana pun AWS DMS mendukungnya sebagai titik akhir sumber: + Oracle + Database yang kompatibel dengan PostgreSQL (PostgreSQL, Aurora PostgreSQL, atau Aurora Tanpa Server untuk PostgreSQL) + Database yang kompatibel dengan MySQL (MySQL, MariaDB, Aurora MySQL, atau Aurora Tanpa Server untuk MySQL) + Microsoft SQL Server + IBM Db2 LUW Validasi data bekerja dengan database target berikut di mana pun AWS DMS mendukungnya sebagai titik akhir target: + Oracle + Database yang kompatibel dengan PostgreSQL (PostgreSQL, Aurora PostgreSQL, atau Aurora Tanpa Server untuk PostgreSQL) + Database yang kompatibel dengan MySQL (MySQL, MariaDB, Aurora MySQL, atau Aurora Tanpa Server untuk MySQL) + Microsoft SQL Server + IBM Db2 LUW + Amazon Redshift + Amazon S3. Untuk informasi tentang memvalidasi data target Amazon S3, lihat. [Validasi data target Amazon S3](CHAP_Validating_S3.md) Untuk informasi lebih lanjut tentang titik akhir yang didukung, lihat [Bekerja dengan titik AWS akhir DMS](CHAP_Endpoints.md). Validasi data memerlukan waktu tambahan, melampaui jumlah yang diperlukan untuk migrasi itu sendiri. Waktu tambahan yang diperlukan tergantung pada berapa banyak data yang dimigrasi. Untuk informasi selengkapnya tentang pengaturan ini, lihat [Pengaturan tugas validasi data](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md). Untuk contoh pengaturan `ValidationSettings` tugas dalam file JSON, lihat[Contoh pengaturan tugas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example). ## Statistik tugas replikasi Saat validasi data diaktifkan, AWS DMS berikan statistik berikut di tingkat tabel: + **ValidationState**—Status validasi tabel. Parameter dapat memiliki nilai berikut: + **Not enabled**—Validasi tidak diaktifkan untuk tabel dalam tugas migrasi. + **Pending records**—Beberapa catatan dalam tabel menunggu validasi. + **Mismatched records**—Beberapa catatan dalam tabel tidak cocok antara sumber dan target. Ketidakcocokan mungkin terjadi karena sejumlah alasan; Untuk informasi lebih lanjut, periksa tabel `awsdms_control.awsdms_validation_failures_v1` pada titik akhir target. + **Suspended records**—Beberapa catatan dalam tabel tidak dapat divalidasi. + **No primary key**—Tabel tidak dapat divalidasi karena tidak memiliki kunci primer. + **Table error**—Tabel tidak divalidasi karena berada dalam status kesalahan dan beberapa data tidak dimigrasi. + **Validated**—Semua baris dalam tabel divalidasi. Jika tabel diperbarui, status dapat berubah dari Validated. + **Error**—Tabel tidak dapat divalidasi karena ada kesalahan tidak terduga. + **Pending validation**—Tabel menunggu validasi. + **Mempersiapkan tabel**—Mempersiapkan tabel diaktifkan dalam tugas migrasi untuk validasi. + **Pending revalidation**—Validasi semua baris dalam tabel tertunda setelah tabel diperbarui. + **ValidationPending**—Jumlah catatan yang telah dimigrasikan ke target, tetapi itu belum divalidasi. + **ValidationSuspended**—Jumlah catatan yang tidak AWS DMS bisa dibandingkan. Misalnya, jika catatan di sumber terus diperbarui, tidak AWS DMS dapat membandingkan sumber dan target. + **ValidationFailed**—Jumlah catatan yang tidak lulus fase validasi data. Untuk contoh pengaturan `ValidationSettings` tugas dalam file JSON, lihat[Contoh pengaturan tugas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example). Anda dapat melihat informasi validasi data menggunakan konsol, file AWS CLI, atau AWS DMS API. + Di konsol, Anda dapat memilih untuk memvalidasi tugas saat Anda membuat atau memodifikasi tugas. Untuk melihat laporan validasi data menggunakan konsol, pilih tugas di halaman **Tugas** dan pilih tab **Statistik tabel** di bagian detail. + Menggunakan CLI, atur `EnableValidation` parameter `true` saat membuat atau memodifikasi tugas untuk memulai validasi data. Contoh berikut membuat tugas dan mengaktifkan validasi data. ``` create-replication-task --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}' --replication-instance-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q --source-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CSZAEFQURFYMM --target-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CGPP7MF6WT4JQ --migration-type full-load-and-cdc --table-mappings '{"rules": [{"rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": {"schema-name": "data_types", "table-name": "%"}, "rule-action": "include"}]}' ``` Gunakan perintah `describe-table-statistics` untuk menerima laporan validasi data dalam format JSON. Perintah berikut menunjukkan laporan validasi data. ``` aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q ``` Laporan tersebut akan serupa dengan berikut ini. ``` { "ReplicationTaskArn": "arn:aws:dms:us-west-2:5731014:task:VFPFTYKK2RYSI", "TableStatistics": [ { "ValidationPendingRecords": 2, "Inserts": 25, "ValidationState": "Pending records", "ValidationSuspendedRecords": 0, "LastUpdateTime": 1510181065.349, "FullLoadErrorRows": 0, "FullLoadCondtnlChkFailedRows": 0, "Ddls": 0, "TableName": "t_binary", "ValidationFailedRecords": 0, "Updates": 0, "FullLoadRows": 10, "TableState": "Table completed", "SchemaName": "d_types_s_sqlserver", "Deletes": 0 } } ``` + Menggunakan AWS DMS API, buat tugas menggunakan **CreateReplicationTask**tindakan dan atur `EnableValidation` parameter ke **true** untuk memvalidasi data yang dimigrasikan oleh tugas. Gunakan **DescribeTableStatistics**tindakan untuk menerima laporan validasi data dalam format JSON. ## Statistik tugas replikasi dengan Amazon CloudWatch Saat Amazon CloudWatch diaktifkan, AWS DMS berikan statistik tugas replikasi berikut: + **ValidationSucceededRecordCount**— Jumlah baris yang AWS DMS divalidasi, per menit. + **ValidationAttemptedRecordCount**— Jumlah baris yang validasi dicoba, per menit. + **ValidationFailedOverallCount**— Jumlah baris di mana validasi gagal. + **ValidationSuspendedOverallCount**— Jumlah baris di mana validasi ditangguhkan. + **ValidationPendingOverallCount**— Jumlah baris di mana validasi masih tertunda. + **ValidationBulkQuerySourceLatency**— AWS DMS dapat melakukan validasi data secara massal, terutama dalam skenario tertentu selama replikasi beban penuh atau sedang berlangsung ketika ada banyak perubahan. Metrik ini menunjukkan latensi yang diperlukan untuk membaca kumpulan data massal dari titik akhir sumber. + **ValidationBulkQueryTargetLatency**— AWS DMS dapat melakukan validasi data secara massal, terutama dalam skenario tertentu selama replikasi beban penuh atau sedang berlangsung ketika ada banyak perubahan. Metrik ini menunjukkan latensi yang diperlukan untuk membaca kumpulan data massal dari titik akhir target. + **ValidationItemQuerySourceLatency**Selama replikasi yang sedang berlangsung, validasi data dapat mengidentifikasi perubahan yang sedang berlangsung dan memvalidasi perubahan tersebut. Metrik ini menunjukkan latensi dalam membaca perubahan tersebut dari sumber. Validasi dapat menjalankan lebih banyak kueri dari yang diperlukan, berdasarkan jumlah perubahan, jika ada kesalahan selama validasi. + **ValidationItemQueryTargetLatency**— Selama replikasi yang sedang berlangsung, validasi data dapat mengidentifikasi perubahan yang sedang berlangsung dan memvalidasi perubahan baris demi baris. Metrik ini memberi kita latensi dalam membaca perubahan tersebut dari target. Validasi dapat menjalankan lebih banyak kueri dari yang diperlukan, berdasarkan jumlah perubahan, jika ada kesalahan selama validasi. Untuk mengumpulkan informasi validasi data dari statistik yang CloudWatch diaktifkan, pilih **Aktifkan CloudWatch log** saat Anda membuat atau memodifikasi tugas menggunakan konsol. Kemudian, untuk melihat informasi validasi data dan memastikan bahwa data Anda dimigrasi secara akurat dari sumber ke target, lakukan hal berikut. 1. Pilih tugas di halaman **Tugas migrasi basis data**. 1. Pilih tab **CloudWatch metrik**. 1. Pilih **Validasi** dari menu tarik turun. ## Memvalidasi ulang tabel selama pengerjaan tugas Saat tugas sedang berjalan, Anda dapat meminta AWS DMS untuk melakukan validasi data. ### Konsol Manajemen AWS 1. Masuk ke Konsol Manajemen AWS dan buka AWS DMS konsol di [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). Jika Anda masuk sebagai pengguna AWS Identity and Access Management (IAM), pastikan Anda memiliki izin yang sesuai untuk AWS DMS mengakses. izin yang diperlukan, lihat. [Izin IAM diperlukan untuk menggunakan AWS DMS](security-iam.md#CHAP_Security.IAMPermissions) 1. Pilih **Tugas** dari panel navigasi. 1. Pilih tugas berjalan yang memiliki tabel yang ingin Anda validasi ulang. 1. Pilih tab **Statistik Tabel**. 1. Pilih tabel yang ingin Anda validasi ulang (Anda dapat memilih hingga 10 tabel sekaligus). Jika tugas tidak lagi berjalan, Anda tidak dapat memvalidasi ulang tabel. 1. Pilih **Validasi Ulang**. ## Menggunakan editor JSON untuk memodifikasi aturan validasi Untuk menambahkan aturan validasi ke tugas menggunakan editor JSON dari AWS DMS Konsol, lakukan hal berikut: 1. Pilih **Tugas migrasi basis data**. 1. Pilih tugas Anda dari daftar tugas migrasi. 1. Jika tugas Anda sedang berjalan, pilih **Berhenti** dari menu tarik turun **Tindakan**. 1. Setelah tugas telah berhenti, untuk memodifikasi tugas Anda, pilih **Modifikasi** dari menu tarik turun **Tindakan**. 1. Di bagian **Pemetaan tabel**, pilih **Editor JSON** dan tambahkan aturan validasi Anda ke pemetaan tabel Anda. Misalnya, Anda dapat menambahkan aturan validasi berikut untuk menjalankan fungsi ganti pada sumber. Dalam kasus ini, jika aturan validasi bertemu null byte, byte tersebut akan divalidasi sebagai spasi. ``` { "rule-type": "validation", "rule-id": "1", "rule-name": "1", "rule-target": "column", "object-locator": { "schema-name": "Test-Schema", "table-name": "Test-Table", "column-name": "Test-Column" }, "rule-action": "override-validation-function", "source-function": "REPLACE(${column-name}, chr(0), chr(32))", "target-function": "${column-name}" } ``` **catatan** `override-validation-function`tidak berlaku jika kolom adalah bagian dari kunci utama. ## Tugas hanya validasi Anda hanya dapat membuat tugas validasi untuk melihat pratinjau dan memvalidasi data tanpa melakukan migrasi atau replikasi data apa pun. Untuk membuat tugas validasi saja, atur `ValidationOnly` pengaturan `EnableValidation` dan ke`true`. Saat mengaktifkan`ValidationOnly`, persyaratan tambahan berlaku. Untuk informasi selengkapnya, lihat [Pengaturan tugas validasi data](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md). Untuk jenis migrasi hanya beban penuh, tugas validasi hanya selesai jauh lebih cepat daripada yang setara dengan CDC ketika banyak kegagalan dilaporkan. Tetapi perubahan pada titik akhir sumber atau target dilaporkan sebagai kegagalan untuk mode beban penuh, kemungkinan kerugian. Hanya tugas validasi CDC yang menunda validasi berdasarkan latensi rata-rata, dan mencoba ulang kegagalan beberapa kali sebelum melaporkannya. Jika sebagian besar perbandingan data mengakibatkan kegagalan, tugas validasi hanya untuk mode CDC sangat lambat, kelemahan potensial. Tugas validasi saja harus diatur dalam arah yang sama dengan tugas replikasi, terutama untuk CDC. Ini karena tugas Hanya Validasi CDC mendeteksi baris mana yang telah berubah dan perlu divalidasi ulang berdasarkan log perubahan pada sumbernya. Jika target ditentukan sebagai sumber, maka ia hanya tahu tentang perubahan yang dikirim ke target oleh DMS dan tidak dijamin untuk menangkap kesalahan replikasi. ### Validasi beban penuh saja Dimulai dengan AWS DMS versi 3.4.6 dan yang lebih tinggi, tugas validasi beban penuh hanya dengan cepat membandingkan semua baris dari sumber dan tabel target dalam satu lintasan, segera melaporkan kegagalan, dan kemudian dimatikan. Validasi tidak pernah ditangguhkan karena kegagalan dalam mode ini, itu dioptimalkan untuk kecepatan. Tetapi perubahan pada titik akhir sumber atau target dilaporkan sebagai kegagalan. **catatan** Dimulai dengan AWS DMS versi 3.4.6 dan yang lebih tinggi, perilaku validasi ini juga berlaku untuk tugas migrasi beban penuh dengan validasi diaktifkan. ### Hanya validasi CDC Tugas validasi CDC hanya memvalidasi semua baris yang ada antara tabel sumber dan target pada awal yang baru. Selain itu, tugas validasi CDC hanya berjalan terus menerus, memvalidasi ulang perubahan replikasi yang sedang berlangsung, membatasi jumlah kegagalan yang dilaporkan setiap pass, dan mencoba ulang baris yang tidak cocok sebelum gagal. Ini dioptimalkan untuk mencegah positif palsu. Validasi untuk tabel (atau seluruh tugas) ditangguhkan jika `TableFailureMaxCount` ambang batas ` FailureMaxCount` atau dilanggar. Ini juga berlaku untuk tugas migrasi CDC atau Full Load\$1CDC dengan validasi diaktifkan. Dan tugas CDC dengan validasi mengaktifkan penundaan validasi ulang untuk setiap baris yang diubah berdasarkan latensi sumber dan target rata-rata. Tetapi *tugas validasi CDC saja* tidak memigrasikan data dan tidak memiliki latensi. Ini diatur `ValidationQueryCdcDelaySeconds` ke 180 secara default. Dan Anda dapat meningkatkan jumlah untuk memperhitungkan lingkungan latensi tinggi dan membantu mencegah positif palsu. ### Validasi hanya kasus penggunaan Kasus penggunaan untuk memisahkan bagian validasi data dari tugas migrasi atau replikasi menjadi tugas *validasi terpisah yang hanya* mencakup, tetapi tidak terbatas pada, hal-hal berikut: + *Kontrol tepat saat validasi terjadi* - Kueri validasi menambahkan beban tambahan ke titik akhir sumber dan target. Jadi, memigrasi atau mereplikasi data dalam satu tugas terlebih dahulu, kemudian memvalidasi hasil di tugas lain dapat bermanfaat. + *Kurangi beban pada instance replikasi* — Memisahkan validasi data untuk dijalankan pada instancenya sendiri dapat menguntungkan. + *Dapatkan dengan cepat berapa banyak baris yang tidak cocok pada saat tertentu* — Misalnya, tepat sebelum atau selama pemotongan produksi jendela pemeliharaan — ke titik akhir target, Anda dapat membuat tugas validasi Full Load saja untuk mendapatkan jawaban atas pertanyaan Anda. + *Ketika kegagalan validasi diharapkan untuk tugas migrasi dengan komponen CDC* — Misalnya, jika memigrasikan Oracle `varchar2` ke PostgreSQL, validasi CDC terus mencoba ulang `jsonb` baris gagal ini dan membatasi jumlah kegagalan yang dilaporkan setiap kali. Namun, Anda dapat membuat tugas validasi Full Load saja dan mendapatkan jawaban yang lebih cepat. + *Anda telah mengembangkan perbaikan data script/utility yang membaca tabel kegagalan validasi* — (Lihat juga,[Pemecahan masalah](#CHAP_Validating.Troubleshooting)). Tugas validasi Full Load hanya dengan cepat melaporkan kegagalan untuk skrip perbaikan data untuk ditindaklanjuti. Untuk contoh pengaturan `ValidationSettings` tugas dalam file JSON, lihat[Contoh pengaturan tugas](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)). ## Pemecahan masalah Selama validasi, AWS DMS buat tabel baru di titik akhir target:. `awsdms_control.awsdms_validation_failures_v1` Jika ada catatan yang memasuki *ValidationSuspended*atau *ValidationFailed*negara bagian, AWS DMS tulis informasi diagnostik ke`awsdms_control.awsdms_validation_failures_v1`. Anda dapat mengkueri tabel ini untuk membantu memecahkan kesalahan validasi. Untuk informasi tentang mengubah skema default tabel dibuat pada target, lihat [Mengontrol pengaturan tugas tabel](CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.md). Berikut ini adalah deskripsi dari tabel `awsdms_control.awsdms_validation_failures_v1`: | Nama kolom | Jenis data | Deskripsi | | --- | --- | --- | | `TASK_NAME` | `VARCHAR(128) NOT NULL` | AWS DMS pengidentifikasi tugas. | | TABLE\$1OWNER | VARCHAR(128) NOT NULL | Skema (pemilik) dari tabel. | | `TABLE_NAME` | VARCHAR(128) NOT NULL | Nama tabel. | | FAILURE\$1TIME | DATETIME(3) NOT NULL | Waktu ketika kegagalan terjadi. | | KEY\$1TYPE | VARCHAR(128) NOT NULL | Dicadangkan untuk penggunaan di masa mendatang (nilai selalu 'Row') | | KEY | TEXT NOT NULL | Ini adalah kunci primer untuk jenis catatan baris. | | FAILURE\$1TYPE | VARCHAR(128) NOT NULL | Tingkat kepelikan kesalahan validasi. Bisa berupa`RECORD_DIFF`,`MISSING_SOURCE`,`MISSING_TARGET`, atau`TABLE_WARNING`. | | DETAILS | VARCHAR(8000) NOT NULL | JSON string diformat dari semua nilai source/target kolom yang tidak cocok untuk kunci yang diberikan. | Berikut ini adalah contoh query untuk target MySQL yang akan menunjukkan semua kegagalan untuk tugas dengan query tabel. `awsdms_control.awsdms_validation_failures_v1` Perhatikan bahwa nama skema dan sintaks kueri akan bervariasi di seluruh versi mesin target. Nama tugas harus ID sumber daya eksternal tugas tersebut. ID sumber daya eksternal dari tugas adalah nilai terakhir dalam ARN tugas. Misalnya, untuk tugas dengan nilai ARN arn:aws:dms:us-west- 2:5599:task: RYSI, ID sumber daya eksternal dari tugas tersebut adalah RYSI. VFPFKH4 FJR3 FTYKK2 VFPFKH4 FJR3 FTYKK2 ``` select * from awsdms_validation_failures_v1 where TASK_NAME = 'VFPFKH4FJR3FTYKK2RYSI' TASK_NAME VFPFKH4FJR3FTYKK2RYSI TABLE_OWNER DB2PERF TABLE_NAME PERFTEST FAILURE_TIME 2020-06-11 21:58:44 KEY_TYPE Row KEY {"key": ["3451491"]} FAILURE_TYPE RECORD_DIFF DETAILS [[{'MYREAL': '+1.10106036e-01'}, {'MYREAL': '+1.10106044e-01'}],] ``` Anda dapat melihat bidang `DETAILS` untuk menentukan kolom yang tidak cocok. Karena Anda memiliki kunci primer dari catatan yang gagal, Anda dapat mengkueri titik akhir sumber dan target untuk melihat bagian dari catatan yang tidak cocok. ### `awsdms_validation_failures_v2`meja kontrol Selama validasi, di AWS DMS versi 3.6.1 dan di atasnya, DMS membuat tabel baru di titik akhir target PostgreSQL:. `awsdms_validation_failures_v2` Tabel ini terdiri dari kegagalan untuk semua tugas DMS yang memiliki validasi data diaktifkan. Saat `awsdms_validation_failures_v2` tabel dibuat, Anda tidak boleh menjatuhkan atau memotong tabel karena dapat menyebabkan kesalahan untuk tugas apa pun dengan validasi dan sinkronisasi ulang diaktifkan. `awsdms_validation_failures_v2`tabel memiliki fitur kunci utama kenaikan otomatis. Tabel ini terdiri dari kolom baru untuk mendukung fitur Data resync. File tersebut adalah: `RESYNC_RESULT` **Nilai**: `SUCCESS` atau`FAILURE`. **`RESYNC_TIME`** Stempel waktu dengan presisi milidetik. Nilai default adalah `NULL` jika Data resync tidak dicoba untuk kegagalan ini. **`RESYNC_ACTION`** **Nilai**: `UPSERT` atau`DELETE`. `RESYNC_ID` Kolom kunci primer dengan penambahan otomatis diaktifkan. Dalam `awsdms_validation_failures_v2` tabel, indeks ditambahkan ke`TASK_NAME`,,, `TABLE_OWNER` `TABLE_NAME``FAILURE_TYPE`, dan `FAILURE_TIME` kolom untuk membaca kegagalan secara efisien untuk setiap tabel yang diberikan dalam database target Anda. Di bawah ini adalah contoh membuat pernyataan untuk membuat `awsdms_validation_failures_v2` tabel: ``` CREATE TABLE public.awsdms_validation_failures_v2 ( "RESYNC_ID" int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL, "TASK_NAME" varchar(128) NOT NULL, "TABLE_OWNER" varchar(128) NOT NULL, "TABLE_NAME" varchar(128) NOT NULL, "FAILURE_TIME" timestamp NOT NULL, "KEY_TYPE" varchar(128) NOT NULL, "KEY" varchar(7800) NOT NULL, "FAILURE_TYPE" varchar(128) NOT NULL, "DETAILS" varchar(7000) NOT NULL, "RESYNC_RESULT" varchar(128) NULL, "RESYNC_TIME" timestamp NULL, "RESYNC_ACTION" varchar(128) NULL, CONSTRAINT awsdms_validation_failures_v2_pkey PRIMARY KEY ("RESYNC_ID") ); ``` ## Kinerja Validasi Pergeseran Merah Amazon Redshift berbeda dari database relasional dalam beberapa hal, termasuk penyimpanan kolumnar, MPP, kompresi data, dan faktor lainnya. Perbedaan ini memberikan Redshift profil kinerja yang berbeda dari database relasional. Selama fase replikasi beban penuh, validasi menggunakan kueri rentang, dengan ukuran data diatur oleh pengaturan. `PartitionSize` Kueri berbasis rentang ini memilih semua catatan dari tabel sumber. Untuk replikasi yang sedang berlangsung, kueri beralih antara pengambilan berdasarkan rentang dan rekaman individual. Jenis kueri ditentukan secara dinamis berdasarkan beberapa faktor, seperti berikut ini: + Volume kueri + Jenis kueri DMLpada tabel sumber + Latensi tugas + Jumlah total catatan + Pengaturan validasi seperti `PartitionSize` Anda mungkin melihat beban tambahan di klaster Amazon Redshift karena kueri validasi. Karena faktor-faktor di atas bervariasi di seluruh kasus penggunaan, Anda harus meninjau kinerja kueri validasi Anda dan menyetel klaster dan tabel Anda sesuai dengan itu. Beberapa opsi untuk mengurangi isses kinerja meliputi yang berikut: + Kurangi `ThreadCount` pengaturan `PartitionSize` dan untuk membantu mengurangi beban kerja selama validasi beban penuh. Perhatikan bahwa ini akan memperlambat validasi data. + Meskipun Redshift tidak menerapkan kunci utama, AWS DMS bergantung pada kunci utama untuk mengidentifikasi catatan secara unik pada target untuk validasi data. Jika memungkinkan, setel kunci utama untuk mencerminkan kunci pengurutan sehingga kueri validasi beban penuh dijalankan lebih cepat. ## Validasi data yang disempurnakan untuk AWS Database Migration Service AWS Database Migration Service telah meningkatkan kinerja validasi data untuk migrasi database, memungkinkan pelanggan untuk memvalidasi kumpulan data besar dengan waktu pemrosesan yang jauh lebih cepat. Validasi data yang disempurnakan ini sekarang tersedia di versi 3.5.4 dari mesin replikasi untuk beban penuh dan beban penuh dengan tugas migrasi CDC. Saat ini, peningkatan ini mendukung jalur migrasi dari Oracle ke PostgreSQL, SQL Server ke PostgreSQL, Oracle ke Oracle, dan SQL Server ke SQL Server, dengan jalur migrasi tambahan yang direncanakan untuk rilis mendatang. ### Prasyarat + *Oracle:* berikan `EXECUTE` izin `SYS.DBMS_CRYPTO` ke akun pengguna yang mengakses endpoint Oracle: ``` GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_endpoint_user; ``` + Instal `pgcrypto` ekstensi pada database PostgreSQL: Untuk instance PostgreSQL yang dikelola sendiri, Anda perlu menginstal `contrib` pustaka modul dan membuat ekstensi: + Instal pustaka `contrib` modul. Misalnya, pada instans Amazon EC2 dengan Amazon Linux dan PostgreSQL 15: ``` sudo dnf install postgresql15-contrib ``` + Buat `pgcrypto` ekstensi: ``` CREATE EXTENSION IF NOT EXISTS pgcrypto; ``` + Untuk instans Amazon RDS for PostgreSQL, konfigurasikan mode SSL untuk titik akhir: AWS DMS + Secara default, Amazon RDS memaksa koneksi SSL. Saat Anda membuat AWS DMS titik akhir untuk instans Amazon RDS for PostgreSQL, gunakan opsi “mode SSL” = “diperlukan”. + Jika Anda ingin menggunakan opsi “mode SSL” = “tidak ada”, atur `rds.force_ssl` parameter ke 0 di Grup Parameter RDS. + Untuk PostgreSQL 12 dan 13, buat agregat: `BIT_XOR` ``` CREATE OR REPLACE AGGREGATE BIT_XOR(IN v bit) (SFUNC = bitxor, STYPE = bit); ``` ### Batasan validasi data yang ditingkatkan Fitur validasi data yang disempurnakan ini memiliki batasan sebagai berikut: + Persyaratan endpoint database: Peningkatan ini hanya diaktifkan untuk endpoint database yang memenuhi kriteria berikut: + Gunakan AWS Secrets Manager untuk menyimpan kredensil. + Untuk Microsoft SQL Server, otentikasi Kerberos juga didukung. + Dukungan versi basis data: + PostgreSQL 12 dan lebih tinggi + Oracle 12.1 dan lebih tinggi + Untuk versi Microsoft SQL Server yang lebih rendah dari 2019, validasi tipe data NCHAR dan NVARCHAR tidak didukung. ## Batasan + Validasi data mengharuskan tabel memiliki kunci primer atau indeks unik. + Kolom kunci primer tidak dapat berupa tipe `CLOB``BLOB`,,`BINARY`, atau`BYTE`. + Untuk kolom kunci primer jenis `VARCHAR` atau `CHAR`, panjangnya harus kurang dari 1024. Anda harus menentukan panjang dalam tipe data. Anda tidak dapat menggunakan tipe data tak terbatas sebagai kunci utama untuk validasi data. + Kunci Oracle yang dibuat dengan `NOVALIDATE` klausa *tidak* dianggap sebagai kunci utama atau indeks unik. + Untuk tabel Oracle tanpa kunci utama dan hanya kunci unik, kolom dengan kendala unik juga harus memiliki kendala. `NOT NULL` + Validasi PK/UK nilai NULL tidak didukung. + Jika kolasi kolom kunci primer dalam instans PostgreSQL target tidak diatur ke "C", urutan kunci primer berbeda dibandingkan dengan urutan di Oracle. Jika urutan berbeda antara PostgreSQL dan Oracle, validasi data gagal untuk memvalidasi catatan. + Validasi data menghasilkan kueri tambahan terhadap basis data sumber dan target. Anda harus memastikan bahwa kedua basis data memiliki cukup sumber daya untuk menangani beban tambahan ini. Ini terutama berlaku untuk target Redshift. Untuk informasi lebih lanjut, lihat [Kinerja Validasi Pergeseran Merah](#CHAP_Validating.Redshift) berikut ini. + Validasi data tidak didukung saat mengkonsolidasikan beberapa database menjadi satu. + Untuk sumber atau target titik akhir Oracle, AWS DMS gunakan. `DBMS_CRYPTO` Jika Anda menggunakan validasi data pada endpoint Oracle, Anda harus memberikan izin eksekusi ke akun pengguna yang digunakan `dbms_crypto` untuk mengakses endpoint Oracle. Anda dapat melakukan ini dengan menjalankan pernyataan berikut ``` grant execute on sys.dbms_crypto to dms_endpoint_user; ``` + Jika database target dimodifikasi di luar AWS DMS selama validasi, maka perbedaan mungkin tidak dilaporkan secara akurat. Hasil ini dapat terjadi jika salah satu aplikasi Anda menulis data ke tabel target, saat AWS DMS melakukan validasi pada tabel yang sama. + Jika satu atau beberapa baris terus dimodifikasi selama validasi, maka tidak AWS DMS dapat memvalidasi baris tersebut. + Jika AWS DMS mendeteksi lebih dari 10.000 catatan yang gagal atau ditangguhkan, itu menghentikan validasi. Sebelum Anda melanjutkan lebih jauh, selesaikan masalah yang mendasari dengan data tersebut. + AWS DMS tidak mendukung validasi data tampilan. + AWS DMS tidak mendukung validasi data saat pengaturan tugas substitusi karakter digunakan. + AWS DMS tidak mendukung validasi tipe Oracle LONG. + AWS DMS tidak mendukung validasi tipe Oracle Spatial selama migrasi heterogen. + Validasi data mengabaikan kolom-kolom tersebut dalam tabel yang transformasi masking data ada dalam pemetaan tabel. + Validasi data melewatkan seluruh tabel jika ada aturan transformasi masking data untuk kolomnya. PK/UK Status validasi akan ditampilkan sebagai Tidak ada kunci utama untuk tabel tersebut. + Validasi data tidak berfungsi dengan Amazon Aurora PostgreSQL Limitless. Saat mencoba memvalidasi tabel dalam Database Tanpa Batas, status validasi menampilkan “Tidak ada kunci utama” untuk tabel ini. Untuk batasan saat menggunakan validasi target S3, lihat. [Batasan untuk menggunakan validasi target S3](CHAP_Validating_S3.md#CHAP_Validating_S3_limitations) # Validasi data target Amazon S3 AWS DMS mendukung memvalidasi data yang direplikasi di target Amazon S3. Karena AWS DMS menyimpan data yang direplikasi sebagai file datar di Amazon S3, kami menggunakan kueri [Amazon `CREATE TABLE AS SELECT` Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) (CTAS) untuk memvalidasi data. Kueri pada data yang disimpan di Amazon S3 sangat intens secara komputasi. Dengan demikian, AWS DMS menjalankan validasi pada data Amazon S3 selama pengambilan data perubahan (CDC) hanya sekali sehari, pada tengah malam (00:00) UTC. Setiap validasi harian yang AWS DMS berjalan disebut *validasi interval*. Selama validasi interval, AWS DMS validasi semua catatan perubahan yang dimigrasikan ke bucket Amazon S3 target selama 24 jam sebelumnya. Untuk informasi selengkapnya tentang batasan validasi interval, lihat[Batasan untuk menggunakan validasi target S3](#CHAP_Validating_S3_limitations). Validasi target Amazon S3 menggunakan Amazon Athena, jadi biaya tambahan berlaku. Untuk informasi selengkapnya, lihat [Harga Amazon Athena](https://aws.amazon.com/athena/pricing/). **catatan** Validasi target S3 membutuhkan AWS DMS versi 3.5.0 atau yang lebih baru. **Topics** + [Prasyarat](#CHAP_Validating_S3_prerequisites) + [Izin](#CHAP_Validating_S3_permissions) + [Batasan](#CHAP_Validating_S3_limitations) + [Tugas hanya validasi](#CHAP_Validating_S3_only) ## Prasyarat validasi target S3 Sebelum menggunakan validasi target S3, periksa pengaturan dan izin berikut: + Tetapkan `DataFormat` nilai untuk [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html) endpoint Anda ke. `parquet` Untuk informasi selengkapnya, lihat [Pengaturan parket untuk S3](CHAP_Target.S3.md#CHAP_Target.S3.EndpointSettings.Parquet). + Pastikan peran yang ditetapkan ke akun pengguna yang digunakan untuk membuat tugas migrasi memiliki kumpulan izin yang benar. Lihat [Izin](#CHAP_Validating_S3_permissions) berikut. Untuk tugas yang menggunakan replikasi berkelanjutan (CDC), periksa pengaturan berikut: + Aktifkan pencatatan tambahan sehingga Anda memiliki catatan lengkap dalam data CDC. Untuk informasi tentang mengaktifkan logging tambahan, lihat [Secara otomatis menambahkan supplemental logging untuk titik akhir sumber Oracle](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Oracle.AutoSupplLogging) di [Pemecahan masalah dan dukungan diagnostikPemecahan masalah latensi](CHAP_Troubleshooting.md) bagian dalam panduan ini. + Tetapkan `TimestampColumnName` parameter untuk titik akhir target. Tidak ada batasan pada nama kolom stempel waktu. Untuk informasi selengkapnya, lihat [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html). + Siapkan partisi folder berbasis tanggal untuk target. Untuk informasi selengkapnya, lihat [Menggunakan partisi folder berdasarkan tanggal](CHAP_Target.S3.md#CHAP_Target.S3.DatePartitioning). ## Izin untuk menggunakan validasi target S3 Untuk menyiapkan akses untuk menggunakan validasi target S3, pastikan bahwa peran yang ditetapkan ke akun pengguna yang digunakan untuk membuat tugas migrasi memiliki kumpulan izin berikut. Ganti nilai sampel dengan nilai Anda. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:CreateWorkGroup" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:CreateDatabase", "glue:DeleteDatabase", "glue:GetDatabase", "glue:GetTables", "glue:CreateTable", "glue:DeleteTable", "glue:GetTable" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": "*" } ] } ``` ------ ## Batasan untuk menggunakan validasi target S3 Lihat batasan tambahan berikut yang berlaku saat menggunakan validasi target S3. Untuk batasan yang berlaku untuk semua validasi, lihat. [Batasan](CHAP_Validating.md#CHAP_Validating.Limitations) + `DatePartitionSequence`Nilai Anda membutuhkan komponen Hari. Validasi target S3 tidak mendukung format. `YYYYMM` + Ketika validasi interval berjalan selama CDC, Anda mungkin melihat kesalahan validasi palsu dalam tabel. `awsdms_validation_failures_v1` Kesalahan ini terjadi karena AWS DMS memigrasikan perubahan yang tiba selama validasi interval ke folder partisi hari berikutnya. Biasanya, perubahan ini ditulis ke dalam folder partisi hari ini. Kesalahan palsu ini adalah batasan memvalidasi replikasi dari database sumber dinamis ke target statis, seperti Amazon S3. Untuk menyelidiki kesalahan palsu ini, periksa catatan di dekat akhir jendela validasi (00:00 UTC), yaitu saat kesalahan ini biasanya muncul. Untuk meminimalkan jumlah kesalahan palsu, pastikan bahwa `CDCLatencySource` untuk tugas rendah. Untuk informasi tentang pemantauan latensi, lihat[Metrik tugas replikasi](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task). + Tugas di `stopped` negara bagian `failed` atau tidak memvalidasi perubahan hari sebelumnya. Untuk meminimalkan kesalahan validasi karena kegagalan yang tidak terduga, buat tugas validasi terpisah saja dengan pemetaan tabel yang sama, serta titik akhir sumber dan target. Untuk informasi selengkapnya tentang tugas validasi saja, lihat[Menggunakan tugas validasi saja dengan validasi target S3](#CHAP_Validating_S3_only). + Kolom **Status Validasi** dalam statistik tabel mencerminkan keadaan validasi interval terbaru. Akibatnya, tabel yang memiliki ketidakcocokan mungkin muncul sebagai divalidasi setelah validasi interval hari berikutnya. Periksa bucket Amazon S3 target untuk ketidakcocokan yang terjadi lebih dari sehari yang lalu. `s3_validation_failures folder` + Validasi S3 menggunakan fitur tabel bucketed dari Amazon Athena. Hal ini memungkinkan validasi S3 untuk membuat salinan ember dari data tabel target. Ini berarti bahwa salinan data tabel dibagi menjadi subset yang cocok dengan partisi internal validasi DMS. Meja berember Athena memiliki batas 100.000 ember. Setiap tabel yang coba divalidasi oleh validasi S3 yang melebihi batas ini akan gagal validasi. Jumlah bucket yang coba dibuat oleh Validasi S3 sama dengan yang berikut: ``` (#records in the table) / (validation partition size setting) ``` Untuk mengatasi batasan ini, tingkatkan pengaturan ukuran partisi validasi sehingga jumlah bucket yang dibuat oleh Validasi S3 kurang dari 100.000. *Untuk informasi selengkapnya tentang bucketing, lihat [Partisi dan bucketing di Athena di Panduan Pengguna Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/ctas-partitioning-and-bucketing.html).* + Nama tabel tidak boleh mengandung karakter khusus kecuali garis bawah. Validasi S3 menggunakan Amazon Athena yang tidak mendukung karakter khusus (selain garis bawah) dalam nama tabel. Untuk informasi selengkapnya, lihat topik [MEMBUAT TABEL](https://docs.aws.amazon.com/athena/latest/ug/create-table.html) di *Panduan Pengguna Amazon Athena*. + Ketika fitur validasi AWS DMS data digunakan dengan target Amazon S3 yang dikelola oleh Lake AWS Formation, proses validasi gagal. Hal ini dapat mengakibatkan masalah konsistensi data. ## Menggunakan tugas validasi saja dengan validasi target S3 *Tugas hanya validasi* menjalankan validasi pada data yang akan dimigrasi tanpa menjalankan migrasi. Hanya tugas validasi yang terus berjalan, meskipun tugas migrasi berhenti, yang memastikan bahwa AWS DMS tidak melewatkan jendela validasi interval 00:00 UTC. Menggunakan tugas hanya validasi dengan titik akhir target Amazon S3 memiliki batasan berikut: + Validasi Amazon S3 untuk Tugas Beban Penuh dengan pengaturan Validasi saja diaktifkan didukung, tetapi beroperasi secara berbeda dari tugas Beban Penuh dan hanya Validasi untuk titik akhir lainnya. Untuk S3 sebagai Target, tugas jenis ini memvalidasi hanya terhadap Data Beban Penuh di target S3, dan tidak akan memvalidasi terhadap data apa pun yang dimigrasi sebagai bagian dari migrasi CDC. Hanya gunakan fitur ini untuk memvalidasi data yang dibuat oleh tugas Full-Load saja. Menggunakan mode ini untuk memvalidasi data dalam target yang menjalankan tugas CDC aktif tidak akan menghasilkan validasi yang efektif. + Hanya tugas validasi hanya memvalidasi perubahan sejak jendela validasi interval terakhir (00:00 UTC). Hanya tugas validasi yang tidak memvalidasi data muatan penuh atau data CDC dari hari-hari sebelumnya. # AWS DMS sinkronisasi ulang data AWS Database Migration Service (AWS DMS) Resinkronisasi data secara otomatis memperbaiki inkonsistensi data yang diidentifikasi melalui validasi data antara basis data sumber dan target Anda. Fitur ini berfungsi sebagai bagian dari tugas migrasi DMS yang ada, memastikan pembaruan yang tepat terjadi berdasarkan konfigurasi tugas, pengaturan koneksi, pemetaan tabel, dan transformasi Anda. Fitur resync data beroperasi dengan membaca kegagalan validasi dari tabel kontrol pada database target dan menjalankan operasi perbaikan yang sesuai. Ketika ketidakcocokan terdeteksi, data saat ini diambil dari sumber menggunakan kunci utama yang disimpan dalam catatan kegagalan, dan itu diterapkan ke target sambil menghormati transformasi yang dikonfigurasi. Untuk informasi selengkapnya, lihat [`awsdms_validation_failures_v2`meja kontrol](CHAP_Validating.md#CHAP_DataResync.Troubleshooting.v2table). Perilaku bervariasi tergantung pada jenis migrasi Anda. Untuk full-load-only tugas, Data resync berjalan sekali setelah pemuatan awal dan validasi selesai. Untuk tugas dengan Change Data Capture (CDC), Data resync beroperasi sesuai dengan jadwal yang dikonfigurasi, sementara menghentikan replikasi dan validasi sementara perbaikan diterapkan. Selama operasi sinkronisasi ulang CDC: + Replikasi dan validasi berhenti sementara. + Resinkronisasi data memproses kegagalan validasi yang ada. + Resume replikasi dan validasi normal. + Proses ini berulang berdasarkan jadwal yang dikonfigurasi. Resinkronisasi data secara otomatis melacak status setiap operasi perbaikan dan memberikan metrik terperinci melalui statistik tabel. **Prasyarat**: Fitur resync Data membutuhkan prasyarat berikut: + Anda harus memiliki AWS DMS mesin versi 3.6.1 atau yang lebih baru. + Anda harus mengonfigurasi pengaturan durasi jadwal dan waktu untuk tugas yang memiliki replikasi berkelanjutan. Tugas hanya beban penuh tidak memerlukan pengaturan ini. ## Batasan Fitur Data resync memiliki batasan sebagai berikut: + Resinkronisasi data hanya mendukung Oracle dan SQL Server sebagai database sumber. + Data resync mendukung PostgreSQL dan Amazon Aurora PostgreSQL mesin yang kompatibel dengan PostgreSQL sebagai basis data target. + Semua tabel dalam basis data sumber dan target Anda harus memiliki kunci utama. Validasi tidak mendukung tabel tanpa kunci utama atau kunci unik. Setiap tabel yang tidak memiliki kunci primer atau unik yang valid ditangguhkan dari validasi dan tidak ada kegagalan validasi yang dilaporkan. + Saat menjalankan Full-load-only tugas, validasi data harus diaktifkan. + Resinkronisasi data tidak dapat diaktifkan untuk tugas Validasi saja karena tidak mereplikasi data apa pun. Anda dapat mengaktifkan sinkronisasi ulang pada tugas replikasi induk hanya dengan menyediakan Validasi. `taskID` Untuk informasi selengkapnya, lihat [Tugas hanya validasi](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.ValidationOnly). + Jika tugas Validasi saja memiliki pengaturan `ControlSchema` parameter yang dikonfigurasi dalam pengaturan tugas, maka tugas replikasi juga harus memiliki konfigurasi parameter yang sama untuk sinkronisasi ulang Data untuk menemukan kegagalan validasi yang benar. + Anda diminta untuk mengonfigurasi pengaturan jadwal dan durasi waktu untuk tugas CDC. + Selama jendela resync, Data resync dapat berdampak pada latensi replikasi di DMS. [Untuk informasi selengkapnya mengenai validasi pemecahan masalah AWS DMS selama sinkronisasi ulang Data, lihat bagian [Pemecahan masalah](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting) di bawah validasi data.AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html) ## Penjadwalan dan waktu Untuk tugas dengan CDC, Anda harus mengonfigurasi kapan dan berapa lama Data resync beroperasi. Ini membantu mencegah dampak pada operasi replikasi normal Anda. Anda menentukan: + Jadwal menggunakan format cron untuk menentukan kapan operasi resync dapat terjadi. + Durasi maksimum untuk memastikan operasi sinkronisasi ulang tidak meluas ke periode penggunaan puncak. Disarankan untuk menjadwalkan operasi resync selama jam-jam off-peak atau ke periode di mana ada minimal atau tidak ada perubahan pada database sumber. **catatan** Waktu yang dijadwalkan termasuk menunggu aliran penerapan target kosong, karena sinkronisasi ulang Data dan replikasi normal tidak dapat berjalan secara bersamaan. ## Kasus penggunaan Fitur resync data memungkinkan pengguna untuk mendamaikan inkonsistensi data antara sumber dan sistem target. Ini mengidentifikasi catatan yang tidak cocok dan menyinkronkannya untuk menjaga konsistensi data di seluruh lingkungan terdistribusi. Kasus penggunaan berikut menunjukkan skenario umum di mana fitur resync data menyelesaikan tantangan konsistensi data: **Skenario 1: Tugas pemuatan penuh - jalankan sinkronisasi ulang menggunakan tugas DMS yang sama** Dalam tugas migrasi beban penuh DMS yang ada, Anda dapat melakukan hal berikut: + Aktifkan validasi:`Validation with data migration = true`. + Aktifkan sinkronisasi ulang: `Data resync = true` **Skenario 2: Beban penuh dan CDC, tugas hanya CDC - jalankan sinkronisasi ulang menggunakan tugas DMS yang sama** Dalam tugas migrasi CDC DMS yang ada, Anda dapat melakukan hal berikut: + Aktifkan validasi:`Validation with data migration = true`. + Aktifkan sinkronisasi ulang: `Data resync = true` + Tentukan jadwal sinkronisasi ulang:`"ResyncSchedule": "0 0,2,4,6 * * *"`. + Tentukan waktu sinkronisasi ulang: `MaxResyncTime": 60` **Skenario 3: Beban penuh dan tugas hanya CDC atau CDC untuk replikasi dan sinkronisasi ulang, dalam kombinasi dengan tugas validasi saja** Untuk melakukan operasi validasi hanya dalam tugas DMS lain saat menggunakan resync, Anda dapat melakukan hal berikut: + Buat validasi hanya tugas DMS CDC. **catatan** Anda harus mencatat dan menentukan ID tugas ini selama Resinkronisasi data. + Dalam tugas CDC utama Anda, nonaktifkan validasi:. `Data validation = false` + Aktifkan sinkronisasi ulang: `Data resync = true` + Tentukan jadwal sinkronisasi ulang:`"ResyncSchedule": "0 0,2,4,6 * * *"`. + Tentukan waktu sinkronisasi ulang:`MaxResyncTime": 60`. + Tentukan ID validasi hanya tugas DMS CDC. Hanya ID tugas validasi yang ditambahkan di akhir ARN. Contoh ARN: `arn:aws:dms:us-west-2:123456789012:task:6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI` dan Contoh validasi hanya ID tugas:. `6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI` ## Praktik terbaik Anda dapat memanfaatkan fitur resync Data AWS Database Migration Service untuk meningkatkan daya tahan tugas replikasi Anda dan mencapai konsistensi. Beberapa praktik terbaik untuk menggunakan fitur resync Data adalah: + Sebagai bagian dari resync Data, catatan yang memiliki ketidakcocokan diperbaiki dengan mengambilnya dari sumber dan menerapkannya pada database target. Jika database sumber diperbarui selama jendela resync, resync membaca nilai rekaman terbaru dan menerapkannya pada target. Hal ini dapat menyebabkan CDC menerapkan peristiwa gagal dan memperkenalkan inkonsistensi sementara pada database target. Untuk menghindari hal ini, Anda harus menjadwalkan jendela resync selama jam kerja atau periode di mana perubahan pada database sumber nol atau minimal. + Tetapkan jendela sinkronisasi ulang selama periode aktivitas basis data sumber minimal dan dalam ambang latensi target yang dapat diterima. Interval sinkronisasi ulang yang kecil dapat menyebabkan ketidakcocokan validasi yang belum diproses terakumulasi, sementara jendela besar dapat meningkatkan latensi replikasi ketika banyak kegagalan validasi terjadi. Pantau kegagalan validasi dan tingkat sinkronisasi ulang untuk menentukan jendela sinkronisasi ulang yang optimal selama periode tidak aktif sumber. Beberapa contoh untuk menyiapkan jendela resync adalah: + Beberapa konfigurasi jendela pendek: ``` "ResyncSchedule": "0 0,2,4,6 * * *", "MaxResyncTime": 60 ``` + Konfigurasi jendela harian tunggal: ``` "ResyncSchedule": "0 0 * * *", "MaxResyncTime": 360 ``` + Memantau latensi replikasi di DMS selama jendela sinkronisasi ulang dan sesuaikan jadwal yang sesuai untuk mengurangi lonjakan besar. + Anda dapat meninjau hasil sinkronisasi ulang melalui stastik tabel atau dengan menanyakan `awsdms_validation_failures_v2` tabel pada database target. Untuk informasi selengkapnya, lihat [Memantau tugas replikasi menggunakan Amazon CloudWatch](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.CloudWatch). + Saat tugas berada dalam fase replikasi yang sedang berlangsung, hindari memulai pemuatan ulang untuk tabel individual selama jendela sinkronisasi ulang. + Praktik terbaik untuk tugas replikasi CDC: + Semua tabel dalam database Anda menyelesaikan proses pemuatan. + Ketidakcocokan diidentifikasi dalam proses validasi yang sedang berlangsung. + Sesuai jendela terjadwal resync, tugas replikasi berhenti untuk waktu yang singkat. + Resinkronisasi data memperbaiki masalah yang diidentifikasi selama proses validasi. + Proses replikasi dilanjutkan dan diulang sesuai jadwal. ## Konfigurasi dan contoh sinkronisasi ulang data **Konfigurasi pengaturan sinkronisasi ulang data**: Anda dapat mengonfigurasi resync untuk tugas replikasi Anda di DMS. Di bawah ini adalah contoh konfigurasi pengaturan resync Data dalam tugas Anda: ``` "ResyncSettings": { "EnableResync": true, "ResyncSchedule": "0 0,2,4,6 * * *", // Run at 12AM, 2AM, 4AM, and 6AM daily "MaxResyncTime": 60, // Run for maximum of 60 minutes, or 1 hour "ValidationTaskId": "TASK-ID-IF-NEEDED" //Optional, used only if validation is performed as a separate Validation only task } ``` **Contoh pola penjadwalan resync umum**: + `0 0 * * *`: Jalankan sekali setiap hari di tengah malam. + `0 0,12 * * *`: Berlari dua kali setiap hari pada tengah malam dan siang hari. + `0 0,2,4,6, * * *`: Berlari setiap dua jam antara tengah malam dan 6 pagi. + `0 1 * * 1`: Jalankan setiap minggu pada hari Senin pukul 1 pagi. **catatan** Anda harus menentukan angka untuk setiap hari mulai 0 hingga 6. Untuk informasi selengkapnya, lihat [Aturan ekspresi cron](#CHAP_DataResync.cron). **Memantau operasi sinkronisasi ulang**: Anda dapat memantau operasi resync melalui statistik tabel. Berikut adalah contoh output: ``` { "TableStatistics": { ... "ValidationFailedRecords": 1000, ... "ResyncRowsAttempted": 1000, "ResyncRowsSucceeded": 995, "ResyncRowsFailed": 5, "ResyncProgress": 99.5, // ratio of ResyncRowsSucceeded/ValidationFailedRecords "ResyncState": "Last resync at: 2024-03-14T06:00:00Z" } } ``` Untuk mengonfigurasi fitur Resinkronisasi Data di AWS DMS, Anda dapat meninjau berbagai parameter sinkronisasi ulang dan pengaturan konfigurasi masing-masing. Untuk informasi selengkapnya, lihat [Pengaturan sinkronisasi ulang data](CHAP_Tasks.CustomizingTasks.TaskSettings.DataResyncSettings.md). Untuk informasi selengkapnya mengenai pengaturan pencatatan sinkronisasi ulang data, lihat[Pengaturan tugas pengelogan](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md). ## Validasi dan pemecahan masalah **Validasi**: Saat penilaian data diaktifkan, AWS DMS buat tabel kegagalan validasi di database target Anda dengan struktur berikut: ``` CREATE TABLE awsdms_validation_failures_v2 ( "RESYNC_ID" bigint NOT NULL, "TASK_NAME" varchar(128) NOT NULL, "TABLE_OWNER" varchar(128) NOT NULL, "TABLE_NAME" varchar(128) NOT NULL, "FAILURE_TIME" timestamp NOT NULL, "KEY_TYPE" varchar(128) NOT NULL, "KEY" varchar(7800) NOT NULL, "FAILURE_TYPE" varchar(128) NOT NULL, "DETAILS" varchar(7000) NOT NULL, "RESYNC_RESULT" varchar(128) NULL, "RESYNC_TIME" timestamp NULL, "RESYNC_ACTION" varchar(128) NULL ); ``` Anda dapat menulis kueri ke tabel ini untuk memahami ketidakcocokan data yang ditemukan dan bagaimana mereka diselesaikan. Saat validasi diaktifkan, AWS DMS buat tabel kegagalan validasi di database target Anda. Jika Anda memiliki masalah, Anda dapat menanyakan `awsdms_control.awsdms_validation_failures_v2` tabel untuk memahami ketidakcocokan data yang ditemukan dan bagaimana mereka diselesaikan. Untuk informasi selengkapnya, lihat bagian [Pemecahan masalah](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting) di Validasi [AWS DMS data](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html). **Alur kerja umum**: Selama validasi dalam resync data alur kerja standar adalah sebagai berikut: **Tugas Hanya Beban Penuh**: 1. Semua tabel dalam database Anda menyelesaikan proses pemuatan. 1. Ketidakcocokan diidentifikasi dalam proses validasi yang sedang berlangsung. 1. Resinkronisasi data memperbaiki masalah yang diidentifikasi selama proses validasi. 1. Proses validasi memvalidasi perbaikan. 1. Tugas migrasi berhasil diselesaikan. **Tugas CDC**: 1. Semua tabel dalam database Anda menyelesaikan proses pemuatan. 1. Ketidakcocokan diidentifikasi dalam proses validasi yang sedang berlangsung. 1. Sesuai jendela terjadwal resync, tugas replikasi berhenti untuk waktu yang singkat. 1. Resinkronisasi data memperbaiki masalah yang diidentifikasi selama proses validasi. 1. Proses replikasi dilanjutkan dan diulang sesuai jadwal. Setiap modifikasi yang dilakukan pada tugas seperti menghentikan tugas replikasi selama operasi sinkronisasi ulang atau memuat ulang dan memvalidasi ulang tabel dapat memengaruhi perilaku dan hasil tugas. Beberapa perubahan perilaku yang diketahui adalah sebagai berikut: **Saat Anda menghentikan tugas replikasi saat operasi sinkronisasi ulang sedang berlangsung**: + Operasi resync tidak secara otomatis dilanjutkan. Anda harus me-restart lagi. + Operasi sinkronisasi ulang di masa mendatang terjadi sesuai jadwal yang dikonfigurasi. + Setiap perbaikan yang tidak lengkap dicoba di jendela jadwal resync berikutnya. **Saat Anda memuat ulang tabel di database Anda**: + Operasi sinkronisasi ulang melewatkan tabel apa pun yang mengalami pemuatan ulang. + Kegagalan validasi sebelumnya untuk tabel yang dimuat ulang diabaikan. + Validasi baru dimulai setelah tindakan reload selesai. **Saat Anda memvalidasi ulang tabel di database Anda**: + Semua statistik untuk operasi sinkronisasi ulang Anda diatur ulang. + Kegagalan validasi sebelumnya untuk tabel yang divalidasi ulang diabaikan. **catatan** Saat memutakhirkan atau memindahkan tugas ke DMS versi 3.6.1 ke atas, kegagalan apa pun dalam `awsdms_control.awsdms_validation_failures_v1` tabel tidak disinkronkan ulang. Hanya kegagalan dalam `awsdms_validation_failures_v2` tabel yang disinkronkan ulang. Untuk menyinkronkan kembali kegagalan dalam `awsdms_control.awsdms_validation_failures_v2` tabel, Anda harus memuat ulang tugas, memuat ulang satu atau beberapa tabel dalam tugas, atau memvalidasi ulang satu atau beberapa tabel. Untuk informasi selengkapnya, lihat tautan berikut: Untuk memuat ulang tugas, lihat [referensi `StartReplicationTask` API](https://docs.aws.amazon.com/dms/latest/APIReference/API_StartReplicationTask.html). Untuk memuat ulang satu atau beberapa tabel dalam tugas, lihat [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html)di dokumentasi referensi *perintah AWS CLI*. Untuk memvalidasi ulang satu atau beberapa tabel, lihat `validate-only` opsi di [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html)bagian dalam dokumentasi referensi perintah *AWS CLI*. . ## Aturan ekspresi cron Untuk mengonfigurasi operasi resync Data selama tugas replikasi di AWS DMS Anda dapat menggunakan aturan ekspresi cron. Aturan ini memungkinkan Anda menyesuaikan jendela waktu sinkronisasi ulang dan menjadwalkannya sesuai kebutuhan bisnis Anda. Anda dapat menggunakan berbagai parameter seperti menit, jam, hari, bulan, dan hari dalam seminggu. Aturan ekspresi cron untuk setiap parameter adalah: **Menit**: + Rentang menit dari 0 hingga 59. + Anda dapat menggunakan (`-`),`or`/`and`untuk menentukan rentang. Maksimal 10 item dipisahkan dengan koma (`,`). + **Contoh:** + `2-5`sama dengan. `2,3,5,5` + `1-2,3-4,5,7-10`adalah rentang yang valid. + `1,2,3,4,5,6,7,8,9,10`adalah rentang yang valid. + `1,2,3,4,5,6,7,8,9,10,11`bukan rentang yang valid. Operasi sinkronisasi ulang melompati setelah item rentang ke-10. + Anda dapat menggunakan (`*`). Contoh: `*` sama dengan. `0-59` + Anda dapat menggunakan (`/`) hanya dalam kombinasi dengan (`-`) atau (`*`). **Contoh:** + `2-7/2`sama dengan. `2,4,6` + `*/15`sama dengan. `0,15,30,45` **Jam**: Sama seperti "**Menit**" tetapi rentang yang valid adalah dari `0` ke`23`. **Hari**: + Sama seperti "**Menit**" tetapi rentang yang valid adalah dari `1` ke`31`. + Penggunaan `L` didukung dalam konfigurasi sinkronisasi ulang. Itu ditafsirkan sebagai hari terakhir bulan itu. Anda tidak boleh menggunakannya dalam kombinasi dengan sintaks lain. **Bulan**: Sama seperti "**Menit**" tetapi rentang yang valid adalah dari `1` ke`12`. **Hari dalam seminggu**: + Sama seperti "**Menit**" tetapi rentang yang valid adalah dari `0` ke`6`. + Anda tidak dapat menambahkan nilai string untuk nama minggu ini.