-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement automated PGSQL DB migration. #63
base: main
Are you sure you want to change the base?
Conversation
@yakutovicha I am a bit confused here. I believe that @unkcpz mentioned that |
Maybe I missed that part, sorry. For the moment aiida-core images are still based on aiida-prerequisites. We will at some point replace them, but we haven't agreed on the strategy yet. Anyways, I am going to implement the migration here and then we port it elsewhere. |
Co-authored-by: Daniel Hollas <danekhollas@gmail.com>
* Use pg_dumpall to dump the whole server. * Automatically determine the old and the new DB version. * Copy the migration script to the /opt folder.
@@ -29,6 +29,11 @@ else | |||
if ! $running ; then | |||
echo "" > /home/${SYSTEM_USER}/.postgresql/logfile # empty log files | |||
rm -vf /home/${SYSTEM_USER}/.postgresql/postmaster.pid | |||
${PSQL_START_CMD} | |||
${PSQL_START_CMD} || cant_start=true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As @danielhollas suggested, we should distinguish the "migration required" case from other failures and properly handle it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @yakutovicha,
Thanks for doing this annoying work. Just a couple of quick comments. I don't think I'll have time for a more thorough review, unfortunately.
# This script is intended to be run in a container. Its job is to migrate the PGSQL database to a newer version. | ||
|
||
# The following variables are required: | ||
DB_FOLDER=/home/${SYSTEM_USER}/.postgresql |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just noting for future reference that in the new AiiDAlab docker stack we use ${NB_USER}
# Part 1: dump the old database. | ||
|
||
# Make a backup of the database. | ||
mv ${DB_FOLDER} ${BACKUP_DB_FOLDER} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where would this script show it's output?
I would put an echo here to show where the backup is
(although when the script is executed in the debug mode (set -x
), each command is echoed, so I guess and extra echo make it a bit more clear what is happening)
mv ${DB_FOLDER} ${BACKUP_DB_FOLDER} | |
echo "Creating a DB backup to ${BACKUP_DB_FOLDER}" | |
mv ${DB_FOLDER} ${BACKUP_DB_FOLDER} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we can retrieve the debug information, yes, I agree it is more clear to print this massage. But I don't know where to check these printed-out messages. Is it write to some log files?
@@ -93,7 +93,7 @@ RUN cd /tmp && \ | |||
conda clean --all -f -y | |||
|
|||
# Install PostgreSQL in a dedicated conda environment. | |||
RUN conda create -c conda-forge -n pgsql postgresql=10 && conda clean --all -f -y | |||
RUN conda create -c conda-forge -n pgsql postgresql=12 && conda clean --all -f -y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason why not jump straight to version 14? (just asking, I think it is probably better to do it incrementally)
fi | ||
|
||
# Start the old version of PostgreSQL. | ||
conda run -n ${OLD_DB_CONDA_ENV_NAME} pg_ctl -D ${BACKUP_DB_FOLDER} -l ${BACKUP_DB_FOLDER}/logfile start |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the ${BACKUP_DB_FOLDER}
for this makes me a bit nervous, I don't think we should touch it at all during the migration. But perhaps I am misunderstanding....
conda run -n ${OLD_DB_CONDA_ENV_NAME} pg_ctl -D ${BACKUP_DB_FOLDER} -l ${BACKUP_DB_FOLDER}/logfile start | |
conda run -n ${OLD_DB_CONDA_ENV_NAME} pg_ctl -D ${DB_FOLDER} -l ${DB_FOLDER}/logfile start |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never mind, I misunderstood how the backup folder works.
conda run -n ${OLD_DB_CONDA_ENV_NAME} pg_ctl -D ${BACKUP_DB_FOLDER} stop | ||
|
||
# Delete the environment with old version of PostgreSQL. | ||
conda env remove -n ${OLD_DB_CONDA_ENV_NAME} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this command be run only at the very and once we're sure the migration was successfull. Otherwise might be good to keep around for debugging?
I test using
I check the psql version and it is all correct as expected. However,
I did anything wrong? How I confirm the migrate script is executed and the database is successfully migrated? |
As mentioned by @yakutovicha in the meeting, the migration script needs to be run by hand. I manually trigger the migration and it seems failed at last step with:
|
@unkcpz I am wondering if the error that you so could simply be ignored (e.g. user aiida already exist, never mind). Per |
fixes #41
TODO: