Re: Replication

Hi,

[ please keep CCing to the list (reply all), as this certainly isn't a
personal discussion and could help others. ]

anorganic anorganic wrote:
> my opinion:
> partitioning is vertical and horizontal, dived table into two or more
> parts.
>
> replicated only part of some object,here table = replicated two columns
> ins't partitioning, because table is same ;) and have one part = self table
> ;)

The main point is, you divide data *somehow* into partitions and grant
write rights to only *one* server for each partition, thus allowing you
to use a simpler master-slave replication.

> i want have
> s1 and s2
> tableA
> col1
> col2
> col3
>
> tableA is on s1 and s2 same design
> s1 change only col1, s2 change only col3
> is possible set replication on s1 only for col1 of tableA
> is possible set replication on s2 only for col3 of tableA
>
> this is not partitioning i think

How else would you call it? In what way is it different from what's
commonly known as vertical partitioning?

Couldn't you do what you want with the help of ordinary vertical
partitioning and using a VIEW viewA with all the columns col1, col2, col3?

> ok, sync is not saying something about when is transaction log send...

Uhm.. yes it does. It has to be sent before commit confirmation is sent
to the client (Postgres-R does some optimization here, but basically the
above statement still holds true). It is the async approach, which
doesn't say anything about when changes are sent to other servers.

> sync said: i coimmit transaction when all slaves send me commit :)
> asynch: i make change i commit this change and i send it to my slave. and i
> want do it fast as possible ;)

No matter *how* fast you do that, conflicts can arise if you don't
prevent them somehow.

The requirement to send changes as fast as possible in async replication
rings my alarm bell, because it sounds like your application cannot cope
with conflicts and wants to prevent them by minimizing the propagation
delays. That's prone to race conditions and probably won't work.

However, if you partition your data vertically and do per-table
master-slave replication, you of course don't have to worry about
conflicts, as there is only exactly one master.

Regards

Markus