Запуск pg_dump на гарячому сервері очікування?

Відмова: Я, правда, ще не пробував цього, але я не впевнений, що знав би, чи не працює він правильно, тому хотів запитати.

Я хотів би запустити роботу нічного резервного копіювання (через pg_dumpall) з гарячого резервного сервера, на якому працює потокова реплікація, щоб не ставити це навантаження на основну. Я бачив лише згадки про деякі готчі, з якими стикалися люди, наприклад, тут і тут , але дуже мало настанов. Добре, якщо резервне копіювання трохи відстає від основного, доки воно є послідовним (яким воно має бути).

Мої запитання:

1. Чи дійсно я хочу це зробити, або резервне копіювання слід робити на первинному сервері? Чому?

2. Коли ви робите дамп у режимі очікування, які параметри мені потрібні та процедуру, яку я повинен використовувати, щоб правильно це зробити? наприклад, я повинен зупинити реплікацію на час резервного копіювання?

AFAIK, біг pg_dumpу гарячому режимі очікування - одна з найважливіших речей, для якої є корисні. Це абсолютно безпечно, хоча і не зовсім надійно - скидання може вийти з ладу, якщо очікування перерве транзакцію, коли вона занадто сильно відстає від майстра.

Єдине, на що дійсно потрібно дивитися, - це переконатися, що режим очікування поточний і не відстає. Якщо в режимі очікування втратили зв'язок з майстром і занадто сильно відстали, ви не хочете, щоб ви весело підтримували три тижні застарілого режиму очікування.

Вам потрібно дозволити резервному режиму відстати далеко від головного під час резервного копіювання, оскільки в іншому випадку доведеться скасувати pg_dumpтранзакцію, щоб продовжувати відтворення WAL. Дивіться документацію по гарячому резервування , в зокрема , в розділ «Обробку конфліктів запитів», а max_standby_archive_delayй max_standby_streaming_delayпараметри.

Зауважте, що майстер повинен бути готовим зберігати достатньо архівів WAL, щоб раб знову міг наздогнати.

1. Ми робимо резервне копіювання в режимі очікування, це прекрасно.
2. Щоб уникнути скасованого конфлікту операторів під час резервного копіювання в режимі очікування, вам потрібно призупинити реплікацію в режимі очікування SELECT pg_xlog_replay_pause();, а потім запустити резервну копію, як тільки вона закінчиться, запустіть, SELECT pg_xlog_replay_resume();щоб відновити реплікацію. Майте на увазі, що виконання вище команд призведе до відставання відновлення на підлеглому, яке може бути досить великим, залежно від розміру вашої бази даних. Крім того, враховуйте простір WAL-сегментів, оскільки вони не будуть відтворюватися на підлеглому під час паузи.

Ви можете знайти деякі інші корисні адміністративні функції в документації . Наприклад, перевірити , якщо сервер насправді в процесі відновлення, до припинення його: SELECT pg_is_in_recovery().

Якщо ви призупиняєте реплікацію під час резервного копіювання, (Це гарна ідея для збереження цілісності та консистенції), ви можете редагувати деякі рядки у своєму головному postgresql:

Скільки часу затримує ваше резервне копіювання звично. Переконайтеся, що головний вузол зберігає цілі файли x_log, необхідні для відновлення реплікації. Це можна зробити в редагуванні postgresql.conf

wal_keep_segments = 32      # in logfile segments, 16MB each; 0 disables

Якщо ви не змінюєте це, і процес резервного копіювання занадто довгий, ймовірно, головний вузол стирає файли xlog, перш ніж надсилати їх у ведений.