/usr/share/doc/slony1-2-doc/adminguide/mkservice.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>mkservice </TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:slony1-general@lists.slony.info"><LINK
REL="HOME"
TITLE="Slony-I 2.2.5 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Additional Utilities"
HREF="additionalutils.html"><LINK
REL="PREVIOUS"
TITLE=" Log Files"
HREF="logrotation.html"><LINK
REL="NEXT"
TITLE=" Slony-I Test Suites "
HREF="testing.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> 2.2.5 Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="logrotation.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="additionalutils.html"
>Fast Backward</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 6. Additional Utilities</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="additionalutils.html"
>Fast Forward</A
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="testing.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="MKSERVICE"
>6.5. mkservice</A
></H1
><A
NAME="AEN4815"
></A
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN4817"
>6.5.1. slon-mkservice.sh</A
></H2
><P
> Create a slon service directory for use with svscan from
daemontools.  This uses multilog in a pretty basic way, which seems to
be standard for daemontools / multilog setups. If you want clever
logging, see logrep below. Currently this script has very limited
error handling capabilities.</P
><P
> For non-interactive use, set the following environment
variables.  <TT
CLASS="ENVAR"
>BASEDIR</TT
> <TT
CLASS="ENVAR"
>SYSUSR</TT
>
<TT
CLASS="ENVAR"
>PASSFILE</TT
> <TT
CLASS="ENVAR"
>DBUSER</TT
> <TT
CLASS="ENVAR"
>HOST</TT
>
<TT
CLASS="ENVAR"
>PORT</TT
> <TT
CLASS="ENVAR"
>DATABASE</TT
> <TT
CLASS="ENVAR"
>CLUSTER</TT
>
<TT
CLASS="ENVAR"
>SLON_BINARY</TT
> If any of the above are not set, the script
asks for configuration information interactively.</P
><P
></P
><UL
><LI
><P
><TT
CLASS="ENVAR"
>BASEDIR</TT
> where you want the service directory structure for the slon
to be created. This should <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>not</I
></SPAN
> be the <TT
CLASS="FILENAME"
>/var/service</TT
> directory.</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>SYSUSR</TT
> the unix user under which the slon (and multilog) process should run.</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>PASSFILE</TT
> location of the <TT
CLASS="FILENAME"
>.pgpass</TT
> file to be used. (default <TT
CLASS="FILENAME"
>~sysusr/.pgpass</TT
>)</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>DBUSER</TT
> the postgres user the slon should connect as (default slony)</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>HOST</TT
> what database server to connect to (default localhost)</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>PORT</TT
> what port to connect to (default 5432)</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>DATABASE</TT
> which database to connect to (default dbuser)</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>CLUSTER</TT
> the name of your Slony1 cluster? (default database)</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>SLON_BINARY</TT
> the full path name of the slon binary (default <TT
CLASS="COMMAND"
>which slon</TT
>)</P
></LI
></UL
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN4863"
>6.5.2. logrep-mkservice.sh</A
></H2
><A
NAME="AEN4865"
></A
><P
>This uses <TT
CLASS="COMMAND"
>tail -F</TT
> to pull data from log files allowing
you to use multilog filters (by setting the CRITERIA) to create
special purpose log files. The goal is to provide a way to monitor log
files in near realtime for <SPAN
CLASS="QUOTE"
>"interesting"</SPAN
> data without either
hacking up the initial log file or wasting CPU/IO by re-scanning the
same log repeatedly.</P
><P
>For non-interactive use, set the following environment
variables.  <TT
CLASS="ENVAR"
>BASEDIR</TT
> <TT
CLASS="ENVAR"
>SYSUSR</TT
> <TT
CLASS="ENVAR"
>SOURCE</TT
>
<TT
CLASS="ENVAR"
>EXTENSION</TT
> <TT
CLASS="ENVAR"
>CRITERIA</TT
> If any of the above are not set,
the script asks for configuration information interactively.</P
><P
></P
><UL
><LI
><P
><TT
CLASS="ENVAR"
>BASEDIR</TT
> where you want the service directory structure for the logrep
to be created. This should <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>not</I
></SPAN
> be the <TT
CLASS="FILENAME"
>/var/service</TT
> directory.</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>SYSUSR</TT
> unix user under which the service should run.</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>SOURCE</TT
> name of the service with the log you want to follow.</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>EXTENSION</TT
> a tag to differentiate this logrep from others using the same source.</P
></LI
><LI
><P
><TT
CLASS="ENVAR"
>CRITERIA</TT
> the multilog filter you want to use.</P
></LI
></UL
><P
> A trivial example of this would be to provide a log file of all slon
ERROR messages which could be used to trigger a nagios alarm.
<TT
CLASS="COMMAND"
>EXTENSION='ERRORS'</TT
>
<TT
CLASS="COMMAND"
>CRITERIA="'-*' '+* * ERROR*'"</TT
>
(Reset the monitor by rotating the log using <TT
CLASS="COMMAND"
>svc -a $svc_dir</TT
>)</P
><P
> A more interesting application is a subscription progress log.
<TT
CLASS="COMMAND"
>EXTENSION='COPY'</TT
>
<TT
CLASS="COMMAND"
>CRITERIA="'-*' '+* * ERROR*' '+* * WARN*' '+* * CONFIG enableSubscription*' '+* * DEBUG2 remoteWorkerThread_* prepare to copy table*' '+* * DEBUG2 remoteWorkerThread_* all tables for set * found on subscriber*' '+* * DEBUG2 remoteWorkerThread_* copy*' '+* * DEBUG2 remoteWorkerThread_* Begin COPY of table*' '+* * DEBUG2 remoteWorkerThread_* * bytes copied for table*' '+* * DEBUG2 remoteWorkerThread_* * seconds to*' '+* * DEBUG2 remoteWorkerThread_* set last_value of sequence*' '+* * DEBUG2 remoteWorkerThread_* copy_set*'"</TT
></P
><P
>If you have a subscription log then it's easy to determine if a given
slon is in the process of handling copies or other subscription activity.
If the log isn't empty, and doesn't end with a 
<TT
CLASS="COMMAND"
>"CONFIG enableSubscription: sub_set:1"</TT
>
(or whatever set number you've subscribed) then the slon is currently in
the middle of initial copies.</P
><P
> If you happen to be monitoring the mtime of your primary slony logs to 
determine if your slon has gone brain-dead, checking this is a good way
to avoid mistakenly clobbering it in the middle of a subscribe. As a bonus,
recall that since the the slons are running under svscan, you only need to
kill it (via the svc interface) and let svscan start it up again laster.
I've also found the COPY logs handy for following subscribe activity 
interactively.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="logrotation.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="testing.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Log Files</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="additionalutils.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> Test Suites</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
slony1-2-doc 2.2.5-2 / usr / share / doc / slony1-2-doc / adminguide / mkservice.html
