I run a Glassfish app server (3.1.2) with a JDBC pool connecting to 1 DB instance.
Now I created a replication setup with a second DB node. I like to loadbalance the DB by allowing read access to the replication slave.
Can I do this by GF configuration or does my application implementation need to take care of this ?
Thanks for any light
Sven
PgBouncer PgBouncer Wiki does this job.
You still connect to 1 DB IP (the pgbouncer instance) and it will handle the Postgres Side with 2 or more DB instances.
Related
I have PostgreSQL 12, pgbouncer, and Geoserver 2.21.0 running on my Ubuntu 20.04 Virtual Machine (VM). Postgres is behind pgbouncer (connection pooling) and pgbouncer.ini, among other things, specifies the max number of connections, idle timeouts, etc.
I have also connected Geoserver to the postgres via pgbouncer. Since geoserver also has an internal connection pool given by the following options (while adding postgis store), my question is, how do I handle these settings? For the time being, I have kept the default options. But, should these settings (e.g. max_connections, idle) be aligned with the pgbouncer configuration?
I am using EDB Postgres Replication server to setup a replication for my EDB Advanced Server.
Running it on 3 VMs using Centos 7. All have Advanced Server 13 installed.
Creating a Single-Master Replication (SMR)
Publication Server has been setup and a database has been appointed as the controller database.
Encountering a problem when creating the Subscription server, receiving an error of Database connection cannot be added. Controller database is not initialized yet.
All server services are running and all have the proper connection on the configuration file.
How can I resolve this?
My team and I are currently experiencing an issue where we can't connect to Cloud SQL's Postgres instance(s) from anything other than the psql cli tool. We get a too many connections for database "postgres" error (in PGAdmin, DBeaver, and our node typeorm/pg backend). It initially happened on our (only) Postgres database instance. After restarting, stopping and starting again, increasing machine CPU/memory proved to do nothing, I deleted the database instance entirely and created a new one from scratch.
However, after a few hours the problem came back. I know that we're not actually having too many connections as I am able to query pg_stat_activity from psql command line and see the following:
Only one of those (postgres username) connections is ours.
My coworker also can't connect at all - not even from psql cli.
If it matters, we are using PostgreSQL 13, europe-west2 (London), single zone availability, db-g1-small instance with 1.7GB memory, 10GB HDD, and we have public IP enabled and the correct IP addresses whitelisted.
I'd really appreciate if anyone has any insights into what's causing this.
EDIT: I further increased the instance size (to no longer be a shared core), and I managed to successfully connect my backend to it. However my psql cli no longer works - it appears that only the first client to connect is allowed to connect after a restart (even if it disconnects, other clients can't connect...).
From the error message, it is clear that the database "postgres" has a custom connection limit (set, for example, by ALTER DATABASE postgres CONNECTION LIMIT 1). And apparently, it is quite small. Why is everyone try to connect to that database anyway? Usually 'postgres' database is reserved for maintenance operations, and you should create other databases for daily use.
You can see the setting with:
select datconnlimit from pg_database where datname='postgres';
I don't know if the low setting is something you did, or maybe Google does it on its own for their cloud offering.
#jjanes had the right idea/mention.
I created another database within the Cloud SQL instance that wasn't named postgres and then it was fine.
It wasn't anything to do with maximum connection settings (as this was within Google Cloud SQL) or not closing connections (as TypeORM/pg does this already).
I have postgres with hba configuration file and pgbouncer for connection pooling.
I want to connect to pgbouncer (instead of postgres) only by changing the port number of the connection string (6543 instead of 5432). Both postgres and pgbouncer run on the same server.
So far, I've been able to have pgbouncer run with its own hba file with duplicated user/password. It's not maintainable (or at least very painful) to manually sync postgres and pgbouncer user/password.
Is there any way I can make pgbouncer forward user/password login attempts to postgres as-is? Or am I trying to work my conf against the way things should go?
Which version of pgbouncer do you use? Starting from 1.6 it is able to load users/passwords directly from database. You just need to specify "auth_query"
in your config file.
https://pgbouncer.github.io/config.html
I have a Tomcat and PostgreSQL installed on a server. I'm having a connection problem trying to connect from my servlet to PostgreSQL database using c3p0 pool.
I can reach DB if I'm running Tomcat locally on my laptop. Also I can connect from server to DB using psql (i.e. command line sql utility). But when I'm trying to deploy my servlet to server and establish a connection I'm getting the following error:
java.sql.SQLException: Connections could not be acquired from the underlying database!
com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:106)
...
com.mchange.v2.resourcepool.CannotAcquireResourceException: A ResourcePool could not acquire a resource from its primary factory or source.
com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1319)
com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:557)
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:477)
What should I check to locate a problem? It should be a trivial issue but may be due to 4 a.m. I'm missing something :) Thanks in advance!
PS: Connection from all network interfaces are allowed to database. PostgreSQL JDBC driver and c3p0 pool are distributed in WAR. Tomcat configuration is very default. JNDI is not used.
You need to check a few things:
java.policy which tomcat is using
(e.g.
/etc/tomcat5.5/policy.d/02debian.policy)
db server settings (e.g.
/etc/postgresql/pg_hba.conf)
try connecting without pool first as
in my case c3p0 was hiding important information from me
Adding to #Alexey's answer, I had this issue with Tomcat and PostgreSQL 9.4. In my case, the md5 authentication method in postgres was causing the issue.
If you are using Windows server or RHEL server, make sure you update the authentication method in pg_hba.conf file. Modify it to trust and restart postgresql.