mysqli_sql_exception with message 'No such file or directory'

Question

This error is familiar to anyone who ever tried to open a connection using 'localhost' (which transforms into a likely wrong socket path) but...

What could be randomly causing this exception on a TCP connection?

The (simplified) stack trace looks like this :

Uncaught exception 'mysqli_sql_exception'
With message 'No such file or directory' in /var/www/mysite/DB.php:88

#0 [internal function]: mysqli->real_connect()
#1 /var/www/mysite/DB.php(88): mysqli->query('SELECT * FR...')
#2 /var/www/mysite/OtherClass.php(668): DB::query('SELECT * FR...')

This happens after sucessfully making a bunch of other similar queries with THAT same mysqli object/connection, at a seemingly random time.

When this happens, the mysqli object contains the following information, some of which are clearly leftovers from the previous sucessful mysqli->query() call (such as affected_rows):

'affected_rows' => 14,
'client_info' => 'mysqlnd 5.0.11-dev - 20120503 - $Id: 76b08b24596e12d4553bd41fc93cccd5bac2fe7a $'
'client_version' => 50011
'connect_errno' => 2002
'connect_error' => 'No such file or directory'
'errno' => 0
'error' => ''
'error_list' => array ()
'field_count' => 3
'host_info' => '192.168.114.23 via TCP/IP'
'info' => NULL
'insert_id' => 0
'server_info' => '5.5.5-10.1.48-MariaDB'
'server_version' => 50505
'stat' => 'Uptime: 27634  Threads: 1075  Questions: 515109918  
           Slow queries: 92168  Opens: 601885  Flush tables: 1  
           Open tables: 2000  Queries per second avg: 18640.439'
sqlstate' => '00000'
protocol_version' => 10
thread_id' => 4057839
warning_count' => 0               

This happens on PHP 5.6.40 + mysqlnd, running on CLI mode (daemon) under systemd, and a mariadb cluster (4 servers) under moderate load, 1K to 3K sessions per server.

This happens on a script that has another mysqli object/connection open for the same server, but I don't see how that would be a problem. Connections are NOT on persistent (p:...) mode.

The connections are using different credentials and the one that fails does SET SESSION binlog_format = 'ROW' as first query: not sure how that could explain this either.

The error completely baffles me in the context of a TCP mysql connection.

EDIT: using the same credentials and binlog_format for both sessions does not solve the issue.

The code to set up the connections looks like this (for both singletons it is basically the same):

private static function connect()
{
    self::$conn = new mysqli('192.168.144.23', 'web', 'secret', 'products', 3306);
    self::$conn->query("SET SESSION binlog_format = 'ROW'");
    self::$conn->query('SET CHARACTER SET utf8, character_set_connection = utf8');
}

The code to make queries is equally standard

public static function query($query)
{
    if(self::$conn === null) {
        self::connect();
    }

    return $result = self::$conn->query($query)->fetch_all()
}

In the main daemon code, the two singletons are used in an alternated fashion, the order of use varies as it depends on the data:

while($processingLongListOfTasks) {
   ...
   if($someChangingCondition) {
     // exception after a few loops
     $results[] = DB::query("SELECT * FROM `table1`");
   }
   ...
   if($someOtherChangingCondition) {
     $results[] = OtherDB::query("SELECT * FROM `table2`");
   }
   ...
}