From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Replication and coding good practices |
Date: | 2009-06-29 11:11:43 |
Message-ID: | 1246273903.11346.15.camel@ayaki |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, 2009-06-28 at 09:01 -0700, David Fetter wrote:
> > Are there any rules of thumb to consider for making an application
> > easier to work with a "general" replication solution?
> >
> > The applications I mostly deal with are e-commerce sites.
>
> It really depends on what replication solution you choose, along with
> the environment you're deploying into.
... and why you need replication. Reliability/Availability? Data storage
redundancy? Performance? And if performance, read-mostly performance or
write-heavy performance?
> That said, I've noticed that the things that are generally good
> practice help you even more when you're doing replication.
>
> Practices I've seen help directly:
>
> * Separate read users and code from write users and code.
>
> * Separate DDL from both of the above.
>
> * Make DDL changes part of your deployment process and only allow them
> in files which track in your SCM system.
Version your schema, storing the schema version in a 1-row table or even
as a stable function. This makes it much easier for deployment tools or
staff to easily see what needs to be done to get the schema and app to
the latest version - there's no "what the hell is the current state of
this thing, anyway?" to worry about.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | durumdara | 2009-06-29 11:36:59 | Python client + select = locked resources??? |
Previous Message | Torsten Zühlsdorff | 2009-06-29 10:43:22 | Re: masking the code |