A) Какое оптимальное решение для регулярной резервной копии большой базы данных PostgreSQL (версия 8.3 работает на последнем сервере Ubuntu); пожалуйста, не говорите pg_dump с этим мучительно медленными операторами вставкиРешение для восстановления и резервного копирования PostgreSQL
B) Что является лучшим решением для репликации баз данных PostgreSQL, которая работает в реальном мире
A. pg_dump по умолчанию не использует инструкции вставки. Он будет использовать команду COPY по умолчанию. Переключатель командной строки -d или --inserts приведет к тому, что pg_dump будет помещать инструкции insert в экспорт. Если у вас есть один из этих переключателей в вашей команде pg_dump, просто удалите их, чтобы pg_dump использовал COPY.
B. В предстоящей версии Postgres у них будет simple replication из коробки. Я думаю, что релиз 8.4 планируется в ближайшее время. Поэтому, возможно, стоит позаботиться об этом, если это возможно.
Вы можете использовать Online WAL-Backup, возможно, в сочетании с ночным/ежедневно/еженедельно/ежемесячно pg_dumps. Раз в неделю/месяц вы должны скопировать весь кластер.
Восстановление работает довольно хорошо, и вы почти не теряете данные при копировании с раннего времени (rsync лучше всего, так как он очень эффективен).
Скорость хорошая, потому что она должна применять только WAL, которые позже, чем ваша последняя полная резервная копия/копия кластера.
Я думаю, что есть только один ответ на этот вопрос.
PITR, или момент времени восстановления. Это, в основном, архивирование журналов транзакций и, насколько я знаю, лучший способ делать резервные копии.
Я установил его пару раз для 8.1, но он должен быть таким же в 8.3.
В postgresql.conf все, что вам нужно сделать, это добавить следующее:
archive_command = 'test ! -f /path/to/your/backups/archive_logs/%f && cp -i %p /path/to/your/backups/archive_logs/%f </dev/null'
Эта команда копирует архив журналов в указанный каталог, где вы можете смело его резервную копию с программным обеспечением резервного копирования на ваш выбор.
Чтобы сделать полную резервную копию, вам нужно сначала сообщить PostgreSQL, что вы берете резервную копию. Выполняется командой psql psql "SELECT pg_start_backup('my_backup');" После этого просто скопируйте данные в каталог с помощью rsync, cpio или какого-либо другого инструмента. Если база данных сильно используется, файлы будут меняться во время копирования, поэтому важно, чтобы инструмент правильно справился с этим и не выручил.
После завершения копирования просто запустите psql "SELECT pg_stop_backup();", чтобы сообщить PostgreSQL, чтобы остановить его снова. То, что эти команды делают, - это помещать маркер в журналы архива, где началась резервная копия, поэтому при восстановлении он знает, откуда ему нужно начинать чтение.
Этот метод также может использоваться для теплого резерва для репликации, но он не будет читабельным, просто готов принять его в случае чрезвычайной ситуации. Полный горячий режим ожидания планируется в версии 8.4, поэтому до тех пор я не думаю, что есть другой вариант.
Замечательно, если вы используете PITR, вы можете указать временную метку, когда вы хотите добавить архивные журналы.Таким образом, он может также сохранить базу данных от несчастных случаев (например, удаление или изменение некоторых данных).
pg_dump по умолчанию не использует инструкции insert. Он будет использовать команду COPY по умолчанию. Переключатель командной строки -d или --inserts приведет к тому, что pg_dump будет помещать инструкции insert в экспорт. Вы имеете в виду, что COPY слишком медленный? Или вы используете командный переключатель -d или --inserts? –
Я не знал, что могу отключить инструкции вставки, КОПИРОВАТЬ ОК. – tropikalista