I have created a PostgreSQL 13.1 cluster with 1` where I have 2 standby and 1 primary.
Here I have used scram-sha-256as authentication mode for client where my cluster is config with TLS.
When I started my PostgreSQL server, I got a continuous fatal log.
the log is:
UTC [181] FATAL: expected SASL response, got message type 88
postgresql.conf
wal_level = replica
max_wal_senders = 90
wal_keep_size = 64
wal_log_hints = on
hot_standby = on
password_encryption = scram-sha-256
recovery_target_timeline = 'latest'
primary_conninfo = 'application_name=<application_name> host=<host_name> password=<Postgres_password sslmode=verify-full sslrootcert=<path_to_ca_cert>/ca.crt'
promote_trigger_file = '/run_scripts/tmp/pg-failover-trigger'
...
<some other basic config>
...
pg_hba.conf
#TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 scram-sha-256
local replication all scram-sha-256
host replication all 127.0.0.1/32 scram-sha-256
host replication all ::1/128 scram-sha-256
host all all 0.0.0.0/0 scram-sha-256
host replication postgres 0.0.0.0/0 scram-sha-256
host all all ::/0 scram-sha-256
host replication postgres ::/0 scram-sha-256
Is it possible to add scram-sha-256 for tls config cluster? If yes, then how can I do it?
Here is how I have tried to connect as a client.
$ export PGPASSWORD=<POSTGRES_PASSWORD>
$ export PGUSER=<POSTGRES_USER>
$ psql -w -h <hostname>
psql (13.1)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=#
I don't see any error from my client site but get continuous fatal log.
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/pv/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... UTC
creating configuration files ... ok
running bootstrap script ... ok
sh: locale: not found
2021-03-03 07:43:56.823 UTC [35] WARNING: no usable system locales were found
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctl -D /var/pv/data -l logfile start
initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
waiting for server to start....2021-03-03 07:44:03.835 GMT [42] LOG: skipping missing configuration file "/etc/config/user.conf"
2021-03-03 07:44:03.836 GMT [42] LOG: skipping missing configuration file "/etc/config/user.conf"
2021-03-03 07:44:03.996 UTC [42] LOG: starting PostgreSQL 13.1 on x86_64-pc-linux-musl, compiled by gcc (Alpine 10.2.1_pre1) 10.2.1 20201203, 64-bit
2021-03-03 07:44:03.996 UTC [42] LOG: listening on IPv4 address "0.0.0.0", port 5432
2021-03-03 07:44:03.996 UTC [42] LOG: listening on IPv6 address "::", port 5432
2021-03-03 07:44:04.073 UTC [42] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2021-03-03 07:44:04.187 UTC [43] LOG: database system was shut down at 2021-03-03 07:43:59 UTC
2021-03-03 07:44:04.237 UTC [44] FATAL: the database system is starting up
2021-03-03 07:44:04.281 UTC [42] LOG: database system is ready to accept connections
done
server started
ALTER ROLE
/run_scripts/role/start.sh: ignoring /var/initdb/*
waiting for server to shut down...2021-03-03 07:44:04.387 UTC [42] LOG: received fast shutdown request
.2021-03-03 07:44:04.478 UTC [42] LOG: aborting any active transactions
2021-03-03 07:44:04.480 UTC [42] LOG: background worker "logical replication launcher" (PID 51) exited with exit code 1
2021-03-03 07:44:04.482 UTC [45] LOG: shutting down
2021-03-03 07:44:05.169 UTC [56] FATAL: the database system is shutting down
.2021-03-03 07:44:05.702 UTC [57] FATAL: the database system is shutting down
2021-03-03 07:44:05.806 UTC [58] FATAL: the database system is shutting down
2021-03-03 07:44:06.217 UTC [59] FATAL: the database system is shutting down
..2021-03-03 07:44:07.648 UTC [60] FATAL: the database system is shutting down
2021-03-03 07:44:07.853 UTC [61] FATAL: the database system is shutting down
2021-03-03 07:44:08.163 UTC [42] LOG: database system is shut down
done
server stopped
2021-03-03 07:44:08.208 GMT [25] LOG: skipping missing configuration file "/etc/config/user.conf"
2021-03-03 07:44:08.208 GMT [25] LOG: skipping missing configuration file "/etc/config/user.conf"
2021-03-03 07:44:08.487 UTC [25] LOG: starting PostgreSQL 13.1 on x86_64-pc-linux-musl, compiled by gcc (Alpine 10.2.1_pre1) 10.2.1 20201203, 64-bit
2021-03-03 07:44:08.487 UTC [25] LOG: listening on IPv4 address "0.0.0.0", port 5432
2021-03-03 07:44:08.487 UTC [25] LOG: listening on IPv6 address "::", port 5432
2021-03-03 07:44:08.688 UTC [25] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2021-03-03 07:44:08.895 UTC [67] LOG: database system was shut down at 2021-03-03 07:44:07 UTC
2021-03-03 07:44:08.905 UTC [68] FATAL: the database system is starting up
2021-03-03 07:44:08.945 UTC [69] FATAL: the database system is starting up
2021-03-03 07:44:08.946 UTC [70] FATAL: the database system is starting up
2021-03-03 07:44:08.991 UTC [25] LOG: database system is ready to accept connections
2021-03-03 07:44:15.990 UTC [94] FATAL: expected SASL response, got message type 88
2021-03-03 07:44:16.011 UTC [95] FATAL: expected SASL response, got message type 88
2021-03-03 07:44:30.197 UTC [108] FATAL: expected SASL response, got message type 88
2021-03-03 07:44:31.324 UTC [110] FATAL: expected SASL response, got message type 88
2021-03-03 07:44:57.571 UTC [114] FATAL: expected SASL response, got message type 88
2021-03-03 07:44:57.729 UTC [115] FATAL: expected SASL response, got message type 88
2021-03-03 07:45:07.982 UTC [127] FATAL: expected SASL response, got message type 88
2021-03-03 07:45:08.020 UTC [128] FATAL: expected SASL response, got message type 88
2021-03-03 07:45:18.135 UTC [140] FATAL: expected SASL response, got message type 88
2021-03-03 07:45:18.173 UTC [141] FATAL: expected SASL response, got message type 88
The problem was with the go-client i was trying to use to connect my server. The problem was solved when i tried https://github.com/lib/pq client instead of https://github.com/go-pg/pg.
I have edited my pg_hba file and copied it to server and restarted the services by "sudo service postgresql restart" but after that the server is not connecting.
Showing the below error, Your database returned: "Connection to 138.2xx.1xx.xx:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections."
The Jenkins job and data visualization tools are failing which was working fine previously. What could be the reason.
Getting this in PostgreSQL Log
2019-10-23 07:21:25.829 CEST [11761] LOG: received fast shutdown request
2019-10-23 07:21:25.829 CEST [11761] LOG: aborting any active transactions
2019-10-23 07:21:25.829 CEST [11766] LOG: autovacuum launcher shutting down
2019-10-23 07:21:25.832 CEST [11763] LOG: shutting down
2019-10-23 07:21:25.919 CEST [11761] LOG: database system is shut down
2019-10-23 07:21:27.068 CEST [22633] LOG: database system was shut down at 2019-10-23 07:21:25 CEST
2019-10-23 07:21:27.073 CEST [22633] LOG: MultiXact member wraparound protections are now enabled
2019-10-23 07:21:27.075 CEST [22631] LOG: database system is ready to accept connections
2019-10-23 07:21:27.075 CEST [22637] LOG: autovacuum launcher started
2019-10-23 07:21:27.390 CEST [22639] [unknown]#[unknown] LOG: incomplete startup packet
Below shows no response.
root#Ubuntu-1604-xenial-64-minimal ~ # pg_isready -h localhost -p 5432
localhost:5432 - no response
Below was already added to the postgresql.config file.
listen_addresses = '*'
Do i need to restart the entire server?
Can anyone please help me to resolve this.
We built a debian docker image with postgresql to run one of our service. The database is for internal container use and does not need port mapping. I believe it is installed via apt-get in the Dockerbuild file.
We stop and start this service often, and it is a performance issue that the database is slow to startup. Although empty, takes sightly over 20s to accept connection on the first time we start the docker image. The log is as follow :
2019-04-05 13:05:30.924 UTC [19] LOG: could not bind IPv6 socket: Cannot assign requested address
2019-04-05 13:05:30.924 UTC [19] HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
2019-04-05 13:05:30.982 UTC [20] LOG: database system was shut down at 2019-04-05 12:57:16 UTC
2019-04-05 13:05:30.992 UTC [20] LOG: MultiXact member wraparound protections are now enabled
2019-04-05 13:05:30.998 UTC [19] LOG: database system is ready to accept connections
2019-04-05 13:05:30.998 UTC [24] LOG: autovacuum launcher started
2019-04-05 13:05:31.394 UTC [26] [unknown]#[unknown] LOG: incomplete startup packet
2019-04-19 13:21:58.974 UTC [37] LOG: could not bind IPv6 socket: Cannot assign requested address
2019-04-19 13:21:58.974 UTC [37] HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
2019-04-19 13:21:59.025 UTC [38] LOG: database system was interrupted; last known up at 2019-04-05 13:05:34 UTC
2019-04-19 13:21:59.455 UTC [39] [unknown]#[unknown] LOG: incomplete startup packet
2019-04-19 13:21:59.971 UTC [42] postgres#postgres FATAL: the database system is starting up
[...]
2019-04-19 13:22:15.221 UTC [85] root#postgres FATAL: the database system is starting up
2019-04-19 13:22:15.629 UTC [38] LOG: database system was not properly shut down; automatic recovery in progress
2019-04-19 13:22:15.642 UTC [38] LOG: redo starts at 0/14EEBA8
2019-04-19 13:22:15.822 UTC [38] LOG: invalid record length at 0/24462D0: wanted 24, got 0
2019-04-19 13:22:15.822 UTC [38] LOG: redo done at 0/24462A8
2019-04-19 13:22:15.822 UTC [38] LOG: last completed transaction was at log time 2019-04-05 13:05:36.602318+00
2019-04-19 13:22:16.084 UTC [38] LOG: MultiXact member wraparound protections are now enabled
2019-04-19 13:22:16.094 UTC [37] LOG: database system is ready to accept connections
2019-04-19 13:22:16.094 UTC [89] LOG: autovacuum launcher started
2019-04-19 13:22:21.528 UTC [92] root#test LOG: could not receive data from client: Connection reset by peer
2019-04-19 13:22:21.528 UTC [92] root#test LOG: unexpected EOF on client connection with an open transaction
Any suggetion in fixing this startup issue ?
EDIT : Some requested the dockerfile, here is relevant lines
RUN apt-get update \
&& apt-get install -y --force-yes \
postgresql-9.6-pgrouting \
postgresql-9.6-postgis-2.3 \
postgresql-9.6-postgis-2.3-scripts \
[...]
# Download, compile and install GRASS 7.2
[...]
USER postgres
# Create a database 'grass_backend' owned by the "root" role.
RUN /etc/init.d/postgresql start \
&& psql --command "CREATE USER root WITH SUPERUSER [...];" \
&& psql --command "CREATE EXTENSION postgis; CREATE EXTENSION plpython3u;" --dbname [dbname] \
&& psql --command "CREATE EXTENSION postgis_sfcgal;" --dbname [dbname] \
&& psql --command "CREATE EXTENSION postgis; CREATE EXTENSION plpython3u;" --dbname grass_backend
WORKDIR [...]
End of file after workdir, meaning I guess the database isn't properly shut down
Answer I stopped properly postgresql inside the docker install. It now starts 15s faster. Thanks for replying
Considering the line database system was not properly shut down; automatic recovery in progress that would definitely explain slow startup, please don't kill the service, send the stop command and wait for it to close properly.
Please note that the system might kill the process if it takes to long to stop, this will happen in the case of postgresql if there are connections still held to it (probably from your application). If you disconnect all the connections and than stop, postgresql should be able to stop relatively quickly.
Also make sure you stop the postgresql service inside the container before turning it off.
TCP will linger connections for a while, if you are starting and stopping in quick succession without properly stopping the service inside that would explain your error of why the port is unavailable, normally the service can start/stop in very quick succession on my machine if nothing is connected to it.
3 start-stop cycles of postgresql on my machine (I have 2 decently sized databases)
$ time bash -c 'for i in 1 2 3; do /etc/init.d/postgresql-11 restart; done'
* Stopping PostgreSQL 11 (this can take up to 92 seconds) ... [ ok ]
* /run/postgresql: correcting mode
* Starting PostgreSQL 11 ... [ ok ]
* Stopping PostgreSQL 11 (this can take up to 92 seconds) ... [ ok ]
* /run/postgresql: correcting mode
* Starting PostgreSQL 11 ... [ ok ]
* Stopping PostgreSQL 11 (this can take up to 92 seconds) ... [ ok ]
* /run/postgresql: correcting mode
* Starting PostgreSQL 11 ... [ ok ]
real 0m1.188s
user 0m0.260s
sys 0m0.080s
I use postgres:10 (https://hub.docker.com/_/postgres/) image for DB.
It is deployed in docker swarm cluster.
After running DB replica I got database system is shut down in DB's log.
2018-05-11 10:26:53.073 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432,
2018-05-11 10:26:53.073 UTC [1] LOG: listening on IPv6 address "::", port 5432,
2018-05-11 10:26:53.077 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432",
2018-05-11 10:26:53.092 UTC [20] LOG: database system was shut down at 2018-05-11 10:26:20 UTC,
2018-05-11 10:26:53.100 UTC [1] LOG: database system is ready to accept connections,
The files belonging to this database system will be owned by user "postgres".,
This user must also own the server process.,
,
The database cluster will be initialized with locale "en_US.utf8".,
The default database encoding has accordingly been set to "UTF8".,
The default text search configuration will be set to "english".,
,
Data page checksums are disabled.,
,
fixing permissions on existing directory /var/lib/postgresql/data ... ok,
creating subdirectories ... ok,
selecting default max_connections ... 100,
selecting default shared_buffers ... 128MB,
selecting dynamic shared memory implementation ... posix,
creating configuration files ... ok,
running bootstrap script ... ok,
performing post-bootstrap initialization ... ok,
,
WARNING: enabling "trust" authentication for local connections,
You can change this by editing pg_hba.conf or using the option -A, or,
--auth-local and --auth-host, the next time you run initdb.,
syncing data to disk ... ok,
,
Success. You can now start the database server using:,
,
pg_ctl -D /var/lib/postgresql/data -l logfile start,
,
waiting for server to start....2018-05-11 09:39:21.129 UTC [37] LOG: listening on IPv4 address "127.0.0.1", port 5432,
2018-05-11 09:39:21.130 UTC [37] LOG: could not bind IPv6 address "::1": Cannot assign requested address,
2018-05-11 09:39:21.130 UTC [37] HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.,
2018-05-11 09:39:21.133 UTC [37] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432",
2018-05-11 09:39:21.147 UTC [38] LOG: database system was shut down at 2018-05-11 09:39:20 UTC,
2018-05-11 09:39:21.152 UTC [37] LOG: database system is ready to accept connections,
done,
server started,
CREATE DATABASE,
,
CREATE ROLE,
,
,
/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*,
,
2018-05-11 09:39:21.595 UTC [37] LOG: received fast shutdown request,
waiting for server to shut down....2018-05-11 09:39:21.596 UTC [37] LOG: aborting any active transactions,
2018-05-11 09:39:21.598 UTC [37] LOG: worker process: logical replication launcher (PID 44) exited with exit code 1,
2018-05-11 09:39:21.599 UTC [39] LOG: shutting down,
2018-05-11 09:39:21.613 UTC [37] LOG: database system is shut down,
done,
server stopped,
,
PostgreSQL init process complete; ready for start up.,
,
2018-05-11 09:39:21.706 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432,
2018-05-11 09:39:21.706 UTC [1] LOG: listening on IPv6 address "::", port 5432,
2018-05-11 09:39:21.709 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432",
2018-05-11 09:39:21.724 UTC [64] LOG: database system was shut down at 2018-05-11 09:39:21 UTC,
2018-05-11 09:39:21.729 UTC [1] LOG: database system is ready to accept connections,
2018-05-11 10:26:20.444 UTC [1] LOG: received smart shutdown request,
2018-05-11 10:26:20.449 UTC [1] LOG: worker process: logical replication launcher (PID 70) exited with exit code 1,
2018-05-11 10:26:20.449 UTC [65] LOG: shutting down,
2018-05-11 10:26:20.460 UTC [1] LOG: database system is shut down,
Image :
FROM postgres:10
COPY healthcheck /usr/local/bin/
RUN chmod +x /usr/local/bin/healthcheck
HEALTHCHECK --interval=30s --timeout=30s --retries=3 \
CMD healthcheck
Snippet from docker-compose :
db_jackrabbit:
build: ./images/pgsql_jackrabbit
container_name: db_jackrabbit
environment:
- POSTGRES_DB=${JACK_POSTGRES_DB}
- POSTGRES_USER=${JACK_POSTGRES_USER}
- POSTGRES_PASSWORD=${JACK_POSTGRES_PASSWORD}
volumes:
- pgsql_jackrabbit_local:/var/lib/postgresql/data
ports:
- ${PORT_DB_JACKRABBIT}:5432
healthcheck:
#!/bin/bash
set -eo pipefail
host="$(hostname -i || echo '127.0.0.1')"
user="${POSTGRES_USER:-postgres}"
db="${POSTGRES_DB:-$POSTGRES_USER}"
export PGPASSWORD="${POSTGRES_PASSWORD:-}"
args=(
# force postgres to not use the local unix socket (test "external" connectibility)
--host "$host"
--username "$user"
--dbname "$db"
--quiet --no-align --tuples-only
)
if select="$(echo 'SELECT 1' | psql "${args[#]}")" && [ "$select" = '1' ]; then
exit 0
fi
exit 1
But DB still alive. It is shutdown periodically and accept connections again (
What it the problem?
Thanks in advance!
Ok, so I solved my issue. This issue helped me.
It seems like Postgres initialization process does stop the initialization process once done, and it is another process which follows up and accepts connexion.
Hence I had:
postgres:
deploy:
restart_policy:
condition: on-failure
window: 15m
and apparently docker received a end-of-process status code, so it stopped without going to the next process so never accepting connexions.
My interpretation may be incorrect, but at least if you face the issue, try removing restart_policy key to see if it fixes it.
I haven't tried to restore healthcheck yet, as it may also have undesired side effects.
I'm trying to do python manage.py syncdb on a Django installation, but I keep getting OperationalError: ERROR: pgbouncer cannot connect to server. pgbouncer.log contains lines such as:
2017-09-19 19:44:15.107 1128 LOG C-0x8a9930: mydb/myuser#unix:6432 closing because: pgbouncer cannot connect to server (age=0)
2017-09-19 19:44:15.107 1128 WARNING C-0x8a9930: mydb/myuser#unix:6432 Pooler Error: pgbouncer cannot connect to server
2017-09-19 19:44:15.107 1128 LOG S-0x8c72e0: mydb/myuser#35.154.149.188:5432 new connection to server
2017-09-19 19:44:15.107 1128 LOG C-0x8a9930: mydb/myuser#unix:6432 login failed: db=mydb user=myuser
2017-09-19 19:44:30.108 1128 LOG S-0x8c72e0: mydb/myuser#35.154.149.188:5432 closing because: connect failed (age=15)
In case needed, ps -aef | grep pgbouncer yields:
postgres 1128 1 0 18:38 ? 00:00:00 /usr/sbin/pgbouncer -d /etc/pgbouncer/pgbouncer.ini
myuser 1919 1533 0 19:45 pts/0 00:00:00 grep --color=auto pgbouncer
Moreover, grep port /etc/pgbouncer/pgbouncer.ini results in:
;; dbname= host= port= user= password=
mydb = host=xx.xxx.xxx.xxx port=5432 dbname=mydb
;forcedb = host=127.0.0.1 port=300 user=baz password=foo client_encoding=UNICODE datestyle=ISO connect_query='SELECT 1'
listen_port = 6432
Lastly, the relevant parts of settings.py contain:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'mydb',
'USER': 'myuser',
'PASSWORD': 'mypassword',
'HOST': '/var/run/postgresql',
'PORT': '6432',
}
I turned log_connections to on in postgresql.conf, restarted PG and tried again. Here's the relevant lines:
2017-09-20 07:50:59 UTC LOG: database system is ready to accept connections
2017-09-20 07:50:59 UTC LOG: autovacuum launcher started
2017-09-20 07:51:00 UTC LOG: connection received: host=[local]
2017-09-20 07:51:00 UTC LOG: incomplete startup packet
2017-09-20 07:51:00 UTC LOG: connection received: host=[local]
2017-09-20 07:51:00 UTC LOG: connection authorized: user=postgres database=postgres
2017-09-20 07:51:01 UTC LOG: connection received: host=[local]
2017-09-20 07:51:01 UTC LOG: connection authorized: user=postgres database=postgres
2017-09-20 07:51:01 UTC LOG: connection received: host=[local]
2017-09-20 07:51:01 UTC LOG: connection authorized: user=postgres database=postgres
It seems the connection is going through, but the user and database name is postgres. Those credentials aren't what I supplied in pgbouncer.ini.
However, explicitly adding myuser in the connection string described in pgbouncer.ini leads to:
2017-09-20 09:37:37 UTC FATAL: Peer authentication failed for user "myuser"
2017-09-20 09:37:37 UTC DETAIL: Connection matched pg_hba.conf line 90: "local all all peer"
Totally stumped.
It seems the mis-configuration emanated from this line in settings.py:
'PORT': '6432',
I commented it and pgbouncer started working.
Though I'm not sure 'why'.
Maybe there's a collision on this port; Pgbouncer and PG coexist on a single server in my case. I've set them up over different VMs in the past without a hitch (and without needing to comment 'PORT': '6432',)