Комментарии 17
Во вторых-и это самое неприятное, были случаи несовпадения исходной и целевой БД при восстановлении из дампа.
Какие еще несовпадения? Вы ожидали совпадения на какой момент?
В начале дампа pg_dump начинает serializable транзакцию, все, что произошло в исходной БД после, в дамп не попадает.
Думаете, копия через create database как-то по-другому работает?
В третьих-время, сначала на создание дампа, потом на восстановление БД из дампа.
Неужели репликация быстрее? Хмм…
В итоге единственное преимущество — экономия на месте для дампов (временных).
Какие еще несовпадения?
Несовпадение количество строк в некоторых таблицах в исходной и целевой БД, после выполнения pg_restore (Исходная БД не использовалась в процессе копирования, если, что ).
Ситуация иногда случалась при использовании формата directory. В случае использования формата plain — ситуация исключалась. Но plain огромный размер дампа.
Это кажется странным и я бы сам не поверил, если бы не видел собственными глазами.
Причем на некоторых БД все нормально, но некоторых проблема.
В итоге единственное преимущество — экономия на месте для дампов (временных).
Плюс простота организации и управления хранением.
БД все таки управляются проще чем гигабайтные файлы.
Несовпадение количество строк в некоторых таблицах в исходной и целевой БД, после выполнения pg_restore (Исходная БД не использовалась в процессе копирования, если, что ).не верю (с)
Имхо, лучше бы вы поисследовали эту проблему и про нее написали статью. Было бы гораздо полезнее разобраться, если что-то такое действительно может иметь место.
Но plain огромный размер дампа.Включите сжатие (custom/directory сжаты по умолчанию, отсюда вся разница).
К слову об экономии места: копия БД весит заведомо больше, чем любой дамп. Так что сомнительная у вас экономия даже на этом.
Плюс простота организации и управления хранением
Не знаю…
Если свежесть данных некритична (или БД можно отключить от пользователей), что-то проще dump/restore придумать сложно.
Если важна полнота данных (как, например, при онлайн миграции на новую версию), то дамп схемы + логическая репликация с живой БД — канонический способ, описанный примерно везде.
не верю (с)
Имхо, лучше бы вы поисследовали эту проблему и про нее написали статью.
Я и сам не поверил. Пока не сделал select count(*) на таблицах исходной и целевой БЛ после pg_dump->pg_restore. Факт есть факт. Проблема повторялось. И проблему надо было решать. Был использован план Б — не использовать сжатие и использовать формат plain.
Возможно будет статья. Может быть приведу и цитаты переписки со службой техподдержки по проблеме. Пока не решил, стоит ли тратить время на глубокий разбор, поскольку сейчас проблема уже потеряла свою актуальность.
копия БД весит заведомо больше, чем любой дамп
БД размером 3GB, дамп в формате plain весит порядка 14-17GB.
Если придерживаться такого решения задачи, то я бы сделал через снапшоты zfs:
1. Реплику на zfs
2. beginBackup
3. zfs create snapshot
4. zfs send | zfs recv
5. endBackup
6. recover clone (wal or replicatoin)
Как-то не продакшн-рэйди выглядит, а скорее ночной скрипт когда все точно с рабочих мест ушли.
Именно,ночной скрипт. На сервере хранения копий, каждую ночь обновляется набор баз с разных серверов.
В рабочее время - по согласованному запросу и с остановкой приложения.
Есть мысль попробовать запустить логическую репликацию и всегда иметь копию БД. Но в силу ограничений логической репликации ,есть подозрения что БД будут не идентичны.
Пока тема в разработке. Бывали случаи когда синхронизация не завершалась. Может быть для данного приложения (1С) и не получится.
А не проще настроить потоковую репликацию с исходного кластера на кластер хранения и делать копию уже на кластере хранения?
Потоковую репликацию не получится настроить - исходных кластеров несколько.
Потоковая репликация может быть и логической.
Спасибо за идею.
Надо будет проверить такой сценарий - запуск логической репликации между исходной БД и копией бд , синхронизация , закрытие репликации.
Однако в этом сценарии есть одна проблема - процесс синхронизации гораздо дольше, чем процесс создания клона БД. А на этапе синхронизации желательно, чтобы исходная БД не изменялась.
Вы меня не поняли.
У Вас есть две роли серверов БД: исходный сервер БД и сервер хранения БД. Каждая роль может включать в себя несколько серверов БД. Зависит от Ваших потребностей. Но не суть.
Вы настраиваете потоковую логическую репликацию базы с исходного сервера БД на сервер хранения БД. Т.е. изменения в этой базе на исходном сервере БД в реальном времени накатываются на реплику этой базы на сервере хранения БД.
Таким образом, в любой момент времени на сервере хранения БД у Вас уже есть экземпляр этой базы в актуальном состоянии. Поэтому в любой момент времени Вы можете сделать копию данной базы уже на самом сервере хранения БД, не трогая при этом исходный сервер БД.
Если необходимо, чтобы база на момент создания копии не изменялась, Вы всегда можете просто поставить репликацию на паузу, сделать копию, а потом обратно включить репликацию. Тут надо помнить, что во время паузы начнут накапливаться валы (wal).
Вы настраиваете потоковую логическую репликацию базы с исходного сервера БД на сервер хранения БД. Т.е. изменения в этой базе на исходном сервере БД в реальном времени накатываются на реплику этой базы на сервере хранения БД.
и планировался с самого начала.
Но, выяснился неприятный момент — копия БД иногда не открывается приложением 1С(копируются БД для 1С). Возникают разнообразные ошибки со стороны 1С.
Поэтому и был выбран другой вариант, для надежности.
Вообще 1С и PostgreSQL это отдельная тема для исследования.
Две схемы работы:
1) Исходный сервер БД —> копия базы на исходном сервере БД —> логическая репликация копии базы на сервер хранения БД.
2) Исходный сервер БД —> логическая репликация базы на сервер хранения БД —> копия базы на сервере хранения БД.
В обоих схемах используется как копирование базы, так и логическая репликация.
Используя первую схему, Вы излишне нагружаете исходный (как я понял — продуктовый) сервер БД:
— постоянным копированием базы;
— каждый раз новой (т.е. с нуля) логической репликацией.
Я бы тут попытался разобраться, почему одни и те же операции дают, как Вы утверждаете, разный результат.
Этюд — логическая репликация для копирования баз данных PostgreSQL