blob: 505cfec9e93afda0e4666989e737c124c7aa00d2 (
plain)
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
|
<refentry id="SQL-CREATEBARRIER">
<indexterm zone="sql-createbarrier">
<primary>CREATE BARRIER</primary>
</indexterm>
<refmeta>
<refentrytitle>CREATE BARRIER</refentrytitle>
<manvolnum>7</manvolnum>
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
<refnamediv>
<refname>CREATE BARRIER</refname>
<refpurpose>create a new barrier</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
CREATE BARRIER <replaceable class="PARAMETER">barrier_name</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
<command>CREATE BARRIER</command> is new SQL command specific
to <productname>Postgres-XL</productname> that creates
a new XLOG record on each node of the cluster consistently.
Essentially a barrier is a consistent point in the cluster that
you can recover to. Note that these are currently created manually,
not autoatically. Without barriers, if you recover an individual
component, it may be possible that it is not consistent with the
other nodes depending on when it was committed.
</para>
<para>A barrier
is created via a 2PC-like mechanism from a remote Coordinator in 3
phases with a prepare, execute and ending phases. A new recovery
parameter called recovery_target_barrier has been added in
recovery.conf. In order to perform a complete PITR recovery, it is
necessary to set recovery_target_barrier to the value of a barrier
already created. Then distribute recovery.conf to each data folder
of each node, and then to restart the nodes one by one.
</para>
<para>
The default barrier name is <literal>dummy_barrier_id</literal>. It is
used when no barrier name is specified when using <command>CREATE
BARRIER</command>.
</para>
</refsect1>
</refentry>
|
