We switched over to using timescaledb on db-datanommer02 and it's live and doing ok.
However, we should back up it's database before we nuke the old db-datanommer01.
I tried to just run the backup db script on it, but it couldn't talk to the socket.
I'm afraid I don't know much about timescaledb, I guess it mostly looks like postgres?
@abompard might you have a few cycles to look at this and get the backup-dbs script running on it so we can save off backups of it's database?
Metadata Update from @zlopez: - Issue priority set to: Waiting on External (was: Needs Review) - Issue tagged with: medium-gain, medium-trouble, ops
[backlog refinement] Still needs some explanation from @abompard
Metadata Update from @abompard: - Issue assigned to abompard
Alright, I found the reason: there was an incorrect selinux label on the socket directory, preventing postgresql from creating it.
# ls -l /var/run/postgresql/.s.PGSQL.5432 ls: cannot access '/var/run/postgresql/.s.PGSQL.5432': No such file or directory # restorecon -v /var/run/postgresql/ Relabeled /run/postgresql from unconfined_u:object_r:var_run_t:s0 to unconfined_u:object_r:postgresql_var_run_t:s0 # systemctl restart postgresql # ls -l /var/run/postgresql/.s.PGSQL.5432 srwxrwxrwx. 1 postgres postgres 0 May 23 10:14 /var/run/postgresql/.s.PGSQL.5432
And now the backup script works. I've just had to adjust the database name because it's named datanommer2 and not just datanommer (I've changed this in ansible too).
datanommer2
datanommer
Metadata Update from @abompard: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.