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 Pull vs Push (markdown)

Michael Stanclift 2020-10-21 20:45:34 -05:00
parent 364e03e977
commit 21d1592b20
1 changed files with 14 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
Pull-vs-Push.md

@ -1,3 +1,17 @@
Central to Gravity Sync is the idea of a primary and secondary Pi-hole. This has been there since the beginning. Originally the intention was only to take data from the primary and replicate it to the secondary. Since the secondary wouldn't have as much load on it under normal conditions, it seemed logical for Gravity Sync to run there since frequent restarts of the Pi-hole service wouldn't disrupt normal DNS user traffic.
Gravity Sync would _pull_ the data from the primary (remote) Pi-hole, to the secondary (local) server.
Almost immediately after release of 1.0, the small group of users who were testing the script asked what happened if you made changes on the secondary while the primary was down. You'd need a way to _push_ the changes back the other way.
So version 1.1 broke out the original functionality into `./gravity-sync.sh pull` and created `./gravity-sync.sh push` to go the other way.
This is the way it functioned until version 2.0. `./gravity-sync.sh smart` or just a simple `./gravity-sync.sh` will detect which way the data needs to go. So if the gravity.db has been modified on the primary Pi-hole, but the custom.list file has been changed on the secondary, Gravity Sync will do a _pull_ of the gravity.db then _push_ custom.list and then restart the correct components on each server. It will also only perform a sync of each component, if there are changes within each type to replicate. Now, if you only make a small change to your Local DNS settings, it doesn't kickoff the larger gravity.db replication.
This allows you to be more flexible in where you make your configuration changes, but it's considered best practice to continue making changes on one side where possible. In the event there are configuration changes to the same element within any given replication window (for 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 when these replication events happen, it simply overwrites the file on the other side.
The previous `./gravity-sync.sh pull` and `./gravity-sync.sh push` commands continue to function as they did previously, with no intention to break this functionality.
### The Pull Function
The Gravity Sync Pull, prior to version 2.0, was the standard method of sync operation, and will not prompt for user input after execution.