Replace Oracle RAC with MariaDB Galera Cluster?
https://mariadb.com/blog/replace-oracle-rac-mariadb-galera-cluster
这篇文章讨论了MariaDB Gelera Cluster替代RAC的可能性，总结如下：
1.RAC share disk架构；MariaDB Gelera Cluster share nothing架构。MariaDB Gelera Cluster节约了成本。
2.RAC无论select还是update都有节点间内部通信，block在节点间传输；MariaDB Gelera Cluster只有在commit发生时才发生节点间通信。
3.RAC添加新节点，无需同步数据。MariaDB Gelera Cluster添加新节点要同步数据（SST）
If you want to avoid downtimes in your business, High Availabilty (HA) is a strong requirement which, by definition, makes it possible to access your data all the time without losing (any) data. In this blog we compare two alternatives: Oracle RAC and MariaDB Galera Cluster.
There are several options to implement High Availability. Oracle RAC is a popular and proven HA solution. HA can also be enabled for your data and systems with loadbalancers that make it possible to always access your data. MariaDB Galera Cluster provides similar functionality using synchronous multi-master Galera replication. It is also easier to build and proves to be more cost-effective. Being OpenSource, you may have to pay for support, but not for running the system.
Next, the designs of Oracle RAC and MariaDB Galera Cluster are going to be compared, so you can make up your mind on your own.
Oracle RAC
With RAC, Oracle instances run on separate nodes, while the data is located on shared storage. All instances access the same files.
To prevent conflicts, the instances must agree on which instance is actually working on a block of data. If a node wants to change a row, it must get exclusive access to that block and store it in its cache. It therefore asks the other nodes whether they have the block. If no other node does, it gets the block from storage.
Even in case of read-access data all the nodes need to communicate this way to get the data as it is done for writing. When the block is modified, the requesting nodes get a consistent read version (which they are not allowed to modify) from the block. This adds latency due to internode communication - there will be read and write access every time a node does not have the block.
The need for communication between the nodes for every access on a table adds overhead. On the other hand, having all blocks advance local locks on a node, e.g. for SELECT FOR UPDATE, are cluster wide locks.
The advantage of RAC is that losing an Oracle node does not harm the service at all. The other nodes will keep providing data (HA of the access). Therefore, you can shut down a node to perform maintenance tasks such as upgrading hardware or software, while reducing unexpected downtime. However, the shared storage - responsible for the data - is a potential single point of failure.
On Oracle RAC distributing read or write access is not optimal because latency is added by additional internode round trips. The best results occur when the application only accesses a fixed part of the data per node, so that no blocks have to be moved around, but it makes the setup more complicated.
MariaDB Galera Cluster
In contrast to Oracle RAC, MariaDB Galera Cluster is a high availability setup with shared-nothing architecture. Instead of having one shared storage (SAN or NAS), every cluster member has its own copy of all the data, thus eliminating the single point of failure.
MariaDB Galera Cluster take care about syncing data even for new nodes. This makes managing the cluster easy, as adding an empty node into the cluster is sufficient. MariaDB Galera Cluster will provide all data for the new node.
Unlike Oracle RAC, accessing a node to read data does not result in internode communication. Instead, communication (and so latency) happens at the time transactions are committed. This is faster than the Oracle RAC approach of acquiring all blocks in advance, but this also means conflicts are found at the time a transaction is committed.
And conflict are found by the internode communication because of the commit. Thats why the same data should not be accessed (at least not at the same time) on different nodes, as this increases the chance of having conflicts. This will not happen when the data is accessed on different nodes one after another. In the case of Oracle RAC the blocks would have to be copied.
This means that a SELECT FOR UPDATE statement is able to fail on commit, as it locks the data locally but not cluster wide. So conflicts with transactions on other nodes can only be found at the time of the commit. That is why the same data should not be accessed at the same time on different nodes, as it increases the chance of having conflicts. This is slightly different to Oracle RAC where accessing data on another node any time later does move the blocks.
While Oracle RAC has a lot of latency moving data blocks into the cache of every node, MariaDB Galera Cluster has an increased likelihood of failing commits.
Like Oracle RAC, single nodes in a MariaDB Galera Cluster can be taken down for maintenance without stopping the cluster. When a node rejoins the cluster, it automatically gets missing transactions via Incremental State Transfer (IST), or it may sync all data using State Snapshot Transfer (SST). If the missing transactions are in a local (configurable) cache of a node, IST is used, if not SST is used.
One drawback of the current Galera version is that Data Definition Language (DDL) commands (CREATE, ALTER, DROP) are run synchronously on the cluster. Therefore the entire cluster stalls until a DDL command finishes. Thats why Magento installations running default configuration do not scale at all on MariaDB Galera Cluster. In general using tools like pt-online-schema-change bypass this limitation. Eliminating this limitation is on the development roadmap.
In comparison
Oracle RAC and MariaDB Galera Cluster provide similar functionality using different designs. Each one is eliminating maintenance downtime for many tasks and thus gives you more freedom to run applications.
In general Oracle RAC has a lot more latency because of internode communication (including moving all requested data blocks) for read and write access. In MariaDB Galera Cluster the changed dataset is sent around by committing. So only changed datasets are sent.
Despite the obvious similarities, the two databases have quite different architectures. Oracle RAC uses shared storage, while MariaDB Galera Cluster uses a shared-nothing architecture, which is less expensive. Oracle RACs shared storage is quite expensive. The author has observed EMC or NetApp for that, as it is the single point of failure something reliable is needed.
Data on MariaDB Galera Cluster is replicated on all the nodes, which makes it easy to run the cluster spread over different regions. Consequently, your data will be safe even if your datacenter burns down. To have this level of redundancy with Oracle RAC you need a shared storage accordingly, i.e. a Netapp MetroCluster. Beside adding more costs, Netapp MetroCluster requires a network with a round trip latency of less than 10ms, while MariaDB Galera Cluster even runs in Cloud environments in different regions.
With Oracle RAC there are two inherent sources of latency: accessing the shared storage and internode communication for read and write access. While in MariaDB Galera Cluster there is latency for every COMMIT needed by the internode communication to check and send the data to be committed.
Of course MariaDB Galera Cluster is no one-to-one replacement for Oracle RAC. But if your application runs with either Oracle or MySQL/MariaDB, MariaDB Galera Cluster is more than an alternative. Greetz provides an online personalized greeting card service to 1000s of customers in Europe and North America. Greetz approached MariaDB to provide them with a replacement database technology for their webshop that would significantly reduce the total cost of ownership (TCO) whilst ensuring high availability and a solid, predictable performance. Greetz provides an online personalized greeting card service to 1000s of customers in Europe and North America. The company’s webshop application is built on Java and Hibernate (Object Relation mapping) and, prior to working with us, used Oracle? RAC as its underlying database. Their infrastructure is based on Linux and they use Ansible for configuration management. Greetz was concerned by the shortage of internal Oracle DBA resources and the increasing complexity of managing their Oracle database as their business grew. They approached us to provide them with a replacement database technology for their webshop that would significantly reduce the total cost of ownership (TCO) whilst ensuring high availability and a solid, predictable performance. Greetz stressed to our project team that Linux, Hibernate and Ansible were to remain with only the database component being replaced. Before the migration, MySQL? was already in use at Greetz for Business Intelligence, Disaster Recovery and other supplementary services. These servers were updated on a regular basis using purpose built scripts and programs. Fortunately the client’s existing Hibernate deployment used Hibernate’s default query setup. This ensured there was no native SQL to replace prior to the migration. Therefore the project team understood that migrating the application would consist of moving the database schema and data, pointing Hibernate to the new database, end-to-end testing and performance tuning. There were a few issues in the migration process, mainly dealing with differences in character sets and data type behaviour. The differences between Oracle and MariaDB/Galera caused few issues from the application point of view due to the use of Hibernate. However the project team did have to take into account the differences in infrastructure. For example, they had to develop Ansible configuration for MariaDB and had to extend this work to support Galera. The load balancer / failover also needs to be configured, as well as Galera itself. Also, as part of the project, Greetz wanted their existing BI and Disaster Recovery databases to be migrated from MySQL to MariaDB. Rather than deploying these systems using Galera, standard MariaDB replication was used. This has the added advantage that the BI and Disaster Recovery databases could be updated in real-time. One issue that is common to many migration projects is that there is bad data in the system being migrated and there was no exception here - a problem that had to be handled carefully. The schema was reasonably easy to migrate, but this was continually fine tuned during the migration process, e.g. data type mappings and indexing. The big issue with the migration of data was performance during scheduled downtime. During a very restricted time window large amounts of data had to be extracted from the existing servers, transferred to the new ones and then finally imported into MariaDB/Galera. This proved very challenging and require close co-operation with the client team. The testing of the resulting schema and data was a continuous process through the migration, including application testing as well as automated verification of migrated data. As part of the migration, consideration was also given to Greetz’s future data growth and services to ensure the system could be scaled, both horizontally and vertically. Immediately after the new system went live there were some stability issues but these were anticipated as new database technologies were being used to support an existing high performance application. Even so, the newly migrated application was soon stable as our Developer and Remote DBA teams systematically resolved each remaining issue. The Greetz migration project set out to deploy a more scalable, more performant and highly available database solution whilst providing real-time disaster recovery and BI databases. From a performance point of view, the new MariaDB/Galera setup is now faster than Oracle RAC and provides just as good, if not better, stability and high availability. We successfully reduced the Total Cost of Owership of Greetz’s database solution by removing the need for a SAN and significantly lowering license and maintenance costs. Today, MariaDB with Galera provides a stable, proven and reliable new platform for Greetz’s high capacity webshop. Whilst the migration was more complex than initially envisioned, our project team rapidly resolved issues as they arose. Greetz has also engaged our Remote DBA’s team on an ongoing basis to keep the webshop running optimally and assists with implementing new features and/or modifications as required. Giulio Gaioni, COO at Greetz said: "A key part of any database implementation is the accuracy of data together with the successful migration of data from the old legacy systems. This is particularly important in the ecommerce sector where customer details and purchasing history must be fully traceable and auditable." "We engaged with MariaDB in order to establish a single point of governance and control across all of the disparate strands relating to data and to help us ensure that best practice principles would be applied to our data migration activities." "MariaDB’s controlled and structured approach gave us certainty in relation to data and enabled us to achieve the overall project goal of going live on time. I would not hesitate in working again with MariaDB and would highly recommend them." Anders Karlsson, Sales Engineer for MariaDB on the Greetz project, said: "We were proud to play an important role in such a critical project for Greetz. Our approach to data migration with its emphasis on data quality and process control was particularly well suited to the ecommerce industry." "Our team managed to deliver a successful data migration within challenging timelines because they remained focused on the key drivers of success: scope agreement, business engagement, robust approval procedures and sign-off."
附上成功案例。Successful Migration from Oracle RAC to MariaDB Galera Cluster
Who is Greetz?
The Challenge
Our Solution
The Results