We are taking daily backup using pg_basebackup.
from two days ago it has been failing. we are using standalone environment.
error details
pg_basebackup: error: FATAL: number of requested standby connections exceeds max_wal_senders (currently 10)
FATAL: number of requested standby connections exceeds max_wal_senders (currently 10)
There are already too many replication connections to that database. Either terminate some, or increase max_wal_senders and restart PostgreSQL.
I would query pg_stat_activity to find the offending connections and use pg_terminate_backend to terminate them
You should extend your max_wal_replication slots in postgresql.conf. Here is a code to perform this change in linux terminal:
sed -i "s/max_replication_slots = 10/max_replication_slots = 20/g" postgresql.conf
Related
After 10 connections to a Postgres RDS database I start getting error - Too Many Connections or Timed-out waiting to acquire database connection.
But when I check max_connections it shows 405. pg_roles shows -1 as rollconnlimit. If none of the ceilings are hit why can I not have more than 10 concurrent connections for that user?
A comment from #jjanes on another question gave me a pointer.. the bottleneck was datconnlimit setting from pg_database. Changing it using query below fixed the issue:-
ALTER DATABASE mydb with CONNECTION LIMIT 50
I have a master\server setup with pgpool and postgres 9.5. Both servers are running on centOS7.
I wanted to setup a point in time recovery with base backups every saturday, eliminating the old xlogs.
The server is archiving the xlogs with success on a external filesystem.
But when I try to execute the basebackup command it gives the following error:
pg_basebackup: could not connect to server: FATAL: database "replication" does not exist.
You seems to be missing the explicit HBA record for replication database, because specifying all does not covers the replication connections
host replication postgres 127.0.0.1/0 trust
The value replication specifies that the record matches if a
replication connection is requested (note that replication connections
do not specify any particular database). Otherwise, this is the name
of a specific PostgreSQL database.
We have PostgreSQL 9.1.3 running on (SUSE Linux) 4.3.4 - 64 bit. There is a master slave set up and a streaming replication has been set up between the two. We have a cron job set up which runs the VACUUM command on the master database every Friday. My observation is that replication breaks withing half an hour from the time VACUUM job was run.
Ther error in the postgres logs on slave is
FATAL: could not receive data from WAL stream: FATAL: requested WAL segment 00000003000013500000001A has already been removed
Could you please help me understand the relation between the two and how can I prevent replication from breaking.
Please note I am a novice in Postgres.
I have tried to do database replication in linux 7.0 red hat using postgresql.
I refered this URL for Confuring http://blog.terminal.com/postgresql-replication-and-backup-methods/ I completed the the steps upto this step
Configuring the slave server
but the step
Initial replication
when I executed this command in Master
-bash-4.2$ psql -c "select pg_start_backup('initial_backup');"
I got Error Like this
ERROR: WAL level not sufficient for making an online backup
HINT: wal_level must be set to "archive" or "hot_standby" at server start.
So kindly let me know where we are wrong.
On your master PostgreSQL server's configuration file <PG_DATA>/postgresql.conf there is parameter called wal_level it should be set to either "archive" or "hot_standby"
Both said to postgres to keep WAL segmetnts for replication server. The difference between the two is rather simple:
"hot_standby" means that your replication server will allow connections for SELECT statements
"archive" means you don't want that possibility.
More to read in this tutorial on streaming replication
Also keep in mind that change of wal_level property needs server restart to take an effect.
I'm using pgAdmin III to manage my database from client. I have a master and a slave postgreSQL running in streaming replication mode. There's another pgpool server in front of them to do connection pooling and load-balancing.
When I was connection pgAdmin to pgpool, I got:
Error connecting to the server: ERROR: unable to read message kind
DETAIL: kind does not match between master(52) slot[1] (45)
I had no problem connecting to it before, but somehow pgpool died and I restarted it, and then this error popped up out of no where.
The pgpool and postgreSQL servers are running well. I can access them with psql -h hostname database user. The app server can also connect to it and the web app is running as usually. I just cannot access it from pgAdmin.
http://www.sraoss.jp/pipermail/pgpool-general/2012-March/000297.html
In short: max_connections is exceeded on postgres cluster.
What I assume has happened - you restarted pgpool and it opened new connections to postgres, while old ones left in idle or idle in transaction (depending on timeout). So after restarting pgpool it consumed double amount of num_init_children and reached actual allowed maximum.
Killing old (before restart) pgpool connections should fix it. Try pg_terminate_backend(pid) run on postgres in order to do it. Also be carefull to kill right connections. At least check
select pid,query, client_address
from pg_stat_activity where now()-query_start > '1 day'::interval
or alike to catch only zombies