I know it isn't ideal, but I'm wondering if there are any limitations preventing me from having a downstream replica be on Ubuntu (xenial), while its upstream replica is on CentOS?
I've got postgresql installed on the Ubuntu box and plan to set the $PGDATA dir and all of those settings the same as the CentOS boxes.
I'm just curious of anyone has tried this and run into any snags.
In principle that would work as long as both Linuxen are running on the same architecture. But read this mailing list post for an example of what can go wrong:
PostgreSQL uses the operating system's collations for ordering indexes, and if the two versions of glibc installed on both machines have a different idea of how to order strings, the indexes on string columns will be corrupted on the standby.
So if you need to replicate across distributions, make sure that one of the following applies:
You are using the C collation.
All indexes on string columns in your database are using the text_pattern_ops operator class.
You have the same version of glibc on both machines.
Related
I would like to switch from postgres 9.6 to version 14 which runs on Ubuntu 21.04. I have a cluster with 3 databases.
I would like to know what is the difference between upgrading with pg_upgrade and pg_upgradecluster? Which one is faster and safer?
pg_upgrade is a tool from Postgresql itself that will operate on a single database (folder).
pg_upgradecluster however is a wrapper from your operating system (= Ubuntu) to pg_upgrade or pg_dump/pg_restore. In addition to very conveniently upgrading your database, it will also do some housekeeping like moving the config files to the correct folder in /etc/postgres/ .
So, if you have set up your database by pg_createcluster and it is hence listed by pg_lsclusters, I'd strongly recommend using pg_upgradecluster to upgrade it.
In terms of "faster vs. safer", be sure to read about the various options on the manpage.
If you can take a reliable backup (e.g. snapshot), you can safely use the -m upgrade --link option which will be fastest and allow for a very short downtime (depending on database size and resources, but I've recently upgraded a 700GB database in ~25 seconds).
The safest option of course is not using pg_upgrade, but the default pg_dump/pg_restore method, which will shut down your original database and copy the data to a new database in a new location (= it will use at approx. twice the space, at least temporarily until you decide to delete the original folder).
I have postgres 9.5 database with one master and two replicas. My project is on c++.
To check if master instance is available I run mock query. Is there more convenient way to do this?
UPD: I know about instruments which can be used in terminal such as systemctl and pg_isready, but they are not applicable to use from c++ project
We use repmgr to keep an eye on all clusters and to manage the primary and secondary databases.
But version 9.5, are you sure? That's EOL for a pretty long time. Plan a move to version 14.
I'm trying to upgrade my postgres database from 9.6 to 10 without any downtime. Can this be done?
As "a_horse_with_no_name" mentioned logical replication is a very good choice in your situation.
Only problem is 9.6 does not have internal implementation yet so you would have to use extension "pglogical" on both DB - here I found some description - https://rosenfeld.herokuapp.com/en/articles/infrastructure/2017-11-10-upgrading-postgresql-from-9-6-to-10-with-minimal-downtime-using-pglogical - skip parts about Docker and see how pglogical works.
The only slight problem is pglogical must be added into "shared_preload_libraries" parameter and postgresql service must be restarted which can be sometimes difficult on production...
I did quite a lot of tests with pglogical (here are some notes - http://postgresql.freeideas.cz/pglogical-postgresql-9-6-small-hints-debian/) although at the end I never used pglogical on production. So I do not have experiences from long usage.
But I presume some problems can be similar to the internal implementation of logical replication in PG 10 and 11. So here are my notes from my current usage of internal logical replication on PG 11 - http://postgresql.freeideas.cz/setting-logical-replication-is-not-entirely-straight-forward/ - maybe something from it would help you.
My recommendation for you would be:
make a hot backup copy of your PG 9.6 database on some other machine on cloud VM with exactly the same OS and if possible disks types and configuration using pg_basebackup - you can find some inspiration here:
http://postgresql.freeideas.cz/pg_basebackup-bash-script-backup-archiving-google-storage/
http://postgresql.freeideas.cz/pg_basebackup-experiences/
or if you already use pg_basebackup for tar backups of your db restore latest backup on other machine or VM (http://postgresql.freeideas.cz/pg_basebackup-pgbarman-restore-tar-backup/)
start is as normal server (not as hot standby) and test pglogical on this copy of your DB against some testing installation of PG 10 - test it as close to the production environment as possible including at least simulated DML operations of similar intensity - this will show you differences in load on machine / VM.
I highly recommend to set monitoring for example using telegraf + influxdb + Grafana (easiest implementation by my opinion) to be able to analyze CPU and memory usage later - this can be very crucial part for usage on production !
after hopefully short and successful tests implement it and celebrate your success :-) and please write about you experiences. Because I believe a lot of people would welcome it.
How to configure clustering (active/active) in PostgreSQL 9.1 ? My current configurations are listed below:
RAM : 8Gb,
O.S : Ubuntu 12.04 LTS,
CPU : 4
If you are looking for a multimaster PostgreSQL solution (one where you can modify data on either node, and the modification is replicated to the other node), there is no built-in solution yet.
You can use extensions like 2ndQuadrant's BDR (but that requires a modified PostgreSQL server) or proprietary solutions like EnterpriseDB's xDB Replication Server.
There is also the open source fork Postgres-XL which provides a different solution.
You can use open-source database sync software symmetricDS for PostgreSQL Active Active replication setup.
There's also SymmetricDS, an open source product that allows you to configure your Postgres instances in an active/active configuration.
A good guide on how to do this can be found here.
Try configure native Bi-Direction (synchronous) replication between two postgresql 9.5 beta 2.
OS Ubuntu 14.04
Googled many documents and blogs, but still dont understand how can I configure postgresql.conf to start Bi-Direction replication
Any sample please.
You can't, because there is no built-in support for bidirectional replication in PostgreSQL 9.5.
The BDR project is an effort to develop mesh multimaster logical replication. It is based on 9.4. There is no plan to support 9.5; we intend to skip straight to 9.6 when it is released, and stay on 9.4 in the mean time.
There are external trigger-based tools that do multi-master for PostgreSQL 9.5, like Londiste and Bucardo.
There's also Postgres-XL for full tightly-coupled multi-master but it hasn't been updated to 9.5 yet, and it's a separate modified PostgreSQL, not an add-on.
pglogical, which is derived from BDR, will hopefully provide full multimaster in future, but that's more like 9.6 timeframe.