[prev in list] [next in list] [prev in thread] [next in thread]
List: slony1-general
Subject: Re: [Slony1-general] Wish to run altperl scripts on master rather than slave
From: Mark Steben <mark.steben () drivedominion ! com>
Date: 2015-02-24 18:31:47
Message-ID: CADyzmyySNV0OQ3z7btOgJLn80eJZHb9gAcQYidgcM7V_8zk=Fw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks for the clarification Chris. My problem had to do with a mismatch of
slony versions
between master and slave on our test platform. That being fixed we can
easily run slon and slonik
on our master. I will consider your recommendation to run these commands
on a non-postgres-backend
server.
On Thu, Feb 19, 2015 at 3:05 PM, Christopher Browne <cbbrowne@afilias.info>
wrote:
> On Thu, Feb 19, 2015 at 11:59 AM, Mark Steben <
> mark.steben@drivedominion.com> wrote:
>
>> Good morning,
>>
>> We are running the following on both master and slave: (a simple 1 master
>> to 1 slave configuration)
>> postgresql 9.2.5
>> slony1-2.2.2
>> x86_64 GNU/Linux
>>
>> We currently run altperl scripts to kill / start slon daemons from the
>> slave:
>> cd ...bin folder
>> ./slon_kill -c .../slon_tools.....conf
>> and
>> ./slon_start -c ../slon_tools...conf 1 (and 2)
>>
>> Because we need to run maintenance on the replicated db on the master
>> without slony running I would like to run these commands on the master
>> before and after the maintenance. Since the daemons now run on the slave
>> when I attempt to run these commands on the master the daemons aren't
>> found. Is
>> there a prescribed way to accomplish this? I could continue to run them
>> on the
>> slave and send a flag to the master when complete but I'd like to take a
>> simpler approach if possible.
>> Any insight appreciated. Thank you.
>>
>
> There are three things you are identifying here, and they are each quite
> independent of each other:
>
> a) Each database participating in replication is a "cluster node", and
> will run whereever it happens to run
>
> b) Each node requires a slon process that manages replicating data to that
> node, as well as bookkeeping (e.g. - managing the flow of replication
> events)
>
> c) Slonik is the tool that manages configuration of the cluster; it must
> have access to all of the nodes that it is to manage
>
> The only one of those things that needs to run in a particular place is
> the set of Postgres databases. (And you get to pick where they run.)
>
> There is no "prescribed way" to run the slon processes of b); you are free
> to run those processes where ever you prefer. We have found it useful to
> run all the slon processes for the replicas within a given data centre on
> the same host, as it is generally more convenient to manage logs and
> restart processes if they are in one place. You are apparently running
> them on the same host that is also hosting one of the replicated databases;
> nothing wrong with that.
>
> If you want to run slonik on another host, that's fine, but, as observed,
> if you need to also do management of slon processes (e.g. - need to restart
> them), it tends to be convenient to run slonik on the same node so that
> your shell scripts can both manage the slon processes and the slonik
> scripts.
>
> The approach we have tended to take has been to define a "database
> administration" host which hosts both slons and slonik. That seems to be
> most convenient. Commonly, we have added a host (real or virtual) that is
> devoted to this sort of thing, separate from the hosts supporting Postgres
> backends.
>
> That adds an extra host, so I don't think it's entirely fair to call it a
> "simpler approach"; by having a separate host, we don't need to think about
> whether that host is hosting an origin or a subscriber, or to imagine we
> need to shift database management tasks elsewhere supposing we reshape a
> cluster. We just assume "connect to the DB App Server and manage things
> from there."
>
--
*Mark Steben*
Database Administrator
@utoRevenue <http://www.autorevenue.com/> | Autobase
<http://www.autobase.net/>
CRM division of Dominion Dealer Solutions
95D Ashley Ave.
West Springfield, MA 01089
t: 413.327-3045
f: 413.383-9567
www.fb.com/DominionDealerSolutions
www.twitter.com/DominionDealer
www.drivedominion.com <http://www.autorevenue.com/>
<http://autobasedigital.net/marketing/DD12_sig.jpg>
[Attachment #5 (text/html)]
<div dir="ltr"><div><div><div>Thanks for the clarification Chris. My problem had to \
do with a mismatch of slony versions <br></div>between master and slave on our test \
platform. That being fixed we can easily run slon and slonik<br></div>on our \
master. I will consider your recommendation to run these commands on a \
non-postgres-backend <br></div>server.<br></div><div class="gmail_extra"><br><div \
class="gmail_quote">On Thu, Feb 19, 2015 at 3:05 PM, Christopher Browne <span \
dir="ltr"><<a href="mailto:cbbrowne@afilias.info" \
target="_blank">cbbrowne@afilias.info</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><span class="">On Thu, Feb 19, 2015 at 11:59 \
AM, Mark Steben <span dir="ltr"><<a href="mailto:mark.steben@drivedominion.com" \
target="_blank">mark.steben@drivedominion.com</a>></span> wrote:<br></span><div \
class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div \
dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>Good \
morning,<br><br></div>We are running the following on both master and slave: (a \
simple 1 master to 1 slave configuration)<br></div> postgresql 9.2.5<br></div> \
slony1-2.2.2<br> x86_64 GNU/Linux<br><br></div>We currently run altperl \
scripts to kill / start slon daemons from the slave:<br></div> cd ...bin \
folder<br></div> ./slon_kill -c .../slon_tools.....conf <br></div> \
and<br></div> ./slon_start -c ../slon_tools...conf 1 (and 2)<br><br></div> \
Because we need to run maintenance on the replicated db on the master without
slony running I would like to run these commands on the master before
and after the maintenance. Since the daemons now run on the slave when I
attempt to run these commands on the master the daemons aren't found.
Is<br></div>there a prescribed way to accomplish this? I could continue to run them \
on the<br></div>slave and send a flag to the master when complete but I'd like to \
take a simpler approach if possible. <br></div> Any insight appreciated. Thank \
you.<br></div></blockquote><div><br></div></span><div>There are three things you are \
identifying here, and they are each quite independent of each other:<br><br>a) Each \
database participating in replication is a "cluster node", and will run \
whereever it happens to run<br><br>b) Each node requires a slon process that manages \
replicating data to that node, as well as bookkeeping (e.g. - managing the flow of \
replication events)<br><br>c) Slonik is the tool that manages configuration of the \
cluster; it must have access to all of the nodes that it is to \
manage<br><br></div><div>The only one of those things that needs to run in a \
particular place is the set of Postgres databases. (And you get to pick where they \
run.)<br><br></div><div>There is no "prescribed way" to run the slon \
processes of b); you are free to run those processes where ever you prefer. We have \
found it useful to run all the slon processes for the replicas within a given data \
centre on the same host, as it is generally more convenient to manage logs and \
restart processes if they are in one place. You are apparently running them on the \
same host that is also hosting one of the replicated databases; nothing wrong with \
that.<br><br></div><div>If you want to run slonik on another host, that's fine, \
but, as observed, if you need to also do management of slon processes (e.g. - need to \
restart them), it tends to be convenient to run slonik on the same node so that your \
shell scripts can both manage the slon processes and the slonik \
scripts.<br><br></div><div>The approach we have tended to take has been to define a \
"database administration" host which hosts both slons and slonik. That \
seems to be most convenient. Commonly, we have added a host (real or virtual) that \
is devoted to this sort of thing, separate from the hosts supporting Postgres \
backends.<br><br></div><div>That adds an extra host, so I don't think it's \
entirely fair to call it a "simpler approach"; by having a separate host, \
we don't need to think about whether that host is hosting an origin or a \
subscriber, or to imagine we need to shift database management tasks elsewhere \
supposing we reshape a cluster. We just assume "connect to the DB App Server \
and manage things from there."<br></div></div></div></div> \
</blockquote></div><br><br clear="all"><br>-- <br><div \
class="gmail_signature"><div><span><font color="#888888"><span \
style="font-family:Calibri;font-size:11pt"><span style="color:rgb(51,51,51)"><b>Mark \
Steben</b></span> </span><br> Database Administrator<span \
style="font-family:"Century Gothic";font-size:8pt"><span \
style="color:rgb(51,51,51)"></span><br><a \
style="color:rgb(79,129,189);font-size:8pt;font-weight:bold;text-decoration:none" \
href="http://www.autorevenue.com/" target="_blank">@utoRevenue</a> <span \
style="color:rgb(79,129,189);font-size:10pt">|</span> <a \
style="color:rgb(79,129,189);font-size:8pt;font-weight:bold;text-decoration:none" \
href="http://www.autobase.net/" target="_blank">Autobase</a> <span \
style="color:rgb(79,129,189);font-size:10pt"></span> <br> <span \
style="color:rgb(79,129,189);font-size:8pt;font-weight:bold;text-decoration:none">CRM \
division of Dominion Dealer Solutions</span> <br><span \
style="color:gray;font-size:8pt">95D Ashley Ave.<br>West Springfield, MA 01089</span> \
<br> <span style="color:gray;font-size:8pt">t: <a \
value="+14132434800">413.327-3045</a></span> <br><span \
style="color:gray;font-size:8pt">f: <a value="+14132434800">413.383-9567</a></span> \
</span></font></span></div><p><span><font color="#888888"><span \
style="font-family:"Century Gothic";font-size:8pt"><a \
href="http://www.fb.com/DominionDealerSolutions" \
target="_blank">www.fb.com/DominionDealerSolutions</a><br><a \
href="http://www.twitter.com/DominionDealer" \
target="_blank">www.twitter.com/DominionDealer</a><br><span \
style="color:gray;font-size:8pt"> <a href="http://www.autorevenue.com/" \
target="_blank">www.drivedominion.com</a><br><br><a \
href="http://autobasedigital.net/marketing/DD12_sig.jpg" \
target="_blank"></a><br><br></span></span></font></span><br><span><font \
color="#888888"><span style="font-family:"Century \
Gothic";font-size:8pt"><span \
style="color:gray;font-size:8pt"><br></span></span></font></span></p><font \
color="#888888"></font></div> </div>
_______________________________________________
Slony1-general mailing list
Slony1-general@lists.slony.info
http://lists.slony.info/mailman/listinfo/slony1-general
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic