Tag Archives: replication
In the blog MariaDB replication using containers, we showed how to properly replicate data in MariaDB using Docker containers.
We used standard or asynchronous or lazy replication.
The problem with this type of replication is potential data loss if the primary goes down. Transactions that are committed on the primary are not being sent to replicas, and the replica doesn’t commit the changes. Failover from primary to replica in this case may lead to missing transactions relative to the primary.
To overcome these type of errors, there is semi-sync replication that is integrated into MariaDB since 10.4 and fully sync replication, which we plan to implement eventually as MDEV-19140.
…
Continue reading “MariaDB semi-sync replication using containers”
In this blog we are going to demonstrate how to replicate a MariaDB database that runs in a Docker container (let’s call it primary) to one or more MariaDB servers that run in a Docker container (let’s call them replicas) using binary logging, a method that creates binary log files and an index that contains the record of all changes to the database (both data and structure). You can find an overview of how replication works here and you can find how to setup replication here. An example can be found in this GitHub script.
…
With the release of 10.1.8, MariaDB takes a next step. MariaDB 10.1 is now considered a stable release.
MariaDB 10.1 has a couple of main themes:
- Security
- High Availability
- Scalability
During the last few years there have been many request for more security features in MariaDB. Actually it’s a trend in general. Since open source software is getting more attractive all the time, more functionality is wanted in areas where proprietary software typically has been leading. This is especially true for databases. In addition data privacy is a very hot topic.
The big new thing in security for MariaDB 10.1 is a complete data at rest encryption solution. …
Background
Eventual consistency is a consistency model used in many large distributed databases which requires that all changes to a replicated piece of data eventually reach all affected replicas; conflict resolution is not handled and responsibility is pushed up to the application author in the event of conflicting updates [13].
Eventual consistency is a specific form of weak consistency; the storage system guarantees that if no new updates are made to the object, eventually all accesses will return the last updated value [14]. If no failures occur, the maximum size of the inconsistency window can be determined based on factors such as communication delays, the load on the system, and the number of replicas involved in the replication scheme [3]. …