pg_start_backupбудет выполнять контрольно-пропускной пункт, как отмечает Дезсо. Это оказывает влияние, но ваша база данных в любом случае выполняет контрольные точки довольно регулярно, и должна работать так, чтобы они явно не были для вас проблемой. Ранняя контрольная точка означает, что было накоплено меньше данных, а это означает, что контрольная точка, с которой она работает, pg_start_backupбудет иметь меньшее воздействие, чем обычно.
Где вам нужно беспокоиться, это rsync или эквивалентный pg_basebackupшаг. Чтение ввода-вывода из этого не будет слишком плохим, поскольку оно последовательное, но оно все же, вероятно, значительно ухудшит производительность ввода-вывода вашей базы данных, а также будет стремиться вытеснить горячие данные из кеш-памяти в пользу меньшего количества -используемые данные, что приводит к перебоям в кеше, поскольку более необходимые данные затем считываются обратно.
Вы можете использовать niceи, ioniceчтобы помочь ограничить влияние ввода-вывода (но не влияние кэша); Тем не менее, есть цена для этого. Резервное копирование займет больше времени, и до тех пор, пока вы не завершите резервное копирование и не запустите pg_stop_backupсвою систему - как я понимаю, - накапливается WAL, который она не может удалить, накапливает задолженность контрольных точек для БОЛЬШОЙ контрольной точки в конце выполнения резервного копирования и накапливает таблицу и индекс раздувать, потому что он не может очистить мертвые ряды. Таким образом, вы действительно не можете позволить себе резервное копирование навсегда, особенно если у вас очень высокие показатели оттока.
В конце концов, трудно сказать, можете ли вы безопасно использовать pg_start_backupи pg_stop_backupгорячее резервное копирование в вашей среде. Большинство людей могут, но если вы близки к тому, что может сделать ваше оборудование, у вас жесткие требования к срокам, вы не можете позволить себе риск остановки, и у вас очень высокие таблицы оттока, а также очень большие таблицы, это может быть проблематично. ,
К сожалению, вам в значительной степени нужно проверить это и посмотреть.
Если вы можете, то, возможно, стоило бы выпустить CHECKPOINTатомный снимок тома, на котором находится ваша база данных, вместо этого, используя LVM, инструменты вашей SAN, EBS или что-то еще. Если вы можете сделать это, вы можете скопировать снимок на досуге. Этот подход не подходит для создания базовой резервной копии для PITR / горячего резервирования / горячего резервирования, но он идеально подходит для статической резервной копии и оказывает гораздо меньшее влияние на систему. Вы можете сделать это только в том случае, если ваши снимки являются атомарными, а вся база данных, включая WAL, находится на одном томе.
Одна возможность, которую я еще не исследовал, - это объединение двух подходов. Мне приходит в голову, что кто-то может ( непроверенный и, возможно, неправильный и небезопасный , я еще не знаю):
pg_start_backup- Триггерные снимки всех табличных пространств, основного каталога данных и тома xlog
pg_stop_backup- Скопируйте WAL до окончательного архива из
pg_stop_backup
- Скопируйте данные из томов моментальных снимков
По сути, идея состоит в том, чтобы сократить длительность задержки БД на своих контрольных точках, используя момент времени для каждого тома, который вы можете скопировать на досуге.