On Mon, 9 Feb 2026 at 19:35, Xavier Figari via discuss <[email protected]> wrote:
> According to the MariaDB operator documentation, the snapshot is taken > as follows: > > - Temporarily pause the MariaDB writes by executing a `FLUSH TABLES WITH > READ LOCK` command in one of the secondary Pods. > - Create a VolumeSnapshot resource of the data PVC mounted by the > MariaDB primary Pod. > - Wait until the VolumeSnapshot is provisioned by the storage system. > When timing out, the operator will delete the VolumeSnapshot resource > and retry the operation. > - Issue a `UNLOCK TABLE` statement. If your snapshots are atomic (and they should be on any snapshot-capable solution, or the snapshots are useless anyway), you shouldn't need to do that. InnoDB is crash-safe, so just taking a snapshot will still be restorable, you'll just have to wait for redo log replay at startup, which is not a big deal if the redo log is sanely sized. > (https://github.com/mariadb-operator/mariadb-operator/blob/main/docs/physical_backup.md#volumesnapshots) > > I'm asking myself a few questions on this strategy : > - Does it work with Galera clusters ? (In principle, yes; the example > given in the documentation uses Galera). > - Does it handle Galera desynchronization correctly, as explained in > https://mariadb.com/docs/galera-cluster/galera-management/general-operations/backing-up-a-mariadb-galera-cluster > ? > - How do you perform a clean restore when using Galera ? Restore to a single node, bring it up in bootstrap mode, SST to the other two. > So far, until MariaDB 12.3 is out, the binlogs are not restored with > this strategy. I'll have to backup them in another way. Not sure how that is related, it depends on how/where your binlogs are stored, but bear in mind that by default when binlogs are in use, binlogs are used for recovery because there is an optimisation that was brought in a while back that omits one of the flushes when binlogs are enabled. On ZFS, I normally put binlogs somewhere like $datadir/.bin/ so the whole subtree can be atomically snapshotted and backed up. > They should be saved in the VolumeSnapshots, however, starting with > MariaDB 12.3 if I understand correctly : the > binlog_storage_engine=innodb parameter allows binlogs to be stored in > the InnoDB engine, instead of separate binary files (mysql-bin.*). > Binlogs will become an integral part of InnoDB data files, so they will > be included in the snapshot (tell me if I'm wrong). Snapshots are file system based. If you are on LVM, if your binlogs are in your $datadir they will be included. On ZFS you might have something like: pool/mysql -> /var/lib/mysql pool/mysql/.bin -> /var/lib/mysql/.bin And you can take an atomic recursive snapshot of pool/mysql to get the snapshot of both pool/mysql and pool/mysql/.bin at the same point in time, i.e. mutually consistent. If you arrange things that way there is no reason why you would need to treat your binlogs in a special, separate way. > Instead of using the MariaDB operator to perform the snapshot, could the > volume snapshot be achieved with a tool like Kasten? Kasten probably > won't do "FLUSH TABLES WITH READ LOCK" before the snapshot, in > particular, but I guess we could create pre-exec and post-exec hooks. No idea what that is, but as long as it takes a point-in-time consistent snapshot that then remains static or the duration of the backup, it should work just fine. -- Gordan Bobic Database Specialist, Shattered Silicon Ltd. https://shatteredsilicon.net Follow us: LinkedIn: https://www.linkedin.com/company/shatteredsilicon X: https://x.com/ssiliconbg _______________________________________________ discuss mailing list -- [email protected] To unsubscribe send an email to [email protected]
