![]() If you would prefer to be explicitly redirected to the Leader, add redirect as a URL query parameter. The receiving node will transparently forward the request to the Leader as needed, and return the response of the Leader to the client. Finally, this type of load request can be sent to any node. In addition any preexisting SQLite database is completely overwritten by this type of load operation, so it’s safe to perform regardless of any data already loaded into your rqlite cluster. This is the recommended way to initialize your rqlite node from existing SQLite data. Even large SQLite databases can be loaded into rqlite in a matter of seconds. This is the fastest way to initialize a rqlite node from an existing SQLite database. Rqlite supports loading a node directly from two sources, either of which can be used to initialize your system from preexisting SQLite data, or to restore from an existing node backup: If your SQLite database is in wal mode, convert it (or a copy of it) to delete mode first by issuing the command PRAGMA journal_mode=delete. Rqlite does not support loading SQLite database files which are in wal mode. ![]() The configuration file also supports variable expansion – this means any string starting with $ will be replaced with that value from Environment variables when it is loaded by rqlite. If you wish to disable compression of the backup add no_compress: true to the top-level section of the configuration file. The backup will be stored in the bucket at path, which should also be set to your preferred value. You must also supply your Access Key, Secret Key, S3 bucket name, and the bucket’s region, but setting the Endpoint is optional. In the example above, rqlite will check every 5 minutes if an upload is required, and do so if needed. Interval is configurable and must be set to a Go duration string. To configure automatic backups to an S3 bucket, create a file with the following (example) contents and supply the file path to rqlite: In the event that you lose your rqlite cluster you can use the backup in the Cloud to recover your rqlite system. Only the cluster Leader performs the upload.īackups are controlled via a special configuration file, which is supplied to rqlited using the -auto-backup flag. To save network traffic rqlite uploads a compressed snapshot of its SQLite database, and will not upload a backup if the SQLite database hasn’t changed since the last upload took place. Rqlite supports automatically, and periodically, backing up its data to Cloud-hosted storage. See the SQLite documentation for more details. This means that any changes due to transactions to the database, that take place during the backup, will be reflected immediately once the transaction is committed, but not before. The isolation offered by binary backups is READ COMMITTED. dump bak.sqlĬurl -s -XGET localhost:4001/db/backup?fmt =sql -o bak.sql You can also dump the database in SQL text format via the CLI as follows: 127.0.0.1:4001>. In either case the generated file can then be used to restore a node (or cluster) using the restore API. It is then up the clients to re-issue the command to the Leader. In that case if a Follower receives a backup request the Follower will respond with HTTP 301 Moved Permanently and include the address of the Leader as the Location header in the response. If you do not wish a Follower to transparently forward a backup request to a Leader, add redirect to the URL as a query parameter. ![]() If, instead, you want a backup of SQLite database of the actual node that receives the request, add noleader to the URL as a query parameter. Note that if the node is not the Leader, the node will transparently forward the request to Leader, wait for the backup data from the Leader, and return it to the client. Curl -s -XGET localhost:4001/db/backup -o bak.sqlite3 ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |