From: | Ekaterina Amez Gonzalez <registrosekaterina(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Streaming replication problem with collation |
Date: | 2024-12-20 10:06:29 |
Message-ID: | CAC5zuTqssvYehaG3maYNeWYmvURN+h5xG7KiOoSeYtQKhCLV_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi List,
I'm making some tests in order to prepare a db migration. We have version
9.6 over CentOS 7 and we're going to migrate to version 15 over Rocky Linux
9. Of course there is a no downtime requirement or I wouldn't be here
asking.
I was previously aware of the problem with different glibc version between
systems before I started my tests, but I tried it anyway. I first upgraded
CentOS version to 15 and then made a streaming replication to the other
server (Rocky). After that I encountered the next warning when connecting
to new hot standby database:
WARNING: database my_db has a collation version mismatch
DETAIL: The database was created using collation version 2.17, but the
operating system provides version 2.34.
HINT: Rebuild all objects in this database that use the default collation
and run ALTER DATABASE my_db REFRESH COLLATION VERSION, or build PostgreSQL
with the right library version.
I tried what was suggested: reindexing and running "refresh collation"
alter after that and everything seems to work ok so this looks like an easy
wat to migrate from one server to another. Plus I feel more comfortable
using streaming replication than logical replication, and also I find it
more useful when you need to replicate the whole cluster.
So my question is: is there anything I'm missing here, some kind of problem
that could hit my face after moving to the new server?
Thanks in advance,
Ekaterina
From | Date | Subject | |
---|---|---|---|
Next Message | Mukesh Tanuku | 2024-12-20 10:19:16 | pgpool Connection issue: ERROR: unable to read message kind |
Previous Message | Achilleas Mantzios - cloud | 2024-12-20 08:35:01 | Re: Clusters and shared permissions using LDAP |