Cutlery/gravity-sync
1
0
Fork 0
mirror of https://github.com/vmstan/gravity-sync.git synced 2025-07-09 02:34:06 -04:00
Code Issues Packages Projects Releases Wiki Activity

Updated Execution (markdown)

Michael Stanclift 2022-04-13 09:30:17 -05:00
parent 287191ab9d
commit d7ac2f91a5
1 changed files with 1 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Execution.md

@ -30,18 +30,4 @@ Gravity Sync will perform some checks to help ensure success and then stop befor
In the event there are configuration changes to the same element (example, `custom.list` changes at both sides) then Gravity Sync will attempt to determine based on timestamps on what side the last changed happened, in which case the latest changes will be considered authoritative and overwrite the other side. Gravity Sync **does not** merge the contents of the files.
If the execution completes, you will now have a synchronized copy of your running `gravity.db`, `custom.list` and `05-pihole-custom-cname.conf` on both Pi-hole.
## Automation
Automation of sync is accomplished by adding an execution of the script to each host's systemd configuration.
```bash
gravity-sync auto
```
Automation tasks within systemd are configured by default to run at semi-randomized times on each node. The net effect is replication should happen in under 5 minutes.
(Replications will also automatically attempt for the first time 2 minutes after either system is rebooted/powered on.)
Now, make another small adjustment to your primary settings and wait until anointed time to see if your changes have been synchronized. If so, profit! If not, start from the beginning. From this point forward any block list changes you make to either instance will quickly be reflected on the peer.
If the execution completes, you will now have a synchronized copy of your running `gravity.db`, `custom.list` and `05-pihole-custom-cname.conf` on both Pi-hole.