Highly available database refers to the maximum extent to provide services for users, such as failure to avoid server downtime caused by service interruptions. High availability of the database is not only reflected in the database can continue to provide services, but also in ability to ensure data consistency.
SequoiaDB Sequoia database compatibility as a 100% MySQL domestic open source distributed database, and how its performance in terms of high availability? How its high availability is achieved? The principles herein SequoiaDB high availability database redwood described in detail, verified and tested.
01 redwood Sequoia SequoiaDB distributed database cluster architecture using computing and storage separation architecture, SequoiaSQL-MySQL is calculated SQL layer, the memory layer by a coordinating node, and the node catalog data nodes.
Figure 1 SequoiaDB distributed architecture
As shown in Figure 1 is the simplest SequoiaDB distributed database architecture of FIG clusters by a coordinating node, a catalog nodes, nodes 3 and SequoiaSQL-MySQL data configuration. Wherein the data nodes on three servers, data replication comprising three sets 1, 2, each group consisting of three data replication identical copies of data composed of data between the synchronization data copy consistency through the log.
A, A1, A2 data replication group consisting of 1, the three identical copies of the data. Data replication group 1 group 2, 3 is similar to data replication. In SequoiaDB distributed cluster, each replication group supports up to seven copies of the data.
Highly available distributed test environment described herein cluster architecture shown in Figure 1, wherein the master node has read and write capabilities, two backup copies may perform a read operation or backup.
02 Sequoia achieve high availability database availability using SequoiaDB Raft algorithm, synchronized to maintain data consistency across multiple copies of the log.
FIG 2 is maintained between the three nodes are connected
as shown in Figure 2, a heartbeat connection between the holding three copies SequoiaDB clusters.
Copy data between groups through shared state shared heartbeat sharing-beat. As shown, sharing-beat heart beat information structure includes ID 3, the LSN itself starts, the LSN termination itself, the time stamp, the data group version number, and the role of its current synchronization state.
FIG 3 heartbeat status information structure
Each node maintains a status-sharing table table for recording the node status. sharing-beat transmitted once every 2 seconds, the acquisition response information, if N consecutive second response message is not received, the node is considered down.
Only one node in the cluster as a master node, the standby node to other nodes. If dual master or multi-master occurs, need to be prepared according to the LSN reduce contrast, to ensure that only one master node in the cluster.
Note: . 1) when the master node goes down, the backup node from the need to elect a new node as new master node. 2) When the standby node goes down, the master node is not affected, and the like after recovery standby node, the master node continues to maintain the log to which synchronization data.
The following describes when the primary node goes down, the new master of the election process. Election conditions satisfying the following two conditions may be elected as the master node: a majority vote by the standby node 2. The maximum LSN node election process 1) down when the master node A, A is automatically reduced to the standby node, the coordinator node traffic off connection.
FIG 4 cluster master node hang
2) A1 and A2 are equipped to determine whether it is a master node L, i.e., if they meet initiate an election request. Conditions Content:
-
It is not the master node
-
The remaining standby node accounted for more than half
-
LSN own equipment than other nodes LSN new
3) other nodes will be prepared to vote with their nodes LSN LSN do comparison, if the new LSN than their own, the vote in favor of, or vote against it. 4) If the favor of more than (n / 2 + 1), supports the master node node election success. Otherwise, keep the equipment nodes, and electoral defeat. 5) After successful election state information sharing heartbeat data group information to other nodes.
03 High Availability Disaster Recovery verification is generally distributed database POC testing including functional testing, performance testing, test distributed transactions, high availability disaster recovery testing and compatibility testing. The following will SequoiaDB Sequoia High Availability database to verify the test.
Test Environment Description
Distributed cluster environment test article, comprising a SequoiaSQL-MySQL, 3 data nodes, one node catalog, a coordinator node, the cluster structures refer to specific embodiment Sequoia official website virtual machine image build tutorial. After kill off the master node process, we read and write operations on a distributed database cluster, to validate high availability.
-
View server cluster status
# service sdbcm status ..... Main PID: 803 (sdbcm) Tasks: 205 (limit: 2319) CGroup: /system.slice/sdbcm.service ├─ 779 sdbcmd ├─ 803 sdbcm(11790) ├─1166 sequoiadb(11840) D ├─1169 sequoiadb(11810) S ├─1172 sequoiadb(11830) D ├─1175 sdbom(11780) ├─1178 sequoiadb(11820) D ├─1181 sequoiadb(11800) C 1369 /opt/sequoiadb/plugins/SequoiaSQL/bin/../../../java/jdk/bin/java -jar /opt/sequoiadb/plugins/SequoiaSQL .....
-
SequoiaDB distributed data nodes in the cluster port 11820,11830,11840; catalog nodes 11800, 11810 coordinator node
sdbadmin@sequoiadb:~$ ps -ef|grep sequoiadb sdbadmin 1166 1 0 Aug20 ? 00:02:23 sequoiadb(11840) D sdbadmin 1169 1 0 Aug20 ? 00:01:43 sequoiadb(11810) S sdbadmin 1172 1 0 Aug20 ? 00:02:24 sequoiadb(11830) D sdbadmin 1178 1 0 Aug20 ? 00:02:33 sequoiadb(11820) D sdbadmin 1181 1 0 Aug20 ? 00:04:01 sequoiadb(11800) C
-
11820 kill off the master node, execute the query and write sql
sdbadmin@sequoiadb:~$ kill 1178 sdbadmin@sequoiadb:~$ ps -ef|grep sequoiadb sdbadmin 1166 1 0 Aug20 ? 00:02:24 sequoiadb(11840) D sdbadmin 1169 1 0 Aug20 ? 00:01:43 sequoiadb(11810) S sdbadmin 1172 1 0 Aug20 ? 00:02:24 sequoiadb(11830) D sdbadmin 1181 1 0 Aug20 ? 00:04:01 sequoiadb(11800) C sdbadmin 1369 1 0 Aug20 ? 00:01:33 /opt/sequoiadb ....
-
See performed sql, view data 121 before the insertion operation
mysql> select * from news.user_info; +------+-----------+ | id | unickname | +------+-----------+ | 1 | test1 | ........ | 119 | test119 | | 120 | test120 | | 121 | test121 | +------+-----------+ 121 rows in set (0.01 sec)
-
A write sql, see the insert was successful
mysql> insert into news.user_info(id,unickname)values(122,"s uccess"); Query OK, 1 row affected (0.00 sec) mysql> commit; Query OK, 0 rows affected (0.01 sec) mysql> select * from news.user_info; +------+-----------+ | id | unickname | +------+-----------+ | 1 | test1 | ......... | 120 | test120 | | 121 | test121 | | 122 | success | +------+-----------+ 122 rows in set (0.00 sec)
Data (122, "success") data insertion success, in the case where a master node hang, are not affected by the write, read and write data consistent, high availability is verified.
1000w now perform the import data writing scripts imprt.sh, during execution kill off the primary data node, the master node failure scenario simulation, changes in the view cluster write Sequoia graphical monitoring database interface SAC.
Note: If you need to get imprt.sh script, concerned about the "giant sequoias database" Public No. reply "imprt" can get.
-
The import data script
./imprt.sh 协调节点主机 协调节点端⼝ 次数./imprt.sh 192.168.1.122 11810 100
-
5, the data in the import time, kill off the primary data node, insert written down after the high availability cluster recovery
FIG 5 SAC cluster monitoring interface changes schematic reader
A schematic view of FIG. 6 SAC write data amount tpcc
SAC can be seen from the visual interface, when the duration of the primary data node fails in the course of our 1000w data insertion operation, the data read is affected very short. Finally, by using imprt.sh script to re-import the data into a failure, you can ensure data consistency final.
04 summary SequoiaDB
Distributed cluster have better high availability cluster data replication may be provided a plurality of groups, each group composed of a data replication plurality of identical copies, by maintaining data consistency between copies of logs in a synchronized manner and Raft algorithm. Finally, also verify the write operation, if the cluster master data node goes down, the cluster may be distributed in the normal data read and write data performed ten million, and the data remains consistent with the final, high availability is verified.