Article Series
Maintenance and Monitoring
SQL Server comes with built-in maintenance and monitoring tools like Cluster Manager, Profiler, etc. that can be used to manage your SQL Server Clusters, nodes and troubleshoot performance issues.
PostgreSQL on the other hand, does extensive logging and provides many different ways of monitoring database performance. For an extensive list of all monitoring options, please check out this page.
If you are opting to migrate to AWS Aurora/RDS, it has built-in monitoring for its Aurora and RDS databases. AWS CloudWatch provides additional enhanced monitoring and comes with a cost. Other Cloud providers like Azure have built-in monitoring tools as well.
High Availability, Load Balancing, and Replication
A detailed discussion on the subject is beyond the scope of this article. Check out these pages for an in-depth discussion on the topics:
Replication, Clustering, and Connection Pooling
High Availability, Load Balancing, and Replication
PostgreSQL Replication Solutions (pdf)
Environment Stabilization via Parallel Deployment
After your databases are migrated successfully, you would want to run both your SQL Server and PostgreSQL workloads parallelly for few days till you make sure that your new databases are stable and handling your production loads smoothly. The applications and services that write to your databases would have to write to both your SQL Server and PostgreSQL or they need to be kept in sync through replication/CDC solutions till the cut-over date. The applications/reporting systems that only read from your databases can read from either of these databases during the soak-in period and then permanently switch to your PostgreSQL databases after the cut-over date.
If your SQL Server database is an offline database and if it is okay for the database to be down for few hours, then you can just switch over to PostgreSQL database on a pre-determined cut-over date and save yourself the trouble of writing to multiple databases and setting up replications.
Summary
In this article series, we discussed migrating your entire SQL Server workloads to PostgreSQL, the different migrations options available and choosing the one that’s right for you. We also discussed the comparative strengths and weaknesses of the both the platforms, and post migration considerations as well.
Migrating databases from one platform to another along with their workloads is a mammoth task and requires careful and meticulous planning to make it a success. This article touches upon all the topics and tasks that are required for a smooth migration.
If you found this article helpful, or have suggestions to improve its content, please feel free to leave a comment.
The post Migrating your SQL Server Workloads to PostgreSQL – Part 4 appeared first on The Developer Space.
Submit an article or tip
