PATTERN Cited by 1 source
Logical backup engine plug-in¶
Pattern¶
Treat the database backup engine as a pluggable interface rather than a single implementation, so logical-backup and physical-backup engines can coexist inside one cluster, and external contributors can author new engines against the interface. The cluster's backup subsystem defines an engine contract (take full backup, take incremental backup, restore, produce point-in-time recovery) and each engine implementation (logical via mysqlshell / mysqldump; physical via xtrabackup / LVM snapshot) satisfies the contract with its own mechanism. Operators select the engine per-workflow per-use-case: physical for fast disaster-recovery restores that match the source binary layout; logical for schema-version-portable archival, cross-engine migration, or selective per-table restore.
Structural benefits:
- Coexistence — one cluster can keep physical backups for DR and logical backups for archival without needing separate subsystems.
- External contribution — a pluggable engine interface lets external companies author and upstream new engines (Slack authored the
mysqlshellengine for Vitess 21). - Use-case-specific selection — the backup team doesn't have to pick one engine and live with its trade-offs; different workflows pick different engines.
Seen in¶
- sources/2026-04-21-planetscale-announcing-vitess-21 — Vitess 21 ships an experimental
mysqlshelllogical-backup engine authored by Slack Engineering, alongside the prior-default physical engine: "Introducing an experimental mysqlshell engine. With this engine, it is possible to run logical backups and restores. The mysqlshell engine can be used to create full backups, incremental backups, and point-in-time recoveries. It is also available to use with the Vitess Kubernetes Operator. The mysqlshell engine work was contributed by the Slack engineering team." First canonical wiki instance of the pattern — both the pluggable-interface architecture and the external-company-contribution dynamic.