Support Joint Consensus #18079

Description

Etcd and TiKV use a simple implementation for membership change(adding/removing one peer one time when applying the raft log).

This works well most of the time, but sometime it may still have risk, especially when PD does balance.
Eg, three racks 1, 2, and 3, each rack has 2 machines (we use h11, h12 for machines in rack1, and so on). PD first schedules three peers p1, p2, p3 to h11, h21, and h31, then it finds that h11 has a high load, so it decides to add a new peer p4 to h12 and remove p1 in h11.

If rack 1 is down after adding p4, the region can't supply service. especially if this region is a very important region, it may affect high availability. To avoid this, we must add p4 and remove p1 atomically, but now, we can't support it.

Supporting join consensus can fix this problem

Category

Feature

Value

Improve the ability of system disaster tolerance

Task List

• Port joint consensus to raft-rs
• TiKV use joint consensus
• PD use joint consensus
• TiFlash use joint consensus
• TLA+ for joint consensus

Schedule

GanttStart: 2020-06-24
GanttDue: 2020-09-31
GanttProgress: 80%
TestProgress: 10%

Progress Tracking

• Joint Consensus: https://github.com/tikv/tikv/projects/44

Workload Estimation

300