<!-- $Id: dropthings.sgml,v 1.13 2005/02/23 23:18:58 cbbrowne Exp $ -->
<sect1 id="dropthings"> <title>Dropping things from &slony1; Replication</title>

<para>There are several things you might want to do involving dropping
things from &slony1; replication.</para>

<sect2><title>Dropping A Whole Node</title>

<para>If you wish to drop an entire node from replication, the <xref
linkend="slonik"> command <xref linkend="stmtdropnode"> should do the
trick.</para>

<para>This will lead to &slony1; dropping the triggers (generally that
deny the ability to update data), restoring the <quote>native</quote>
triggers, dropping the schema used by &slony1;, and the <xref
linkend="slon"> process for that node terminating itself.</para>

<para>As a result, the database should be available for whatever use
your application makes of the database.</para>

<para>This is a pretty major operation, with considerable potential to
cause substantial destruction; make sure you drop the right node!</para>

<para>The operation will fail if there are any nodes subscribing to
the node that you attempt to drop, so there is a bit of a failsafe to
protect you from errors.</para>

<para><link linkend="faq17"> <envar>sl_log_1</envar> isn't getting
purged</link> documents some extra maintenance that may need to be
done on <xref linkend="table.sl-confirm"> if you are running versions
prior to 1.0.5.</para></sect2>

<sect2><title>Dropping An Entire Set</title>

<para>If you wish to stop replicating a particular replication set,
the <xref linkend="slonik"> command <xref linkend="stmtdropset"> is
what you need to use.</para>

<para>Much as with <xref linkend="stmtdropnode">, this leads to
&slony1; dropping the &slony1; triggers on the tables and restoring
<quote>native</quote> triggers.  One difference is that this takes
place on <emphasis>all</emphasis> nodes in the cluster, rather than on
just one node.  Another difference is that this does not clear out the
&slony1; cluster's namespace, as there might be other sets being
serviced.</para>

<para>This operation is quite a bit more dangerous than <xref
linkend="stmtdropnode">, as there <emphasis>isn't</emphasis> the same
sort of <quote>failsafe.</quote> If you tell <xref
linkend="stmtdropset"> to drop the <emphasis>wrong</emphasis> set,
there isn't anything to prevent potentially career-limiting
<quote>unfortunate results.</quote> Handle with care...</para>
</sect2>

<sect2><title>Unsubscribing One Node From One Set</title>

<para>The <xref linkend="stmtunsubscribeset"> operation is a little
less invasive than either <xref linkend="stmtdropset"> or <xref
linkend="stmtdropnode">; it involves dropping &slony1; triggers and
restoring <quote>native</quote> triggers on one node, for one
replication set.</para>

<para>Much like with <xref linkend="stmtdropnode">, this operation
will fail if there is a node subscribing to the set on this node.

<warning>
<para>For all of the above operations, <quote>turning replication back
on</quote> will require that the node copy in a
<emphasis>full</emphasis> fresh set of the data on a provider.  The
fact that the data was recently being replicated isn't good enough;
&slony1; will expect to refresh the data from scratch.</para>
</warning>
</para>

</sect2>
<sect2><title> Dropping A Table From A Set</title>

<para>In &slony1; 1.0.5 and above, there is a Slonik command <xref
linkend="stmtsetdroptable"> that allows dropping a single table from
replication without forcing the user to drop the entire replication
set.</para>

<para>If you are running an earlier version, there is a <quote>hack</quote>
to do this:</para>

<para>You can fiddle this by hand by finding the table ID for the
table you want to get rid of, which you can find in <xref
linkend="table.sl-table">, and then run the following three queries,
on each host:
<programlisting>
  select _slonyschema.alterTableRestore(40);
  select _slonyschema.tableDropKey(40);
  delete from _slonyschema.sl_table where tab_id = 40;
</programlisting>
</para>

<para>The schema will obviously depend on how you defined the &slony1;
cluster.  The table ID, in this case, 40, will need to change to the
ID of the table you want to have go away.</para>

<para>You'll have to run these three queries on all of the nodes,
preferably firstly on the origin node, so that the dropping of this
propagates properly.  Implementing this via a <xref linkend="slonik">
statement with a new &slony1; event would do that.  Submitting the
three queries using <xref linkend="stmtddlscript"> could do that; see
<xref linkend="ddlchanges"> for more details.  Also possible would be
to connect to each database and submit the queries by hand.</para>
</sect2>

<sect2><title>Dropping A Sequence From A Set</title>

<para>Just as with <xref linkend="stmtsetdroptable">, version 1.0.5
introduces the operation <xref linkend="stmtsetdropsequence">.</para>

<para>If you are running an earlier version, here are instructions as
to how to drop sequences:</para>

<para>The data that needs to be deleted to stop &slony1; from
continuing to replicate the two sequences identified with Sequence IDs
93 and 59 are thus:

<programlisting>
delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59);
delete from _oxrsorg.sl_sequence where seq_id in (93,59);
</programlisting>
</para>

<para> Those two queries could be submitted to all of the nodes via
<xref linkend="function.ddlscript-integer-text-integer"> / <xref
linkend="stmtddlscript">, thus eliminating the sequence everywhere
<quote>at once.</quote> Or they may be applied by hand to each of the
nodes.</para>
</sect2>
</sect1>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:"book.sgml"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->

