Я ищу решения для репликации PostgreSQL. Я знаю две разновидности этих решений
Моя база данных не очень загружена и огромна (по крайней мере, сейчас). Но я хочу избежать простоев из-за сбоев Amazon EC2 (например, недавнего). Мое решение - поддерживать ведомое устройство в другой зоне доступности, которое будет синхронизироваться с моим главным экземпляром базы данных. Таким образом, я могу переключиться на него, когда мастер выйдет из строя. Следует учитывать, что для этого потребуется непрерывная репликация данных от главного устройства к подчиненному, что будет являться сетевым трафиком в зонах доступности EC2. Это не бесплатно. Сейчас это стоит 1 цент за ГБ, но, прочитав некоторые расчеты в кулинарной книге PostgreSQL, я узнал, что затраты могут вырасти очень высокими даже при низком трафике БД. Например, в главе «Горячее физическое резервное копирование и непрерывное архивирование» "Поваренная книга администратора PostgreSQL 9" Я читал это:
Если для параметра archive_timeout установлено значение 30 секунд, мы будем генерировать минимум 2 * 60 * 24 = 2880 файлов в день, каждый размером 16 МБ, то есть общий объем 46 ГБ в день (минимум)
[и это я предполагаю с минимальным трафиком в БД]
Мое единственное требование состоит в том, что каждый SQL-запрос записи, выполняемый на главном сервере, должен воспроизводиться на подчиненном сервере. Если это делается при обратном вызове события, то это будет идеально, потому что передача данных между ведущим и ведомым будет происходить только при изменении БД, а не каждые 30 секунд или около того, даже если в БД не произошло никаких изменений.
Поэтому я подумал, что Londiste может быть для меня решением, но я не уверен на 100%, что это работает именно так.
Что ты предлагаешь?
После недели исследований я считаю Streaming Log Shipping и Hot Standby Конфигурация экземпляров PostgreSQL удовлетворяет мои потребности в мгновенной репликации (минимальное окно потери данных) при низком сетевом трафике. Я написал подробный Сообщение блога о том, как я это настроил.
Могут быть и другие решения с использованием сторонних инструментов, таких как pgpool, но я не добился большого успеха с ними.
Посмотри на pgpool. Мы используем его в продакшене и пока очень довольны. Очевидно, вы все еще хотите создавать резервные копии, поскольку это не защищает вас от ошибок SQL-запросов, но прекрасно выполняет синхронизацию / репликацию.