|
Home > Archive > Slony1 PostgreSQL Replication > August 2005 > Multiple Slons
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Magnus Hagander 2005-08-05, 8:24 pm |
| People,
It is probably not totally uncommon to have multiple slon backends
running on the same machine, replicating different databases. For unix,
this is simple - you just start a separate slon daemon. For win32 it's
not as simple. I see three options for dealing with this on win32:
1) Do it the unix way, and require the user to install a separate
service for each database. This means we cannot use the installer to put
in the service. It will also require local admin rights in order to
admin slony, as well as making it harder to deal with complete
configuration from pgadmin.=20
The advantage with this option is that this will have the least effect
on the codebase, and zero effect on the Unix code.
2) Implement the capability for Slon to deal with multiple replication
engines at the same time.=20
The advantage with this option is that Unix people get to start a single
slon daemon as well. The disadvantage is that this is probably the most
complicated option, and will have a lot of impact on the current system.
3) Implement a "master slon service" that will start and control one or
more normal "slon" processes. It would read a separate config and just
launch several normal slons, keeping a lookout on them if they die, and
handle restarts etc. This could be done either only for win32, or for
both win32 and unix.
The advantage with this option is that single-instance slon is not
affected *at all*, and the code impact is minimal, while still helping
situations like the win32 one.
Doing option 3 specific for win32 will certianly make that part of the
code simpler, as it can make use of more win32 specific functions. I'm
doubtful if the functionality is actually needed under Unix - the
concept of starting multiple daemons (possibly just using a special
init-script) is fairly common there... That is, if option 3 is the way
to go at all.
Oh, and we must not forget - optoin 4, which I didn't think of at all,
and will learn about shortly.
I as personally leaning towards option 3 for win32 only, mainly because
I think it's what'll give us best functionality for the least amount of
work.=20
What do people think? Which is the best way to proceed?
//Magnus
| |
| Scott Marlowe 2005-08-05, 8:24 pm |
| On Fri, 2005-08-05 at 14:44, Magnus Hagander wrote:
> People,
>
> It is probably not totally uncommon to have multiple slon backends
> running on the same machine, replicating different databases. For unix,
> this is simple - you just start a separate slon daemon. For win32 it's
> not as simple. I see three options for dealing with this on win32:
I'd think putting all your data in multiple schemas in one database
would make for a decent compromise.
| |
| Magnus Hagander 2005-08-05, 8:24 pm |
| > > People,
> with this on win32:
>=20
> I'd think putting all your data in multiple schemas in one=20
> database would make for a decent compromise.
That may not always be possible, but it is an argument that says option
1 would hold in more cases. I think this will lead to complaints about
lacking functionality, but I'm certainly not sure about that...
//Magnus
| |
| Hannu Krosing 2005-08-05, 8:24 pm |
| On R, 2005-08-05 at 14:50 -0500, Scott Marlowe wrote:
> On Fri, 2005-08-05 at 14:44, Magnus Hagander wrote:
>
> I'd think putting all your data in multiple schemas in one database
> would make for a decent compromise.
How would it help with multiple slon daemons problem ?
--
Hannu Krosing <hannu-7C/ iILuz2RdeoWH0uzbU5w@
public.gmane.org>
| |
| Andreas Pflug 2005-08-05, 8:24 pm |
| Magnus Hagander wrote:[color=darkred
]
Certainly not. In most cases there was a reason to put the data in
different databases, not schemas. Example: Often the same app has to run
against several sets of data, but can't deal with schemas.
I'd opt for version 1), because this seems the most flexible way
especially in terms of controllability.
Regards,
Andreas
| |
| Scott Marlowe 2005-08-05, 8:24 pm |
| On Fri, 2005-08-05 at 16:38, Hannu Krosing wrote:
> On R, 2005-08-05 at 14:50 -0500, Scott Marlowe wrote:
>
> How would it help with multiple slon daemons problem ?
You wouldn't need them. You could just have one set of slon daemons
running to replicate all your data.
| |
| Rod Taylor 2005-08-05, 8:24 pm |
| On Fri, 2005-08-05 at 21:45 +0000, Andreas Pflug wrote:
> Magnus Hagander wrote:
>
> Certainly not. In most cases there was a reason to put the data in
> different databases, not schemas. Example: Often the same app has to run
> against several sets of data, but can't deal with schemas.
If you can give the application different databases, you can probably
give it several different users each of which has a different default
schema within the same database (woo for user configurable search
paths).
That said, I see no reason not to implement multi-database replication
if someone was willing to code it.
--
| |
| cbbrowne-swQf4SbcV9C7WVzo/KQ3Mw@public.gmane.org 2005-08-06, 3:23 am |
| > People,
>
> It is probably not totally uncommon to have multiple slon backends
> running on the same machine, replicating different databases. For unix,
> this is simple - you just start a separate slon daemon. For win32 it's
> not as simple. I see three options for dealing with this on win32:
>
> 1) Do it the unix way, and require the user to install a separate
> service for each database. This means we cannot use the installer to pu=
t
> in the service. It will also require local admin rights in order to
> admin slony, as well as making it harder to deal with complete
> configuration from pgadmin.
> The advantage with this option is that this will have the least effect
> on the codebase, and zero effect on the Unix code.
>
> 2) Implement the capability for Slon to deal with multiple replication
> engines at the same time.
> The advantage with this option is that Unix people get to start a singl=
e
> slon daemon as well. The disadvantage is that this is probably the most
> complicated option, and will have a lot of impact on the current system=
..
That strikes me as a mistake. It would add considerable complexity to
slon, and introduce new failure modes.
> 3) Implement a "master slon service" that will start and control one or
> more normal "slon" processes. It would read a separate config and just
> launch several normal slons, keeping a lookout on them if they die, and
> handle restarts etc. This could be done either only for win32, or for
> both win32 and unix.
> The advantage with this option is that single-instance slon is not
> affected *at all*, and the code impact is minimal, while still helping
> situations like the win32 one.
Makes sense to me. If I understand correctly, Win32 services are special
sorts of applications, which means that it wouldn't make sense to run thi=
s
on Unix.
> Doing option 3 specific for win32 will certianly make that part of the
> code simpler, as it can make use of more win32 specific functions. I'm
> doubtful if the functionality is actually needed under Unix - the
> concept of starting multiple daemons (possibly just using a special
> init-script) is fairly common there... That is, if option 3 is the way
> to go at all.
>
>
> Oh, and we must not forget - optoin 4, which I didn't think of at all,
> and will learn about shortly.
>
>
> I as personally leaning towards option 3 for win32 only, mainly because
> I think it's what'll give us best functionality for the least amount of
> work.
>
> What do people think? Which is the best way to proceed?
"Option #3" makes a lot of sense to me...
| |
| Magnus Hagander 2005-08-06, 7:24 am |
| > > It is probably not totally uncommon to have multiple slon backends=20
> with this on win32:
> installer to=20
> in order=20
> least effect=20
> replication=20
> is probably=20
> on the current system.
>=20
> That strikes me as a mistake. It would add considerable=20
> complexity to slon, and introduce new failure modes.
That's exactly what I thought - complexity makes for failures..
> control one=20
> config and=20
> still helping=20
>=20
> Makes sense to me. If I understand correctly, Win32 services=20
> are special sorts of applications, which means that it=20
> wouldn't make sense to run this on Unix.
Yes, they are somehwat special. With regards to slon in the way I was
thinking, you could think of them as a separate "init" process - read a
config file, make sure other programs (the actual slon.exe processes)
are running, and restart them if they fail.
>=20
> "Option #3" makes a lot of sense to me...
//Magnus
| |
| Andreas Pflug 2005-08-06, 8:23 pm |
| Rod Taylor wrote:
> On Fri, 2005-08-05 at 21:45 +0000, Andreas Pflug wrote:
>
>
>
> If you can give the application different databases, you can probably
> give it several different users each of which has a different default
> schema within the same database
No. This is merely an assumption. You can't have too much fantasy how
weird some apps behave, with users/dbnames/... hardcoded.
Regards,
Andreas
|
|
|
|
|