Видео недоступно для предпросмотра
Смотреть в Telegram
🔄 Репликация базы данных необходима для обеспечения надежности, но она также может вызвать задержку репликации
Но что же такое "задержка репликации"?
В типичной конфигурации репликации с ведущим узлом все операции записи направляются на основной узел.
Тем не менее, запросы на чтение могут обрабатываться любой репликой (включая основную в некоторых случаях).
Это хорошо, потому что вы можете масштабировать операции чтения, добавляя больше реплик.
Но для получения полного преимущества от репликации используется асинхронная репликация.
Однако, когда ваше приложение читает данные с асинхронной реплики, существует большая вероятность, что оно может получить устаревшую информацию, если реплика по какой-то причине отстала.
📝 Например:
1️⃣ Пользователь А отправляет запрос на обновление (запись) на основной или ведущий узел.
2️⃣ Ведущий узел отправляет новую информацию своим репликам.
3️⃣ Реплика 1 обновляется.
4️⃣ Однако пользователь B запрашивает (читает) данные с реплики 2 и получает устаревшую информацию.
5️⃣ Позже реплика 2 в конечном итоге обновляется.
Задержка между моментом выполнения записи на ведущем узле и её отражением на подчиненном узле известна как "задержка репликации".
Задержка может составлять всего лишь долю секунды (практически незаметно).
Однако, если система работает на пределе своих возможностей, задержка также может увеличиться до нескольких секунд или даже минут.
🚨 Таким образом, основная проблема - несоответствие данных для пользователей:
1. Пользователь B может неоднократно читать данные и видеть разные результаты из-за задержки репликации.
2. Пользователь А, сделавший запись, может получить устаревшие данные при чтении с реплики.
#databases #replica #eventual_consistency
На связи с вами https://t.me/itarchitecture
Но что же такое "задержка репликации"?
В типичной конфигурации репликации с ведущим узлом все операции записи направляются на основной узел.
Тем не менее, запросы на чтение могут обрабатываться любой репликой (включая основную в некоторых случаях).
Это хорошо, потому что вы можете масштабировать операции чтения, добавляя больше реплик.
Но для получения полного преимущества от репликации используется асинхронная репликация.
Однако, когда ваше приложение читает данные с асинхронной реплики, существует большая вероятность, что оно может получить устаревшую информацию, если реплика по какой-то причине отстала.
📝 Например:
1️⃣ Пользователь А отправляет запрос на обновление (запись) на основной или ведущий узел.
2️⃣ Ведущий узел отправляет новую информацию своим репликам.
3️⃣ Реплика 1 обновляется.
4️⃣ Однако пользователь B запрашивает (читает) данные с реплики 2 и получает устаревшую информацию.
5️⃣ Позже реплика 2 в конечном итоге обновляется.
Задержка между моментом выполнения записи на ведущем узле и её отражением на подчиненном узле известна как "задержка репликации".
Задержка может составлять всего лишь долю секунды (практически незаметно).
Однако, если система работает на пределе своих возможностей, задержка также может увеличиться до нескольких секунд или даже минут.
🚨 Таким образом, основная проблема - несоответствие данных для пользователей:
1. Пользователь B может неоднократно читать данные и видеть разные результаты из-за задержки репликации.
2. Пользователь А, сделавший запись, может получить устаревшие данные при чтении с реплики.
#databases #replica #eventual_consistency
На связи с вами https://t.me/itarchitecture