online-backup

Целью данной заметки является демонстрация того, как с помощью встроенных средств Postgresql 8.0 можно совершать online backup.

В нашем примере у нас будут два узла - master и slave. Задача заключается в том, чтобы при отказе узла master (крах файловой системы, отказ оборудования и т.п.) максимально быстро и с минимальными потерями данных восстановить БД на узле slave.

Для демонстрации мы будем использовать тестовую базу ok, содержащую таблицу okp с кодами классификатора ОКП. Структура таблицы okp такова

create table okp (
code text not null,
kch text,
name text,
txtdata tsvector,
primary key (code)
);
CREATE INDEX okp_tidx ON okp using gist (txtdata);

После внесения первой порции данных (~ 25000 записей) будет произведен базовый (опорный) бэкап. Затем будет внесена вторая порция данных (еще ~ 25000 записей) и сервер БД на узде master будет остановлен. После чего на узле slave будет запущена восстановленная копия сервера БД. Восстановление будет произведено с помощью опорного бэкапа и журнала транзакций.

Начальные условия

• На обоих узлах установлен PostgreSQL 8.x одинаковой версии
• PostgreSQL запускается от пользователя postgres, который входит в группу postgres.
• Данные БД на узле master находятся в каталоге /db2/pgdata
• Данные БД на узле slave находятся в каталоге /db2/pgdata-backup
• Пользователь postgres может попасть с узла master на узел slave при помощи ssh, не вводя при этом пароль
• Примечание. Везде далее по тексту все операции будут производить от пользователя postgres, если не указано другое.

Демонстрация

• Slave
  • Создаем директорию для хранения журнала транзакций и для данных БД (пользователь root)

mkdir -p /u/postgres/wal-backup
mkdir -p /db2/pgdata-backup
chown postgres:postgres /u/postgres/wal-backup /db2/pgdata-backup
chmod 0700 /u/postgres/wal-backup /db2/pgdata-backup

• Master
  • Настраиваем сохранение журнала транзакций. В /db2/pgdata/postgresql.conf добавляем строку:

archive_command = '/usr/bin/scp %p slave:/u/postgres/wal-backup/%f </dev/null'

поскольку в нашем примере мы точно уверены, что на узел slave данные поступают только с узла master, то проверку на совпадение имен файлов журнала транзакций мы не производим.

• Запускаем postgresql

pg_ctl -D /db2/pgdata start

• Распаковываем ok.tar.gz (лежит zeon.sai.msu.ru:/u/postgres/ok.tar.gz)

tar xzf ok.tar.gz
cd ok

• Создаем базу ok

createdb ok

• Создаем структуру базы ok

psql -f /usr/local/pgsql/share/contrib/tsearch2.sql ok
psql -f ok.schema ok

• Заливаем первую часть данных

psql -f ok1.dump ok

При этом на узле slave в wal-backup появляется нечто похожее:

pg@slave:~/wal-backup$ ll
total 65624
drwx------    2 postgres postgres     4096 Mar 21 23:02 ./
drwxr-xr-x   11 postgres postgres     4096 Mar 21 22:48 ../
-rw-------    1 postgres postgres 16777216 Mar 21 22:35 00000001000000000000000F
-rw-------    1 postgres postgres 16777216 Mar 21 22:38 000000010000000000000010
-rw-------    1 postgres postgres 16777216 Mar 21 22:44 000000010000000000000011
-rw-------    1 postgres postgres 16777216 Mar 21 23:04 000000010000000000000012

• Ставим backup point

psql -c "select pg_start_backup('backup-2005-03-21')" ok

 pg_start_backup 
-----------------
 0/134DAD8C
(1 row)

• Копируем содержимое /db2/pgdata на узел slave в /db2/pgdata-backup

