Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Point-In-Time Recovery (PITR) / 14 сообщений из 14, страница 1 из 1
22.02.2008, 12:51
    #35150216
Vasonik
Vasonik
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
Настраиваю механизм PITR.
Возник вопрос. Накатывание сегментов WAL происходит только на базу, которая была скопирована после pg_start_backup?
Или можно можно накатывать архивные файлы по мере их накопления на slave машине?
Тоесть скопировали базу, накопили какое то количество сегментов WAL, подложили recovery.conf, запустили slave сервер, накатили их на базу.
Потом накопили еще какое то количество, опять накатили.

Судя по логам slave сервера получается, что он каждый раз пытается начать с первого после копирования базы сегмента WAL и увидев, что он уже в базе, новые WAL сегменты уже не вносит.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.02.2008, 13:33
    #35150376
Thamerlan
Thamerlan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
После успешного recovery база на slave машине станет самостоятельной и начнет писать свои WAL логи. Поэтому дальнейшие WAL'ы с основной базы более не годны.

Другое дело, что есть механизм, при котором ваш recovery процесс как-бы никогда не доходит до конца и ожидает очередную порцию WAL'ов. Но тогда БД на slave машине всё это время не доступна для использования.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.04.2008, 14:21
    #35245436
ChameLe0n
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
Опишите, если не сложно, процесс поднятия резервного сервера.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.04.2008, 11:04
    #35251259
ChameLe0n
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
Столкнулся с такой проблемой. Все делаю как описано на sai.msu.su .
Почти все работает. Однако
на master смотрим

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
[root@maxi pg_xlog]# ll
итого  131240 
-rw------- 1 postgres postgres      250 Апр 12 13:37 000000010000000000000011.00000068.backup
-rw------- 1 postgres postgres 16777216 Апр 12 13:43 00000001000000000000001C
-rw------- 1 postgres postgres 16777216 Апр 12 13:50 00000001000000000000001D
-rw------- 1 postgres postgres 16777216 Апр 12 13:42 00000001000000000000001E
-rw------- 1 postgres postgres 16777216 Апр 12 13:42 00000001000000000000001F
-rw------- 1 postgres postgres 16777216 Апр 12 13:42 000000010000000000000020
-rw------- 1 postgres postgres 16777216 Апр 12 13:43 000000010000000000000021
-rw------- 1 postgres postgres 16777216 Апр 12 13:43 000000010000000000000022
-rw------- 1 postgres postgres 16777216 Апр 12 13:43 000000010000000000000023
drwx------ 2 postgres postgres     4096 Апр 12 13:50 archive_status


Код: plaintext
1.
2.
3.
4.
[root@maxi archive_status]# ll
итого  0 
-rw------- 1 postgres postgres 0 Апр 12 13:37 000000010000000000000011.00000068.backup.done
-rw------- 1 postgres postgres 0 Апр 12 13:43 00000001000000000000001C.done

