Failed to refresh session cache after physical restore
Description
Environment
Tested with MongoDB 6.0.2-1
AFFECTED CS IDs
Activity
andrew.pogrebnoi June 26, 2023 at 8:51 AM
As I wrote above, this is just a slightly confusing log message. The "error" in the log is not even an error but `"s":"I"` - severity: Info. It's just a part of the standard post-restore start routine. The user doesn't have to do anything and the cluster will start perfectly fine on its own. That doesn't affect the database start or data consistency.
PBM documentation has been updated: https://docs.percona.com/percona-backup-mongodb/usage/restore.html#restore-from-a-logical-backup-made-on-previous-major-version-of-percona-server-for-mongodb (see Post-restore steps)
andrew.pogrebnoi April 27, 2023 at 3:10 PM
, maybe we should mention this in the documentation somehow?
andrew.pogrebnoi April 20, 2023 at 2:46 PM
Mongo logs after the start are a bit confusing:
As you can see it recreates `config.system.sessions` but indexes are still being built while the last check. So it leaves that confusing last record with an error message. But nevertheless, the collection is recreated successfully. So the user don't have to do anything in that regard
andrew.pogrebnoi April 20, 2023 at 10:03 AM
Hi
Does this make any issues with the database? Users cannot log in or something else? Or is the customer just worries because of the log message?
The message in the log is not an error but informative (`"s":"I"`, for the error it would be `"s":"E"`). The PSMDB just reports that there is no `config.system.sessions` and it'll create it.
We do drop `config.system.sessions` as part of the restoring routine. And PSMDB eventually recreates it upon a cluster start without the need for user intervention.
zelmar.michelini April 19, 2023 at 11:15 PM
There is a workaround for this issue; you can drop the collection config.system.sessions, and wait for the next refresh interval.
MongoDB will recreate the collection again.
After a physical restore, we can see an error on the log that the config.system.sessions doesn't exist, but the collection exist and we can see the log message of the creation just before the error:
{"t":{"$date":"2023-04-19T22:48:02.221+00:00"},"s":"I", "c":"STORAGE", "id":20320, "ctx":"LogicalSessionCacheRefresh","msg":"createCollection","attr":{"namespace":"config.system.sessions","uuidDisposition":"generated","uuid":{"uuid":{"$uuid":"7bc79857-3b7f-43bd-8d95-a07e97c4db10","options":{}}}}}{"t":{"$date":"2023-04-19T22:48:02.222+00:00"},"s":"I", "c":"CONTROL", "id":20712, "ctx":"LogicalSessionCacheReap","msg":"Sessions collection is not set up; waiting until next sessions reap interval","attr":{"error":"NamespaceNotFound: config.system.sessions does not exist"}}Tested with MongoDB 6.0.2-1