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 не были переданы в хранилище журнала транзакций.