scp -rp /db2/pgdata/* slave:/db2/pgdata-backup/

• Фиксируем backup point

psql -c "select pg_stop_backup()" ok

 pg_stop_backup 
----------------
 0/134DCEC0
(1 row)

• Содержимое wal-backup на slave будет выглядеть примерно так:

pg@slave:~/wal-backup$ ll
total 65628
drwx------    2 postgres postgres     4096 Mar 21 23:35 ./
drwxr-xr-x   11 postgres postgres     4096 Mar 21 22:48 ../
-rw-------    1 postgres postgres 16777216 Mar 21 22:35 00000001000000000000000F
-rw-------    1 postgres postgres 16777216 Mar 21 22:38 000000010000000000000010
-rw-------    1 postgres postgres 16777216 Mar 21 22:44 000000010000000000000011
-rw-------    1 postgres postgres 16777216 Mar 21 23:04 000000010000000000000012
-rw-------    1 postgres postgres      255 Mar 21 23:35 000000010000000000000013.004DAD8C.backup 

• Заливаем вторую часть данных

psql -f ok2.dump ok

• Содержимое wal-backup на slave будет выглядеть примерно так:

pg@slave:~/wal-backup$ ll
total 82032
drwx------    2 postgres postgres     4096 Mar 21 23:40 ./
drwxr-xr-x   11 postgres postgres     4096 Mar 21 22:48 ../
-rw-------    1 postgres postgres 16777216 Mar 21 22:35 00000001000000000000000F
-rw-------    1 postgres postgres 16777216 Mar 21 22:38 000000010000000000000010
-rw-------    1 postgres postgres 16777216 Mar 21 22:44 000000010000000000000011
-rw-------    1 postgres postgres 16777216 Mar 21 23:04 000000010000000000000012
-rw-------    1 postgres postgres 16777216 Mar 21 23:41 000000010000000000000013
-rw-------    1 postgres postgres      255 Mar 21 23:35 000000010000000000000013.004DAD8C.backup

• Посчитаем кол-во записей в эталонной базе и запомним его.

psql -c "select count(*) from okp" ok
 count 
-------
 52938
(1 row)

• Опускаем postgres на master, имитируя падение файловой системы

pg_ctl -D /db2/pgdata stop

• Slave
  • Удаляем журнал транзакций из /db2/pgdata-backup/pg_xlog

rm -rf /db2/pgdata-backup/pg_xlog/*

• Создаем файл /db2/pgdata-backup/recovery.conf следующего содержания:

restore_command = 'cp /u/postgres/wal-backup/%f %p'

• Поскольку у нас есть базовый backup, то мы можем удалить транзакции, предшествующие точке бэкапа, чтобы не занимать лишнего места на диске

cd /u/postgres/wal-backup
rm -f 00000001000000000000000F 000000010000000000000010 000000010000000000000011 000000010000000000000012

после чего содержимое wal-backup на slave будет выглядеть так:

pg@slave:~/wal-backup$ ll
total 16416
drwx------    2 postgres postgres     4096 Mar 21 23:50 ./
drwxr-xr-x   11 postgres postgres     4096 Mar 21 22:48 ../
-rw-------    1 postgres postgres 16777216 Mar 21 23:41 000000010000000000000013
-rw-------    1 postgres postgres      255 Mar 21 23:35 000000010000000000000013.004DAD8C.backup

• Запускаем postgresql

pg_ctl -D /db2/pgdata-backup start

при этом в логах postgresql мы увидим следующее

::LOG:  database system was shut down at 2005-03-21 23:57:57 MSK
::LOG:  starting archive recovery
::LOG:  restore_command = "cp /u/postgres/wal-backup/%f %p"
cp: /u/postgres/wal-backup/00000001.history: No such file or directory
cp: /u/postgres/wal-backup/000000010000000000000014: No such file or directory
::LOG:  checkpoint record is at 0/1456CCF8
::LOG:  redo record is at 0/1456CCF8; undo record is at 0/0; shutdown TRUE
::LOG:  next transaction ID: 238261; next OID: 17490
::LOG:  automatic recovery in progress
::LOG:  record with zero length at 0/1456CD34
::LOG:  redo is not required
cp: /u/postgres/wal-backup/000000010000000000000014: No such file or directory
::LOG:  archive recovery complete
::LOG:  database system is ready
::LOG:  transaction ID wrap limit is 2147484130, limited by database "ok"

• Все, восстановление успешно завершено. Сверяем количество записей с эталонной базой

psql -c "select count(*) from okp" ok
 count 
-------
 52938
(1 row)

• Поскольку изменения в некоторых типах индексов (например, gist) не фиксируются в журнале транзакций, необходимо пересоздать эти индексы заново

psql -c "reindex table okp" ok

Примечание. В данном примере восстановленная база ничем не отличается от эталонной. В реальной жизни может быть потеряна часть данных из последнего сегмента транзакций, которые из-за краха узла master не были переданы в хранилище журнала транзакций.