Configuring MySQL for ZFS Replication
1336
For example, to copy a snapshot of the
scratchpool
file system to a new file system called
slavepool
on a new server, you would use the following command. This sequence combines the
snapshot of
scratchpool
, the transmission to the slave machine (using
ssh
with login credentials),
and the recovery of the snapshot on the slave using
zfs recv
:
root-shell> zfs send scratchpool@snap1 |ssh
id
@
host
pfexec zfs recv -F slavepool
The first part of the pipeline,
zfs send scratchpool@snap1
, streams the snapshot. The
ssh
command, and the command that it executes on the other server,
pfexec zfs recv -F
slavepool
, receives the streamed snapshot data and writes it to slavepool. In this instance, I've
specified the
-F
option which forces the snapshot data to be applied, and is therefore destructive. This
is fine, as I'm creating the first version of my replicated file system.
On the slave machine, the replicated file system contains the exact same content:
root-shell> ls -al /slavepool/
total 23
drwxr-xr-x 6 root root 7 Nov 8 09:13 ./
drwxr-xr-x 29 root root 34 Nov 9 07:06 ../
drwxr-xr-x 31 root bin 50 Jul 21 07:32 DTT/
drwxr-xr-x 4 root bin 5 Jul 21 07:32 SUNWmlib/
drwxr-xr-x 14 root sys 16 Nov 5 09:56 SUNWspro/
drwxrwxrwx 19 1000 1000 40 Nov 6 19:16 emacs-22.1/
Once a snapshot has been created, to synchronize the file system again, you create a new snapshot
and then use the incremental snapshot feature of
zfs send
to send the changes between the two
snapshots to the slave machine again:
root-shell> zfs send -i scratchpool@snapshot1 scratchpool@snapshot2 |ssh
id
@
host
pfexec zfs recv slavepool
This operation only succeeds if the file system on the slave machine has not been modified at all. You
cannot apply the incremental changes to a destination file system that has changed. In the example
above, the
ls
command would cause problems by changing the metadata, such as the last access
time for files or directories.
To prevent changes on the slave file system, set the file system on the slave to be read-only:
root-shell> zfs set readonly=on slavepool
Setting
readonly
means that you cannot change the file system on the slave by normal means,
including the file system metadata. Operations that would normally update metadata (like our
ls
)
silently perform their function without attempting to update the file system state.
In essence, the slave file system is nothing but a static copy of the original file system. However, even
when configured to to be read-only, a file system can have snapshots applied to it. With the file system
set to read only, re-run the initial copy:
root-shell> zfs send scratchpool@snap1 |ssh
id
@
host
pfexec zfs recv -F slavepool
Now you can make changes to the original file system and replicate them to the slave.
15.5.2. Configuring MySQL for ZFS Replication
Configuring MySQL on the source file system is a case of creating the data on the file system that
you intend to replicate. The configuration file in the example below has been updated to use
/
scratchpool/mysql-data
as the data directory, and now you can initialize the tables:
root-shell> mysql_install_db --defaults-file=/etc/mysql/5.5/my.cnf --user=mysql
To synchronize the initial information, perform a new snapshot and then send an incremental snapshot
to the slave using
zfs send
:
root-shell> zfs snapshot scratchpool@snap2
Summary of Contents for 5.0
Page 1: ...MySQL 5 0 Reference Manual ...
Page 18: ...xviii ...
Page 60: ...40 ...
Page 396: ...376 ...
Page 578: ...558 ...
Page 636: ...616 ...
Page 844: ...824 ...
Page 1234: ...1214 ...
Page 1427: ...MySQL Proxy Scripting 1407 ...
Page 1734: ...1714 ...
Page 1752: ...1732 ...
Page 1783: ...Configuring Connector ODBC 1763 ...
Page 1793: ...Connector ODBC Examples 1773 ...
Page 1839: ...Connector Net Installation 1819 2 You must choose the type of installation to perform ...
Page 2850: ...2830 ...
Page 2854: ...2834 ...
Page 2928: ...2908 ...
Page 3000: ...2980 ...
Page 3122: ...3102 ...
Page 3126: ...3106 ...
Page 3174: ...3154 ...
Page 3232: ...3212 ...