{"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\/sk\/blog\/news\/vypusk-rqlite-6-0-raspredelyonnoj-otkazoustojchivoj-subd-na-osnove-sqlite","title":{"rendered":"Vydanie rqlite 6.0, distribuovanej odolnej DBMS zalo\u017eenej na SQLite","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Bol released the distributed DBMS rqlite 6.0, which uses SQLite as its storage engine and allows for the organization of a cluster of synchronized storage systems. rqlite is noted for its ease of installation, deployment, and maintenance of a distributed fault-tolerant storage, somewhat similar to etcd and Consul, but utilizing a relational model for data handling instead of a key\/value format. The project's code is written in Go and is distributed under the MIT license. <\/p>\n
To keep 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 runs a layer that processes client requests, performs replication to other nodes, and monitors the consensus for leader selection. <\/p>\n
Changes in the database can only be made by the node elected as the leader, but write operation connections can also be directed to other cluster nodes, which will return the leader's address to repeat the request (the next version promises to add automatic forwarding to the leader). The main focus is on fault tolerance, so the DBMS scales only for read operations, while write operations are a bottleneck. A rqlite cluster can be run from a single node, and such a solution can be used to provide SQLite access over HTTP without ensuring fault tolerance. <\/p>\n
SQLite data on each node is stored in memory, not in a file. At the Raft protocol implementation layer, a log of all SQLite commands that change the database is maintained. This log is used during replication (replication at the request replay level on other nodes), launching a new node, or recovery after loss of connectivity. To reduce the log size, automatic packing is applied, which starts after a specified number of changes and leads to the snapshot being fixed on disk, relative to which a new log begins (the in-memory database state is identical to the snapshot plus the accumulated change log). <\/p>\n
Vlastnosti rqlite: <\/p>\n
\n
Jednoduchos\u0165 nasadenia klasteru, bez potreby samostatnej in\u0161tal\u00e1cie SQLite.\n
Podpora \u0161ifrovania prenosu d\u00e1t medzi uzlami.\n
Mo\u017enos\u0165 nastavi\u0165 \u00farove\u0148 overovania aktu\u00e1lnosti a konzistentnosti d\u00e1t pri \u010d\u00edtan\u00ed.\n
Volite\u013en\u00e1 mo\u017enos\u0165 pripojenia uzlov v re\u017eime iba na \u010d\u00edtanie, ktor\u00e9 sa nez\u00fa\u010dast\u0148uj\u00fa na ur\u010den\u00ed konsenzu a s\u00fa vyu\u017e\u00edvan\u00e9 na zvy\u0161ovanie \u0161k\u00e1lovate\u013enosti klastru pri oper\u00e1ci\u00e1ch \u010d\u00edtania.\n
Podpora vlastn\u00fdch transak\u010dn\u00fdch foriem zalo\u017een\u00fdch na zl\u00fa\u010den\u00ed pr\u00edkazov v jednom dopyte (transakcie zalo\u017een\u00e9 na BEGIN, COMMIT, ROLLBACK, SAVEPOINT a RELEASE nie s\u00fa podporovan\u00e9).\n
V novom vydan\u00ed boli vykonan\u00e9 v\u00fdznamn\u00e9 architektonick\u00e9 zmeny zameran\u00e9 na zlep\u0161enie spo\u013eahlivosti klastera prostredn\u00edctvom vylep\u0161en\u00e9ho procesu smerovania po\u017eiadaviek na \u010d\u00edtanie a z\u00e1pis k spr\u00e1vnym uzlom klastera. Uzly rqlite teraz m\u00f4\u017eu multiplexova\u0165 medzi sebou nieko\u013eko logick\u00fdch spojen\u00ed, pri\u010dom vyu\u017e\u00edvaj\u00fa TCP spojenia, ktor\u00e9 s\u00fa vytvoren\u00e9 medzi uzlami pomocou protokolu Raft. Ak po\u017eiadavka vy\u017eaduje opr\u00e1vnenia ved\u00faceho uzla, ale je zaslan\u00e1 sekund\u00e1rnemu uzlu, sekund\u00e1rny uzol m\u00f4\u017ee ur\u010di\u0165 adresu l\u00eddra a odovzda\u0165 ju klientovi, bez vykonania v\u00fdpo\u010dtu konsenzu pod\u013ea protokolu Raft. <\/p>\n
Zmeny tie\u017e umo\u017enili zbavi\u0165 sa samostatnej zlo\u017eky pre synchroniz\u00e1ciu metad\u00e1t a vyl\u00fa\u010di\u0165 samostatn\u00e9 spracovanie stavu Raft a metad\u00e1t. Sekund\u00e1rne uzly teraz smeruj\u00fa po\u017eiadavky k uzlu l\u00eddrovi len pod\u013ea potreby, ke\u010f potrebuj\u00fa z\u00edska\u0165 adresu ved\u00faceho uzla. V API je poskytnut\u00e1 mo\u017enos\u0165 z\u00edskania inform\u00e1ci\u00ed o stave ostatn\u00fdch uzlov v klastri. Do pr\u00edkazov\u00e9ho rozhrania bola pridan\u00e1 pr\u00edkaz «.sysdump». \n Zdroj: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"