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.
Related
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.
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 would like to save a bourne shell script in /etc/cron.* on vCenter server virtual appliance 5.5 to backup the vpostgres (VMware vCenter postgresql database).
VMware knowledge base article 2034505 recommend stopping vpxd service before backing up.
I suppose to prevent backing up the database in an inconsistent state (while vcenter operations are running).
However the official PostgreSQL documentation precises :
<<3.Perform the backup, using any convenient file-system-backup tool such as tar or cpio (not pg_dump or pg_dumpall). It is neither necessary nor desirable to stop normal operation of the database while you do this.>>
My questions are:
Do I need to stop VMWare Composer and vpxd services prior to backing up the DB ?
If not can I use cpio to back it up without stopping the services ? how ?
PostgreSQL or VMware experts answers preferred please.
You may notice that this script does not stop VPXD services for backing up the database. It is because the official PostgreSQL documentation precises : “pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently“.
https://web.archive.org/web/20160122054619/http://bidabe.zapto.org/?p=360