I am new in using pgbouncer 1.7 and I want to configure it with master slave configuration.
I have configured postgres 9.3 streaming replication using repmgr and I want to use pgbouncer for load balancing and connection pooling so that it automatically switches to slave if master goes down . So how should I configure it for the same. I have both master and slave on diff servers and og bouncer on diff servers. Do i need to install pgbouncer on both master and slave servers also for it to work or just installing on a diff server will work .
I have tried many online tutorial for it but sadly didnt found any suggestions. Please if anyone can help.
Thanks in advance,
Mohit
PgBouncer does not have automatic failover, propagation and ex-master rebuild handling. You can change IP for same hostname to failover though:
https://pgbouncer.github.io/faq.html
How to failover
PgBouncer does not have internal failover-host configuration nor detection. It is possible via some external tools:
DNS reconfiguration - when ip behind DNS name is reconfigured, pgbouncer will reconnect to new server. This behaviour can be tuned
via 2 config parameters - dns_max_ttl tunes lifetime for one hostname,
and dns_zone_check_period tunes how often zone SOA will be queried for
changes. If zone SOA record has changed, pgbouncer will re-query all
hostnames under that zone.
Write new host to config and let PgBouncer reload it - send SIGHUP or use RELOAD; command on console. PgBouncer will detect changed host
config and reconnect to new server.
Pgpool has automatic failover if you wnat to try.
Related
I have a cluster of master/slave PostgreSQL replication. I am looking for some kind of application that will proxy all the traffic to the master server. In case of fail-over when slave becomes master, I need that software to auto detect the new master. Currently I am using pgpool II, but it has no ability to auto detect which back-end is master. I mean I need to manually change backend1 (slave) to be backend0 (master) in case of master failure.
Please advice.
This requires considerable setup and is described in detail in chapter 8 of the pgpool 2 documentation.
I have 2 PostgreSQL servers and I have set up streaming replication between them.
I have built a shell script which will ping to master server every minute and will promote the slave as master when master won't respond. I am using rh-postgresql95 and 3rd party tools are not working with this version.
My JDBC connection string has comma separated nodes with targetServerType=master like below
jdbc:postgresql://node1,node2/accounting?targetServerType=master.
I just want to know how can I avoid split brain scenario if the slave is promoted to master and old master also comes up somehow?
or
Is there anyway so that old master never comes up automatically?
EDIT
node1 is master and node2 is the slave in my JDBC connection string.
I stopped postgres service on master and promoted the slave to New Master. In this case, service was pointing to the new master.
Then I restarted postgres service on old master and service started pointing to the old master(node1 is old master's ip and it comes first in JDBC connection string.).
So, I didn't get split brain issue, but this scenario will lead to a data inconsistency.
As an idea, your ping script could check if both servers think they are masters:
select pg_is_in_recovery();
A server that is not in recovery is a master. Then you could check the last received WAL's number:
select pg_last_wal_receive_lsn();
The server with the highest LSN is the server that was promoted last. You could then shut down the other server.
If you change your mind about third party options, have a look at the PostgresSQL wiki.
I have pgpool-II for HA and repmgr for automatic failover. Pgpool-II also can also run failover I am just wondering doing automatic failover using pgpool or repmgr? If pgpool can do the failover do I need to use repmgr? and use shell scripts to the promotion of new master?
I want to do the automatic failover via repmgrd and use pgpool only as entry point for the applications. It almost works: I have set the failover_command in pgpool configuration file to an empty string (''). When the primary database fails pgpool executes the failover_command (which does nothing because failover_command is empty), and then it will repeatedly try to find a new master. When repmgrd has done the failover, then pgpool see the new master and it is fine.
If the master is stopped, repmgrd will do the failover after x seconds (depending on reconnect interval and attemps parameters). You have to make sure that the health check interval specified in pgpool is bigger than that otherwise pgpool will detach the stopped database too early : the parameters are health_chek_max_retries and health_check_retry_delay (there is also health_check_period which is not clear). You must also set failover_on_backend_error to no.
I am not very confident in this set-up though, I still need to test it more intensively.
pgpool-II: Connection Pooling, Load Balancing, Automated failover, Limiting Exceeding Connections
In pgpool virtual IP is their application connect to VIP( a delegated_ip parameter on pgpool. conf file) primary goes down then failover happens standby promote to primary ( automatic failover )then there are no-changes on application end.
failover_command to write a script then configure the failover.sh script location on pgpool.conf file failover_command="" parameter
repmgr: replication and failover
In Repmgr If the primary is stopped, it will do the failover after xx seconds (depending on reconnecting interval connect_timeout parameter on /etc/repmgr.conf
I am running two databases (PostgreSQL 9.5.7) in a master/slave setup. My application is connecting to a pgpool instance which routes to the master database (and slave for read only queries).
Now I am trying to scale out some data to another read-only database instance containing only a few tables.
This works perfectly using pglogical directly on the master database.
However if the master transitions to slave for some reason, pglogical can't replicate any longer because the node is in standby.
Tried following things:
subscribed on the slave since it's less likely to go down, or overheated: Can't replicate on standby node.
subscribed via pgpool server: pgpool doesn't accept replication connections.
subscribed to both servers: pglogical config gets replicated along, so can't give them different node names.
The only thing I can think of now is to write my own tcp proxy which regularly checks for the state of the server to which I can subscribe to.
Is there any other/easier way I can solve this ?
Am I using the wrong tools perhaps ?
Ok so it seems that there are no solutions for this problem just yet.
Since the data in my logically replicated database is not changing fast, there is no harm if the replication stops for a moment.
Actions on failover could be:
Re-subscribe to the promoted master.
or promote standby node back to master after failover.
PostgreSql 9.1 has master-slave synchronous replication. Suppose the master is machine A and the slave is machine B.
If the master fails, how does PostgreSQL know when to make the slave the master? What if the slave incorrectly thought the master was down because of a temporary network glitch on the master where the client program could still contact the master though.
And moreover, how would my client program know the slave in the new master and more importantly is ready to accept writes. Does the slave send a message to the client?
Check repmgr, it's one of its jobs is to deal with this issue.
Typically you want to use a promotion-management system like repmgr or patroni. Then you want to use some sort of a high availability proxy (could be pgbouncer or haproxy) to handle the actual abstraction so your applications do not need to know what system is master.
In answer to your question, most of these systems use a heartbeat to determine if there is a problem. Patroni goes out over the etcd heartbeat. Repmgr has its own heartbeat check. With Repmgr you need to write hook scripts to take care of stonith, and so forth.