Operate — Service
MySQL Engineering and High Availability
MySQL deployment and operational support — from a small standalone database to high-availability DC and DR architecture.
High availability is not a product you install; it is a set of trade-offs between consistency, latency, failover time and operational complexity, and the right answer differs for every workload. We size the architecture to the requirement rather than deploying the same cluster everywhere, and we test the failover and the restore, because a recovery position that has never been exercised is a hope rather than a plan.
Available as
- MySQL installation
- Database migration
- Database deployment
- MySQL performance tuning
- Backup and recovery
- MySQL high availability
- MySQL cluster
- DC and DR implementation
- MySQL upgrade
- Database deployment support
- Managed MySQL support
- On-demand DBA support
What is included
- MySQL installation, configuration and upgrades
- Schema deployment and database release support
- Backup strategy and point-in-time recovery
- Restoration testing
- Slow-query and execution-plan analysis
- Configuration, memory and connection tuning
- User, role and access management
- Replication and Group Replication
- InnoDB Cluster and MySQL Router
- Automatic failover and switchover procedures
- Cross-site DC and DR replication
- Database monitoring and health reporting
What changes
The difference this makes.
- 01
An architecture chosen against your workload and recovery targets, not a default template
- 02
Backups proven by restoring them, with the recovery time actually measured
- 03
Failover and switchover written as procedures and rehearsed before you need them
- 04
Replication and cluster health monitored, so a broken replica is found before a failover needs it
In detail
Everything this service covers.
The full breakdown. Not every item applies to every engagement — scope is agreed against your requirement.
Installation and deployment
- Requirement assessment
- Server sizing
- MySQL installation
- Version selection
- Configuration
- Database creation
- Schema deployment
- Application connectivity
- User and permission configuration
- Secure-access setup
- Character-set and collation configuration
- Environment-specific deployment
- Upgrade planning
- Version upgrades
- Patch management
- Deployment documentation
Database release support
Schema and data changes run the same controlled channel as application deployments.
- SQL script review
- Database dependency review
- Schema-change validation
- Data-migration planning
- Pre-deployment backup
- Database Method of Procedure
- Rollback planning
- Production execution
- Post-deployment validation
- Application-connectivity validation
- Deployment closure report
Backup and recovery
- Backup strategy
- Logical backup
- Physical backup where appropriate
- Full backup
- Incremental backup
- Binary-log management
- Point-in-time recovery
- Backup automation
- Backup encryption
- Retention policy
- Restoration testing
- Recovery documentation
Performance optimisation
- Slow-query analysis
- Query optimisation
- Index review
- Execution-plan analysis
- Configuration tuning
- Memory tuning
- Connection tuning
- Storage assessment
- Lock analysis
- Deadlock analysis
- Database-growth assessment
- Capacity planning
- Performance monitoring
Database security
- User management
- Role management
- Least-privilege access
- Password policies
- Network restrictions
- Encryption configuration
- Audit configuration where supported
- Security patching
- Access review
High availability
Capabilities we deploy. Which of them applies is decided per project, not in advance.
- Primary and replica
- Asynchronous replication
- Semi-synchronous replication
- Group Replication
- InnoDB Cluster
- MySQL Router
- Proxy-based routing
- Read scaling
- Automatic failover
- Multi-node architecture
- MySQL NDB Cluster where appropriate
- Cluster monitoring
- Split-brain prevention
- Failover procedure
- Switchover procedure
- High-availability testing
How the architecture is selected
The same cluster is not right for every project. Selection is made against all of these together.
- Workload profile
- Availability requirement
- Recovery target
- Data-consistency requirement
- Application compatibility
- Network design
- Operational capability
- Budget
DC and DR
- Primary DC database architecture
- DR database architecture
- Cross-site replication
- Replication monitoring
- Recovery Point Objective
- Recovery Time Objective
- DR failover procedure
- DR fallback procedure
- Application-connectivity coordination
- Data-consistency validation
- DR drills
- Failover testing
- Restoration testing
- DC-DR documentation
Monitoring and support
- Database availability
- Replication monitoring
- Cluster-health monitoring
- Query-performance monitoring
- Connection monitoring
- Disk monitoring
- Backup monitoring
- Error-log monitoring
- Slow-query monitoring
- Capacity alerts
- Incident support
- Root-cause analysis
- Monthly database-health reporting
Scope and limits
What we will not claim.
These are on the page deliberately. A service description that only makes promises is the one that produces an argument later.
Recovery Point and Recovery Time Objectives are set with you against the architecture actually deployed. We do not publish uptime figures or recovery targets that are not tied to a specific design.
A high-availability architecture increases operational complexity as well as resilience. Where a simpler design meets your recovery target, we will recommend it.
Considering mysql engineering and high availability?
Tell us what you are trying to achieve and what you already have in place. We will tell you what we would take on.