Migration MySQL

Uploaded by

Narendra Balasa

Available Formats

Download as TXT, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

11 views

Migration MySQL

Uploaded by

Narendra Balasa

Available Formats

Download as TXT, PDF, TXT or read online on Scribd

You are on page 1/ 4

Reasons for Migration:

1. End of Life for MySQL 5.6:

- MySQL 5.6 has reached its end of life, meaning it no longer receives updates,
including security patches, making it vulnerable to security risks.
2. Modernization:
- Upgrading to MySQL 8.0 allows taking advantage of the latest database
technologies and practices, improving overall application performance and
capabilities.
3. Operational Efficiency:
- Managed services in Azure can significantly reduce the operational burden on IT
staff, allowing them to focus on more strategic initiatives.
4. Disaster Recovery and Business Continuity:
- Azure provides robust disaster recovery options, ensuring business continuity
even in case of data center failures.
5. Elasticity:
- The ability to scale resources up or down based on demand helps manage costs
and ensures optimal performance during peak loads.
6. Global Reach:
- Azure’s global presence allows for deploying databases closer to your user
base, reducing latency and improving user experience.
By migrating to Azure Flexible Server MySQL 8.0, you leverage a modern, scalable,
and secure database platform that aligns with contemporary cloud practices and
organizational needs.

===================================================================================
=======================================================================

Migrating from an on-premises MySQL 5.6 VM to Azure Flexible Server MySQL 8.0 can
offer several advantages

Advantages:
1. Improved Performance and Features:
- New Features: MySQL 8.0 introduces many new features such as window functions,
CTEs (Common Table Expressions), JSON improvements, and more.
- Performance Enhancements: MySQL 8.0 includes significant performance
improvements, including better indexing, faster query processing, and improved
InnoDB engine.
2. Scalability:
- Azure Flexible Server offers scalability options, allowing you to easily adjust
resources (CPU, memory, storage) based on your workload requirements.
3. High Availability and Reliability:
- Built-in high availability options with automatic failover.
- Managed backups and disaster recovery solutions.
4. Security:
- Enhanced security features like advanced threat protection, data encryption at
rest and in transit.
- Automated security patches and updates.
5. Cost Efficiency:
- Pay-as-you-go pricing model can be more cost-effective compared to maintaining
on-premises hardware.
- Reduced overhead costs associated with hardware maintenance and upgrades.
6. Managed Service:
- Reduced administrative overhead since Azure handles routine database
maintenance tasks such as backups, patching, monitoring, and scaling.
7. Compliance:
- Azure services are compliant with a variety of industry standards and
regulations, which can help meet organizational compliance requirements.
===================================================================================
============================================================================

Azure VM MySQL 8.0 vs Azure Flexible Server for MySQL 8.0

Azure VM MySQL 8.0:

Pros:
1. Full Control: Complete control over the operating system, MySQL version, and
configurations.
2. Customizability: Ability to customize the environment according to specific
requirements, including installing additional software.
3. Scalability: High flexibility in scaling resources (CPU, memory, storage) as
needed.
4. Networking: More control over networking configurations, including setting up
custom virtual networks and firewalls.
5. Backup and Recovery: Can use any preferred backup and recovery strategy.

Cons:
1. Management Overhead: Requires more management, including OS maintenance,
patching, and security updates.
2. Complexity: Higher complexity in setup and maintenance, which may require more
technical expertise.
3. Cost: Potentially higher costs due to the need to manage and maintain the
virtual machine.
4. Responsibility: Greater responsibility for ensuring high availability, disaster
recovery, and performance optimization.

Azure Flexible Server for MySQL 8.0

Pros:
1. Managed Service: Reduced management overhead as Azure handles the OS, MySQL
updates, backups, and patching.
2. High Availability: Built-in high availability with automated failover
capabilities.
3. Performance Optimization: Automated performance tuning and scaling options.
4. Cost Efficiency: Potentially lower costs due to pay-as-you-go pricing and
reduced administrative efforts.
5. Simplified Setup: Easier to set up and manage, making it suitable for users with
less technical expertise.
6. Integration: Seamless integration with other Azure services, improving overall
workflow and deployment.
Cons:
1. Less Control: Limited control over the underlying infrastructure and some
configurations.
2. Customization Limits: Constraints on customization compared to a fully
controlled VM environment.
3. Potential Latency: Slightly higher latency compared to a well-optimized self-
managed VM in some scenarios.
4. Dependency on Azure: Reliance on Azure’s managed service can be a con if you
need very specific configurations or features not supported by Azure Flexible
Server.

