On 3/28/07, Andrew Edson <[EMAIL PROTECTED]> wrote: > I have been requested to look into making some modifications to our postgres > db setup, and see what changes will be needed to enable slony to handle the > changes. (We are running Slony 1.1.5, as best I can discern, using the log > shipping structure. I have been asked to try setting our system up without > logshipping, as well.)
If you are using slony log shipping then you must also be replicating to at least one live subscriber in order to generate the logs. Furthermore, I believe that log shipping is sorta broken prior to 1.2.6 or something in that era. Read the release notes for details. > In this particular case, I have been requested to > set up a test replication (using a copy of our original database) on two > test boxes. The problem is, one of the test boxes is already running > replication from the main database (the one I am to copy from) I believe the term for this is foot cannon. Do not do this, you will almost certainly screw up your production replication system. >, and the > schema for that db appears to include a specific set of instructions related > to the replication set for the original structure. (Appears to; I'm not > certain they are, but the name of the common thread is _cpc_replic, which > looks like a replication set from what I can gather off of the slony > documentation. If I am wrong in this, please set me straight.) I think the > part in question is the cluster; it's the part that goes in the > '$CLUSTERNAME' variable in the slon startup commands in the documentation. > > When trying to set up and run slon processes for the new 'test' setup, I am > getting warnings that the schema name I am trying to use does not exist. In > my previous (admittedly rather limited) tests of replication, this did not > seem to be a problem; it appeared that the system was creating the schema > on-the-fly as I ran the slon processes. It does not. I creates the schema when you use slonik init on the origin. > This is the main reason why I > believe it is the pre-existing schema data that I had to load to copy the > old db that is causing a problem for me. I am not sure of this, it is > simply my best guess. > > > Here is the error message I'm getting from this: > 10.10.10.176/srv/www/htdocs # slon NewAttest "dbname=test_attest > user=postgres host=10.10.10.176" > 2007-03-28 07:59:27 CST CONFIG main: slon version 1.1.5 starting up > 2007-03-28 07:59:27 CST ERROR cannot get sl_local_node_id - ERROR: schema > "_NewAttest" does not exist > 2007-03-28 07:59:27 CST FATAL main: Node is not initialized properly > > Also, the setup values for the slon script's variables are as follows: > CLUSTER=NewAttest > DBNAME1=test_attest > DBNAME2=test_attest > HOST1=10.10.10.176 > HOST2=10.10.10.175 > SLONY_USER=postgres > > > I am afraid to simply rename the schema (cluster?) for my test run to match > the schema name the older system uses. You need to remove the entire production replication schema on your test/dev system and then re-init it from scratch. > As I said, another database on one > of the test servers I am using is in fact part of the original replication > structure, and I'm afraid that if I try to create the new setup under the > same name I will hose something I need for that db. If it's part of the original replication cluster then you will almost certainly hose your entire production replication setup if you screw around with it. > Given the above, what is my best option here? Do I open the > schema-generating .sql file that I used to load my db and rename all > references to the schema, then drop and reload the db? Do I go ahead and > run the system under the old schema name, without worrying about hosing my > other database? Or is there some other option I'm not seeing here that > would be better? Separate your production environment from your dev/test/qa/whatever environment and treat it as a production environment. Otherwise you will cause Bad Things to happen. Andrew _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
