Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

en: replace master and slave with leader and follower #576

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 24 additions & 24 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -132,8 +132,8 @@ Review the [Contributing Guidelines](CONTRIBUTING.md).
* [Service discovery](#service-discovery)
* [Database](#database)
* [Relational database management system (RDBMS)](#relational-database-management-system-rdbms)
* [Master-slave replication](#master-slave-replication)
* [Master-master replication](#master-master-replication)
* [Leader-follower replication](#leader-follower-replication)
* [Leader-leader replication](#leader-leader-replication)
* [Federation](#federation)
* [Sharding](#sharding)
* [Denormalization](#denormalization)
Expand Down Expand Up @@ -508,15 +508,15 @@ With active-passive fail-over, heartbeats are sent between the active and the pa

The length of downtime is determined by whether the passive server is already running in 'hot' standby or whether it needs to start up from 'cold' standby. Only the active server handles traffic.

Active-passive failover can also be referred to as master-slave failover.
Active-passive failover can also be referred to as leader-follower failover.

#### Active-active

In active-active, both servers are managing traffic, spreading the load between them.

If the servers are public-facing, the DNS would need to know about the public IPs of both servers. If the servers are internal-facing, application logic would need to know about both servers.

Active-active failover can also be referred to as master-master failover.
Active-active failover can also be referred to as leader-leader failover.

### Disadvantage(s): failover

Expand All @@ -525,12 +525,12 @@ Active-active failover can also be referred to as master-master failover.

### Replication

#### Master-slave and master-master
#### Leader-follower and leader-leader

This topic is further discussed in the [Database](#database) section:

* [Master-slave replication](#master-slave-replication)
* [Master-master replication](#master-master-replication)
* [Leader-leader replication](#leader-follower-replication)
* [Leader-leader replication](#leader-leader-replication)

### Availability in numbers

Expand Down Expand Up @@ -824,52 +824,52 @@ A relational database like SQL is a collection of data items organized in tables
* **Isolation** - Executing transactions concurrently has the same results as if the transactions were executed serially
* **Durability** - Once a transaction has been committed, it will remain so

There are many techniques to scale a relational database: **master-slave replication**, **master-master replication**, **federation**, **sharding**, **denormalization**, and **SQL tuning**.
There are many techniques to scale a relational database: **leader-follower replication**, **leader-leader replication**, **federation**, **sharding**, **denormalization**, and **SQL tuning**.

#### Master-slave replication
#### Master-leader replication

The master serves reads and writes, replicating writes to one or more slaves, which serve only reads. Slaves can also replicate to additional slaves in a tree-like fashion. If the master goes offline, the system can continue to operate in read-only mode until a slave is promoted to a master or a new master is provisioned.
The leader serves reads and writes, replicating writes to one or more leaders, which serve only reads. Slaves can also replicate to additional leaders in a tree-like fashion. If the leader goes offline, the system can continue to operate in read-only mode until a leader is promoted to a leader or a new leader is provisioned.

<p align="center">
<img src="images/C9ioGtn.png">
<br/>
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Source: Scalability, availability, stability, patterns</a></i>
</p>

##### Disadvantage(s): master-slave replication
##### Disadvantage(s): leader-follower replication

* Additional logic is needed to promote a slave to a master.
* See [Disadvantage(s): replication](#disadvantages-replication) for points related to **both** master-slave and master-master.
* Additional logic is needed to promote a leader to a leader.
* See [Disadvantage(s): replication](#disadvantages-replication) for points related to **both** leader-follower and leader-leader.

#### Master-master replication
#### Leader-leader replication

Both masters serve reads and writes and coordinate with each other on writes. If either master goes down, the system can continue to operate with both reads and writes.
Both leaders serve reads and writes and coordinate with each other on writes. If either leader goes down, the system can continue to operate with both reads and writes.

<p align="center">
<img src="images/krAHLGg.png">
<br/>
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Source: Scalability, availability, stability, patterns</a></i>
</p>

##### Disadvantage(s): master-master replication
##### Disadvantage(s): leader-leader replication

* You'll need a load balancer or you'll need to make changes to your application logic to determine where to write.
* Most master-master systems are either loosely consistent (violating ACID) or have increased write latency due to synchronization.
* Most leader-leader systems are either loosely consistent (violating ACID) or have increased write latency due to synchronization.
* Conflict resolution comes more into play as more write nodes are added and as latency increases.
* See [Disadvantage(s): replication](#disadvantages-replication) for points related to **both** master-slave and master-master.
* See [Disadvantage(s): replication](#disadvantages-replication) for points related to **both** leader-follower and leader-leader.

##### Disadvantage(s): replication

* There is a potential for loss of data if the master fails before any newly written data can be replicated to other nodes.
* There is a potential for loss of data if the leader fails before any newly written data can be replicated to other nodes.
* Writes are replayed to the read replicas. If there are a lot of writes, the read replicas can get bogged down with replaying writes and can't do as many reads.
* The more read slaves, the more you have to replicate, which leads to greater replication lag.
* On some systems, writing to the master can spawn multiple threads to write in parallel, whereas read replicas only support writing sequentially with a single thread.
* The more read leaders, the more you have to replicate, which leads to greater replication lag.
* On some systems, writing to the leader can spawn multiple threads to write in parallel, whereas read replicas only support writing sequentially with a single thread.
* Replication adds more hardware and additional complexity.

##### Source(s) and further reading: replication

* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
* [Multi-master replication](https://en.wikipedia.org/wiki/Multi-master_replication)
* [Multi-leader replication](https://en.wikipedia.org/wiki/Multi-master_replication)

#### Federation

Expand All @@ -879,7 +879,7 @@ Both masters serve reads and writes and coordinate with each other on writes. I
<i><a href=https://www.youtube.com/watch?v=kKjm4ehYiMs>Source: Scaling up to your first 10 million users</a></i>
</p>

Federation (or functional partitioning) splits up databases by function. For example, instead of a single, monolithic database, you could have three databases: **forums**, **users**, and **products**, resulting in less read and write traffic to each database and therefore less replication lag. Smaller databases result in more data that can fit in memory, which in turn results in more cache hits due to improved cache locality. With no single central master serializing writes you can write in parallel, increasing throughput.
Federation (or functional partitioning) splits up databases by function. For example, instead of a single, monolithic database, you could have three databases: **forums**, **users**, and **products**, resulting in less read and write traffic to each database and therefore less replication lag. Smaller databases result in more data that can fit in memory, which in turn results in more cache hits due to improved cache locality. With no single central leader serializing writes you can write in parallel, increasing throughput.

##### Disadvantage(s): federation

Expand All @@ -902,7 +902,7 @@ Federation (or functional partitioning) splits up databases by function. For ex

Sharding distributes data across different databases such that each database can only manage a subset of the data. Taking a users database as an example, as the number of users increases, more shards are added to the cluster.

Similar to the advantages of [federation](#federation), sharding results in less read and write traffic, less replication, and more cache hits. Index size is also reduced, which generally improves performance with faster queries. If one shard goes down, the other shards are still operational, although you'll want to add some form of replication to avoid data loss. Like federation, there is no single central master serializing writes, allowing you to write in parallel with increased throughput.
Similar to the advantages of [federation](#federation), sharding results in less read and write traffic, less replication, and more cache hits. Index size is also reduced, which generally improves performance with faster queries. If one shard goes down, the other shards are still operational, although you'll want to add some form of replication to avoid data loss. Like federation, there is no single central leader serializing writes, allowing you to write in parallel with increased throughput.

Common ways to shard a table of users is either through the user's last name initial or the user's geographic location.

Expand Down