Ключевые слова:backup, postgresql, replication, (найти похожие документы)
From: Олег Бартунов
Date: Mon, 24 Apr 2007 14:31:37 +0000 (UTC)
Subject: Online backup при помощи встроенных средств PostgreSQL 8
Оригинал: http://www.sai.msu.su/~megera/oddmuse/index.cgi/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 не
были переданы в хранилище журнала транзакций.
