Как можно избежать чтения старых или отсутствующих записей в реплике из-за задержки репликации между базой данных master / slave? - PullRequest
0 голосов
/ 14 февраля 2020

Я использую базу данных AWS Aurora Postgres, в которой есть мастер и реплика. В одной части моего приложения система должна читать из TableA сразу после вставки или обновления записи в той же таблице. Поскольку он читает из реплики, существует небольшая задержка между мастером и репликой чтения. Таким образом, я не всегда получаю последние данные, и иногда запись может показаться отсутствующей, потому что реплика еще не синхронизировала c запись от мастера.

Что я сделал сейчас, так это направил все запрос на чтение в этой части приложения для чтения непосредственно из TableA в master после запроса вставки / обновления. Однако из-за количества операций чтения из этого запроса нагрузка на главный экземпляр резко возросла.

Внезапно в этой части приложения количество операций ввода-вывода в секунду увеличивается вдвое. Если бы было 100 000 вставок / обновлений для TableA, теперь было бы еще 1000 000 операций чтения из TableA и на главном экземпляре! Между тем реплика имеет очень небольшую нагрузку, но я не могу перенести эту операцию чтения только из-за задержки репликации. Это приводит к неполному использованию реплики.

Могу ли я использовать какие-либо стратегии для предотвращения этой проблемы?

При чтении непосредственно из мастер-произведений, звучание удара по мастеру с таким количеством операций чтения кажется неправильным.

Я использую Node и Sequelize в своем приложении.

1 Ответ

1 голос
/ 14 февраля 2020

Потоковая репликация на самом деле не является устройством балансировки нагрузки.

Если вы хотите, чтобы изменения данных были видны в режиме ожидания немедленно, вы должны

  1. использовать синхронную потоковую передачу репликации путем добавления резервного к synchronous_standby_names на первичном (но учтите, что это уменьшает общую доступность!)

  2. установите synchronous_commit = remote_apply на первичном сервере

Это будет хорошо работать только в том случае, если задержка в сети мала, и у вас мало транзакций записи, поэтому, вероятно, это правильно с размещенной базой данных.

...