This is not a problem of the ZODB or relstorage, but specific to how
MySQL handles a) replication and b) temporary tables.
MySQL employs a log-based replication mechanism. This means the
replication slave replays the commands performed on the master to
keep its copy of the database in
Stefan H. Holek wrote:
In MySQL, temporary tables live in RAM. So when a slave goes down,
its copy of the table vanishes. When the slave comes back up the log
may still contain commands using the temporary table however, causing
execution to barf (and replication to stop). To fix this
I have made two checkins to relstorage 1.1 branch:
[1] http://svn.zope.org/relstorage/branches/1.1/?rev=88789view=rev
[2] http://svn.zope.org/relstorage/branches/1.1/?rev=88790view=rev
If someone wants to discuss them this is the thread. ;-)
Ad [1]:
This clearly is not the only problem with
Stefan H. Holek wrote:
I have made two checkins to relstorage 1.1 branch:
It's really cool to have another contributor. Thanks! 1.1c1 has
already been tagged, so I fixed the change log.
[1] http://svn.zope.org/relstorage/branches/1.1/?rev=88789view=rev
[2]
On Thursday 24 July 2008, Shane Hathaway wrote:
P.S.: I am quite excited about the memcached support. Does it just
work? I.e. can I run my ZODB in RAM now? ;-)
I expect the new memcache support to be safe for everyone to use, but we
still require the main database to be connected at all
Stephan Richter wrote:
We should get Brian Aker into this discussion, since is one of the main
architects of MySQL and one of the founders of memcached.
As Shane knows, I have some access to Brian these days, so we could have an
online meeting talking about it.
Cool. Memcache could do a
Stephan Richter wrote:
On Thursday 24 July 2008, Shane Hathaway wrote:
P.S.: I am quite excited about the memcached support. Does it just
work? I.e. can I run my ZODB in RAM now? ;-)
I expect the new memcache support to be safe for everyone to use, but we
still require the main
