Questions about orchestrator and Amazon Aurora

[Jim Ausman]

Hi,

I am the PM for the SRE team at Eventbrite and we use orchestrator for MySQL migrations. Now we are migrating to Amazon Aurora. Can we use it to manage the failover? Are there any particular details we need to pay attention to?

Thanks,

Jim Ausman

[Shlomi Noach]

I unfortunately have no expertise with Amazon Aurora; I have no tips on my side. If this group yields no solution, you may also try https://mysqlcommunity.slack.com/.

--
You received this message because you are subscribed to the Google Groups "orchestrator-mysql" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orchestrator-my...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/orchestrator-mysql/edb71004-877b-4b01-96eb-68297d3fe656n%40googlegroups.com.

[Matthias Crauwels]

Hi Jim,

Without much research I would say not it will not work… As Orchestrator uses the regular CHANGE MASTER TO, START SLAVE, STOP SLAVE commands. These commands don’t work on Aurora/RDS because of the lack of the SUPER privilege. Amazon has created some functions to trigger these command but Orchestrator does not know how to use those afaik.

Apart from that, Aurora replica’s don’t use regular MySQL replication but some kind of custom built redo-log/filesystem replication so Orchestrator won’t even discover the replica’s if you tried...

Best regards.

Matthias

[Luis Motta Campos]

Hello Jim, how are you doing today?

EXECUTIVE SUMMARY: Amazon RDS Aurora MySQL database clusters use their own failover mechanism. As far as I understand it there is no support in Orchestrator for it.

RDS Aurora “Clusters” (yeah, with quotes, because they are kind of weird) share one set of data-files (contained in EBS Volumes in the underlying storage) for all read-only replicas that are member of the same cluster.

This arrangement does not use MySQL’s traditional replication mechanism (which prevents Orchestrator from working properly). Also, it has its own master-promotion mechanism, which unfortunately is your only alternative in this case.

RDS Aurora Cluster’s arrangement of multiple database instances sharing the same underlying data storage in EBS volumes also makes it hard to configure and use the traditional replication mechanism we all know and love.

For a glimpse of the data-file organization and other High-Availability features of RDS Aurora MySQL clusters, I recommend you read this document and it’s first-level links:

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html

Additionally, RDS Aurora does not allow CHANGE MASTER statements to be executed. They require that all replication configuration change goest through a set of stored procedures. I am unsure wherever Orchestrator knows about these procedures and can call them. I would defer this question back to Shlomi, as it seems that there is not (anymore?) documentation about this in Orchestrator. 

I hope this helps. Please feel welcome to ask follow-ups directly to me, so we keep this list dedicated to Orchestrator-related topics.

Kind regards,

--

LMC

On Mar 25, 2021, at 4:06 PM, Jim Ausman <aus...@gmail.com> wrote:



--

[Shlomi Noach]

>  I am unsure wherever Orchestrator knows about these procedures and can call them. I would defer this question back to Shlomi, 

orchestrator knows nothing about such procedures and never did...

Thank you Luis

To view this discussion on the web visit https://groups.google.com/d/msgid/orchestrator-mysql/3A188E9A-5866-48C1-A5AF-2EBFDE749522%40gmail.com.