1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
Upgrading from an earlier version of Slony-I to 1.2
-----------------------------------------------------
When upgrading Slony-I, the Slony installation on all nodes in a cluster
must be upgraded at once, using the slonik command UPDATE FUNCTIONS.
While this requires temporarily stopping replication, it does not
require an outage for applications that submit updates.
The proper upgrade procedure is thus:
1. Stop the slons on all nodes. (e.g. - old version of slon)
2. Install the new version of Slony-I software on all nodes.
3. Execute a slonik script containing the command
update functions (id = [whatever]);
for each node in the cluster.
If you installed the "altperl" tools via "./configure --with-altperl",
this step may be done more simply, assuming you have a suitable
slon_tools.conf file configured. You may instead run:
% slonik_update_nodes | slonik
4. Start all slons.
Upgrading is also discussed in more detail in the "Admin Guide."
The section is entitled "Slony-I Upgrade", distributed as
doc/adminguide/slonyupgrade.html in the documentation package.
Nullable Column issue in version 1.2
=====================================
In version 1.2, a check has been added to reject subscriptions to
tables where the candidate primary key has columns that are "Nullable"
(e.g. - that are not defined in the schema as NOT NULL).
This was not checked in earlier versions, and people may have set up
constraints (e.g. - via triggers) to enforce NOT NULL as opposed to
using the NOT NULL column constraint. As a result, a replica running
on version 1.1 may have violations of this check.
You may search for these violations via the following query:
select c.relname as table_name, ic.relname as index_name, att.attname, att2.attnotnull
from _cluster.sl_table t, pg_catalog.pg_class c, pg_index i, pg_catalog.pg_class ic, pg_catalog.pg_attribute att, pg_catalog.pg_attribute att2
where t.tab_reloid = c.oid
and t.tab_idxname = ic.relname
and ic.oid = i.indexrelid
and att.attrelid = i.indexrelid
and att2.attname = att.attname
and att2.attrelid = c.oid
and att2.attnotnull = 'f';
The problem may be rectified by submitting, for each entry found, a
query of the form:
alter table mytable alter column nullablecol set not null;
It would minimally suffice to apply this to the schema of new
subscribers; such queries will run rapidly against empty tables.
It will take longer to apply this change to a table that already
contains a great deal of data, as the alteration will scan the table
to verify that there are no tuples where the column is NULL.
TABLE ADD KEY change in version 2.0
=====================================
In version 2.0, Slony-I drops out support for creating
system-generated "pseudo primary keys" that involve adding in a custom
Slony-I-generated column.
There is documentation in the Admin Guide (slonyupgrade.sgml,
slonyupgrade.html) explaining approaches to "cleaning up" after having
used TABLE ADD KEY.
|
