Задать вопрос

igortru

Комментарии

  • Почему возникает ошибка при восстановлении PiTR Postgres WAL-G?

    @igortru Автор вопроса
    Попробовал восстановить БД побольше 4Гб, судя по журналам WAL пишутся в S3 каждые пол часа.

    restore_command = 'wal-g --config=/mnt/pg-data/.walg.json wal-fetch \"%f\" \"%p\" >> /var/log/wal-g/wal_g_restore_command.log 2>&1'
recovery_target_time = '2023-06-16 23:00:00 '


    wal_g_restore_command.log
    ERROR: 2023/06/17 02:55:40.458071 Archive '0000000D.history' does not exist.
ERROR: 2023/06/17 02:55:40.971844 Archive '0000000C0000003100000095' does not exist.
ERROR: 2023/06/17 02:55:41.148688 Archive '0000000B0000003100000095' does not exist.
ERROR: 2023/06/17 02:55:41.277587 Archive '0000000A0000003100000095' does not exist.


    postgresql-Sat.log
    2023-06-17 02:55:39.463 GMT [22637] LOG:  starting PostgreSQL 14.8 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
2023-06-17 02:55:39.463 GMT [22637] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2023-06-17 02:55:39.463 GMT [22637] LOG:  listening on IPv6 address "::", port 5432
2023-06-17 02:55:39.464 GMT [22637] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-06-17 02:55:39.466 GMT [22637] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2023-06-17 02:55:39.470 GMT [22641] LOG:  database system was interrupted; last known up at 2023-06-16 17:00:03 GMT
2023-06-17 02:55:40.039 GMT [22641] LOG:  restored log file "0000000A.history" from archive
2023-06-17 02:55:40.135 GMT [22641] LOG:  restored log file "0000000B.history" from archive
2023-06-17 02:55:40.237 GMT [22641] LOG:  restored log file "0000000C.history" from archive
2023-06-17 02:55:40.459 GMT [22641] LOG:  starting point-in-time recovery to 2023-06-16 23:00:00+00
2023-06-17 02:55:40.773 GMT [22641] LOG:  restored log file "0000000C.history" from archive
2023-06-17 02:55:41.573 GMT [22641] LOG:  restored log file "000000090000003100000095" from archive
2023-06-17 02:55:41.611 GMT [22641] FATAL:  requested timeline 12 is not a child of this server's history
2023-06-17 02:55:41.611 GMT [22641] DETAIL:  Latest checkpoint is at 31/95000060 on timeline 9, but in the history of the requested timeline, the server forked off from that timeline at 2A/6C0000
A0.
2023-06-17 02:55:41.612 GMT [22637] LOG:  startup process (PID 22641) exited with exit code 1
2023-06-17 02:55:41.612 GMT [22637] LOG:  aborting startup due to startup process failure
2023-06-17 02:55:41.616 GMT [22637] LOG:  database system is shut down
    Написано

  • Почему возникает ошибка при восстановлении PiTR Postgres WAL-G?

    @igortru Автор вопроса
    wal-g --config=/mnt/pg-data/.walg.json wal-show

    648d1adea631c062076983.png
    Написано

  • Почему возникает ошибка при восстановлении PiTR Postgres WAL-G?

    @igortru Автор вопроса
    Melkij, БД маленькая, задание выполняется несколько секунд. Журнал выполнения ниже. Задание запускаеися с такими параметрами:
    su postgres -c 'wal-g --config=/mnt/pg-data/.walg.json delete retain FULL 2 --confirm >> /var/log/wal-g/wal_g_backup.log 2>&1'
su postgres -c 'wal-g --config=/mnt/pg-data/.walg.json backup-push /mnt/pg-data/14 >> /var/log/wal-g/wal_g_backup.log 2>&1'


    Журнал выполнения за 14-е число.

    INFO: 2023/06/14 17:00:01.158815 retrieving permanent objects
