{"id":100516,"date":"2021-06-14T16:22:58","date_gmt":"2021-06-14T14:22:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-rqlite-6-0-raspredelyonnoj-otkazoustojchivoj-subd-na-osnove-sqlite"},"modified":"2021-06-14T16:22:58","modified_gmt":"2021-06-14T14:22:58","slug":"vypusk-rqlite-6-0-raspredelyonnoj-otkazoustojchivoj-subd-na-osnove-sqlite","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/vypusk-rqlite-6-0-raspredelyonnoj-otkazoustojchivoj-subd-na-osnove-sqlite","title":{"rendered":"Release of rqlite 6.0, a distributed fault-tolerant DBMS based on SQLite","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
The release of the distributed database management system rqlite 6.0 has been announced, which uses SQLite as its storage engine and allows for the organization of a cluster of synchronized storage systems. rqlite is noted for its simplicity in installation, deployment, and maintenance of a distributed fault-tolerant storage system, somewhat similar to etcd and Consul, but utilizing a relational model for data management instead of a key\/value format. The project's code is written in Go and is distributed under the MIT license. <\/p>\n
To maintain all nodes in a synchronized state, the Raft consensus algorithm is used. Rqlite employs the original SQLite library and the standard go-sqlite3 driver, on top of which a layer processes client requests, performs replication to other nodes, and monitors the consensus in selecting the leader node. <\/p>\n
Changes to the database can only be made by the node that is selected as the leader, but connections for write operations can also be directed to other nodes in the cluster, which will return the leader's address for request retrying (automatic forwarding to the leader is promised in the next version). The main emphasis is on fault tolerance, which is why the DBMS scales only for read operations, with write operations being a bottleneck. It is possible to run an rqlite cluster from a single node, and this solution can be used to organize access to SQLite over HTTP without providing fault tolerance. <\/p>\n
SQLite data on each node is stored not in a file but in memory. At the layer implementing the Raft protocol, a log of all SQLite commands that lead to changes in the database is maintained. This log is used during replication (replication at the level of executing requests on other nodes), starting a new node, or recovery after loss of connectivity. To reduce the log size, automatic packaging is applied, which is triggered after a specified number of changes and results in a snapshot being committed to disk, relative to which a new log begins (the in-memory state of the database is identical to the snapshot plus the accumulated log of changes). <\/p>\n
Features of rqlite: <\/p>\n
\n
Ease of deploying a cluster without the need for a separate SQLite installation.\n
The ability to quickly obtain a replicated SQL storage.\n
Ready for use in production projects.\n
Availability of an HTTP(S) API that allows for batch updates of data and identifies the cluster's leading node. A command-line interface is also provided, along with the ability to use various client libraries created for SQLite.\n
Availability of a service for identifying other nodes, allowing dynamic cluster creation.\n
Support for encrypting data exchanges between nodes.\n
Ability to configure the level of data freshness and consistency checks upon reading.\n
Optional capability to connect nodes in read-only mode, which do not participate in consensus determination and are used to increase cluster scalability for read operations.\n
Support for a custom form of transactions based on grouping commands in a single request (transactions based on BEGIN, COMMIT, ROLLBACK, SAVEPOINT, and RELEASE are not supported).\n
Support for creating hot backups. <\/ul>\n
The new release includes significant architectural changes aimed at enhancing the reliability of the cluster by improving the request routing process for reading and writing to the appropriate cluster nodes. Rqlite nodes can now multiplex between multiple logical connections using TCP connections established between nodes via the Raft protocol. If a request requires the authority of the leader node but is sent to a secondary node, the secondary node can determine the leader's address and relay it to the client without executing a consensus calculation via the Raft protocol. <\/p>\n
The change also eliminated the need for a separate component for metadata synchronization and removed the separate handling of the Raft state and metadata. Secondary nodes now direct requests to the leader node only when necessary, to find out the address of the leading node. The API provides the ability to obtain information about the state of other nodes in the cluster. A new command \u2018.sysdump\u2019 has been added to the command line interface. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"