A solutions architect is using AWS Database Migration Service (DMS) to migrate an on-premises MySQL database to Amazon Aurora MySQL. The architect configures a replication task with both full load and continuous replication (Change Data Capture) enabled. The full load phase completes successfully, and all existing data is copied to the target database. However, subsequent insert and update transactions performed on the on-premises database are not replicated, and the task status stalls. Which of the following is the most likely cause of this behavior?
- Binary logging (binlog) was not enabled on the source MySQL database prior to starting the replication task.Cevap
- BThe replication task attempted to write directly to a standby instance of a Multi-AZ deployment instead of the primary instance.
- CThe migration was misclassified as refactoring, requiring the schema to be converted with the AWS Schema Conversion Tool (SCT) before continuous replication could begin.
- DTCP port 1500 was blocked on the source database server's firewall, preventing the replication agent from transmitting transaction logs.
Cevap
Binary logging (binlog) was not enabled on the source MySQL database prior to starting the replication task.
The correct answer is that binary logging (binlog) was not enabled on the source MySQL database. AWS Database Migration Service (DMS) uses the source database transaction logs (binary logs in MySQL) to capture and replicate ongoing transactions (CDC). Without binary logging enabled on the source, DMS has no way to track changes after the full load phase completes, resulting in a stalled or failed task.
Adım Adım Çözüm
Anahtar Kavram
Continuous replication (CDC) using AWS DMS requires database-specific log configurations (such as binary logging for MySQL or supplemental logging for Oracle) to capture real-time changes.