1, found the same issue in our environment.

This issue still persists,
this fact either needs documentation with big bold letters, or the module must track the database selected by the connection somehow. We ran into this issue with the module being used as the session handler with options persistent=1&database=2.
The application was using persistent connections and expecting database 0 to be selected, but sometimes got the connection used for session handling with database 2 selected.

issue still persists on phpredis: 5.3.4

For me, it looks like last selected database is chosen in all connections.

For anyone with the same problem: try to avoid using databases when possible. If you need logical separation of data (e.g. session storage vs cache vs Prometheus data), spin up another Redis instance. It doesn't add much overhead, but it isolates your data and makes debugging so much easier.

ini_set('redis.pconnect.pooling_enabled', 0); // Default is 1

Works as expected after set "redis.pconnect.pooling_enabled=0".

I think, "redis.pconnect.pooling_enabled=1" means sharing idle redis connections across php-fpm progress by host and port.

1. When redis.pconnect.pooling_enabled=0, the pid and client-id bound in pair, and when redis.pconnect.pooling_enabled=1, client-id is random but reused in a static range.
2. $redis->getDbNum() only shows you the dbIndex recorded in PHP variable, not in redis connection.

I found commit 8206b14749e2583895023312c2143116c2480a50 caused this problem

My Suggest:

• The default value of "redis.pconnect.pooling_enabled" in phpredis should changed to 0, not 1.
  In most scenarios, a Redis Connection Pool is not necessary, a Long-Lived Connection bound to process is match with PHP's common language conventions and works well.
• Connection reuse across in pconnect pool, should think about persistent_id

This is my test code:

<?php

// Switch this config and refresh page to test.
// =0; getDbNum() keep same to getDbIndexFromConnection()
// =1; getDbNum() same as getDbIndexFromConnection() on first time, but show random result after.
ini_set('redis.pconnect.pooling_enabled', 0);

function makeConnection($id) {
    $redis = new Redis();
    // Change to your own redis params
    $redis->pconnect('127.0.0.1', 6379, 5, $id);
    return $redis;
}

/**
 * Show Redis ClientID
 */
function getConnectionId($redis) {
    return $redis->client('ID');
}

/**
 * Retrieve  the REAL dbIndex from Redis Connection
 */
function getDbIndexFromConnection($redis) {
    $conns = $redis->client('LIST');
    $clientId = $redis->client('ID');
    foreach ($conns as $conn) {
        if ($conn['id'] === $clientId) {
            return $conn['db'];
        }
    }
    return null;
}

$redis0 = makeConnection('redis0');
$redis1 = makeConnection('redis1');
$redis1->select(1);
$redis2 = makeConnection('redis2');
$redis2->select(2);


echo 'PID: ', getmypid(), PHP_EOL;

echo
    getConnectionId($redis0), ' ',
    $redis0->getDbNum(), ' ',
    getDbIndexFromConnection($redis0), PHP_EOL;
$redis0->set('REDIS_0', '0');

echo
    getConnectionId($redis1), ' ',
    $redis1->getDbNum(), ' ',
    getDbIndexFromConnection($redis1), PHP_EOL;
$redis1->set('REDIS_1', '1');

echo
    getConnectionId($redis2), ' ',
    $redis2->getDbNum(), ' ',
    getDbIndexFromConnection($redis2), PHP_EOL;
$redis2->set('REDIS_2', '2');

I can still reproduce this behaviour and I consider this a critical bug. At least it should be documented in the description of pconnect().

I am not happy with the recommendation to not use different DBs because saving everything to DB 0 makes it impossible to use FLUSHDB to quickly delete logical portions of the stored data (and other things).

If turning off persistent connections and using several Redis instances, instead of using one existing connection (from the pool) or connecting one single time I would have to connect (for instance) 4 Times during the handling of one Request (if I want to access 4 different instances instead of 4 DBs). This has a huge performance impact, as connecting (an sending a subsequent AUTH command) is probably the slowest thing many scripts do.

Please fix this, my recommendation would be to save the selected DB alongside the connection and if it is not 0, issue a "SELECT 0" before handing a connection from the pool over to another PHP script.

Does this issue also happen on develop? It seems that 6.0.0RC1 was tagged 2 days ago (not on PECL though).

If turning off persistent connections and using several Redis instances, instead of using one existing connection (from the pool) or connecting one single time I would have to connect (for instance) 4 Times during the handling of one Request (if I want to access 4 different instances instead of 4 DBs). This has a huge performance impact, as connecting (an sending a subsequent AUTH command) is probably the slowest thing many scripts do.

ini_set('redis.pconnect.pooling_enabled', 0); 

Disable pconnect pooling should fix your problem, it just disable pconnect pooling, pconnect is still a long-live connection, the difference is: with redis.pconnect.pooling_enabled=1 connection shares across php-fpm, with redis.pconnect.pooling_enabled=0 connection bound to php-fpm process which created it.

Currently, I'm debugging an issue where cache keys were written into the wrong database after adding a new persistent connection (separate persistent_id). After reading about this issue, I'm pretty sure that this is related.

This code seems to not use the persistent_id if redis.pconnect.pooling_enabled is enabled:

• If redis.pconnect.pooling_enabled is enabled:

  phpredis/library.c

  Line 3111 in 008ec53

  persistent_id = strpprintf(0, "phpredis_%ld%ld", tv.tv_sec, tv.tv_usec);

• If redis.pconnect.pooling_enabled is disabled and a persistent_id is set:

  phpredis/library.c

  Line 3114 in 008ec53

  persistent_id = strpprintf(0, "phpredis:%s:%s", host, ZSTR_VAL(redis_sock->persistent_id));

Is this not a bug where the persistent_id should be taken into account if redis.pconnect.pooling_enabled is enabled?

What I don't understand yet: what are the implications of disabling redis.pconnect.pooling_enabled when running in PHP-FPM? Will we get issues because multiple workers reuse the same connection?

This hit us when trying to use a dedicated database for a Symfony RedisSessionHandler. Cache keys kept appearing in the wrong database.

In fact, only keys for db 0 end up in db 1, not the other way around. I figure this is because Symfony uses $params['dbindex'] && !$redis->select($params['dbindex']), so only selects if it's not the db 0.

I've asked if they would consider a workaround in Symfony, too.

Did you configure redis.pconnect.pool_pattern? It needs to contain i to actually use the persistent_id as part of a hashmap key, if I understand correctly.