Getting Started with Data Services Manager 2.0 – Part 6: Day 2 Operations
In this post, I want to demonstrate some of the key “day 2” features of Data Service Manager 2.0. Day 2 operations are typically operation that an administrator might carry out after a data service / database is already deployed and configured. This blog will discuss operations such as the ability for a DSM administrator to assign database ownership to a different DSM User. We will also see how it is possible to both clone an existing database and how to restore a new database from a backup. These operations will be done from the UI but I did want to mention that these operations can also be done via the Kubernetes Consumption API which is available in DSM. This will be the topic of another blog post. To run any of the day 2 operations discussed below, select the database in the DSM UI and click on the Actions dropdown. This will bring up the Clone, Create Database from Backup, Change Owner and Delete operations as shown below.
Note: At the time of writing, DSM version 2.0 is not yet generally available. Therefore some of the screenshots captured in the upcoming post may differ slightly in the final product. However, for the purposes of our getting started series of posts, this should not matter too much.
Change Ownership
The first day 2 operation is a very interesting one if an administrator wishes to carry out the provisioning of databases and maintain control over who has access. This would mean that the end users would not have to concern themselves with any parts of the infrastructure or infrastructure policies which we discussed in part 1 of this series. A DSM administrator could take responsibility for deploying all of the databases and data services, and then using this this feature, assign ownership of the database to a DSM User. This means that the new DSM User, on being assigned ownership, would receive any email alerts associated with the database, and could also carry out additional day 2 operations such as clone and restore. Of course, you could also use DSM to provide complete self-service to end-users to that they provision their own databases, allowing administrators to focus on more important tasks.
Clone
A clone operation, as the name infers, is the process of making an exact copy of the database or data service. The clone operation allows users to make changes to the scale (topology) as well as resource sizing (CPU & Memory) to the cloned database which we saw in part 4 of this series. Thus, while a clone makes an exact copy of the data, other aspects of the database can be modified. The cloned database is allocated a new set of IP addresses from the IP Pool in the infrastructure policy. This is a very nice feature, and can be implemented by the DSM admin or the DSM user from the DSM UI. A clone can also be thought of as a short-cut for a restore from latest backup operation, which is discussed next.
Restore from backup
Again, the name is self-explanatory. In this UI, this is referred to as ‘Create Database from Backup’. One thing to highlight is that a restore does not overwrite the existing database but rather creates a new one. As we have seen with the clone operation, many aspects of the restored database can be modified as part of the restore, including topology and resources. Since we are taking WAL backups every 5 minutes, it is possible to restore a backup of the database to a specific point in time (PIT). When the restore option is selected in the UI, you are given 2 choices; restore the latest backup or restore from a PIT.
Similar to the clone operation, restores can be done by both DSM Admins and DSM Users via the DSM UI.
Delete
And of course, once a user is the owner of a database, they have the ability to delete the database. For obvious reasons, this is highlighted in red in the dropdown menu. Use this day 2 operation with caution!
Lifecycle Management
Now, there is one essential day 2 operation which is not covered above, and which you may be wondering about. That is, of course, updates to the database version and patching. Data Services Manager 2.0 provides a mechanism that will automatically apply minor version upgrades to databases without the need of any operator or administrator intervention. Once a maintenance window has been defined and enabled (which DSM does by default), then any new patches for the Postgres or MySQL databases that are released by VMware will be automatically applied to the database during the maintenance window. And if you decide to disable the maintenance window, you can apply the updates at your own convenience. Notifications will appear in the DSM dashboard notifying operators and administrators of pending updates. The maintenance window can be adjusted in the Summary tab of the database.
Thanks for reading this far. These are just some of the day 2 operations which we feel make Data Services Manager version 2.0 a very compelling solution for DBAs who want to provide self-service to end-users. It allows the end-users to do various operations on their respective databases, whilst allowing DBAs to focus on the more important tasks that bring value to their line of business.