Conclusion
- Azure VM MySQL 8.0 is ideal for scenarios where you need full control and
customization, are willing to manage the infrastructure, and have the technical
expertise to handle the complexity.
- Azure Flexible Server for MySQL 8.0 is better suited for users who prefer a
managed service with reduced administrative burden, built-in high availability, and
seamless integration with Azure services.
Choosing between them depends on your specific needs, technical expertise, and the
level of control you require.

===================================================================================
=======================================================================

In-Place Upgrade:

Estimated Time: Each server is going to take 20Hours which

includes(Upgrade/backup/Restore/enable replication). There is more of a manual
effort on each step mention in brackets so 20 man hours on each server.

MySQL Upgrade process

Phase 1(Downtime): On current RHEL 6 server - Performing MySQL upgrade to 8.0

which need to be done in sequential way – MySQL 5.6 to MySQL 5.7 and MySQL 5.7 to
MySQL 8.0
Shut down MySQL 5.6 – 10 min to clean shutdown
Remove MySQL 5.6 library on RHEL 6 instance – 10 min
Install new MySQL 5.7 packages and bring the server up and do validation – 30 min
Shutdown upgrade MySQL 5.7 server – 30 min to clean shutdown
Remove MySQL 5.7 packages – 10 min
Install new MySQL 8.0 packages and bring the server up and do validation – 1 hour
Phase 2(Downtime): Create new instance RHEL 8 with new IP address – Backup and
restore does not require downtime these operation will be done backend
Take a backup from RHEL 6 box with MySQL 8.0 – Depends on server to start with 6
hours
Restore backup from RHEL 6 box to RHEL 8 instance - MySQL 8.0 – 8 hours
After restore enable replication between RHEL 6 MySQL to RHEL 9 MySQL – Replication
Is going to catch and stay in sync until cut over. – 90 min and then wait until the
replication caught up for current
Update the DNS on RHEL 9 to match with RHEL 6 DNS name – 15 min for each server to
update DNS
Application should be able to connect without any difference.
Simplicity: In-place upgrade involves upgrading the existing MySQL instance and the
operating system directly on the same server.

Control: With an in-place upgrade, you have direct control over the upgrade process
and can perform custom configurations or adjustments as needed.

Downtime: In-place upgrades typically require downtime as the MySQL service and the
server itself need to be stopped during the upgrade.

OS upgrade considerations: In an in-place upgrade, we need to separately handle the

upgrade of the operating system from RHEL 6.9 to RHEL 9. This may involve
additional steps, such as migrating data, reconfiguring applications, and handling
compatibility issues.

Manual setup and configuration: we are responsible for setting up the new server
with RHEL 9, installing MySQL 8.0, migrating data, and ensuring compatibility of
applications with the new MySQL version.

Migration to Flexi server by Using DMS.

1.Do in place on existing server from MySQL 5.6 to MySQL 5.7 on RHEL 6. - This is
because we don't have MySQL 5.6 version flexible so we have to upgrade before doing
anything- 60 mins
2. Configure DMS job to migrate data from on prem MySQL 5.7 to MySQL flexible
server 5.7 version -- 8 Hours
3. Once data migration is done to MySQL 5.7 then we do upgrade the flexible server
to 8.0 - At this point we either stop and work on MySQL 5.7 flexible or we can
immediately upgrade 8.0 which is very easy from azure portal.-- 30 mins.

We can enable DMS job for all the servers at once and without any downtime we can
migrate the data from old to new server until the replication is caught up. Once
replication is caught up we wait for the minimal downtime for DNS record change and
then cut replication when ready and done.

Flexibility: DMS provides flexibility for migrations by supporting various source

and target databases, including MySQL to MySQL migrations or upgrades.

Minimal Downtime: DMS can perform migrations with minimal downtime using continuous
replication or utilizing features like database snapshots and change data capture.

Data Transformation: DMS offers options to perform data and schema transformations
during the migration process, allowing you to modify and map data between the
source and target databases.

OS upgrade included: When using DMS, you can provision a new RHEL 9 instance in
azure and perform the migration to the new operating system as part of the
migration process.

Automation and Simplified Configuration: DMS provides a user-friendly interface,

automation capabilities, and handles much of the migration setup and configuration
for you.

Considering our scenario, an in-place upgrade may involve more complexity as it

requires separately upgrading the operating system from RHEL 6.9 to RHEL 9. We
would need to handle migration, reconfiguration, and compatibility challenges
manually.