On 8/25/19 11:46 AM, Howard Wells wrote:
I have enabled logging. I chose the highest level of recording so I would have the best chance of finding out what's wrong. My error log is written to a .csv file. I initiated a browser-based transaction to insert records into a database. That transaction produced 1,299 records, with what appear to be repeating blocks. I don't see anything in here that specifically tells me why the client is not able to connect.
Huh? The client could not connect, but it produced 1299 records. You
will need to be more specific or clear about what you consider a client
and a connection?
To get to the bottom of this we will need:
1) The load balancer in use? I know you say below that the balancer is
not at issue, but that remains to be seen in my mind.
2) How the balancer is set up.
3) What is the client?
4) What is the server?
5) How does the server connect to the database?
The last 26 lines look like representative of the transaction blocks:
StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0
pg_statistic: vac: 0 (threshold 129), anl: 0 (threshold 89)
pg_type: vac: 0 (threshold 125), anl: 0 (threshold 88)
pg_authid: vac: 0 (threshold 51), anl: 0 (threshold 51)
pg_attribute: vac: 0 (threshold 566), anl: 0 (threshold 308)
pg_proc: vac: 0 (threshold 629), anl: 0 (threshold 339)
pg_class: vac: 0 (threshold 118), anl: 0 (threshold 84)
pg_index: vac: 0 (threshold 77), anl: 0 (threshold 63)
pg_opclass: vac: 0 (threshold 77), anl: 0 (threshold 63)
pg_am: vac: 0 (threshold 51), anl: 0 (threshold 51)
pg_amop: vac: 0 (threshold 192), anl: 0 (threshold 121)
pg_amproc: vac: 0 (threshold 132), anl: 0 (threshold 91)
pg_cast: vac: 0 (threshold 94), anl: 0 (threshold 72)
pg_namespace: vac: 0 (threshold 51), anl: 0 (threshold 51)
pg_database: vac: 0 (threshold 50), anl: 0 (threshold 50)
pg_tablespace: vac: 0 (threshold 50), anl: 0 (threshold 50)
CommitTransaction(1) name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/0
shmem_exit(0): 1 before_shmem_exit callbacks to make
shmem_exit(0): 7 on_shmem_exit callbacks to make
proc_exit(0): 2 callbacks to make
exit(0)
shmem_exit(-1): 0 before_shmem_exit callbacks to make
shmem_exit(-1): 0 on_shmem_exit callbacks to make
proc_exit(-1): 0 callbacks to make
reaping dead processes
server process (PID 15930) exited with exit code 0
My problem now is I don't know what to look for to find out why the client is not able to connect within the timeout period. The dev console (Chrome) always ends with a display of the echo messages up to the lines:
$pdo = new PDO($dsn);
$pdo->setAttribute(PDO::ATTR_TIMEOUT, 300);
And the final line is the Chrome dev console is SQLSTATE[08006] [7] timeout expired.
The load balancer is not the issue; if I point the browser to the IP address of one of the servers behind the load balancer (bypassing the load balancer), the same thing happens. Only when I go to the IP address of the server with the Postgres database will the transaction complete, and it happens quickly.
Thanks for any tips on what to look for in the csv log file to explain why the browser-based PHP connection does not complete
Howard
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, August 25, 2019 9:36 AM, Condor <condor@xxxxxxxxxx> wrote:
On 25-08-2019 02:54, Adrian Klaver wrote:
On 8/24/19 3:42 PM, Howard Wells wrote:
I have three servers behind a load balancer and a fourth server solely
for Postgres 10 database that is not behind the load balancer. All
four are behind the same firewall, with port 5432 open.
I have a simple browser-based html form to submit email addresses,
usernames and passwords; the form submits through a jQuery program
that calls a php program.
I can navigate the browser to the IP address of the server that hosts
the Postgres database and submit records to the database with no
problems. When I navigate to the site's URL (which goes through the
load balancer), I always get "SQLSTATE[08006] [7] timeout expired"
after a short delay -- in other words, no connection.
The php program is very simple:
<?php
echo 'Hello ' . htmlspecialchars($_POST["firstname"]) . '!' ;
echo PHP_EOL;
$dsn = vsprintf('pgsql:host=%s;port=%s;dbname=%s;user=%s;password=%s',
[
'host' => 'xxx.xx.xx.xx',
'port' => '5432',
'dbname' => '[DBNAME]',
'user' => '[USERNAME]',
'password' => '[PASSWORD]',
]);
echo 'HTTP Referer ' . $_SERVER['HTTP_REFERER'];
echo PHP_EOL;
echo 'IP Address ' . $_SERVER["REMOTE_ADDR"];
echo PHP_EOL;
try{
// create a PostgreSQL database connection
echo "I'm here now";
echo PHP_EOL;
//ini_set("default_socket_timeout", 300);
$pdo = new PDO($dsn);
$pdo->setAttribute(PDO::ATTR_TIMEOUT, 300);
// display a message if connected to the PostgreSQL successfully
if($pdo){
echo "Connected to the database successfully!";
echo PHP_EOL;
}
}catch (PDOException $e){
// report error message
echo $e->getMessage();
exit();
}
$pdo = null;
?>
The echo messages are simply debugging progress messages for the
browser's dev console.
The pg_hba.conf has these lines enabled:
pg_hba.conf:
host all [username] 0.0.0.0/0 trust
host all all 0.0.0.0/0 md5
host all all ::/0 md5
host all all all md5
The $_SERVER["REMOTE_ADDR"]; line shown in my PHP program above always
comes back with the address of the load balancer.
I'm new to Postgres, so any help with this connection problem will be
very appreciated. Thanks a lot.
In addition to what Rob suggested, what do you see or not in the
Postgres logs when you try the connections(both direct to db and to
load balancer).
You can use strace or tcpdump to see what's happened. First check to see
did the balncer is up and port is opened. Next if the balancer is bind
on port 5432 and pgsql server is started on same ip without port to be
changed this can't be happened unless the pgsql server is started on
socket without inet connection. If the balancer is up and they are not
in the same server then it's seems the problem is between balancer and
sql server. The balancer is not connected to pg server with some reason
/firewall, permissions, users and so on, you need to check them -
balancer logs, firewall rules /.
Regards,
HS
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
