2019-03-21 15:48:41 -04:00
|
|
|
#!/bin/bash
|
|
|
|
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License"); you may
|
|
|
|
# not use this file except in compliance with the License. You may obtain
|
|
|
|
# a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
|
|
|
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
|
|
|
# License for the specific language governing permissions and limitations
|
|
|
|
# under the License.
|
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
# Capture the user's command line arguments
|
2019-03-21 15:48:41 -04:00
|
|
|
ARGS=("$@")
|
2019-04-23 13:36:07 -05:00
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
# This is needed to get the postgresql admin password
|
|
|
|
# Note: xtracing should be off so it doesn't print the pw
|
|
|
|
export PGPASSWORD=$(cat /etc/postgresql/admin_user.conf \
|
|
|
|
| grep postgres | awk -F: '{print $5}')
|
2019-04-23 13:36:07 -05:00
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
source /tmp/restore_main.sh
|
2019-04-23 13:36:07 -05:00
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
# Export the variables needed by the framework
|
|
|
|
export DB_NAME="postgres"
|
|
|
|
export DB_NAMESPACE=${POSTGRESQL_POD_NAMESPACE}
|
|
|
|
export ARCHIVE_DIR=${POSTGRESQL_BACKUP_BASE_DIR}/db/${DB_NAMESPACE}/${DB_NAME}/archive
|
2019-04-23 13:36:07 -05:00
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
# Define variables needed in this file
|
|
|
|
POSTGRESQL_HOST=$(cat /etc/postgresql/admin_user.conf | cut -d: -f 1)
|
|
|
|
export PSQL="psql -U $POSTGRESQL_ADMIN_USER -h $POSTGRESQL_HOST"
|
2020-06-03 22:27:57 +00:00
|
|
|
export LOG_FILE=/tmp/dbrestore.log
|
2019-03-21 15:48:41 -04:00
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
# Extract all databases from an archive and put them in the requested
|
|
|
|
# file.
|
2019-03-21 15:48:41 -04:00
|
|
|
get_databases() {
|
2020-05-08 13:04:28 +00:00
|
|
|
TMP_DIR=$1
|
|
|
|
DB_FILE=$2
|
2019-04-23 13:36:07 -05:00
|
|
|
|
|
|
|
SQL_FILE=postgres.$POSTGRESQL_POD_NAMESPACE.all.sql
|
2020-05-08 13:04:28 +00:00
|
|
|
if [[ -e $TMP_DIR/$SQL_FILE ]]; then
|
|
|
|
grep 'CREATE DATABASE' $TMP_DIR/$SQL_FILE | awk '{ print $3 }' > $DB_FILE
|
2019-03-21 15:48:41 -04:00
|
|
|
else
|
2020-05-28 21:50:05 +00:00
|
|
|
# Error, cannot report the databases
|
|
|
|
echo "No SQL file found - cannot extract the databases"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
# Extract all tables of a database from an archive and put them in the requested
|
|
|
|
# file.
|
|
|
|
get_tables() {
|
|
|
|
DATABASE=$1
|
|
|
|
TMP_DIR=$2
|
|
|
|
TABLE_FILE=$3
|
|
|
|
|
|
|
|
SQL_FILE=postgres.$POSTGRESQL_POD_NAMESPACE.all.sql
|
|
|
|
if [[ -e $TMP_DIR/$SQL_FILE ]]; then
|
2020-06-03 22:27:57 +00:00
|
|
|
cat $TMP_DIR/$SQL_FILE | sed -n /'\\connect '$DATABASE/,/'\\connect'/p | grep "CREATE TABLE" | awk -F'[. ]' '{print $4}' > $TABLE_FILE
|
2020-05-28 21:50:05 +00:00
|
|
|
else
|
|
|
|
# Error, cannot report the tables
|
|
|
|
echo "No SQL file found - cannot extract the tables"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
# Extract all rows in the given table of a database from an archive and put them in the requested
|
|
|
|
# file.
|
|
|
|
get_rows() {
|
2020-06-03 22:27:57 +00:00
|
|
|
DATABASE=$1
|
|
|
|
TABLE=$2
|
2020-05-28 21:50:05 +00:00
|
|
|
TMP_DIR=$3
|
|
|
|
ROW_FILE=$4
|
|
|
|
|
|
|
|
SQL_FILE=postgres.$POSTGRESQL_POD_NAMESPACE.all.sql
|
|
|
|
if [[ -e $TMP_DIR/$SQL_FILE ]]; then
|
|
|
|
cat $TMP_DIR/$SQL_FILE | sed -n /'\\connect '${DATABASE}/,/'\\connect'/p > /tmp/db.sql
|
|
|
|
cat /tmp/db.sql | grep "INSERT INTO public.${TABLE} VALUES" > $ROW_FILE
|
|
|
|
rm /tmp/db.sql
|
|
|
|
else
|
|
|
|
# Error, cannot report the rows
|
|
|
|
echo "No SQL file found - cannot extract the rows"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
# Extract the schema for the given table in the given database belonging to the archive file
|
|
|
|
# found in the TMP_DIR.
|
|
|
|
get_schema() {
|
2020-06-03 22:27:57 +00:00
|
|
|
DATABASE=$1
|
|
|
|
TABLE=$2
|
2020-05-28 21:50:05 +00:00
|
|
|
TMP_DIR=$3
|
|
|
|
SCHEMA_FILE=$4
|
|
|
|
|
|
|
|
SQL_FILE=postgres.$POSTGRESQL_POD_NAMESPACE.all.sql
|
|
|
|
if [[ -e $TMP_DIR/$SQL_FILE ]]; then
|
|
|
|
DB_FILE=$(mktemp -p /tmp)
|
|
|
|
cat $TMP_DIR/$SQL_FILE | sed -n /'\\connect '${DATABASE}/,/'\\connect'/p > ${DB_FILE}
|
2020-06-03 22:27:57 +00:00
|
|
|
cat ${DB_FILE} | sed -n /'CREATE TABLE public.'${TABLE}' ('/,/'--'/p > ${SCHEMA_FILE}
|
2020-05-28 21:50:05 +00:00
|
|
|
cat ${DB_FILE} | sed -n /'CREATE SEQUENCE public.'${TABLE}/,/'--'/p >> ${SCHEMA_FILE}
|
|
|
|
cat ${DB_FILE} | sed -n /'ALTER TABLE public.'${TABLE}/,/'--'/p >> ${SCHEMA_FILE}
|
|
|
|
cat ${DB_FILE} | sed -n /'ALTER TABLE ONLY public.'${TABLE}/,/'--'/p >> ${SCHEMA_FILE}
|
|
|
|
cat ${DB_FILE} | sed -n /'ALTER SEQUENCE public.'${TABLE}/,/'--'/p >> ${SCHEMA_FILE}
|
|
|
|
cat ${DB_FILE} | sed -n /'SELECT pg_catalog.*public.'${TABLE}/,/'--'/p >> ${SCHEMA_FILE}
|
2020-06-03 22:27:57 +00:00
|
|
|
cat ${DB_FILE} | sed -n /'CREATE INDEX.*public.'${TABLE}' USING'/,/'--'/p >> ${SCHEMA_FILE}
|
|
|
|
cat ${DB_FILE} | sed -n /'GRANT.*public.'${TABLE}' TO'/,/'--'/p >> ${SCHEMA_FILE}
|
2020-05-28 21:50:05 +00:00
|
|
|
rm -f ${DB_FILE}
|
|
|
|
else
|
|
|
|
# Error, cannot report the rows
|
|
|
|
echo "No SQL file found - cannot extract the schema"
|
|
|
|
return 1
|
2019-03-21 15:48:41 -04:00
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
# Extract Single Database SQL Dump from pg_dumpall dump file
|
|
|
|
extract_single_db_dump() {
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
ARCHIVE=$1
|
|
|
|
DATABASE=$2
|
|
|
|
DIR=$3
|
|
|
|
sed -n '/\\connect'" ${DATABASE}/,/PostgreSQL database dump complete/p" ${ARCHIVE} > ${DIR}/${DATABASE}.sql
|
|
|
|
}
|
|
|
|
|
|
|
|
# Re-enable connections to a database
|
|
|
|
reenable_connections() {
|
|
|
|
SINGLE_DB_NAME=$1
|
|
|
|
|
|
|
|
# First make sure this is not the main postgres database or either of the
|
|
|
|
# two template databases that should not be touched.
|
|
|
|
if [[ ${SINGLE_DB_NAME} == "postgres" ||
|
|
|
|
${SINGLE_DB_NAME} == "template0" ||
|
|
|
|
${SINGLE_DB_NAME} == "template1" ]]; then
|
|
|
|
echo "Cannot re-enable connections on an postgres internal db ${SINGLE_DB_NAME}"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Re-enable connections to the DB
|
|
|
|
$PSQL -tc "UPDATE pg_database SET datallowconn = 'true' WHERE datname = '${SINGLE_DB_NAME}';" > /dev/null 2>&1
|
|
|
|
if [[ "$?" -ne 0 ]]; then
|
|
|
|
echo "Could not re-enable connections for database ${SINGLE_DB_NAME}"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
|
|
|
# Drop connections from a database
|
|
|
|
drop_connections() {
|
|
|
|
SINGLE_DB_NAME=$1
|
|
|
|
|
|
|
|
# First make sure this is not the main postgres database or either of the
|
|
|
|
# two template databases that should not be touched.
|
|
|
|
if [[ ${SINGLE_DB_NAME} == "postgres" ||
|
|
|
|
${SINGLE_DB_NAME} == "template0" ||
|
|
|
|
${SINGLE_DB_NAME} == "template1" ]]; then
|
|
|
|
echo "Cannot drop connections on an postgres internal db ${SINGLE_DB_NAME}"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
# First, prevent any new connections from happening on this database.
|
|
|
|
$PSQL -tc "UPDATE pg_database SET datallowconn = 'false' WHERE datname = '${SINGLE_DB_NAME}';" > /dev/null 2>&1
|
|
|
|
if [[ "$?" -ne 0 ]]; then
|
|
|
|
echo "Could not prevent new connections before restoring database ${SINGLE_DB_NAME}."
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Next, force disconnection of all clients currently connected to this database.
|
|
|
|
$PSQL -tc "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = '${SINGLE_DB_NAME}';" > /dev/null 2>&1
|
|
|
|
if [[ "$?" -ne 0 ]]; then
|
|
|
|
echo "Could not drop existing connections before restoring database ${SINGLE_DB_NAME}."
|
|
|
|
reenable_connections ${SINGLE_DB_NAME}
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
|
|
|
# Re-enable connections for all of the databases within Postgresql
|
|
|
|
reenable_connections_on_all_dbs() {
|
|
|
|
# Get a list of the databases
|
|
|
|
DB_LIST=$($PSQL -tc "\l" | grep "| postgres |" | awk '{print $1}')
|
|
|
|
|
|
|
|
RET=0
|
|
|
|
|
|
|
|
# Re-enable the connections for each of the databases.
|
|
|
|
for DB in $DB_LIST; do
|
|
|
|
if [[ ${DB} != "postgres" && ${DB} != "template0" && ${DB} != "template1" ]]; then
|
|
|
|
reenable_connections $DB
|
|
|
|
if [[ "$?" -ne 0 ]]; then
|
|
|
|
RET=1
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
|
|
|
|
return $RET
|
|
|
|
}
|
|
|
|
|
|
|
|
# Drop connections in all of the databases within Postgresql
|
|
|
|
drop_connections_on_all_dbs() {
|
|
|
|
# Get a list of the databases
|
|
|
|
DB_LIST=$($PSQL -tc "\l" | grep "| postgres |" | awk '{print $1}')
|
|
|
|
|
|
|
|
RET=0
|
|
|
|
|
|
|
|
# Drop the connections for each of the databases.
|
|
|
|
for DB in $DB_LIST; do
|
|
|
|
# Make sure this is not the main postgres database or either of the
|
|
|
|
# two template databases that should not be touched.
|
|
|
|
if [[ ${DB} != "postgres" && ${DB} != "template0" && ${DB} != "template1" ]]; then
|
|
|
|
drop_connections $DB
|
|
|
|
if [[ "$?" -ne 0 ]]; then
|
|
|
|
RET=1
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
|
|
|
|
# If there was a failure to drop any connections, go ahead and re-enable
|
|
|
|
# them all to prevent a lock-out condition
|
|
|
|
if [[ $RET -ne 0 ]]; then
|
|
|
|
reenable_connections_on_all_dbs
|
|
|
|
fi
|
|
|
|
|
|
|
|
return $RET
|
2019-04-09 12:55:44 -04:00
|
|
|
}
|
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
# Restore a single database dump from pg_dumpall sql dumpfile.
|
2019-03-21 15:48:41 -04:00
|
|
|
restore_single_db() {
|
2019-04-23 13:36:07 -05:00
|
|
|
SINGLE_DB_NAME=$1
|
2020-05-08 13:04:28 +00:00
|
|
|
TMP_DIR=$2
|
2019-04-23 13:36:07 -05:00
|
|
|
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
# Reset the logfile incase there was some older log there
|
|
|
|
rm -rf ${LOG_FILE}
|
|
|
|
touch ${LOG_FILE}
|
|
|
|
|
|
|
|
# First make sure this is not the main postgres database or either of the
|
|
|
|
# two template databases that should not be touched.
|
|
|
|
if [[ ${SINGLE_DB_NAME} == "postgres" ||
|
|
|
|
${SINGLE_DB_NAME} == "template0" ||
|
|
|
|
${SINGLE_DB_NAME} == "template1" ]]; then
|
|
|
|
echo "Cannot restore an postgres internal db ${SINGLE_DB_NAME}"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2019-04-23 13:36:07 -05:00
|
|
|
SQL_FILE=postgres.$POSTGRESQL_POD_NAMESPACE.all.sql
|
2020-05-08 13:04:28 +00:00
|
|
|
if [[ -f $TMP_DIR/$SQL_FILE ]]; then
|
|
|
|
extract_single_db_dump $TMP_DIR/$SQL_FILE $SINGLE_DB_NAME $TMP_DIR
|
|
|
|
if [[ -f $TMP_DIR/$SINGLE_DB_NAME.sql && -s $TMP_DIR/$SINGLE_DB_NAME.sql ]]; then
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
# Drop connections first
|
|
|
|
drop_connections ${SINGLE_DB_NAME}
|
|
|
|
if [[ "$?" -ne 0 ]]; then
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Next, drop the database
|
2020-06-03 22:27:57 +00:00
|
|
|
$PSQL -tc "DROP DATABASE $SINGLE_DB_NAME;"
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
if [[ "$?" -ne 0 ]]; then
|
|
|
|
echo "Could not drop the old ${SINGLE_DB_NAME} database before restoring it."
|
|
|
|
reenable_connections ${SINGLE_DB_NAME}
|
|
|
|
return 1
|
|
|
|
fi
|
2020-06-03 22:27:57 +00:00
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
# Postgresql does not have the concept of creating database if condition.
|
|
|
|
# This next command creates the database in case it does not exist.
|
|
|
|
$PSQL -tc "SELECT 1 FROM pg_database WHERE datname = '$SINGLE_DB_NAME'" | grep -q 1 || \
|
|
|
|
$PSQL -c "CREATE DATABASE $SINGLE_DB_NAME"
|
|
|
|
if [[ "$?" -ne 0 ]]; then
|
|
|
|
echo "Could not create the single database being restored: ${SINGLE_DB_NAME}."
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
reenable_connections ${SINGLE_DB_NAME}
|
2020-05-08 13:04:28 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
$PSQL -d $SINGLE_DB_NAME -f ${TMP_DIR}/${SINGLE_DB_NAME}.sql 2>>$LOG_FILE >> $LOG_FILE
|
|
|
|
if [[ "$?" -eq 0 ]]; then
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
if grep "ERROR:" ${LOG_FILE} > /dev/null 2>&1; then
|
|
|
|
cat $LOG_FILE
|
|
|
|
echo "Errors occurred during the restore of database ${SINGLE_DB_NAME}"
|
|
|
|
reenable_connections ${SINGLE_DB_NAME}
|
|
|
|
return 1
|
|
|
|
else
|
|
|
|
echo "Database restore Successful."
|
|
|
|
fi
|
2019-03-21 15:48:41 -04:00
|
|
|
else
|
2020-06-03 22:27:57 +00:00
|
|
|
# Dump out the log file for debugging
|
|
|
|
cat $LOG_FILE
|
|
|
|
echo -e "\nDatabase restore Failed."
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
reenable_connections ${SINGLE_DB_NAME}
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Re-enable connections to the DB
|
|
|
|
reenable_connections ${SINGLE_DB_NAME}
|
|
|
|
if [[ "$?" -ne 0 ]]; then
|
2020-05-08 13:04:28 +00:00
|
|
|
return 1
|
2019-03-21 15:48:41 -04:00
|
|
|
fi
|
|
|
|
else
|
2020-05-08 13:04:28 +00:00
|
|
|
echo "Database dump For $SINGLE_DB_NAME is empty or not available."
|
|
|
|
return 1
|
2019-03-21 15:48:41 -04:00
|
|
|
fi
|
|
|
|
else
|
2020-05-08 13:04:28 +00:00
|
|
|
echo "No database file available to restore from."
|
|
|
|
return 1
|
2019-03-21 15:48:41 -04:00
|
|
|
fi
|
2020-05-08 13:04:28 +00:00
|
|
|
return 0
|
2019-03-21 15:48:41 -04:00
|
|
|
}
|
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
# Restore all the databases from the pg_dumpall sql file.
|
2019-03-21 15:48:41 -04:00
|
|
|
restore_all_dbs() {
|
2020-05-08 13:04:28 +00:00
|
|
|
TMP_DIR=$1
|
|
|
|
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
# Reset the logfile incase there was some older log there
|
|
|
|
rm -rf ${LOG_FILE}
|
|
|
|
touch ${LOG_FILE}
|
|
|
|
|
2019-04-23 13:36:07 -05:00
|
|
|
SQL_FILE=postgres.$POSTGRESQL_POD_NAMESPACE.all.sql
|
2020-05-08 13:04:28 +00:00
|
|
|
if [[ -f $TMP_DIR/$SQL_FILE ]]; then
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
# First drop all connections on all databases
|
|
|
|
drop_connections_on_all_dbs
|
|
|
|
if [[ "$?" -ne 0 ]]; then
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
$PSQL postgres -f $TMP_DIR/$SQL_FILE 2>>$LOG_FILE >> $LOG_FILE
|
|
|
|
if [[ "$?" -eq 0 ]]; then
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
if grep "ERROR:" ${LOG_FILE} > /dev/null 2>&1; then
|
|
|
|
cat ${LOG_FILE}
|
|
|
|
echo "Errors occurred during the restore of the databases."
|
|
|
|
reenable_connections_on_all_dbs
|
|
|
|
return 1
|
|
|
|
else
|
|
|
|
echo "Database Restore Successful."
|
|
|
|
fi
|
2019-03-21 15:48:41 -04:00
|
|
|
else
|
2020-06-03 22:27:57 +00:00
|
|
|
# Dump out the log file for debugging
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
cat ${LOG_FILE}
|
2020-06-03 22:27:57 +00:00
|
|
|
echo -e "\nDatabase Restore failed."
|
Fix drop databases issue in Postgresql restore
Recently, the Postgresql backups were modified to generate drop database
commands (--clean pgdumpall option). Also for single database restore,
a DROP DATABASE command was added before the restore so that the
database could be restored without duplicate rows. However, if there are
existing database connections (by the applications or other users), then
the drop database commands will fail. So for the duration of the restore
database operation, the databases being restored need to have their
existing connections dropped and new connections prevented until the
database(s) restored, then connections should be re-allowed.
Also found a problem with psql returning 0 (success code) even though
there were errors during its execution. The solution is to check the
output for errors and if there are any, dump out the log file for the
user to see and let the user know there are errors.
Lastly, a problem was found with the single database restortion, where
the database dump for a single database was being incorrectly extracted
from the psql dump file, resulting in the database not being restored
correctly (most of the db being wiped out). This patchset fixes that
issue as well.
Change-Id: I4db3f6ac7e9fe7cce6a432dfba056e17ad1e3f06
2020-06-29 18:16:41 +00:00
|
|
|
reenable_connections_on_all_dbs
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Re-enable connections on all databases
|
|
|
|
reenable_connections_on_all_dbs
|
|
|
|
if [[ "$?" -ne 0 ]]; then
|
2020-05-08 13:04:28 +00:00
|
|
|
return 1
|
2019-03-21 15:48:41 -04:00
|
|
|
fi
|
|
|
|
else
|
2020-05-08 13:04:28 +00:00
|
|
|
echo "There is no database file available to restore from."
|
|
|
|
return 1
|
2019-04-23 13:36:07 -05:00
|
|
|
fi
|
2020-05-08 13:04:28 +00:00
|
|
|
return 0
|
2019-03-21 15:48:41 -04:00
|
|
|
}
|
|
|
|
|
2020-05-08 13:04:28 +00:00
|
|
|
# Call the CLI interpreter, providing the archive directory path and the
|
|
|
|
# user arguments passed in
|
|
|
|
cli_main ${ARGS[@]}
|