Comments 4
ОУ виндавс POSTGRES — ты серьезно?
Думаю можно ещё так:
Для уменьшения задержки при синхронной репликации можно установить значение
Так же использовать её следует для реально важных данных и включать её следует на уровне приложения, а не конфигурационно для всего сервера.
Не ведомых, а ведомой, СУБД для синхронной репликации в версии 9.4 использует первую доступную ноду. В случае её сбоя другую доступную, но всегда одну.
Всё-таки синхронную репликацию лучше делать частью каскадной репликации с горячим резервом, т.к. как ни крути, а накладной расход на ожидание уменьшает отклик, а если приложение постоянно мелкими запросами меняет данные, то отклик увеличится на порядок.
Про потерю данных в асинхронном режиме: она возможна, на время недоступности ведущего сервера, это есть, хотя потоковая репликация уменьшает это время, всё равно остаётся риск. Но она сильно быстрее работает, а по восстановлении ведущего сервера комиты дозапишутся, если ведомые сервера работали в режиме только для чтения. Если же горячая замена, то по идее без конфликтов допишется, но конфликты могут начаться просто с id записей и oid-ами.
Поэтому грамотный баланс синхронной и асинхронной репликации дадут и возможность горячего резерва с рабочими данными, и бэкап, и хорошие нервы, но делать его хорошо бы на уровне и приложения, и БД, и сетевом, и хардварном))
Для уменьшения задержки при синхронной репликации можно установить значение
synchronous_commit в remote_write. В таком случае будет ожидаться не запись на диск, а ответ от резервного сервера о получении данных.Так же использовать её следует для реально важных данных и включать её следует на уровне приложения, а не конфигурационно для всего сервера.
Минус: при больших нагрузках скорость работы клиентов снизиться: здесь скажется задержка ведомых нод при подтверждении записи транзакций.
Не ведомых, а ведомой, СУБД для синхронной репликации в версии 9.4 использует первую доступную ноду. В случае её сбоя другую доступную, но всегда одну.
Всё-таки синхронную репликацию лучше делать частью каскадной репликации с горячим резервом, т.к. как ни крути, а накладной расход на ожидание уменьшает отклик, а если приложение постоянно мелкими запросами меняет данные, то отклик увеличится на порядок.
Про потерю данных в асинхронном режиме: она возможна, на время недоступности ведущего сервера, это есть, хотя потоковая репликация уменьшает это время, всё равно остаётся риск. Но она сильно быстрее работает, а по восстановлении ведущего сервера комиты дозапишутся, если ведомые сервера работали в режиме только для чтения. Если же горячая замена, то по идее без конфликтов допишется, но конфликты могут начаться просто с id записей и oid-ами.
Поэтому грамотный баланс синхронной и асинхронной репликации дадут и возможность горячего резерва с рабочими данными, и бэкап, и хорошие нервы, но делать его хорошо бы на уровне и приложения, и БД, и сетевом, и хардварном))
Sign up to leave a comment.
Притча про синхронную репликацию и том, как от неё избавиться