OK, after making that change and confirming that the backup directory is located on the server that is running the pod, I get an issue with restoring for this failed task:
TASK: Restore database_dump to the new postgresql container
OK, after making that change and confirming that the backup directory is located on the server that is running the pod, I get an issue with restoring for this failed task:
TASK: Restore database_dump to the new postgresql container
Make some investigations on your side; adding no_log: false
to your AWXRestore
may help you
I added the no_log: false parameter to the spec file. It looks like the job is failing because password authentication fails to database ‘awx’ for user ‘awx’.
I am not understanding how this could be. I thought these values are part of the backup from the old cluster. How can this happen?
Have you confirmed that your PV for your PSQL on the new cluster is empty before restoring?
I read you question but I am confused. How can you do what you are suggesting? I think we have a different understanding from each other but I am trying to understand your way, which will be the correct way!
I thought that AWX needed to be running. How is this possible without PV and PVC?
Also, I see the documentation says:
postgres-<postgres version>-
Is this what you mean?
Okay, let me explain…
A new PSQL will be created by the restore, and this PSQL should use the /var/lib/postgresql/data
of the one of the nodes of the new cluster via PVC.
If, you already have previously attempted to deploy AWX on the new cluster, there may still be data created by PSQL from that time in /var/lib/postgresql/data
on your nodes.
The AWX Operator does not reset the PSQL password during restoration, nor deletes old data before the restore. Additionally, even if you delete old PVs or PVCs, the actual contents on the directory on your nodes will not be automatically removed.
So, a new PSQL will be created by the restore, but if there is already old data created by PSQL in the PV, the new PSQL may start up using the old data, leading to a potential mismatch in the password.
OK, it took me a moment to digest what I needed to do but I got it to work!
I can simply delete the contents of the DB at the Postgres PV/PVC path on the node where it is running.
cd /var/lib/postgres/data/data/pgdata
rm -rf *
So here is the overall sequence that should happen:
It’s not required at all, but it’s okay if it works anyway
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.