Availability & recovery review

Availability & Recovery Review

Understand the risks in your database failover and recovery approach. Identify untested assumptions and the next checks your team should prioritise.

What a review can look at

A focused review of your MySQL, MariaDB or Aurora MySQL setup, with a written assessment of the evidence, the main risks, and recommended validation steps. We agree the scope before starting: failover, restore readiness, or a related set of recovery concerns.

  • Failure handling

    What happens when a node, an availability zone or a network link fails: what detects it, what reacts, and what the application sees.

  • Replication and failover design

    How is failover triggered? How do applications reconnect? Review the promotion path, replication assumptions, and the checks needed to validate safe failover.

  • Backup and restore assumptions

    Could your team restore the backups in the way you expect? Identify which parts of the recovery procedure have been tested and which still need evidence.

  • Recovery objectives

    Compare the data loss and recovery time your team can accept with what the current design and procedures can plausibly support.

Relevant environments

MySQL, MariaDB and Aurora MySQL; asynchronous or semi-synchronous replication, Galera Cluster and InnoDB Cluster; proxies such as ProxySQL, MaxScale and MySQL Router. The review follows the agreed failure and recovery scenarios across the database and its supporting components.

What you receive

A written assessment and a handover, covering:

  • The concerns reviewed and the scope of the investigation.
  • The key assumptions, stated explicitly, including the ones that could not be confirmed.
  • Risks, with the scenario in which each one matters.
  • Recovery considerations for the agreed scenarios.
  • Validation recommendations, such as restore tests or failover exercises your team can run.

How it runs

  1. Agree the environment, related concerns, scenarios and effort limit.
  2. Review the architecture, configuration and procedures you share.
  3. Write up assumptions, risks and validation recommendations.
  4. Walk your team through the findings in a handover.

Scope, deliverables, effort limit, fee and schedule are agreed in writing before work begins.

Boundaries

  • No guaranteed availability level or recovery objective.
  • Not a managed recovery operation, on-call cover or emergency response.
  • Production changes and implementation stay with your team or implementation partner.

Related reading: testing a MySQL backup by restoring it as a replica (a lab walkthrough).

Questions

Do you run the failover tests or restores yourself?

Not as part of the standard review. The review recommends validation steps and explains what each one proves; your team runs them. Hands-on involvement would be a separate, explicitly agreed scope.

Can you guarantee a recovery time or availability level?

No. The review assesses whether your design and procedures plausibly support the objectives you set, and how to test that. Only testing in your environment can show what they actually deliver.

Which platforms does the review cover?

MySQL, MariaDB, Galera-based clusters, InnoDB Cluster and Amazon Aurora MySQL, including the proxies and backup tooling around them.

Need an independent review of your recovery approach?

Describe the architecture and the concerns you need to investigate. We can then agree whether a focused review is the right next step.