Full sync logic

This commit is contained in:
Michael Stanclift 2020-06-29 15:49:16 -05:00
parent 5cee345ee9
commit adb63debc1
2 changed files with 38 additions and 8 deletions

View File

@ -6,11 +6,11 @@
**Features**
For 2.0, the `push` and `pull` functions have been broken up for each component part (`gravity.db` and `custom.list`), and Gravity Sync will now detect not only if each component has changed since the last sync but also what direction they need to go.
Example: 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 now do a pull and a push of each part and then restart the correct components on each server.
Example: 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 now do a pull and then push for each part, 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.
This allows you to be more flexible in where you make your configuration changes to block/allow lists, but it's still suggested to identify a primary server to make these changes on. In the event there are configuration changes to the same element (`custom.list` changes at both sides) then the primary will still be the authoritative source and overwrite the secondary copy.
This allows you to be more flexible in where you make your configuration changes to block/allow lists and local DNS settings being made on either the primary or secondary, but it's best practice to continue making changes on the primary server where possible. In the event there are configuration changes to the same element (`custom.list` changes at both sides) then the primary will still be the authoritative source and overwrite the secondary copy.
Existing users who want to use this new method as their standard should run `./gravity-sync.sh automate` function to replace the existing automated `pull` with the new Smart Sync.
Existing users who want to use this new method as their standard should run `./gravity-sync.sh automate` function to replace the existing automated `pull` with the new Smart Sync. You can also continue to use `pull` in your automation if you choose. New installs will use the smart Sync function by default. Running `./gravity-sync.sh` without any arguments will now run the smart Sync function.
## 1.8
### The Logical Release

View File

@ -405,24 +405,39 @@ function smart_gs {
if [ "${primaryDBMD5}" != "${last_primaryDBMD5}" ]
then
pull_gs_grav
PULLRESTART="1"
elif [ "${secondDBMD5}" != "${last_secondDBMD5}" ]
then
push_gs_grav
PUSHRESTART="1"
else
echo "No DB changes"
# echo "No DB changes"
fi
if [ "${primaryCLMD5}" != "${last_primaryCLMD5}" ]
then
pull_gs_cust
PULLRESTART="1"
elif [ "${secondCLMD5}" != "${last_secondCLMD5}" ]
then
push_gs_cust
PUSHRESTART="1"
else
echo "No CL changes"
# echo "No CL changes"
fi
if [ "$PULLRESTART" == "1" ]
then
pull_gs_reload
fi
if [ "$PUSHRESTART" == "1" ]
then
push_gs_reload
fi
logs_export
exit_withchange
}
function restore_gs {
@ -1178,9 +1193,10 @@ function list_gs_arguments {
echo -e " ${YELLOW}version${NC} Display installed version of ${PROGRAM}"
echo -e ""
echo -e "Replication Options:"
echo -e " ${YELLOW}pull${NC} Sync remote ${GRAVITY_FI} to this server"
echo -e " ${YELLOW}push${NC} Force changes made on this server back"
echo -e " ${YELLOW}restore${NC} Restore ${GRAVITY_FI} on this server"
echo -e " ${YELLOW}sync${NC} Detect changes on each side and bring them together"
echo -e " ${YELLOW}pull${NC} Force remote configuration changes to this server"
echo -e " ${YELLOW}push${NC} Force local configuration made on this server back"
echo -e " ${YELLOW}restore${NC} Restore the ${GRAVITY_FI} on this server"
echo -e " ${YELLOW}compare${NC} Just check for differences"
echo -e ""
echo -e "Debug Options:"
@ -1465,6 +1481,20 @@ case $# in
1)
case $1 in
sync)
TASKTYPE='SYNC'
MESSAGE="${MESSAGE}: ${TASKTYPE} Requested"
echo_good
import_gs
validate_gs_folders
validate_ph_folders
validate_os_sshpass
smart_gs
exit
;;
pull)
TASKTYPE='PULL'
MESSAGE="${MESSAGE}: ${TASKTYPE} Requested"