When using a database server (ZEO, relstorage), you can make a
configuration error that causes you to connect to the wrong database.
This can be especially painful in a situation where you get
disconnected from the server and "reconnect" to an incorrect server
and end up with objects from separate databases in the same cache.
This happened to us (ZC) once when we fat-fingered a ZRS database
fail-over.

ZEO currently defends against this by refusing to connect to a server
if the server's last transaction ID is less than the last transaction
ID the client has seen.  This has a couple of problems:

- The test is too weak.

- It makes fail-over to a slightly out of date secondary storage quite
  painful.

I propose to add a database identifier that clients can verify.

- To minimize impact to storage implementations, the database
  identifier will be stored under the ZODB_DATABASE_ID key of object 0
  (root object).  The key will be added on database open if it is
  absent. The value will be a configured value, or a UUID.

- If a ZEO client is configured with a database identifier, then it
  will refuse to connect to a database without a matching identifier.

- If a ZEO client is *not* configured with a database identifier, it
  will configure itself with the identifier of the first server it
  connects to, saving the information in the ZEO cache.  This will at
  least protect against "reconnect" to the wrong server.

- A ZEO client can *optionally* be configured to discard cache if it
  (re)connects to a server with a last transaction lower than the last
  one the client has seen as long as the database ID matches.

- ZRS secondaries will also check database ids when (re)connecting to
  primaries.

Comments?

Jim

--
Jim Fulton
http://www.linkedin.com/in/jimfulton
_______________________________________________
For more information about ZODB, see http://zodb.org/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev

Reply via email to