From: Christopher Browne Date: Fri, 19 Jul 2013 22:27:02 +0000 (-0400) Subject: More fixes to anachonisms X-Git-Tag: REL_2_2_0_B5~16 X-Git-Url: http://git.postgresql.org/gitweb/edit?a=commitdiff_plain;h=822a08560e08c112ddc5ea708f423b4e4f9d4bd6;p=slony1-engine.git More fixes to anachonisms --- diff --git a/doc/adminguide/faq.sgml b/doc/adminguide/faq.sgml index 8db87b92..1ba2cde0 100644 --- a/doc/adminguide/faq.sgml +++ b/doc/adminguide/faq.sgml @@ -591,8 +591,8 @@ could also announce an admin to take a look... Both sl_log_1 and sl_log_2 are continuing to grow, and sl_log_1 is never getting -truncated. What's wrong? - +truncated. What's wrong? (This could be true for subsequent +versions, as well.) This is symptomatic of the same issue as above with dropping replication: if there are still old connections lingering @@ -664,7 +664,10 @@ structure of the replication tree changes. Version 1.1 provides better tools to help manage -this. +this, and later versions of &slony1; hopefully +populate the listener table automatically and +correctly so that you should not encounter this +problem. @@ -732,6 +735,16 @@ each one manages. If the &lslon; runs on the same server as the database it manages, any networking failure that could interrupt local connections would be likely to be serious enough to threaten the entire server. + + It is likely that the several hours TCP +timeout is rather longer than it should be in these days where people +expect their servers to be pretty synchronously connected. +Configuring the &postgres; to use much shorter timeouts is likely a +wise idea. The relevant postgresql.conf +parameters are tcp_keepalives_idle, +tcp_keepalives_interval, and +tcp_keepalives_count. See man 7 tcp +for more details. @@ -827,60 +840,6 @@ SET event, switch to a non-SSL &postgres; connection. &slony1; FAQ: Configuration Issues - -Slonik fails - cannot load &postgres; library - -PGRES_FATAL_ERROR load '$libdir/xxid'; - - When I run the sample setup script I get an error message similar -to: - - -stdin:64: PGRES_FATAL_ERROR load '$libdir/xxid'; - ERROR: LOAD: -could not open file '$libdir/xxid': No such file or directory - - - Evidently, you haven't got the -xxid.so library in the $libdir -directory that the &postgres; instance is -using. Note that the &slony1; components -need to be installed in the &postgres; -software installation for each and every one of -the nodes, not just on the origin node. - -This may also point to there being some other mismatch between -the &postgres; binary instance and the &slony1; instance. If you -compiled &slony1; yourself, on a machine that may have multiple -&postgres; builds lying around, it's possible that the -slon or slonik binaries are asking to load something that isn't -actually in the library directory for the &postgres; database cluster -that it's hitting. - -Long and short: This points to a need to audit -what installations of &postgres; and &slony1; you have in place on the -machine(s). Unfortunately, just about any mismatch will cause things -not to link up quite right. -... - - Life is simplest if you only have one set of &postgres; -binaries on a given server; in that case, there isn't a wrong -place in which &slony1; components might get installed. If -you have several software installs, you'll have to verify that the -right versions of &slony1; components are associated with the right -&postgres; binaries. - - - I tried creating a CLUSTER NAME with a "-" in it. -That didn't work. - - &slony1; uses the same rules for unquoted identifiers -as the &postgres; main parser, so no, you probably shouldn't put a "-" -in your identifier name. - - You may be able to defeat this by putting quotes around -identifier names, but it's still liable to bite you some, so this is -something that is probably not worth working around. - - ps finds passwords on command line @@ -922,6 +881,10 @@ adding it. See slony1_base.sql for an example of how to create the index. + + That's not quite the end of the story; a critical query +had the potential to scan the entirety of these log tables even in +&slony1; 2.1. I need to rename a column that is in the @@ -963,65 +926,6 @@ the alteration to the subscriber, it can retry the new column names, work just fine. - - I have a &postgres; 7.2-based system that I -really, really want to use &slony1; to help me -upgrade it to 8.0. What is involved in getting &slony1; to work for -that? - - - Rod Taylor has reported the following... - - - This is approximately what you need to do: - -Take the 7.3 templates and copy them to 7.2 -- or otherwise - hardcode the version your using to pick up the 7.3 templates -Remove all traces of schemas from the code and sql templates. I - basically changed the "." to an "_". - Bunch of work related to the XID datatype and functions. For - example, Slony creates CASTs for the xid to xxid and back -- but - 7.2 cannot create new casts that way so you need to edit system - tables by hand. I recall creating an Operator Class and editing - several functions as well. -sl_log_1 will have severe performance problems with any kind of - data volume. This required a number of index and query changes - to optimize for 7.2. 7.3 and above are quite a bit smarter in - terms of optimizations they can apply. - Don't bother trying to make sequences work. Do them by hand - after the upgrade using pg_dump and grep. - - Of course, now that you have done all of the above, it's not compatible -with standard Slony now. So you either need to implement 7.2 in a less -hackish way, or you can also hack up slony to work without schemas on -newer versions of &postgres; so they can talk to each other. - - Almost immediately after getting the DB upgraded from 7.2 to 7.4, we -deinstalled the hacked up Slony (by hand for the most part), and started -a migration from 7.4 to 7.4 on a different machine using the regular -Slony. This was primarily to ensure we didn't keep our system catalogues -which had been manually fiddled with. - - - All that said, we upgraded a few hundred GB from 7.2 to 7.4 -with about 30 minutes actual downtime (versus 48 hours for a dump / -restore cycle) and no data loss. - - - - That represents a sufficiently ugly set of -hackery that the developers are exceedingly reluctant -to let it anywhere near to the production code. If someone were -interested in productionizing this, it would probably -make sense to do so based on the &slony1; 1.0 branch, with the express -plan of not trying to keep much in the way of -forwards compatibility or long term maintainability of replicas. - - - You should only head down this road if you are sufficiently -comfortable with &postgres; and &slony1; that you are prepared to hack -pretty heavily with the code. - I had a network glitch that led to my @@ -2508,7 +2412,120 @@ what &lslonik; does by hand: + +Slonik fails - cannot load &postgres; library - +PGRES_FATAL_ERROR load '$libdir/xxid'; + + When I run the sample setup script I get an error message similar +to: + + +stdin:64: PGRES_FATAL_ERROR load '$libdir/xxid'; - ERROR: LOAD: +could not open file '$libdir/xxid': No such file or directory + + + Evidently, you haven't got the +xxid.so library in the $libdir +directory that the &postgres; instance is +using. Note that the &slony1; components +need to be installed in the &postgres; +software installation for each and every one of +the nodes, not just on the origin node. + +This may also point to there being some other mismatch between +the &postgres; binary instance and the &slony1; instance. If you +compiled &slony1; yourself, on a machine that may have multiple +&postgres; builds lying around, it's possible that the +slon or slonik binaries are asking to load something that isn't +actually in the library directory for the &postgres; database cluster +that it's hitting. + +Long and short: This points to a need to audit +what installations of &postgres; and &slony1; you have in place on the +machine(s). Unfortunately, just about any mismatch will cause things +not to link up quite right. +... + + Life is simplest if you only have one set of &postgres; +binaries on a given server; in that case, there isn't a wrong +place in which &slony1; components might get installed. If +you have several software installs, you'll have to verify that the +right versions of &slony1; components are associated with the right +&postgres; binaries. + + + I tried creating a CLUSTER NAME with a "-" in it. +That didn't work. + + &slony1; uses the same rules for unquoted identifiers +as the &postgres; main parser, so no, you probably shouldn't put a "-" +in your identifier name. + + You may be able to defeat this by putting quotes around +identifier names, but it's still liable to bite you some, so this is +something that is probably not worth working around. + + + + + I have a &postgres; 7.2-based system that I +really, really want to use &slony1; to help me +upgrade it to 8.0. What is involved in getting &slony1; to work for +that? + + + Rod Taylor has reported the following... + + This is approximately what you need to do: + +Take the 7.3 templates and copy them to 7.2 -- or otherwise + hardcode the version your using to pick up the 7.3 templates +Remove all traces of schemas from the code and sql templates. I + basically changed the "." to an "_". + Bunch of work related to the XID datatype and functions. For + example, Slony creates CASTs for the xid to xxid and back -- but + 7.2 cannot create new casts that way so you need to edit system + tables by hand. I recall creating an Operator Class and editing + several functions as well. +sl_log_1 will have severe performance problems with any kind of + data volume. This required a number of index and query changes + to optimize for 7.2. 7.3 and above are quite a bit smarter in + terms of optimizations they can apply. + Don't bother trying to make sequences work. Do them by hand + after the upgrade using pg_dump and grep. + + Of course, now that you have done all of the above, it's not compatible +with standard Slony now. So you either need to implement 7.2 in a less +hackish way, or you can also hack up slony to work without schemas on +newer versions of &postgres; so they can talk to each other. + + Almost immediately after getting the DB upgraded from 7.2 to 7.4, we +deinstalled the hacked up Slony (by hand for the most part), and started +a migration from 7.4 to 7.4 on a different machine using the regular +Slony. This was primarily to ensure we didn't keep our system catalogues +which had been manually fiddled with. + + + All that said, we upgraded a few hundred GB from 7.2 to 7.4 +with about 30 minutes actual downtime (versus 48 hours for a dump / +restore cycle) and no data loss. + + + + That represents a sufficiently ugly set of +hackery that the developers are exceedingly reluctant +to let it anywhere near to the production code. If someone were +interested in productionizing this, it would probably +make sense to do so based on the &slony1; 1.0 branch, with the express +plan of not trying to keep much in the way of +forwards compatibility or long term maintainability of replicas. + + + You should only head down this road if you are sufficiently +comfortable with &postgres; and &slony1; that you are prepared to hack +pretty heavily with the code. +