When looking into using an Orchestration software to facilitate OS patching on servers, which would involve autonomously stopping and starting the Performance Center components.
In regard to the Data Repository. This is the command that is used to stop the database:
/opt/vertica/bin/adminTools -t stop_db -d caim -p PASSWORD -F
On a nightly cronjob scheduled at 8pm to execute the vbr.py backup routine, configured to manage 7 restore points. What are the consequences of the OS Patching Orchestration beginning later at 10pm while that backup routine is running?
1.) What will happen to the running vbr.py script when a "stop_db" command is issued? Will the vbr.py script stop by itself? Or will the kill commands still need to be run?
2.) If no, how do we safely stop the vbr.py backup routine prior to issuing the command to stop the database?
3.) Any concerns for corrupting the previous restore points?
4.) Will the vbr.py backup routine continue successfully the next time it runs at 8pm the following night?
CA Infrastructure Management - MULTI-PLATFORM Release:2.7
1.) If a "stop_db" command is issued whiled the vbr.py script is running, the vbr.py script will not stop by itself, a kill command will need to run to stop it. The vbr.py backup will not clean itself up. They can be cleaned up by first checking here:
=> select * from database_snapshots;
=> select remove_database_snapshot(' snapshot_name');
2.) There is no specific command to stop vbr.py backup in Vertica in between. For stopping vbr.py backup in between you can use two ways and both are server utilities:
The process may look like this:
dbadmin 304024 295291 6 01:47 pts/0 00:00:01 /opt/vertica/oss/python/bin/python /opt/vertica/bin/vbr.py -t backup -c 30May.ini
After killing vbr process , please kill rsync process as well to ensure successful kill of backup.
3.) Previous restore points should be unaffected, however, interrupted backups cannot be used to restore.
4.) Yes. VBR creates a list of files and compares them to the database to determine which have been updated and need to be copied over. This process should resume from where it left off and also recopy any files which have changed since the initial run.
The backup will fail during initialization and clean-up snapshots if the database is DOWN. The database is required to be UP for backup to run. This may leave some orphaned snapshots which will consume space on your disk.