Christopher Browne cbbrowne at ca.afilias.info
Thu Dec 3 11:35:24 PST 2009
P <user2037 at live.com> writes:
> Is it safe to send data changes via Slonik or is it wiser to make such
> changes via traditional API's to the master?

Yes.
No.
Maybe.

I'd think that it's *usually* preferable to do updates via doing I/U/D
requests against the "master" node.  That will automatically propagate,
and things work the same way whether you have Slony installed or not.

That is typically the natural answer.

More interesting is to ask in what cases it would be preferable or
definitely NOT DESIRABLE to use
EXECUTE SCRIPT.

- If you're making changes that wouldn't be processed identically on another
  database, then you mustn't use EXECUTE SCRIPT.

  Examples of this would include:
   - queries using locally-sensitive data, such as random(), NOW(), and
     such

   - queries that have the potential to have ambiguous results

     For instance:
          update my_table set attribute_a = 6 where my_id in
              (select my_id from my_table limit 500);

     This would become unambiguous if my_id is a unique key, and you
     specify an order:

          update my_table set attribute_a = 6 where my_id in
              (select my_id from my_table order by my_id limit 500);

     But if the selection criteria doesn't forcibly identify a unique
     set of tuples, it mightn't run the same on another node, even with
     an ORDER BY clause.

   In such cases, you *need* to submit changes directly to the master,
   and have them propagate via replicating the tuples.

- On versions of Slony-I prior to 2.0, EXECUTE SCRIPT establishes a big
  lock on all replicated tables (because it has to ALTER TABLE on every
  table to deactivate replication and then to turn it back on).

  If you need to cope with concurrent updates coming in, then using
  EXECUTE SCRIPT won't work out very happily!

  Even on 2.0, it'll still be pretty expensive to do such updates,
  albeit not with One Big Lock On Everything.

- If you're making DDL changes to a table, those are highly likely to
  need to go in via EXECUTE SCRIPT.

- Needing to construct (and likely test) an EXECUTE SCRIPT-based request
  requires quite a different structuring of the work (and thinking) than
  would be used for doing straight updates that are expected to be
  replicated.

  In particular, submitting a request via EXECUTE SCRIPT works a fair
  bit differently from just "attaching to the DB and doing the updates."

  I'd usually rather just "attach to the DB and do the updates."

Does that help, I hope?
-- 
let name="cbbrowne" and tld="ca.afilias.info" in String.concat "@" [name;tld];;
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"


More information about the Slony1-general mailing list