👍

Flexible database servers now Generally Available

Flexible database servers are now generally available on MedStack Control. Legacy single database servers will no longer be able to be created.

Database servers are Azure managed resources available to use in your compliant environments. They have been provisioned in similar ways as compute nodes to meet the guarantees outlined in MedStack Control's compliance policies.

Overview

Specifications

To enable an extension on a flexible database server, please contact our support team using this form.

🚧

Building a production system?

Recommended: General purpose tier database servers target most workloads that require balanced compute and memory with scalable I/O throughput. Examples include servers for hosting web and mobile apps and other enterprise applications.

Burstable tier database servers target workloads that require light compute and I/O performance. Examples include servers used for staging, development, testing or small-scale infrequently used applications.

Security

Intrusion detection system

Advanced Threat Protection for Azure Database for PostgreSQL and MySQL is a service used on each database server. It detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases and reports this information to MedStack.

SSL connectivity

Azure Database for MySQL supports connecting your database server to client applications using SSL. Enforcing SSL connections between your database server and your client applications helps protect against "man in the middle" attacks by encrypting the data stream between the server and your application.

In some cases, applications require a local certificate file generated from a trusted Certificate Authority (CA) certificate file to connect securely. The certificate to connect to an:

• Azure Database for PostgreSQL server is located at https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem.
• Azure Database for MySQL server which is located at https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem.

Backup and restore

Azure managed databases for MySQL and PostgreSQL are backed up daily and capture transaction logs to perform a point-in-time restore within the past 35 days.

🚧

Restoration creates a new database server

Please note that by restoring a database server, a new database server with the same CPU and Memory resources, and user credentials as were defined when creating the original database server.

Note, the allowed IP list does not replicate on the new database server.

A backup can be restored by:

1. Click the "Restore from backup" action on a database server.

2. Select the point in time (UTC) to create the new database server.

3. Click "Restore" to provision the new database server.

   

4. The new database server will be indicated by its label containing the timestamp of the restore point.

   

📘

New connection string generated

The new restored database server will also have a new database connection string. Please ensure the list of allowed IPs and connection string in the database client are updated accordingly.

Actions

Create

1. Click the Create flexible database button in the cluster you'd like to create a managed database server.
2. Select the type of database you'd like to create.
3. Configure the database version from the list of supported versions.
4. Select the tier and size of the database server as outlined in the specifications section of this guide.
5. Configure the initial storage capacity. By default, database server storage capacities will automatically scale upward using Azure's autogrow feature.
6. Create a set of credentials to use for connecting to the database.

👍

Remember your credentials

MedStack does not store your database credentials. If you lose the password for the credentials, you can reset the password. If you lose the entire set of credentials, you may contact [email protected] for assistance.

Reset password

You may reset the password configured for the database server by selecting Reset Password from the Actions menu on a database server row.

It's important to note that you cannot reset the username through MedStack Control.

Allowed IPs

You may permit IP addresses external of the cluster with connection privileges to databases on the server by selecting Allowed IPs from the actions menu on a database server.

You can manage rules here to permit and rescind connections from IP addresses outside the cluster. This is especially helpful when performing a migration, connecting a database between clusters, and troubleshooting a database using a workbench or similar utility hosted on a known IP address.

Common use cases

It is common for allowed IP rules to be used to:

• Permit cluster access to database servers provisioned in separate clusters on MedStack Control.
• Manage database servers with database management tools on a web server or local machine.
• Facilitate database migration processes from external systems into MedStack Control.

Delete

You may permanently delete a database server and its backups by selecting Delete from the actions menu on a database server. Only Owner roles can delete database servers.

❗️

Make sure you grab a database dump

MedStack cannot guarantee the availability of a database's backups once a database server has been deleted. Before you delete a database server, we recommend you capture a database dump for PostgreSQL or MySQL.

Connect

You can establish a connection to a database server by making a URI request with the credentials established when creating the database server and the connection strings.

For more information on connecting to a database server, see our guide advising how to connect to a database .

Connection strings

The connection strings to a database server can be found by clicking on the database technology and version.

SSL certificates

In some cases, applications require a local certificate file generated from a trusted Certificate Authority (CA) certificate file to connect securely. The certificate can be downloaded at: https://dl.cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem

MedStack does not recommend pinning certificates for SSL connections to your database servers. If you are still experiencing connection issues to your database servers in Azure, please refer to the official Azure documentation on TLS/SSL connectivity:

• Azure Database for PostgreSQL server: https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-tls-ssl.
• Azure Database for MySQL server: https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-connect-tls-ssl.

Example

In this example, we'll walk through both the MedStack Control actions and the application layer modifications to establish a connection to a database server and create a database on the database server.

See the example to learn how to connect databases to your applicaiton.

Extensions

The default permissions for database extensions are to disallow the installation of extensions. If you would like to install an extension, you must first submit a request to MedStack Support via the help desk to request for the extension to be allowed for install.

1. Submit a request using this form in the help desk
2. Wait for the request to be processed, allowing the installation of the database extension
3. Install the database extension

When the request is processed, the extension is allowed and loaded, but it is not installed. Extensions must be installed in your database before you can use them. To install a particular extension, you should run the CREATE EXTENSION command. This command loads the packaged objects into your database.

📘

How to see a list of allowed database extensions

To see a list of all database extensions that are allowed for installation, you can run the SHOW azure.extensions command for database servers running in Azure clusters on MedStack Control.

Migrate

Migrating a database can be done easily using the PostgreSQL or MySQL dump and restore functionality.

You must ensure the data is available to be moved into the database. This can be done by:

• Uploading the dump to a Docker volume.
• Baking the dump into a container image.
• Allowing the IP address of a host machine with the dump.