A master copy from
1, the main principle of the copy:
-
Designate a copy as a master copy. When a customer writes to the database, the data is first written to the primary copy locally.
-
The master copy is sent to change it from a copy of the log data. Each copy of the application to the local change log. Strictly maintain the master copies of the same written order.
-
When a client reads data from the database, and can be read from a copy of the master copy, but can only write written on the master copy.
2, synchronous and asynchronous replication
Replication : the client sends an update to the master node, the master node updates the data sent from the node, the master node to the node after the completion of the update, the client last update completion notification by the master node.
Semisynchronous : from one node are synchronized, the other nodes are asynchronous. When the failed node from the sync, then from another node to a synchronous mode. This ensures that there are at least two nodes have the latest data.
Full asynchronous : good system throughput performance, but can not guarantee that persistent data.
3, the new configuration from the node
Increase copy, if only a simple copy, cause there are different points of time data on different nodes. Because the client is still kept writing data to the master copy of the data is constantly changing.
Increase from the node in the case of non-stop, uninterrupted data services:
-
Produce a consistent snapshot of the data copy of the master node at some point in time.
-
This snapshot copy to the slave node.
-
After the data connection from the requesting node to the master node a consistent snapshot change log.
-
From these data node application changes, known as catch up.
4, processing node failure
-
From node failure : Save the change log data received from the node's hard disk. From node can know the final sum of the transaction before the failure, and connected to the main node of data changes after this transaction request, be chased.
-
The master node failure : switching node. Select a node from the master node upgrade. The client also needs to be updated, send a request to the new primary node.
Automatic switching step:
-
Verify that the master node fails: The timeout mechanism, heartbeat messages frequently transmitted between the nodes.
-
New primary elections: consensus on the issue.
-
Configure the system so that the primary node into effect: the system needs to ensure that the original primary node downgraded from node and approved the new master node.
-
5, copy of the log to achieve
-
And the operation instruction write request sent from the node as the master node of each log record: statement-based replication.
Suited Scene: non-deterministic statements, depending on the available data, there are side effects of the statement.
-
Based on the write-ahead log transmission: all bytes written to the database are logged, the log can be constructed using the exact same copy on another node. The disadvantage is that very bottom of the log, resulting in tightly coupled and storage engine. From the master node can not run different versions of the software upgrade downtime.
-
Log based replication logical line: copy logs and log storage engine in different formats. Logical logs and storage engine logic decoupling.
-
Replication trigger based on: a database when a data change occurs, execution of the application-level code.
6, replication lag problems
-
Read write their own user submit data then view the contents of your own submission. However, when reading data from the slave node possible. The new data may not arrive from the node, affecting the user experience. Read-after-write consistency guarantees the user to reload the page, can always see their own updates recently submitted.
Program:
1. If a user accesses content may be modified, read only from the master node. You need a way to know the information might be modified.
2. Track time last updated. If after one minute updates, it is always read in the master node. And monitor the extent of lag from the node.
3. The client may include a timestamp in the request, the system to ensure the provision of services are included reading the time stamp, and if not, to deal with another copy. Question: cross-device consistency.
-
Monotone reading a user to write data to the master node A, B at this time another user read twice. First read data from the node has been written, to read data written by the user A. From the second visit of the node has not received updated data of the master node, B users just see something and disappeared, as if rolled back.
Solution: Always read the same user from a fixed copy. ID such as a hash-based approach rather than a random selection copy.
-
Prefix consistent reading for a series of write occurring in a certain order request, also when reading the order was written. Distributed databases, different partitions independently, global write order does not exist.
Solution: Any write a causal relationship were handed over to a partition to complete.
Second, multi-master replication
1, application scenarios
-
Multiple Data Center: For disaster recovery and closer to the user's consideration, a copy of the database across multiple data centers. Within each data center, a master-slave replication scheme. Between data centers, each master node is responsible for updating the data exchange with the master node other data centers.
-
Offline client operations: offline, any changes to the local user data, when the device is on-line again, with the synchronization servers and other devices. A primary node corresponding to the local database, multi-master replication considerable time synchronization between the data center and network.
-
Collaborative editing: faster collaboration efficiency will reduce editable size. This can lead to generation of multi-master replication.
2, processing write conflict
Avoid conflicts: a write request for specific data is always by the same master node. As a particular user's personal information by modifying particular data center. From the master copy corresponds for each user.
Principle to resolve the conflict: converge to a consistent state . You should ensure that all copies of the data in the final state is the same.
-
Convergence solutions possible ways:
-
Based on the timestamp, or the user id of priority to determine the final winner.
-
A copy of the set priorities.
-
The combined values will be written.
-
Retention of information conflicts with the application layer to solve. It allows users to custom solutions.
Third, no replication master node
Give up the master node, allowing any copies directly receive write requests from clients.
When written to the database node failure does not need to perform the switching operation at the primary node replication model. Node failure may read stale data back online later. When To solve this problem, the client reads the data, instead of reading a copy of the read request transmitted in parallel to a plurality of copies. The version number can be used to determine which value is updated.
1, to repair the failed node:
-
When reading the data to the new values and old values, the updated value is written backward node. (Read repair) Cons: Few database lost data read may not be detected.
-
Background processes continue to look for differences between the copies (anti-entropy process)
2, to determine the reading success:
If there are n copies requires written confirmation w nodes, reading at least r must query nodes.
Need w + r> n. Thus read in a certain node contains the latest value. (Quorum)
w and r may be configured, for writing the read how much load can be set w = n, r = 1.
3, loose Quorum:
In need high availability scenario, when the client node and the node of a network failure led to a response of less than the number needed to arbitration. Loose quorum value written in the client can not be written into the node n nodes, as long as the response is greater than the number of nodes that can be successfully written w. When the network problem resolution and then sent to the original node. But the client is not necessarily read from node r to the new value.
4, across data center operations:
1, can be sent to all copies, but only waiting for confirmation from the local data center. ,
2, only the data center and the local interactive, multi-master replication between data centers.
5, concurrent write
Concurrent write need to address multiple clients simultaneously write all copies, between multiple copies eventually converge to the same content.
1, the last write wins . Attach a time stamp each write request, each node discards data written earlier. So at the expense of data persistence, though sending a written message to the client success, but the data is discarded.
2, causality and concurrency relationships : If A and B operations depend operation occurs, is Happens-Before relationship. If you do not need each other know if they occurred, is complicated by the relationship.
Resolve Concurrency relationship algorithm (p178 examples deduction):
-
Server maintains a version number for each primary key. The version number is incremented when the main key to write the new value and save the new value and version number.
-
The client reads the primary key. The server returns all primary key value of the current version number and server.
-
Before client contains a write server with the primary key to return to this later version read the version number, and the new value of the merger.
-
When the server receives written, covering all values of the version numbers and earlier versions, save all values later.
The combined value is simultaneously written
Vector version : multiple copies, you can save the version number of the version number and a copy of the master key. Written can be read on another copy on a copy. Database decisions should be covered or left concurrency value.