Multi-Region/Multi-Node Veri Tabanı

Giriş

Multi-Region Veri Tabanları çeşit çeşit. Aralarındaki en temel fark ise hangi  replication yöntemini kullandıkları. Temelde 2 farklı replication yöntemi var. Açıklaması şöyle

Replication is the process of sharing/storing information in multiple places to ensure reliability, fault tolerance, and accessibility. The replication options are described as follows:

1. Active/passive replication - Daha basit olanı
2. Active/active replication

Not : Open-Source Data Replication Tools yazısında replication için kullanılabilecek bazı araçlar var.

1. Single Node Veri Tabanı

Multi-region çalışan veri tabanlarına bakmadan önce single node göz atmak gerekir. Bu konudaki bazı notlarım şöyle

1. Yedek Alınması

Şeklen şöyle. Tek bir veri tabanı varsa, bunun yedeğinin alınması active/passive veya active/active sistem olduğu anlamına gelmez. 

Açıklaması şöyle

The most basic deployment is a single-site single-node architecture. This does not give you anything in terms of business continuity. It provides no High availability and the only DR mechanism is to restore your database from a backup file. This type of deployment is normally seen in less critical environments such as development or used in CI/CD Pipelining technologies when testing is automated as part of that process. Nearly all databases can be deployed in this manner including CockroachDB, Oracle, SQL Server, etc.

2. Multi-Node Veri Tabanı - Active/Passive Yöntem

Şeklen şöyle. 

Açıklaması şöyle. Bu yöntemde primary tek bir veri tabanı var. Replica veri tabanlarından her hangi birisi primary yapılabiliyor.

In this model, there is a single master node and x number of passive nodes. This means that if there is an issue with the master node the application can be pointed at a secondary node and the secondary node can be promoted as a master, This is typically automatic but does involve downtime as the application repoints to the new node. This makes recovering from failure a lot faster than a single node architecture but still not a perfect solution for production deployments. Examples of databases that run in active-passive configurations are Oracle, SQL Server, MySQL, and Postgres.

Benim Active-Passive için incelediğim bazı ürünler şöyle

Vitess

Açıklaması şöyle. Vitess çözümünde aslında tarif edilen şey "multi-cell with 2 data centers". Yani bir primary herhangi bir region içinde. Replicalar ise her iki region içinde. High availability adına da her region içinde "cell" veya "availability zone" olarak tabir edilen farklı donanımlar üzerinde koşan veri tabanları kullanılıyor.

No active-active replication 
Vitess doesn’t support active-active replication setup (previously called multi-master). It has alternate ways of addressing most of the use cases that are typically solved by such a configuration.

- Scalability: There are situations where active-active gives you a little bit of additional runway. However, since the statements have to eventually be applied to all writable servers, it’s not a sustainable strategy. Vitess addresses this problem through sharding, which can scale indefinitely.

- High availability: Vitess integrates with Orchestrator, which is capable of performing a failover to a new primary within seconds of failure detection. This is usually sufficient for most applications.

- Low-latency geographically distributed writes: This is one case that is not addressed by Vitess. The current recommendation is to absorb the latency cost of long-distance round-trips for writes. If the data distribution allows, you still have the option of sharding based on geographic affinity. You can then setup primarys for different shards to be in different geographic location. This way, most of the primary writes can still be local.

3. Multi-Node Veri Tabanı - Active/Active Yöntem

Açıklaması şöyle

In this model, all the nodes in the cluster are available for read and write operations. There is no concept of a master and secondary nodes as all nodes are equal within a multi-active cluster. This gives you a lot of benefits and control over HA and DR capabilities. It also has the inherent ability to allow ease of scalability. Databases that can be deployed in this category include CockroachDB, Cassandra, and Couchbase.

Açıklaması şöyle. Yani farklı bölgelerde çalışan active/active veri tabanları var.

Replicating data in multiple regions around the globe is a key way to solve a lot of potential headaches with globally distributed applications. Not only does it reduce latency for local end users, but if something goes wrong, you’ve got the redundancy required to increase availability, ensure business continuity and support disaster recovery plans.

Accomplishing this data replication requires an active/active database deployed across multiple regions or data centers. Most distributed databases are active/passive, where there is one primary database that serves both reads and writes, and the remaining database instances are read-only. In an active/active database, all the instances can accept read and write requests. There’s one database, but it’s distributed with data replicated across multiple regions, typically deployed in a cloud provider. Regions can cross continents or be within one country.

Active/Active Yöntem ihtiyacı için bazı sebepler şöyle

1. Disaster recovery

2. Data sovereignty : Bazı ülkeler verinin kendi topraklarında olmasını istiyor.

3. Latency reduction

Benim Active-Active için incelediğim bazı ürünler şöyle

Apache Cassandra

Apache Cassandra Multi-Region Active/Active Veri Tabanı olarak çalışabilir.

GridGain

Açıklaması şöyle

Data Replication Modes
GridGain supports active-passive and active-active modes for replication.

In the active-passive mode, only one cluster (the master) interacts with the user application, and the other cluster (the replica) stores data purely for redundancy and failover purposes.

In the active-active mode, both clusters handle user requests independently and propagate changes to each other. In this mode, care must be taken to resolve conflicts between updates that happen on the same cache entry in both clusters. For more information on how to resolve conflicts, refer to the Conflict Resolution section.

Active/Active Yöntem için Bazı problemler

1. Primary Key Problemi

Eğer primary key için sequence kullanılıyorsa sayılar çakışabilir.

2. Veri Tabanındaki Trigger

Replication ile gelen veri için trigger'ların çalışmaması istenebilir.

3. Cascade Constraints

Örnek ver

4. Data Collision

İki taraf aynı anda aynı veriyi değiştirmek isteyebilir.

Örnek

Burada bir öneri var. Tüm dünyadan gelen istekleri ilk geleni işleyecek şekilde bir ister var. "Sneakers drop" yapılıyor. Bunun için Active-Active multi-region kullanılıyor.

4. Multi-Node Veri Tabanlarının Bazı Sıkıntıları

En önemli sıkıntı region'lar arasındaki ağdan kaynaklanan gecikme. Şeklen şöyle. Burada aynı bölgede çalışan "East" düğümleri arasında gecikme çok az. Ancak East ve South arasındaki gecikme daha fazla. Central ve South arasındaki gecikme çok çok daha fazla.

Örneğin Vitess bir shard için tek bir master'a sahip olduğundan, eğer master bizim bölgemizde değilse, yazma işlemi yavaş kalabiliyor.