3.6 KiB
gh-ost
has been updated to work with Amazon RDS however due to GitHub not relying using AWS for databases, this documentation is community driven so if you find a bug please open an issue!
Amazon RDS
Limitations
- No
SUPER
privileges. gh-ost
runs should be setup use--assume-rbr
and usebinlog_format=ROW
.- Aurora does not allow editing of the
read_only
parameter. While it is defined as{TrueIfReplica}
, the parameter is non-modifiable field.
Aurora
Replication
In Aurora replication, you have separate reader and writer endpoints however because the cluster shares the underlying storage layer, gh-ost
will detect it is running on the master. This becomes an issue when you wish to use migrate/test on replica because you won't be able to use a single cluster in the same way you would with MySQL RDS.
To work around this, you can follow along the AWS replication between clusters documentation for Aurora with one small caveat. For the "Create a Snapshot of Your Replication Master" step, the binlog position is not available in the AWS console. You will need to issue the SQL query SHOW SLAVE STATUS
or aws rds describe-events
API call to get the correct position.
Percona Toolkit
If you use pt-table-checksum
as a part of your data integrity checks, you might want to check out this patch which will enable you to run pt-table-checksum
with the --no-binlog-format-check
flag and prevent errors like the following:
03-24T12:51:06 Failed to /*!50108 SET @@binlog_format := 'STATEMENT'*/: DBD::mysql::db do failed: Access denied; you need (at least one of) the SUPER privilege(s) for this operation [for Statement "/*!50108 SET @@binlog_format := 'STATEMENT'*/"] at pt-table-checksum line 9292.
This tool requires binlog_format=STATEMENT, but the current binlog_format is set to ROW and an error occurred while attempting to change it. If running MySQL 5.1.29 or newer, setting binlog_format requires the SUPER privilege. You will need to manually set binlog_format to 'STATEMENT' before running this tool.
Preflight checklist
Before trying to run any gh-ost
migrations you will want to confirm the following:
- You have a secondary cluster available that will act as a replica. Rule of thumb here has been a 1 instance per cluster to mimic MySQL-style replication as opposed to Aurora style.
- The database instance parameters and database cluster parameters are consistent between your master and replicas
- Executing
SHOW SLAVE STATUS\G
on your replica cluster displays the correct master host, binlog position, etc. - Database backup retention is greater than 1 day to enable binlogs
- You have setup
hooks
to issue RDS procedures for stopping and starting replication. (see github/gh-ost#163 for examples)