INFO: 2023/06/14 17:00:01.574465 Start delete
INFO: 2023/06/14 17:00:01.692653 Objects in folder:
INFO: 2023/06/14 17:00:01.692701        will be deleted: basebackups_005/base_000000180000000000000053_backup_stop_sentinel.json
INFO: 2023/06/14 17:00:01.692789        will be deleted: wal_005/000000180000000000000053.00000028.backup.br
INFO: 2023/06/14 17:00:01.692810        will be deleted: wal_005/000000180000000000000053.br
INFO: 2023/06/14 17:00:01.692818        will be deleted: wal_005/000000180000000000000054.br
INFO: 2023/06/14 17:00:01.692860        will be deleted: basebackups_005/base_000000180000000000000053/metadata.json
INFO: 2023/06/14 17:00:01.692885        will be deleted: basebackups_005/base_000000180000000000000053/tar_partitions/part_001.tar.br
INFO: 2023/06/14 17:00:01.692894        will be deleted: basebackups_005/base_000000180000000000000053/tar_partitions/part_003.tar.br
INFO: 2023/06/14 17:00:01.692905        will be deleted: basebackups_005/base_000000180000000000000053/tar_partitions/pg_control.tar.br
INFO: 2023/06/14 17:00:01.761965 Selecting the latest backup as the base for the current delta backup...
INFO: 2023/06/14 17:00:01.792326 Calling pg_start_backup()
INFO: 2023/06/14 17:00:01.956149 Starting a new tar bundle
INFO: 2023/06/14 17:00:01.956204 Walking ...
INFO: 2023/06/14 17:00:01.956486 Starting part 1 ...
INFO: 2023/06/14 17:00:02.370733 Packing ...
INFO: 2023/06/14 17:00:02.371676 Finished writing part 1.
INFO: 2023/06/14 17:00:03.540698 Starting part 2 ...
INFO: 2023/06/14 17:00:03.540770 /global/pg_control
INFO: 2023/06/14 17:00:03.541743 Finished writing part 2.
INFO: 2023/06/14 17:00:03.542964 Calling pg_stop_backup()
INFO: 2023/06/14 17:00:04.861308 Starting part 3 ...
INFO: 2023/06/14 17:00:04.861406 backup_label
INFO: 2023/06/14 17:00:04.861419 tablespace_map
INFO: 2023/06/14 17:00:04.863097 Finished writing part 3.
INFO: 2023/06/14 17:00:04.954148 Wrote backup with name base_000000180000000000000059


    Возможно ли поведение WAL-G когда он удаляет все предыдущие WAL при создании нового полного бекапа? т.е. восстановить предыдущее 2 полных возможно но без привязки по времени?

    Попробовал восстановить из вчерашнего бекапа, получил другую ошибку :

    Новых данных в БД не заносится, размен как ранее писал очень мал - 11МБ.

    2023-06-17 02:01:45.454 GMT [19421] LOG:  starting PostgreSQL 14.8 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
2023-06-17 02:01:45.456 GMT [19421] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2023-06-17 02:01:45.456 GMT [19421] LOG:  listening on IPv6 address "::", port 5432
2023-06-17 02:01:45.458 GMT [19421] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-06-17 02:01:45.461 GMT [19421] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2023-06-17 02:01:45.464 GMT [19424] LOG:  database system was interrupted; last known up at 2023-06-16 17:00:02 GMT
2023-06-17 02:01:45.648 GMT [19424] LOG:  restored log file "00000019.history" from archive
2023-06-17 02:01:45.895 GMT [19424] LOG:  starting point-in-time recovery to 2023-06-17 00:00:00+00
2023-06-17 02:01:45.996 GMT [19424] LOG:  restored log file "00000019.history" from archive
2023-06-17 02:01:46.363 GMT [19424] LOG:  restored log file "00000018000000000000005D" from archive
<b>2023-06-17 02:01:46.369 GMT [19424] FATAL:  requested timeline 25 is not a child of this server's history
2023-06-17 02:01:46.369 GMT [19424] DETAIL:  Latest checkpoint is at 0/5D000060 on timeline 24, but in the history of the requested timeline, the server forked off from that timeline at 0/5C00000
</b>2023-06-17 02:01:46.370 GMT [19421] LOG:  startup process (PID 19424) exited with exit code 1
2023-06-17 02:01:46.370 GMT [19421] LOG:  aborting startup due to startup process failure
2023-06-17 02:01:46.373 GMT [19421] LOG:  database system is shut down


    restore_command = 'wal-g --config=/mnt/pg-data/.walg.json wal-fetch \"%f\" \"%p\" >> /var/log/wal-g/wal_g_restore_command.log 2>&1'
    recovery_target_time = '2023-06-17 00:00:00'

    /var/log/wal-g/wal_g_restore_command.log
    ERROR: 2023/06/17 02:00:32.899667 Archive '0000001A.history' does not exist.
