Re: Using RelStorage 3.0a in production

Hi,

> On Sep 30, 2019, at 02:51, Brice Vissi=C3=A8re <[email protected]> wrote:
>=20
> - all the tests were ran with RelStorage 3.0a (a1 to a11), which is still=
 under development. If we choose to go with this development version in pro=
duction, I guess we will do it "at our own risks". We are wondering what ki=
nd of risks? And especially, are there points we should focus on and check,=
 in order to minimize those risks?

We are also using RelStorage 3.0 in what I think is a fairly large producti=
on setting (for example, one large single database is around 100GB and 33 m=
illion objects; there are currently about 180 client connections to it). In=
 fact, scaling RelStorage in several different ways has been the general th=
eme for the 3.0 series.

We work hard to make sure that each release is as stable as possible. We tr=
y especially hard to be sure that it doesn't introduce chances for database=
 corruption (but we can still make mistakes!). Any bugs we do spot we try t=
o address as quickly as possible. We usually give each release one to two w=
eeks in QA testing before putting it in production (though not always).

The main risks, I would say, are that things are still changing from releas=
e to release. Options and configuration settings may come and go; the forma=
t of the persistent cache may change; auxiliary tables may be added or alte=
red; stored procedures may change (in such a way that rolling releases aren=
't possible and a complete shutdown is required[1]), and so on. That said, =
I think we're closing in on a final feature set for 3.0 and the rate of cha=
nge in things like that is slowing down.


> - our tests were performed with direct connections to postgresql; we shou=
ld also still use a ZEO instance in front of postgresql. We did not try it.=
 Is this a good/recommended setup?

I wouldn't put ZEO in front of RelStorage on PostgreSQL (or any other RDBMS=
). ZEO doesn't understand and expose that RelStorage is natively an IMVCCSt=
orage and never calls new_instance(), so you wind up attempting to multiple=
x all your client connections over a single PostgreSQL connection. That ten=
ds not to go well, *especially* not in history-free RelStorage.=20

HTH,
Jason

[1] https://github.com/zodb/relstorage/issues/332

--=20
You received this message because you are subscribed to the Google Groups "=
zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/=
zodb/2528A7B7-1664-485F-8951-E35343B59F50%40nextthought.com.