Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

rpungello's avatar

Read PDO is null

I'm trying to troubleshoot a rather bizarre issue with our Laravel app. We use Laravel's read/write DB connection feature to distribute read queries across a pool of read replicas on Amazon Aurora, but I've been noticing a lot of read queries appear to be running on our master (write) DB instance. I've done some digging (adding logging statements to the Laravel framework code), and it appears as though the $readPdo variable in Illuminate\Database\Connection is seemingly randomly resetting itself to null.

I modified the Connection::getReadPdo() function and added this to the bottom (right before the call to return either the read PDO or the main PDO).

print(now()->format('c'));
if(is_null($this->readPdo))
    print("Read PDO null".PHP_EOL);
else
    print("Read PDO good".PHP_EOL);

Looking at the output, it always starts looking like this: 2021-04-20T16:00:05-04:00Read PDO good However, later on I end up seeing stuff like this

2021-04-20T16:01:29-04:00Read PDO good
2021-04-20T16:01:29-04:00Read PDO good
2021-04-20T16:01:29-04:00Read PDO good
2021-04-20T16:01:29-04:00Read PDO null
2021-04-20T16:01:29-04:00Read PDO null
2021-04-20T16:01:29-04:00Read PDO null
2021-04-20T16:01:29-04:00Read PDO null
2021-04-20T16:01:29-04:00Read PDO null
2021-04-20T16:01:29-04:00Read PDO null
2021-04-20T16:01:29-04:00Read PDO good
2021-04-20T16:01:29-04:00Read PDO good

So far as I can tell, the only place the $readPdo can be set is in the Connection class itself, via setReadPdo() or as part of the getReadPdo() call (if it's a closure it sets the read PDO to the result of executing that closure). I added debugging statements to those sections of code as well, and they are not triggering.

So, my question is how is it possible this $readPdo variable is flipping back and forth between null and valid with seemingly no input? We're currently using Laravel 7.17.2, being run via Supervisord and queue:work

Let me know if any other information would be helpful.

0 likes
1 reply
rpungello's avatar

Nevermind, I figured this out. The web server that triggered the job was using the single-instance MySQL connection, not the one with separate read/write hosts. When things were re-hydrated on the worker node, that connection name carried across.

Please or to participate in this conversation.