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.
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'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.
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.
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.
I want to make a script that will run postgres in-memory without durability.
I read this page: http://www.postgresql.org/docs/9.1/static/non-durability.html
But I didn't understand how I can set this parameters in script. Could you please, help me?
Thanks for help!
Most of those parameters, like fsync, can only be set in postgresql.conf. Changes are applied by re-starting PostgreSQL. They apply to the whole database cluster - all the databases in that PostgreSQL install. That's because the databases all share a single postmaster, write-ahead log, and set of shared system tables.
The only parameter listed there that you can set at the SQL level in a script is synchronous_commit. By setting synchronous_commit = 'off' you can say "it's OK to lose this transaction if the database crashes in the next few seconds, just make sure it still applies atomically".
I wrote more on this topic in a previous answer, Optimise PostgreSQL for fast testing.
If you want to set the other params with a script you can do so but you have to do it by opening and modifying postgresql.conf using the script, then re-starting PostgreSQL. Text-processing tools like sed make this kind of job easier.
If you're running a debian based linux distro, you can just do something like:
pg_createcluster -d /dev/shm/mypgcluster 8.4 ramcluster
to create a ram based cluster. Note that you'll have to do:
pg_drop cluster 8.4 ramcluster
and recreate it on reboot etc.