Overall, it should have an understanding of your architectural insight without exposing confidentiality of your data. This should not be limited to the database but it should cover expertise in scalability, redundancy, backups, high-availability, security, monitoring/observability, recovery and engaging on mission critical systems. There are lots of MySQL consulting firms that can help you through this since migration from Oracle to MySQL requires a lot of expertise and know-how in the MySQL Server area. Such options include engaging with experts in the MySQL/Percona Server field and that includes us here at Severalnines. There are different options from migration planning to the things you need to do as part of your development strategy. One thing to consider as well is budget, if the purpose of migration from enterprise database to an open-source RDBMS is because of cost-cutting. On the other side, the question you have also to consider as part of the plan is “How will Percona will provide support and who will help us when Percona Server itself encounters a bug or how high is the urgency when we need help?”. For example, (to name a few) using Corosync/Pacemaker/DRBD/Linux stack, or using MHA (MySQL High Availability), or using Keepalived/HaProxy/ProxySQL stack, or plainly rely on ClusterControl which supports Keepalived, HaProxy, ProxySQL, Garbd, and Maxscale for your high-availability solutions. Then, there’s multiple alternatives that you can implement for your own high-availability solution. However, you can choose from a synchronous replication, an asynchronous replication (Percona XtraDB Cluster is still currently on version 5.7.x), or with Group Replication. There’s no straight answer for this within MySQL/Percona Server. Identifying the key aspect of your database architecture, for example if your current Oracle architecture implements MAA (Maximum Available Architecture) with Data Guard ++ Oracle RAC (Real Application Cluster), you should determine its equivalence in Percona Server. Percona Server/MySQL RDBMS are perfect fit for OLTP (Online Transaction Processing). You must also identify your database architecture requirements, since Percona Server is not designed for OLAP (Online Analytical Processing) or data-warehousing applications. Although you can compile it for Windows, Percona itself does not offer any support for Windows.
#Mysql in oracle sql developer windows#
For example, Oracle can run on a Windows Server machine but Percona Server does not support Windows. Migration from Oracle going to Percona Server 8.0 can be a pain since there’s a lot of key factors that needs to be considered and addressed.
We previously blogged about migrating Oracle Database to PostgreSQL. So any reference of MySQL here is applicable as well to Percona Server. Since Percona Server is a fork of MySQL, almost all features that come along in MySQL are present in Percona Server. But it will hopefully provide enough background information to serve as a guide for your migration process.
This blog will not cover the overall process of migration, as it is a long process. There’s a page in the Oracle website about SQL Developer Supplementary Information for MySQL Migrations which can be used as a reference for the planned migration. This blog will focus on Migrating from Oracle to Percona Server as its specific target database of choice.
Aside from planning for your migration from Oracle to Percona Server, you must ensure that you understand the purpose and functionality for why it has to be Percona Server. Although it is getting easier, especially with the arrival of MySQL 8.0 and Percona announced Percona Server for MySQL 8.0 GA. Migrating from Oracle to MySQL/Percona Server is not a trivial task.
0 kommentar(er)
