This guide will show how to setup an Azure MySQL Database to migrate and store your organizations Secure Messages content from the eShare hosted Database. The following steps will be reviewed:
Requirements and Pricing
The recommended practice is to utilize Microsoft’s Azure SQL Database. It offers several deployment options while running as a hosted service and tiers that scale according to your needs.
We recommend the General Purpose tier for the needs of this feature, it offers the best price/performance ratio.
Please see https://azure.microsoft.com/en-us/pricing/details/mysql for up-to-date pricing.
Setup MySQL Server in Azure
Login to the Microsoft Azure Portal (For Commerical Customers: https://portal.azure.com | For Government Customers: https://portal.azure.us).
Search for ‘Azure Database for MySQL flexible servers’ and select the ‘Azure Database for MySQL flexible servers’ option from the list of services.
.png)
On the next screen, select the ‘Create’ option in the top left, then choose ‘Advanced Create’ under ‘Flexible server’.
Select your subscription model and define the resource group (Resource group could be named "eShareSQLdatabase" for indexing purposes and ease of reference). It is recommended to define a separate resource group to isolate our access from any other service you might be running.
Next, set a ‘Server name‘, the ‘Region’ of the database (US East recommended for better performance / same region as eShare), and the MySQL version (any available version is okay).
Determine the ‘Workload type’, ‘Compute + storage’, and ‘Availability Zone’. eShare recommends the configuration shown in the below image. If the MySQL Flexible server will be used for only the eShare secure conversations, there is no need to select a pricier configuration as eShare’s use of the MySQL Database is not resource intensive in terms of read/write.
Finally, for ‘Authentication Method’ ensure a local SQL Authentication user is created, and add a username and password that will be used to access the database.
Confirm the creation of your MySQL Database Server and wait for the server to be deployed. Once completed, access the resource to proceed with creating a new Database for the server.
Setup MySQL Database in Azure
While in the newly deployed MySQL Server resource, navigate under ‘Settings’ > ‘Databases’.
Select the ‘+ Add’ button at the top of the page.
Enter a name for your database, leave the other options as their defaults, and select ‘Save’.
Once creation has completed, go to the ‘Overview’ page, select ‘JSON View’, and send the Resource ID to your eShare Customer Success Manager so they can initiate the Private Endpoint Connection.
Approve Private Endpoint Connection
In the created newly database navigate to the ‘Security’ section and select ‘Networking’
Select the ‘Private Access’ tab, then under ‘Private endpoint connections” there will be a pending request, review the request and approve it.
Connect the Database in eShare Admin Console
From your Admin Console tab, navigate to the ‘Share messages’ tab, you will be required to point eShare to the Database you created so it can start storing your Organizations Secure Messages. Fill out the required fields with the information:
Database Type: MySQL
Host: Endpoint name of the MySQL Server
Port: 3306
Database: Name of the created Database
User: local admin account username
Password: local admin account password
Enable Secure Transport: Enable, paste the public Azure MySQL SSL certificate
NOTE:
After saving you may receive an error message, ensure you have entered all information about the database correctly and the network connection has been put into place.
All Done! Now eShare will utilize your own Database for all your organization’s secure messages.
Monitoring and Keeping Database Healthy
In our implementation the most important and common things to keep track of to make sure the Database remains healthy are CPU Percent, Memory Percent, Network In/Out and Network connections and finally Storage Metrics.
You will find these in the Metrics tab under Monitoring in your AzureSQL Database.
CPU Percent: A high CPU percent is not a bad thing if you don’t consistently reach the limit.
Memory Percent: Ideally your entire Database should be stored in memory while leaving enough for other processes. Check frequently as your Database scales in size.
Network In/Out and Connections: Unless doing backups or transferring huge amounts of data, it should not be the bottleneck
Storage Metrics: Make sure you always have free space for new data, temporary files, snapshot, or backups. You can create an alert when database, logs and temp is > 85% usage so you can scale accordingly.