How to turn on binary logging for Aurora Serverless V1 cluster?
I want to migrate my Aurora Serverless V1 cluster to V2 with almost zero downtime, for this, I am creating a DMS task which will replicate and capture CDC events from source (Aurora Serverless V1) to target (Aurora Serverless V2) and then I can switch from older cluster to newer one through changes in SecretManager itself.
But DMS migration task is failing as binary logging is turned off in source database, to enable it in Aurora Serverless V1 cluster, I created a custom parameter group and set binlog_format=ROW there, associated this parameter group with cluster. But, still not able to see binary logging turned on.
SHOW VARIABLES WHERE Variable_name IN ('log_bin', 'binlog_format', 'binlog_row_image');
Docs tell to reboot instance after changing params, but I don't see any Reboot option for Aurora Serverless V1 cluster?
Can anyone help me out with this?
- Newest
- Most votes
- Most comments
Unfortunately, it's not possible to enable binary logging for Aurora Serverless v1 clusters. Aurora Serverless v1 does not support binary logging, which is a limitation of this version.
For Aurora Serverless v1, the binary log settings are managed internally by AWS and cannot be modified by users. This means that even if you create a custom parameter group and set the binlog_format parameter, it won't have any effect on the Aurora Serverless v1 cluster.
Given this limitation, your approach of using AWS DMS with CDC for a near-zero downtime migration from Aurora Serverless v1 to v2 won't work as intended.
For migrating from Aurora Serverless v1 to v2 with minimal downtime, you might need to consider alternative approaches:
-
Use AWS Database Migration Service (DMS) with full load only (without CDC). This will copy all existing data, but won't capture changes during the migration.
-
Use a snapshot and restore method. Take a snapshot of your v1 cluster, restore it to a v2 cluster, and then sync any changes that occurred during the restoration process.
-
If possible, consider setting up a read replica of your Aurora Serverless v1 cluster as an Aurora provisioned instance, enable binary logging on this replica, and then use it as the source for your DMS task with CDC.
-
Use application-level logic to track changes during the migration period and apply them to the new cluster after the initial data transfer.
Each of these approaches has its own trade-offs in terms of complexity and potential downtime. The best method will depend on your specific requirements and constraints.
Remember to thoroughly test your chosen migration strategy in a non-production environment before attempting it on your production database.
Sources
Replicating Amazon Aurora MySQL DB clusters across AWS Regions - Amazon Aurora
Setting up binary log replication for Aurora MySQL - Amazon Aurora
Configuring Aurora MySQL binary logging - Amazon Aurora
Relevant content
- AWS OFFICIALUpdated 10 months ago
