Backup and Recovery?

[John Smiley]

I've been looking around on the Orchestrator docs, scanned through 100+ slides on a Shlomi prezzo, Googled a fair amount, and searched this group in an attempt to answer a very basic question without having to install Orchestrator to find out. 

Does Orchestrator manage backup and recovery?  The ability to move replicas around would seem to imply that it does, but I don't see any reference to a "create replica" function or any direct mention of backup and recovery.  If it does it, where can I find the docs on how to manage it.  If it doesn't do it, what does it need?

[Shlomi Noach]

It does not. I'm not planning on adding backup/restore functionality; refactoring does not imply backup/restore.

there's a huge PR to support this: https://github.com/openark/orchestrator/pull/1120 I haven't had the opportunity to review it thoroughly, and I'm unlikely to review it in the near future.

On Mon, Nov 23, 2020 at 6:46 PM John Smiley <jrsm...@gmail.com> wrote:

I've been looking around on the Orchestrator docs, scanned through 100+ slides on a Shlomi prezzo, Googled a fair amount, and searched this group in an attempt to answer a very basic question without having to install Orchestrator to find out. 

Does Orchestrator manage backup and recovery?  The ability to move replicas around would seem to imply that it does, but I don't see any reference to a "create replica" function or any direct mention of backup and recovery.  If it does it, where can I find the docs on how to manage it.  If it doesn't do it, what does it need?

--
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/0d00ce20-94b4-46eb-a256-3f22b2ceca5dn%40googlegroups.com.

[John Smiley]

How does refactoring move the replica if it doesn't do essentially a backup and restore?

[Shlomi Noach]

Refactoring of the topology is merely the act of making the replica replicate from another server. Whether by GTID, Pseudo GTID or plain old coordinates, the replica already has the complete data set, and just needs to pick another server as a parent and know at what coordinates to replicate from. This does not require backup/restore.

To view this discussion on the web visit https://groups.google.com/d/msgid/orchestrator-mysql/ba6e1ba3-1c9f-485a-ac50-61bd44e7b34dn%40googlegroups.com.

[John Smiley]

What do you recommend to automate backup and recovery for a MySQL fleet then?

[John Smiley]

So in the the refactoring case, Orchestrator starts with a copy of the data already present on the target server?  What puts it there?

[John Smiley]

In other words, what instantiates the replica before Orchestrator brings it into the topology?  There are many ways to do this.  I'm looking for recommendations that others have used at scale in conjunction with Orchestrator.  Is there a reason this isn't mentioned in the docs or prezzos?

[Luis Motta Campos]

> On Nov 23, 2020, at 12:33, John Smiley <jrsm...@gmail.com> wrote:
>
> What do you recommend to automate backup and recovery for a MySQL fleet then?

John,

I use Percona's XtraBackup (https://www.percona.com/software/mysql-database/percona-xtrabackup) and a wrapper script that knows how to package and upload a backup file from my EC2 instances to S3 for backups.

For restores, I've written another wrapper script that downloads a backup package from S3 and uses Percona Toolkit tooling to move the data files in place automatically, starting up MySQL at the end.

I also have a separated script that knows how to hook up a server to replication, including retrieving replication credentials from Vault or AWS Secrets Manager.

Last but not least important, I have another script that checks a given MySQL server replication and, while it is still lagging behind drops consistency settings in the server with "SET GLOBAL sync_binlog = 0 , innodb_flush_log_at_trx_commit = 0;" for as long as it takes for that server to catch up with replication. The same script maintains a flag file in the disk to signal other systems (like my load-balancer health checks) that this particular database is lagging behind too much and is currently not suitable for resolving queries in production.

Unfortunately all this is very specific to my environment and I would be hard-pressed to make it all available as open-source software the way it is now.

I hope this gives you ideas about where to start.

Kind regards,
--
LMC

[Luis Motta Campos]

> On Nov 23, 2020, at 12:50, John Smiley <jrsm...@gmail.com> wrote:
>
> In other words, what instantiates the replica before Orchestrator brings it into the topology? There are many ways to do this. I'm looking for recommendations that others have used at scale in conjunction with Orchestrator. Is there a reason this isn't mentioned in the docs or prezzos?

John,

I suggest this might not be the best forum for that. You might be better off asking these questions at a MySQL forum of some sort.

I have some experience with answering these kinds of questions. I am available if you want to set up a private conversation.

Kind regards,
--
LMC