Соответственно в папке, куда он копирует логи
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
[root@maxi wal]# ll
итого  360900 
-rw------- 1 postgres postgres 16777216 Апр 12 13:30 000000010000000000000007
-rw------- 1 postgres postgres      247 Апр 12 13:31 000000010000000000000007.00000068.backup
-rw------- 1 postgres postgres 16777216 Апр 12 13:31 000000010000000000000008
-rw------- 1 postgres postgres 16777216 Апр 12 13:31 000000010000000000000009
-rw------- 1 postgres postgres 16777216 Апр 12 13:31 00000001000000000000000A
-rw------- 1 postgres postgres 16777216 Апр 12 13:31 00000001000000000000000B
-rw------- 1 postgres postgres 16777216 Апр 12 13:31 00000001000000000000000C
-rw------- 1 postgres postgres 16777216 Апр 12 13:31 00000001000000000000000D
-rw------- 1 postgres postgres 16777216 Апр 12 13:31 00000001000000000000000E
-rw------- 1 postgres postgres 16777216 Апр 12 13:32 00000001000000000000000F
-rw------- 1 postgres postgres 16777216 Апр 12 13:35 000000010000000000000010
-rw------- 1 postgres postgres 16777216 Апр 12 13:37 000000010000000000000011
-rw------- 1 postgres postgres      250 Апр 12 13:37 000000010000000000000011.00000068.backup
-rw------- 1 postgres postgres 16777216 Апр 12 13:38 000000010000000000000012
-rw------- 1 postgres postgres 16777216 Апр 12 13:38 000000010000000000000013
-rw------- 1 postgres postgres 16777216 Апр 12 13:38 000000010000000000000014
-rw------- 1 postgres postgres 16777216 Апр 12 13:39 000000010000000000000015
-rw------- 1 postgres postgres 16777216 Апр 12 13:42 000000010000000000000016
-rw------- 1 postgres postgres 16777216 Апр 12 13:42 000000010000000000000017
-rw------- 1 postgres postgres 16777216 Апр 12 13:42 000000010000000000000018
-rw------- 1 postgres postgres 16777216 Апр 12 13:43 000000010000000000000019
-rw------- 1 postgres postgres 16777216 Апр 12 13:43 00000001000000000000001A
-rw------- 1 postgres postgres 16777216 Апр 12 13:43 00000001000000000000001B
-rw------- 1 postgres postgres 16777216 Апр 12 13:43 00000001000000000000001C
Соотвественно на slave имеем:
автор2008-04-12 13:49:02.033 OMSSTLOG: database system was interrupted; last known up at 2008-04-12 13:36:17 OMSST
2008-04-12 13:49:02.033 OMSSTLOG: starting archive recovery
2008-04-12 13:49:02.033 OMSSTLOG: restore_command = 'cp /srv/wal/%f %p'
cp: невозможно выполнить stat для `/srv/wal/00000001.history': Нет такого файла или каталога
2008-04-12 13:49:02.124 OMSSTLOG: restored log file "000000010000000000000011" from archive
2008-04-12 13:49:02.124 OMSSTLOG: automatic recovery in progress
2008-04-12 13:49:02.520 OMSSTLOG: redo starts at 0/110000B0
2008-04-12 13:49:02.615 OMSSTLOG: restored log file "000000010000000000000012" from archive
2008-04-12 13:49:03.438 OMSSTLOG: restored log file "000000010000000000000013" from archive
2008-04-12 13:49:04.259 OMSSTLOG: restored log file "000000010000000000000014" from archive
2008-04-12 13:49:05.075 OMSSTLOG: restored log file "000000010000000000000015" from archive
2008-04-12 13:49:05.766 OMSSTLOG: restored log file "000000010000000000000016" from archive
2008-04-12 13:49:06.587 OMSSTLOG: restored log file "000000010000000000000017" from archive
2008-04-12 13:49:08.729 OMSSTLOG: restored log file "000000010000000000000018" from archive
2008-04-12 13:49:09.559 OMSSTLOG: restored log file "000000010000000000000019" from archive
2008-04-12 13:49:10.387 OMSSTLOG: restored log file "00000001000000000000001A" from archive
2008-04-12 13:49:11.220 OMSSTLOG: restored log file "00000001000000000000001B" from archive
2008-04-12 13:49:12.040 OMSSTLOG: restored log file "00000001000000000000001C" from archive
cp: невозможно выполнить stat для `/srv/wal/00000001000000000000001D': Нет такого файла или каталога
2008-04-12 13:49:14.222 OMSSTLOG: could not open file "pg_xlog/00000001000000000000001D" (log file 0, segment 29): Нет такого файла или каталога
2008-04-12 13:49:14.223 OMSSTLOG: redo done at 0/1CFFFF90
2008-04-12 13:49:14.223 OMSSTLOG: last completed transaction was at log time 2008-04-12 13:42:45.981489+07
2008-04-12 13:49:14.323 OMSSTLOG: restored log file "00000001000000000000001C" from archive
cp: невозможно выполнить stat для `/srv/wal/00000002.history': Нет такого файла или каталога
2008-04-12 13:49:14.327 OMSSTLOG: selected new timeline ID: 2
cp: невозможно выполнить stat для `/srv/wal/00000001.history': Нет такого файла или каталога
2008-04-12 13:49:15.093 OMSSTLOG: archive recovery complete
2008-04-12 13:49:16.525 OMSSTLOG: autovacuum launcher started
2008-04-12 13:49:16.526 OMSSTLOG: database system is ready to accept connections


Те последние 7 логов не перенесены. Почему?

Код: plaintext
1.
2.
3.
archive_mode = on               # allows archiving to be done
archive_command = 'cp -i %p /srv/wal/%f </dev/null'
#archive_timeout = 60s          # force a logfile segment switch after this
Последняя строчку комментил и некомментил - итог одинаков
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2008, 12:11
    #35253068
ss25
ss25
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
http://www.sai.msu.su/~megera/oddmuse/index.cgi/online-backup

у кого нить в нормально открывается эта страница я не могу подобрать кодировку одна ересь выводится.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2008, 20:46
    #35254585
Niemi
Niemi
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
ss25http://www.sai.msu.su/~megera/oddmuse/index.cgi/online-backup

у кого нить в нормально открывается эта страница я не могу подобрать кодировку одна ересь выводится.
FF v2.0 Encoding UTF8
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.04.2008, 13:20
    #35258742
Thamerlan
Thamerlan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
Сам не обращал раньше на такое внимания. Я просто всегда руками до-копировал актуальное содержимое pg_xlog и тогда делал restore.

