Re: [Slony1-general] 2 problems
| От | Andrew Hammond |
|---|---|
| Тема | Re: [Slony1-general] 2 problems |
| Дата | |
| Msg-id | 5a0a9d6f0711161038s2fada05r8b82a45ce89ec1a2@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [Slony1-general] 2 problems ("Lukas" <lukas@fmf.vtu.lt>) |
| Список | pgsql-novice |
On Nov 15, 2007 11:00 AM, Lukas <lukas@fmf.vtu.lt> wrote:
1) While it may be possible to use Gentoo in some fashion to achieve stability, it will always be associated with ricer performance tweaking via the random application of experimental CFLAGs, particularly when contrasted with for example debian or RHEL (if you want to stay in the Linux world).
1) People who are serious about running databases care a great deal about consistency, Gentoo fosters to opposite with their "tweak it yourself".
No. It may be possible with some non-trivial hacking, but if you care about your data enough to replicate it, then you should probably care enough to schedule appropriate downtimes to do maintenance correctly.
I'm curious how you can get a foreign key error from a subscribed table. That should be impossible since the triggers which implement foreign keys are "deactivated" by slony upon subscription. On the subscriber, using psql, please do \d+ kainos then same for padaliniu_grupes.
Did you have replication working correctly at some point? If so, please detail everything you've done (slonik scripts, any ddl) since your last known-good baseline.
Andrew
Hello, and thanks for answer,In two sentences, why?
>> on Gentoo Linux,
> I don't know how you decided on Gentoo as a platform for your database. It
> strikes me as a stupid choice.
1) While it may be possible to use Gentoo in some fashion to achieve stability, it will always be associated with ricer performance tweaking via the random application of experimental CFLAGs, particularly when contrasted with for example debian or RHEL (if you want to stay in the Linux world).
1) People who are serious about running databases care a great deal about consistency, Gentoo fosters to opposite with their "tweak it yourself".
>> DB is replicated with Slon version 1.2.0.> Once again, bad idea. For new clusters, you should always use the latestYes, I agree. One question: can I use different slon versions on different
> stable release, currently that is 1.2.12.
nodes in one replica?
No. It may be possible with some non-trivial hacking, but if you care about your data enough to replicate it, then you should probably care enough to schedule appropriate downtimes to do maintenance correctly.
>> Fist problem started with one node, with stopped to replicate with suchYes, all sets are on my replica.
>> error:
>>
>> 2007-11-15 13:17:21 EET ERROR remoteWorkerThread_1: "insert into
>> "public"."kainos"
>> (paslaugos,laikai,abonimentas,kaina,pastaba,rodyti,tipas,vienkartinis,gal
>>
>> ioja_nuo,galioja_iki,id,pradine_imoka,intervalas,intervalas_paskutinis,imoku_skaicius,viso_sumoketi,periodine_imoka,max_pirkiniu_suma,padalinys,padaliniu_gru
>> pe) values ('baseinas+treniruokliai ','Visos dienos
>> ','1 m<EB>nesio ','284.00','Bendra korta
>> ','t','V
>> isi','f',NULL,NULL,'1110',NULL,NULL,NULL,NULL,NULL,NULL,' 50.00
>> ','0','201');
>> " ERROR: insert or update on table "kainos" violates foreign key
>> constraint "fk_kainos_padaliniu_grupe"
>> DETAIL: Key (padaliniu_grupe)=(201) is not present in table
>> "padaliniu_grupes".
>>
>> Note that table "kainos" and table "padaliniu_grupes" are replicated!
>> only in two different sets.
>
>
> That's probably a bad idea. Unless you have a very good reason to put them
> in different sets, you should keep stuff that inter-relates together in a
> single set. Are both sets subscribed on your replica?
I'm curious how you can get a foreign key error from a subscribed table. That should be impossible since the triggers which implement foreign keys are "deactivated" by slony upon subscription. On the subscriber, using psql, please do \d+ kainos then same for padaliniu_grupes.
> PostgreSQL uses unique indexes to implement primary keys. But as I> mentionedYes, I agree, it just a try for work around.. Can you suggest something?
> before, making changes to your schema is probably not the right way to
> solve
> your problem.
Did you have replication working correctly at some point? If so, please detail everything you've done (slonik scripts, any ddl) since your last known-good baseline.
Andrew
В списке pgsql-novice по дате отправления: