4321
Можно ли ускорить процесс (т.е. держать резервный сервер непрерывно в режиме "recovery mode" и поднимать приращения wal по мере их поступления?)

restore_command = 'cp /mnt/server/archivedir/%f %p'

which will copy previously archived WAL segments from the directory /mnt/server/archivedir. You could of course use something much more complicated, perhaps even a shell script that requests the operator to mount an appropriate tape.

It is important that the command return nonzero exit status on failure. The command will be asked for log files that are not present in the archive; it must return nonzero when so asked. This is not an error condition. Be aware also that the base name of the %p path will be different from %f;

Вроде ничто не мешает - вместо cp пишешь скрипт который возвращает не 0 - тогда Postgres будет висеть в режиме рекавери, а этот скрипт внешней командой после аварии основного сервера заставить вернуть 0 - БД будет считаться накаченой - останется только запустить

4321ОФФ. что произойдет, если стартовать постгрес с зазеркаленным (каким-то макаром) "по горячему" дисками (при идентичных путях к data) другого постгреса?

Насколько я понимаю, простое tar -czvf file_bck.tgz /..../data на работающем сервере допустимо, т е растарив этот архив и запустив постгри на другом узле - мы получим состояние БД с закоммичеными транзакциями до последнего чекпоинта.
Т е можно в cron, скажем, поставить архивирование на работающем сервере с передачей архива и растариванием на другом узле. После падения первого - на втором просто запускаем постгри и получаем консистентное состояние БД на последний чекпоинт с закомиччеными транзакциями.
Время чекпоинта конфигурируется

Точно так же физическое зеркалирование диска будет работать, проблема только в том, чтобы "авария" не произошла в момент еще незаконченного зеркалирования - т е посередине процесса. Если же диски используются в отдельной стойке - типа, скажем, MSA - то нужно просто замонтировать эти диски на другом узле и запустить постгри - как я писал будет откат всех незакоммиченных транзакций на последний чекпоинт. Проблема еще может быть с правами на каталог с БД видимо, но и то не факт.

По поводу 2031045 - падает узел с постгри, стойка рабочая. При старте Postgres просматривает сначала существующие WAL начиная с последнего чекпоинта на предмет redo/undo и только после этого говорит что он готов к работе(этот механизм используют очень многие БД). По поводу затаривания - механизм используется тот же - про это где-то в доке написано, искать некогда. Будет время - запощу сюда по этому поводу

Т е для надежности и скорости работы важно каталог с WAL положить на отдельный быстрый диск, т к эти файлы по чекпоинту обновляются в первую очередь. И еще - не нужно выключать fsync или какой там механизм используется, т к в противном случае запись в WAL будет идти быстро, но нет гарантии, что данные из буфера ОС(не БД) будут сброшены, т е сброс данных физически из буферов системы идет по fsync

Читаем доку вот тут
22.3.2. Making a Base Backup

The procedure for making a base backup is relatively simple:

1.
Ensure that WAL archiving is enabled and working.
.....
3. Perform the backup, using any convenient file-system-backup tool such as tar or cpio. It is neither necessary nor desirable to stop normal operation of the database while you do this.

Т е в первую очередь конечно тарим WAL потом кластер с данными, чтобы лог гарантированно содержал транзакции возможно добавленных данных. В этом случае мы должны потерять данные после последнего чекпоинта в WAL. Это относится к горячему зеркалированию, но это я не проверял да и метод мягко говоря не тривиальный. Лучше конечно на мой взгляд иметь hot stand by и накатыватьего по архивированным логам

Вот, для проверки сделал следующее(на SuSE 9.3)


1. создал БД bench
2. запустил из контриб - pgbench -s 100 -i bench - создание и заполнение таблиц
andy@nbook: ./pgbench -s 100 -i bench
creating tables...
10000 tuples done.
20000 tuples done.
30000 tuples done.
40000 tuples done.
50000 tuples done.
...
3. подождал немного(где-то до 500000) запустил tar -czvf d3.tgz DATA при работающем сервере и pgbench
...
ATA/global/16756
DATA/global/16758
DATA/global/pgstat.stat
DATA/global/pg_pwd
DATA/global/pg_control
DATA/pg_hba.conf
DATA/PG_VERSION
DATA/pg_clog/
DATA/pg_clog/0000
DATA/pg_xlog/
DATA/pg_xlog/000000010000000000000010
DATA/pg_xlog/000000010000000000000011
DATA/pg_xlog/000000010000000000000012
DATA/pg_xlog/00000001000000000000000C
DATA/pg_xlog/00000001000000000000000D
DATA/pg_xlog/00000001000000000000000E
DATA/pg_xlog/00000001000000000000000F
DATA/pg_xlog/archive_status/
DATA/postgresql.conf
DATA/pg_tblspc/
DATA/postmaster.opts

4. прервал pgbench посмотрел что в accounts
1150000 tuples done.

andy@nbook: psql template1
Welcome to psql 8.0.3, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

template1=# \c bench
You are now connected to database "bench".
bench=# select count(*) from accounts;
count
---------
1150000
(1 row)
5. Остановил сервер, растарил d3.tgz в другой каталог и запустил сервер по новой
andy@nbook:~/DATA1> postmaster -i -D DATA
LOG: database system was interrupted at 2005-11-03 20:28:57 MSK
LOG: checkpoint record is at 0/F05FC00
LOG: redo record is at 0/F002010; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 16648; next OID: 1301435
LOG: database system was not properly shut down; automatic recovery in progress
LOG: redo starts at 0/F002010
LOG: unexpected pageaddr 0/9000000 in log file 0, segment 16, offset 0
LOG: redo done at 0/FFFFF24
LOG: database system is ready

Имеем
andy@nbook:~> psql -l
List of databases
Name | Owner | Encoding
-----------+-------+----------
bench | andy | UNICODE
compiere | andy | UNICODE
template0 | andy | UNICODE
template1 | andy | UNICODE
(4 rows)

andy@nbook:~> psql bench
Welcome to psql 8.0.3, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

bench=# select count(*) from accounts;
count
--------
713780
(1 row)

bench=#
Рабочая БД , консистентная - только нет данных после последнего чекпоинта на момент выполнения архива. Как на виндах это работает - хз, может файлы и лочатся не знаю, но на линухе работает

1. Ensure that WAL archiving is enabled and working.

Архивирование необязательно должно быть разрешено и настроено. Без WAL Postgres не будет работать. По умолчанию используется (кажется 5) WAL сегментов по 16 Мб каждый, переключаемые по кругу(если архивирование не настроено). Начсет зеркалирования - часть данных может быть в кэше БД, а часть уже сброшена на диск, как тогда определить что же было записано, а что нет - WAL пишется в первую очередь и является точкой отсчета, на основании которой можно проконтролировать страницы БД.