Conversation
Due to the way aurora is architected, replication means something slightly different to the traditional sense. This includes a work around to use test/migrate on replica instead of only master migrations.
|
@pbitty @shlomi-noach do you mind running your eyes over this and making sure I've covered everything? |
shlomi-noach
left a comment
shlomi-noach
left a comment
There was a problem hiding this comment.
Thank you for working on this ❤️ !
Since I'm not running RDS nor Aurora, I have no technical review to offer.
However, can we have a playbook checklist available for Aurora? A list of actions/configurations that must be checked/set for running the migration?
| @@ -0,0 +1,31 @@ | |||
| # Amazon RDS | |||
There was a problem hiding this comment.
Let's just add a quick sentence before this line, carifying that gh-ost actually runs on RDS and Aurora.
| ## Limitations | ||
|
|
||
| - No `SUPER` privileges. | ||
| - `gh-ost` runs should be setup use [`--assume-rbr`][assume_rbr_docs] and use `binlog_format=ROW`. |
There was a problem hiding this comment.
[assume_rbr_docs] link
There was a problem hiding this comment.
I gather you mean, "whoa, where's the actual link? have you gone crazy?" 😛
These are reference links which allow you to reuse a single link multiple times without repeating it over and over. The links themselves are put at the bottom.
Or would you rather not use reference links?
There was a problem hiding this comment.
oh, you're right 😛 , thank you for pointing this out!
|
|
||
| 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][migrate_test_on_replica_docs] 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][aws_replication_docs] 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. |
There was a problem hiding this comment.
[aws_replication_docs] link
Sure! Let me ponder on how to best present this without confusing people who actually want to use non-RDS documentation when they come searching for it. |
|
@jacobbednarz I changed the title to "WIP: ..." (Work In Progress). Please ping me when you wish me to merge this PR. Thank you very much! |
|
Thanks @shlomi-noach. I'm standing up fresh clusters at the moment to put together a checklist and should be able to report back in the next day or so with some updates. |
|
Sorry for the late reply. I will take a look at it today. |
|
@shlomi-noach I'm happy to merge as is and if there is any feedback from @pbitty (or others on RDS) we can open new PRs for it. |
shlomi-noach
left a comment
shlomi-noach
left a comment
There was a problem hiding this comment.
Looks great! Please make sure there's a link to this document from wherever makes sense to you.
|
Oh, derpp! 🤦♂️ Let me add that too. |
|
Are you 👌 with c3eda3f? |
|
Thank you! |
|
🎉 🎉 🎉 |
3 participants
This adds a new file under the
docdirectory that covers the caveatsand work arounds for using Amazon RDS.
The idea here is that we have a RDS document and each engine (mysql,
aurora, etc) gets a sub section for specific stuff and everything else
ends up as general as possible.