ERROR: 2023/06/17 02:00:33.195372 Archive '00000019000000000000005D' does not exist.
ERROR: 2023/06/17 02:01:45.894435 Archive '0000001A.history' does not exist.
ERROR: 2023/06/17 02:01:46.197105 Archive '00000019000000000000005D' does not exist.


    Журнал выполнения бекапа с сервера за 16-е число.
    INFO: 2023/06/16 17:00:01.582475 retrieving permanent objects
INFO: 2023/06/16 17:00:02.072793 Start delete
INFO: 2023/06/16 17:00:02.222819 Objects in folder:
INFO: 2023/06/16 17:00:02.222870        will be deleted: basebackups_005/base_000000180000000000000057_backup_stop_sentinel.json
INFO: 2023/06/16 17:00:02.222954        will be deleted: wal_005/000000180000000000000057.00000028.backup.br
INFO: 2023/06/16 17:00:02.222963        will be deleted: wal_005/000000180000000000000057.br
INFO: 2023/06/16 17:00:02.222972        will be deleted: wal_005/000000180000000000000058.br
INFO: 2023/06/16 17:00:02.223025        will be deleted: basebackups_005/base_000000180000000000000057/metadata.json
INFO: 2023/06/16 17:00:02.223052        will be deleted: basebackups_005/base_000000180000000000000057/tar_partitions/part_001.tar.br
INFO: 2023/06/16 17:00:02.223066        will be deleted: basebackups_005/base_000000180000000000000057/tar_partitions/part_003.tar.br
INFO: 2023/06/16 17:00:02.223077        will be deleted: basebackups_005/base_000000180000000000000057/tar_partitions/pg_control.tar.br
INFO: 2023/06/16 17:00:02.292458 Selecting the latest backup as the base for the current delta backup...
INFO: 2023/06/16 17:00:02.320451 Calling pg_start_backup()
INFO: 2023/06/16 17:00:02.473048 Starting a new tar bundle
INFO: 2023/06/16 17:00:02.473108 Walking ...
INFO: 2023/06/16 17:00:02.473456 Starting part 1 ...
INFO: 2023/06/16 17:00:02.905460 Packing ...
INFO: 2023/06/16 17:00:02.906443 Finished writing part 1.
INFO: 2023/06/16 17:00:04.052359 Starting part 2 ...
INFO: 2023/06/16 17:00:04.052436 /global/pg_control
INFO: 2023/06/16 17:00:04.053475 Finished writing part 2.
INFO: 2023/06/16 17:00:04.054552 Calling pg_stop_backup()
INFO: 2023/06/16 17:00:05.096904 Starting part 3 ...
INFO: 2023/06/16 17:00:05.097015 backup_label
INFO: 2023/06/16 17:00:05.097027 tablespace_map
INFO: 2023/06/16 17:00:05.098561 Finished writing part 3.
INFO: 2023/06/16 17:00:05.203537 Wrote backup with name base_00000018000000000000005D


    С рабочего сервера, больше записей нет - /var/log/wal-g/wal_g_archive_command.log
    INFO: 2023/06/12 17:00:04.588456 FILE PATH: 000000180000000000000055.br
