-
Notifications
You must be signed in to change notification settings - Fork 0
Description
PUSH Subscription mode is a new feature for SQLRsync that allows
you to optionally automatically PUSH changes from the LOCAL to
REMOTE.
The feature works by using OS native file watchers to monitor changes
to the file, and when a change is detected, begin a PUSH operation after
a variable delay. Users specify how long to a fixed amount of time since
the last change.
The subscription mode is activated by adding the --subscribe flag to a
PUSH command. The first time the command is run, it will do a normal
PUSH, and then begin monitoring the file for changes. When a change is
detected, it will wait the specified delay time (or auto mode) and then
begin a PUSH operation. If another change is detected during the wait
time, the wait timer is reset UNLESS it has been X hours since the last
PUSH, in which case it will immediately begin a PUSH operation.
Example:
sqlrsync mydb.sqlite namespace/mydb.sqlite --subscribe --waitIdle 10m --maxInterval 24h
Wait for 10 minutes of idleness before pushing, but in the event that there's
activity every 8 minutes for multiple days straight, it will at least push
24 hours after the last push.
Example:
sqlrsync mydb.sqlite namespace/mydb.sqlite -m "turn on push subscribe" --subscribe --waitIdle 10m --maxInterval 24h
With push subscribe the database is checked to see if PRAGMA busy_timeout is
greater than waitIdle. If not, it asks the user what value they want to increase
it to and sets it.
If --waitIdle or --minInterval is set, then on change detection, send SQLRSYNC_CHANGED with a 4 byte duration of when we expect to send the PUSH (ETA). If a subsequent change happens, then 10 seconds before the prior SQLRSYNC_CHANGED would expire, send another SQLRSYNC_CHANGED with the new ETA.
Automerge
If the server responds that there was a newer version that we didn't know about but we've already PUSHed some changes, the server rejects the PUSH and tells us what the latest version is. If the user provides the --merge flag, then we:
- use LOCAL mode to copy this database to /tmp/sqlrsync-merge-local*randomstuff
- use PULL mode to grab latest and assert it over that /tmp file
- use sqlrsync --diff to diff the /tmp vs LOCAL and generate a patch file
- if the patch doesn't have any conflicting primary keys, then apply it and push, otherwise send a call to POST serverURL/sapi/notification/account/replicaName/. The server will block this server until a human resolves the conflict.
Message body for post:
{ type: "merge-conflict", the diff file as base64, the versions impacted, hostname, wsID }
Metadata
Metadata
Assignees
Labels
Type
Projects
Status