[Erp5-dev] Cloning ERP5 instance - problem with connection strings

[Jacek Medrzycki]

Hi.

We sometimes fell a need to clone current state of our client's
production ERP5 instance, for example to check client's complaint
without writing to production database.

Cloning the Zope database seems to be easy - just copy data.fs to new
location, there are even backup tools that do it on the fly without
stopping zope. However, there is a problem. Sql connection strings are
stored in ZODB, thus after starting a clone it tries to write to the
production sql database! If there are unfinished activities or so, the
state of production sql database could be modified before we change ERP5
connection strings. Then, mysql database would be inconsistent with
production ZODB! And reindexing is not the solution in production
environment, as it takes time and before finishing the ERP5 site is
partially unusable.

Our solution is to:
- stop production
- clone production ZODB and production SQL (with mysqldump), save
mysqldump results for restoring production
- start clone and modify it's connection strings
- restore production SQL from mysqdump (it can takes a while, but is
much more faster then reindexing).
- start production.

But perhaps there is a better solution? For instance, is it possible to
start ERP5 in a way that it would not be writing to SQL database,
allowing to safely change connection strings? I was thinking about
disabling timer service in zope.conf for a while, but I'm not sure if it
is enough to be sure that there would be no SQL writes.

Regards, Jacek

[Łukasz K. Nowak]

Hello,

Post by Jacek Medrzycki
Hi.
We sometimes fell a need to clone current state of our client's
production ERP5 instance, for example to check client's complaint
without writing to production database.
Cloning the Zope database seems to be easy - just copy data.fs to new
location, there are even backup tools that do it on the fly without
stopping zope. However, there is a problem. Sql connection strings are
stored in ZODB, thus after starting a clone it tries to write to the
production sql database! If there are unfinished activities or so, the
state of production sql database could be modified before we change ERP5
connection strings. Then, mysql database would be inconsistent with
production ZODB! And reindexing is not the solution in production
environment, as it takes time and before finishing the ERP5 site is
partially unusable.
- stop production
- clone production ZODB and production SQL (with mysqldump), save
mysqldump results for restoring production
- start clone and modify it's connection strings
- restore production SQL from mysqdump (it can takes a while, but is
much more faster then reindexing).
- start production.
But perhaps there is a better solution? For instance, is it possible to
start ERP5 in a way that it would not be writing to SQL database,
allowing to safely change connection strings? I was thinking about
disabling timer service in zope.conf for a while, but I'm not sure if it
is enough to be sure that there would be no SQL writes.

We are using virtualization to workaround such problem. But when your
sql connection string contains hostname it is still dangerous.

Because you want to "block" any attempt of connection to original mysql,
you might think about:
- blocking port on firewall
- use selinux to temporarily block clone's connection to original mysql
socket/ip

After reconfiguration you may remove above locks.

Bye,
Luke

[Jacek Medrzycki]

Post by Łukasz K. Nowak
Because you want to "block" any attempt of connection to original mysql,
- blocking port on firewall
- use selinux to temporarily block clone's connection to original mysql
socket/ip

Well, I can just stop mysql. ;)
But there is a problem: if ERP5 can not communicate with mysql, it is
not possible to change connection strings, at least in ZMI. :(


J.