00:00
Hello. My name is Andrew Sullivan, and I am a principle solutions manager with pure storage. Today I'm going to talk to you about databases and volume snapshots and where volume snapshots can be used with databases. Flash right volume snapshots are created as a reference to the content of the volume. At a point in time, they can be created, copied or restored instantaneously.
00:30
They are also thin provision and de duplicated so that they do not consume any more space than is absolutely necessary. Volume snapshots can also be created on their own for a single volume or as part of a protection group containing many volumes, ensuring that all volumes in that protection group are consistent with each other at each point in time. This is really important for databases that
00:52
could potentially be SHAR did, such as s a piano with its scale out technology capabilities, ensuring that each and every single node or replica is consistent with each and every single piece of storage. At each point in time volume snapshots can also be created. Using are safe mode snapshots, technology safe mode snapshots allow us to ensure that no volume is eradicated before the
01:16
point in time that a customer sets this to be volume snapshots for databases can be created in one of two different ways. Crash consistently or application consistently. A crash consistent volume snapshot for a database volume is only done at the volume level. What this means is there is no quieting. There is no state of preparedness for the database volume.
01:38
It is assumed that the state in which the volume snapshot was created is the state in which the database will be restored. Sometimes this is as simple as equating it, too, pulling the plug on an entire database and then powering everything back up application. Consistent snapshots are a lot more involved. What this means is that there is coordination between the creation of the volume snapshot and the application.
02:02
This could involve quieting at the application level or ensuring the database is in a specific state of preparedness in order to create that volume snapshot. So let's begin with the volume. This is our volume on a flash array. This volume is both in provisions and be duplicated. To create a volume snapshot is easy.
02:22
You either execute the command via the CLI, the graphical user interface or any of our rest API s and immediately. As soon as that volume snapshot is created, it is present as an immutable copy of the volume. For that point in time. Now, once your volume snapshot is being created, we can actually do one or two things.
02:47
We can restore it to a new volume, creating a copy of the database at that point in time and ensuring that its contents reflect how it was when we started creating it. Or you can restore the volume snapshot to its original volume, overwriting its contents. Now this is important. Even though you're overwriting its contents, you're not losing the state of those contents
03:12
prior to be being overwritten you. All that happens is we actually just create a snapshot of that volume prior to changing at ST to this volume snapshot, thus ensuring that you have yet another volume snapshot you can restore things to. Should things go very badly, let's move on as to how these unique snapshot capabilities can be used for different databases.
03:33
What I've done is I've drawn up a list of some of the most popular databases on the planet Microsoft SQL Oracle Database s a P Hannah, my SQL Maria db Post grass and mongo db My SQL Maria DB will share a lot of the same use cases, so I'll only be drawing up the use cases for my SQL even though they apply to Maria DB. Let's take a look at the first use case, which is data protection.
04:03
Each and every single one of these databases can use data protection. Microsoft SQL can have volume snapshots created application consistently using the V S s provider or the sequel Server Management Studio Extension. It is also possible and sequel Server 2022 to create V. D. I based snapshots, thus eliminating the need to
04:24
use V. S s Oracle database. Snapshots can be created application consistently or crash consistently if we use crash consistent volume snapshots with Oracle database. All this means is that Oracle will start up as if a power cord has been pulled from the server. S A P. Hannah is a lot more complex, but you can
04:47
create both crash consistent and application consistent storage snapshots with ASAP Hannah the process to creating an application consistent snapshot is called creating a data snapshot creating a data snapshot simply writes all of the instance information to a specific area on the data volume and ensures that during recovery it knows how to recover that specific instance with regards to crash consistent snapshots with S A.
05:11
P. Hannah, all that needs to happen is mount up the volume to the S A. P. Hannah instance. Ensure that it's mounted at the correct location. Start the instance, and it will come up as if it was rebooted or power. Cable has been pulled with a scale out ASAP. Hannah System.
05:27
You need to ensure that each and every single volume is mounted to the correct note from whence it was taken with my SQL Maria DB because there are numerous number of storage engine that could be used for these. What we're going to do is we're going to focus on the most popular storage engine, which is N o. D. B. And what we're going to do is talk about how
05:48
that storage engine can be used to create application consistent snapshots, whereas if you are not using n o. D. B simply just create crash consistent snapshots. So with my school and Maria db, you have the ability to close and open the storage engines and put them into read only mode specifically to N o. D B. That's a single command to create an
06:12
application. Consistent snapshots. All we do is we execute that command, wait for it to come back, create the volume snapshots and release the read lock. That's actually really easy with postgres. There is also a way to do application. Consistent snapshots and crash. Consistent snapshots work perfectly fine with
06:29
it as well. Mongo DB can also create application, consistent snapshots or crash consistent snapshots and required to you to have either CLI or API access to the instance. The next use case we're gonna talk about is how databases achieve scale with Microsoft SQL Server. What we have is we have a technology called
06:51
always on availability groups, always on availability. Groups allow sequel server environments to scale by replicating the data from one instance to another for a specific database or databases. What's really important is that when their data is being copied from one instance to another, that's going to take time. Volume snapshots can be used in this instance
07:14
to speed that up significantly from sequel Server 2022 onwards. This even becomes an a process that can be done online, whereas in previous versions of sequel server availability, groups need to be seated in an offline mode. For Oracle databases, there's a technology called data guard or Active data guard,
07:40
which creates a physical standby server for disaster recovery and availability purposes, as well as read scale for active data guard, which is a licenced feature. Now, volume snapshots can be used to create the physical standby prior to ensuring it comes online and doing the configuration. This saves a hell of a lot of time during the seeding process of setting up that physical standby server,
08:04
thus eliminating the need to use our man or any other backup or recovery capabilities for my SQL Maria db. There are a number of replication technologies starting with standard replication, then moving on to group replication for my SQL or Galera cluster for both my SQL and Maria DB. In every single one of those replication technologies, volume snapshots can be used to
08:28
see the replicas or secondary systems for all of the replication. Technologies within post grass volume snapshots can also be used. This is true for log shipping and streaming replication for Mongo DB databases, we're using replica sets. Any replica can be seeded from one specific available system.
08:53
The final use case for volume snapshots with databases is making application workflows more efficient application. Workflows can include things such as taking a production system, copying it to a different place, doing some bits to it and ensuring your developers can use it for live test and development. It's also possible to use it for quality
09:18
assurance purposes, ensuring that if we need to run specific reports, but we don't want to overload courts, systems or production systems. The use of volume snapshots with databases can rip place slower tools, thus increasing the efficiency of all of these workflows. Thus, for every single database on this list, as well as others,
09:37
if you want to do E T l. If you want to do test Dev cloning, you want to do QA cloning or you just want to spin up an additional replica or every single one of these use cases is possible. Flash volume snapshots are a fantastic tool to accelerate business processes. They are highly efficient, can be used for data protection, increasing overall scale or as a part of increasing
10:00
overall scale as well as application workflow management orchestration. What's really important to note is that through all of these use cases, this is just a single data service included within flash array or cloud block store, but is also highly efficient in terms of reducing costs as volumes are initially de duplicated, volume snapshots only point towards changes in the original volume,
10:26
thus conserving as much. Space volume snapshots, also compressed and de duplicated as well as instantaneous copies are not going to consume more space than is needed at all. This allows you to streamline application business processes. It allows you to focus on what is most important to running your business.
