-
Notifications
You must be signed in to change notification settings - Fork 641
Description
KeyDB Version: 6.3.4
Description:
I’m trying to use SWAPDB in a master–replica setup and noticed some confusing behavior with persistent connections.
If a client is connected to a replica and has already selected a database (e.g., SELECT 7), then when the master runs SWAPDB 7 8, the client that had DB 7 selected suddenly starts seeing the contents of DB 8 — even though the client never re-issued a SELECT.
New client connections to the replica behave as expected (they see the swapped data correctly), but existing persistent connections seem to get "remapped" behind the scenes.
Steps to Reproduce:
Set up master + replica.
Connect a client to the replica and run SELECT 7.
Insert a test key into DB 7 and a different test key into DB 8.
On the master, run SWAPDB 7 8.
Query again from the existing client connected to the replica.
The client with DB 7 selected now sees DB 8’s data.
Behavior:
Persistent clients "follow the swap" and begin reading the other DB’s contents. This creates confusion because the client believes it is still connected to DB 7, but the data it sees comes from DB 8.
Additional Context:
Tested with both go-redis clients and keydb-cli.
Reconnecting the client resets the behavior.
I’m unsure if this is intended behavior for SWAPDB, or if I’m misunderstanding how it should work with persistent connections.
Looking for clarification: is there a recommended way to use SWAPDB safely in a replicated setup with long-lived connections?