From 8af7e2c104b104505cf9de5900aed90641c3d69f Mon Sep 17 00:00:00 2001 From: Christopher Browne Date: Tue, 17 Oct 2006 18:45:15 +0000 Subject: [PATCH] Quite a number of revisions to the "Best Practices" documentation. --- doc/adminguide/bestpractices.sgml | 48 +++++++++++++++++++------------ 1 file changed, 29 insertions(+), 19 deletions(-) diff --git a/doc/adminguide/bestpractices.sgml b/doc/adminguide/bestpractices.sgml index e6ecfe5d..75fdfea5 100644 --- a/doc/adminguide/bestpractices.sgml +++ b/doc/adminguide/bestpractices.sgml @@ -1,4 +1,4 @@ - + &slony1; <quote>Best Practices</quote> best practices for &slony1; usage @@ -29,19 +29,20 @@ of policies you might want to consider. system, with the result that there are almost an innumerable set of places where problems can arise. - As a natural result, maintaining a clean environment is really -valuable, as any sort of environmental messiness can -either cause unexpected problems or mask the real problem. + As a natural result, maintaining a clean, consistent +environment is really valuable, as any sort of environmental +messiness can either cause unexpected problems or mask +the real problem. Numerous users have reported problems resulting from mismatches between &slony1; versions, local libraries, and &postgres; libraries. -Details count; you need to be clear on what hosts are running what +Details count: you need to be clear on what hosts are running what versions of what software. - This is normally a matter of being meticulous about checking -what versions of software are in place everywhere, and is the natural -result of having a distributed system comprised of a large number of -components that need to match. + This is normally a matter of being disciplined about how your +software is deployed, and the challenges represent a natural +consequence of being a distributed system comprised of a large number +of components that need to match. If a slonik script does not run as expected in a @@ -74,7 +75,7 @@ Daylight Savings Time. The geographically unbiased choice seems to be TZ=UTC or TZ=GMT, and to make sure that -systems are in sync by using NTP to syncchronize clocks +systems are in sync by using NTP to synchronize clocks throughout the environment. See also . @@ -118,11 +119,13 @@ should be of what should fail to what, as opposed to trying to automate it. But knowing what to do ahead of time cuts down on the number of mistakes made. - At Afilias, some internal The 3AM Unhappy DBA's Guide -to... guides have been created to provide checklists of -what to do when certain unhappy events take place; this -sort of material is highly specific to the applications running, so -you would need to generate your own such documents. + At Afilias, a variety of internal The 3AM Unhappy +DBA's Guide to... guides have been created to provide +checklists of what to do when certain unhappy events +take place. This sort of material is highly specific to the +environment and the set of applications running there, so you would +need to generate your own such documents. This is one of the vital +components of any disaster recovery preparations. @@ -197,7 +200,9 @@ load work. In early versions of &slony1;, it was frequently the case that connections could get a bit deranged which restarting &lslon;s would clean up. This has become much more rare, but it has -occasionally proven useful to restart the &lslon;. +occasionally proven useful to restart the &lslon;. If there has been +any network derangement, this can clear up the issue of +defunct database connections. The Database Schema Changes @@ -516,8 +521,8 @@ recreating each index ex nihilo, as the latter can take substantial advantage of sort memory. In &slony1; version 1.1.5 and later versions, indices are -dropped and recreated automatically, which mostly eliminates the need -for this. +dropped and recreated automatically, which effectively invalidates +this practice. If there are large numbers of updates taking place as @@ -552,7 +557,12 @@ careful selection of &lslon; parameters: master node, an index on sl_log_1(log_xid) . If it doesn't exist, as the &slony1; instance was set up before version 1.1.1, see slony1_base.sql for -the exact form that the index setup should take. +the exact form that the index setup should take. + + In 1.2, there is a process that runs automatically to add +partial indexes by origin node number, which should be the optimal +form for such an index to take. + On the subscriber's &lslon;, increase the number of SYNC events processed together, with