Home > Workload Solutions > Oracle > White Papers > MySQL InnoDB Cluster on Dell EMC PowerStore T > LUN provisioning options
Snapshots are read-only, point-in-time copies of data in a volume, volume group, virtual machine, or file system. Snapshots are commonly used to create copies of databases for use with new applications or for development and testing of existing database applications. The PowerStore T can take snapshots of file systems (SMB and NFS) and block-based systems.
The PowerStore administrator can create write-ordered-consistent and application-consistent snapshots even for I/O consistency-critical applications like Oracle RAC. With write-ordered snapshots, the array creates a copy of the volumes in which all the writes are order-consistent, ensuring that the database or application can be recovered or repurposed. With write-ordered-consistent snapshots, no database or application recovery is required.
You can also specify a thin clone when creating a copy of the database. Both the original source database and the thin clone of the database can be updated and modified. Even if the original source database is removed, the thin clone is unaffected and the business can continue using the cloned database. With thin clones the business can establish hierarchical snapshots to preserve data over time and in different states.
Both snapshots and thin clones can be used to refresh a storage resource. The process starts with removing the existing data. A good tip is to take a snapshot of the data or database before removing it as a backup. If the original data must be recovered, it is easy to accomplish from the backup snapshot. The refresh completes when all data has been copied. Refreshing a database from array-based copies enables activities like incremental testing or destructive tests common in software dev/test and many other scenarios. Both snapshots and thin clones benefit from data reduction, which saves substantial space on PowerStore systems.
The following table shows the PowerStore volume group configuration for MySQL. Each of the three MySQL nodes had the same storage volumes: OS, data, log, and temp. Thus, each node was provisioned with 4.7 TB of NVMe storage for a total allocation of 14.1 TB.
Volume group |
Name |
Description |
Size |
Number of volumes |
Data reduction |
OS |
PROD_VM |
Guest VM operating system |
600 GB |
1 |
Yes |
DATA |
PROD_DATA |
Data files |
2 TB |
1 |
Yes |
LOG |
PROD_LOG |
Log, redo, and binlog |
2 TB |
1 |
Yes |
TEMP |
PROD_TEMP |
Temporary and undo |
100 GB |
1 |
Yes |
All the volume groups that were created in our tests were configured to be thinly provisioned in the validation tests. No performance issues were observed. Oracle MySQL databases can safely use thin-provisioned volumes.