There are multiple scenarios where cloning using Stratis may be appropriate. Depending on constraints and what resources you have at your disposal there are different options to suit your requirements. It could be storage snapshot based, it could be purely database cloning using backup and restore or cloning from an active database. Another approach is to use facilities provided at an OS level and volume manager. And when this level is discussed – normally solutions like ZFS or BTRFS snapshots are mentioned, or if it is purely an Oracle oriented solution (licensing restrictions apply) see our previous article on – ACFS snapshots
In Red Hat Enterprise 8, Red Hat decided to stop supporting to shift the emphasis onto development of Stratis, which combines functionality of logical volume manager and filesystem management framework. Filesystem mechanisms are delivered by XFS which is well-known in the Linux world and it was in use for years, having a good reputation for performance and reliability.
While it is still in technology preview, Stratis has major features which XFS and other classic filesystems are lacking, like copy on write snapshots, thin provisioning, and pool based storage management . It also has similar features to BTRFS or ZFS (snapshots, storage pools) with some distinct differences:
- Stratis can support hybrid users and kernel local storage management system (ZFS on Linux has user space implementation as well)
- Stratis works more like upper level on top of native Linux subsystems like device-mapper, LVM and XFS filesystem
- Stratis team created a product which provides flexible and simple command line interface
- There are features like snapshots and encryption, however currently it does not support raid mechanisms or checksum protection. It should be implemented at lower levels like storage devices or logical volumes provisioned by LVM
From a database cloning perspective, Stratis can be considered a black box which provides access to crash recovery consistent snapshots of the source database.
Example Cloning Diagram
As Stratis snapshots are implemented as Copy-On-Write (COW) – cloned data is not replicated as a full copy, but it can be accessible as a separately mounted file system, from where cloned database can be started. It has to be noted that before starting we need to create a new Oracle parameter file and modify control files to reflect the new location of database files.
Steps to consider when cloning:
- Create new snapshot using stratis cli:
# stratis fs snapshot stratis-pool stratis-fs clone1
Where Stratis-pool is a Stratis managed pool of devices (SCSI, iSCSI, LVM supported by Stratis), stratis-fs is the filesystem where source database was placed and clone1 is the name of a new filesystem, which represents the snapshot below.
# stratis fs Pool Name Name Used Created Device UUID stratis-pool stratis-fs 8.67 GiB Oct 30 2020 04:03 /stratis/stratis-pool/stratis-fs a9da06e2fb924b70b961cf1935a5fe92 stratis-pool clone1 545 MiB Oct 30 2020 04:44 /stratis/stratis-pool/snap a5b5f024ead9437284e53c6aac451244
- Mounting new filesystem to new mount point
# Mount/stratis/stratis-pool/clone1 /stratis-clone1
- Update Oracle database parameters file
- Re-create control files of cloned database to reflect new location for files
- Recover database using redo logs if required
- Open database with reset logs
Additional links:
Github – Multi-threading support for Stratis (https://stratis-storage.github.io/)
Github – Stratis storage (https://github.com/stratis-storage/)