INFO: 2023/06/13 17:00:03.180230 FILE PATH: 000000180000000000000056.br
INFO: 2023/06/13 17:00:04.911261 FILE PATH: 000000180000000000000057.00000028.backup.br
INFO: 2023/06/13 17:00:04.917427 FILE PATH: 000000180000000000000057.br
INFO: 2023/06/14 17:00:01.995453 FILE PATH: 000000180000000000000058.br
INFO: 2023/06/14 17:00:03.984552 FILE PATH: 000000180000000000000059.00000028.backup.br
INFO: 2023/06/14 17:00:03.986231 FILE PATH: 000000180000000000000059.br
INFO: 2023/06/15 17:00:02.916916 FILE PATH: 00000018000000000000005A.br
INFO: 2023/06/15 17:00:04.716082 FILE PATH: 00000018000000000000005B.br
INFO: 2023/06/15 17:00:04.716215 FILE PATH: 00000018000000000000005B.00000028.backup.br
INFO: 2023/06/16 17:00:02.556806 FILE PATH: 00000018000000000000005C.br
INFO: 2023/06/16 17:00:04.229296 FILE PATH: 00000018000000000000005D.00000028.backup.br
INFO: 2023/06/16 17:00:04.230712 FILE PATH: 00000018000000000000005D.br
    Написано

  • В postgresql параметр max_wal_size - размер всех сегментов или одного?

    @igortru Автор вопроса
    Melkij, Благодарю!
    Написано

  • В postgresql параметр max_wal_size - размер всех сегментов или одного?

    @igortru Автор вопроса
    Melkij, Спасибо за ответы. Раз уж коснулись wal-g, каким образом wal-g понимает (берет список wal) для передачи в параметры %f %p- wal-fetch "%f" "%p"' ?

    Если я правильно понимаю то при восстановлении LATEST бекапа, при запуске postgress restore_command начинает получать wal и "проигрывать" их.
    Написано

  • В postgresql параметр max_wal_size - размер всех сегментов или одного?

    @igortru Автор вопроса
    Melkij, patroni, 5 нод, одна из реплик бывает отьезжает на 5-8 часов, нужно что-бы она нашла нужные ей wal на мастере и встала в строй. Бекапы с помощью wal-g, знаю что можно решить с помощью restore_commannd но пока не изучал этот вариант.
    Написано

  • В postgresql параметр max_wal_size - размер всех сегментов или одного?

    @igortru Автор вопроса
    т.е. max_wal_size вообще не регламентирует размер директории - pg_wal? Верно ли я понимаю что max_wal_size это количество данных переданных в wal но не размер директории или размер файла wal?
    Если мне условно нужно хранить wal для последние 12 часов то это можно сделать c помощью wal_keep_size ?
    Написано

  • Куда мигрировать почту с Office 365?

    @igortru Автор вопроса
    С этими сервисами может возникнуть санкционный отказ, проблемы с оплатой и пр. Отечественное наше всё.
    Написано

  • Какая разница в электронной цифровой подписи?

    @igortru Автор вопроса
    спасибо, но не по существу вопроса.
    Написано

  • Какая разница в электронной цифровой подписи?

    @igortru Автор вопроса
    Василий Банников, я привёл пример. Какой серт выбрать? И чем отличается допустим сертификат "Ключ для отчётности" и "Корпоративные системы ЭДО" ?
    Написано

  • Не впускает в домен?

    @igortru
    нужен текст ошибки.
    dns верно указан?
    Написано

  • Не впускает в домен?

    @igortru
    при смене ip в ad ничего менять не надо, первое предложение вообще не понял
    Написано

  • Pfsense за Cisco ASA?

    @igortru
    для чего вам Pfsense внутри сети? IPS/IDS ? у меня что-то сигнатуры перестали обновляться
    Написано