В доке postgreSQL есть такие предложения:
The segment files are given numeric names that reflect their position in the abstract WAL sequence.
It's assumed that a segment file whose contents precede the checkpoint-before-last is no longer of interest and can be recycled.

Значит PostgreSQL копирует только те WAL файлы, у которых всё содержимое относится ко времени "до последнего чекпоинта".

Вот смотрите:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
$ pg_controldata | grep "Latest checkpoint location"
Latest checkpoint location:           83/ 5C 05E79C

$ tail -10 log_of_wal_process.log
...
pg_xlog/0000000100000083000000 5C 
32769 blocks
OK: 00000001000000830000005C

через какое-то время:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
$ pg_controldata | grep "Latest checkpoint location"
Latest checkpoint location:           83/ 5D 0C7A58

$ tail -10 log_of_wal_process.log
...
pg_xlog/00000001000000830000005C
32769 blocks
OK: 00000001000000830000005C
2008.04.16-08.45.52
pg_xlog/0000000100000083000000 5D 
32769 blocks
OK: 00000001000000830000005D


Содержимое pg_xlog в это время:
Код: plaintext
1.
2.
3.
4.
-rw-------  1 postgres postgres 16M Apr 16 09:05 00000001000000830000005F
...еще 511 файлов ...
-rw-------  1 postgres postgres 16M Apr 16 08:45 000000010000008500000061
-rw-------  1 postgres postgres 16M Apr 16 08:55 000000010000008500000062


А чему у вас равен параметр checkpoint_segments ?


P.s.
Не смог прочитать указанный вами линк ни оперой, ни ехплорером... Кракозяблы...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.04.2008, 08:25
    #35260666
ChameLe0n
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
Я во время тестов PITR немного пронаблюдал, и сделал вывод что PG держит несколько пустых файлов для журнала транзакций. Соответсвенно он знает что они пустые и не спешит их копировать.

Вот копия статьи, кому интересно .
PS: Все хорошо в PITR, еще бы можно было использовать slave, для чтения. Как пример - отдельная обновляемая статистика, чтобы тяжелыми запросами не грузить основной сервер.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.04.2008, 09:44
    #35260812
ss25
ss25
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
FF 2.0.0.7 ересь
Opera 9.23 ересь
IE 6.0.2900.2180 ересь
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.04.2008, 12:11
    #35261392
ChameLe0n
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
Дайте почту, я Вам скину по почте ..
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.04.2008, 12:35
    #35261499
Thamerlan
Thamerlan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
ChameLe0nЯ во время тестов PITR немного пронаблюдал, и сделал вывод что PG держит несколько пустых файлов для журнала транзакций. Соответсвенно он знает что они пустые и не спешит их копировать.


Я бы сказал, что чекпоинты попадают в каждый N-ный сегмент (WAL файл), где N=checkpoint_segments. И поэтому, все промежуточные WAL файлы не копируются до очередного чекпоинта. Легко проверить, поигравшись с параметром checkpoint_segments.


ChameLe0n
Вот копия статьи, кому интересно .
PS: Все хорошо в PITR, еще бы можно было использовать slave, для чтения. Как пример - отдельная обновляемая статистика, чтобы тяжелыми запросами не грузить основной сервер.

Я для этих целей использую SLONY. И тогда slave-node можно использовать под репортинг и прочие read-only цели.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.04.2008, 12:42
    #35261534
ChameLe0n
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
авторЯ для этих целей использую SLONY. И тогда slave-node можно использовать под репортинг и прочие read-only цели.

Я год-полтора назад читал про эту систему. Если все правильно понял - там на триггерах все работает. И это, как мне кажется, огромный минус. При использовании PITR потребление ресурсов сервера остается на том же уровне.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.04.2008, 12:55
    #35261596
Thamerlan
Thamerlan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
ChameLe0n
Я год-полтора назад читал про эту систему. Если все правильно понял - там на триггерах все работает. И это, как мне кажется, огромный минус. При использовании PITR потребление ресурсов сервера остается на том же уровне.

SLONY в самом деле trigger-based репликация. Сложно вот так однозначно сказать плохо это или хорошо. У вас в самом деле сильная нехватка ресурсов? :)
Ведь всё равно, на данном этапе, вы не сможете сделать автоматически обновляемую read-only БД, используя WAL'ы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.04.2008, 18:39
    #35262916
Nick Gazaloff
Nick Gazaloff
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Point-In-Time Recovery (PITR)
ss25http://www.sai.msu.su/~megera/oddmuse/index.cgi/online-backup

у кого нить в нормально открывается эта страница я не могу подобрать кодировку одна ересь выводится.

http://www.sai.msu.su/~megera/wiki/online-backup
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Point-In-Time Recovery (PITR) / 14 сообщений из 14, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]