Redis предоставляет широкий спектр инструментов, направленных на улучшение и поддержание эффективного использования базы данных в памяти. Хотя его уникальные типы данных и команды точно настраивают базы данных для обслуживания запросов приложений без какой-либо дополнительной обработки на уровне приложений, неправильная конфигурация или, скорее, использование готовой конфигурации может (и делает) приводить к эксплуатационным проблемам и производительности проблемы. Несмотря на неудачи, которые стали причиной многих головных болей, решения существуют, и они могут быть даже проще, чем предполагалось. В этой серии статей будут освещены некоторые наиболее раздражающие проблемы, возникающие при использовании Redis, а также советы по их решению. Они основаны на нашем реальном опыте работы с тысячами экземпляров базы данных Redis.
После нашей предыдущей статьи из этой серии, Буфера репликации , следующая головная боль в нашем списке будет продолжена в теме репликации мастер-подчиненный. В частности, мы рассмотрим немного больше времени, необходимого для завершения процесса, а также некоторые проблемы с конфигурацией, которые могут вызвать серьезные неудобства.
Тайм-ауты репликации
Как мы уже обсуждали в посте « Бесконечный цикл репликации», процесс репликации Redis состоит из двух этапов синхронизации: начального и продолжающегося. Несмотря на то, что текущий этап достаточно стабилен (пока сохраняется связь между ведущим и ведомым), начальный этап несколько сложнее завершить. Успешное завершение начальной синхронизации зависит не только от объема памяти, выделенной для буфера репликации (см. Предыдущую головную боль ), но также от количества времени, которое занимает этот шаг.
Вы можете вспомнить, что начальный шаг синхронизации состоит из фонового сохранения и передачи всей базы данных от ведущего устройства к подчиненному. В зависимости от размера набора данных и качества сетевого подключения это может оказаться длительным процессом. Если эта фаза занимает слишком много времени, может быть достигнут параметр тайм-аута репликации Redis, в результате чего начальная фаза будет повторяться снова и снова, до тошноты. В таких случаях вы найдете журнал Redis вашего ведомого, пронизанный сообщениями, такими как:
[28618] 21 Jul 00:33:36.031 * Connecting to MASTER 10.60.228.106:25994 [28618] 21 Jul 00:33:36.032 * MASTER <-> SLAVE sync started [28618] 21 Jul 00:33:36.032 * Non blocking connect for SYNC fired the event. [28618] 21 Jul 00:33:36.032 * Master replied to PING, replication can continue... [28618] 21 Jul 00:33:36.032 * Partial resynchronization not possible (no cached master) [28618] 21 Jul 00:33:36.032 * Full resync from master: 549907b03661629665eb90846ea921f23de6c961:2537453
Время ожидания репликации Redis по умолчанию установлено равным 60 секундам (см. Директиву repl-timeout в вашем файле redis.conf или выполните конфигурацию get repl-timeout, используя redis-cli). Этот период времени может быть слишком коротким, особенно если у вас есть:
-
Медленное хранение: если мастер и / или ведомое устройство подключены к медленному хранилищу, это приведет к тому, что процесс фонового сохранения займет значительное время в случае мастера. В случае ведомого устройства запись и загрузка данных с диска могут быть продлены.
-
Большой набор данных: чем больше размер набора данных, тем больше времени потребуется для его сохранения и передачи.
-
Производительность сети: когда сетевое соединение между ведущим и ведомым устройством имеет ограниченную пропускную способность и / или высокую задержку, это напрямую влияет на скорость передачи данных.
Вы можете исправить это, установив для таймаута репликации более подходящее значение. Начните с работы над приемлемой оценкой времени, необходимого для репликации базы данных. Во-первых, проверьте, как долго Redis выполняет фоновое сохранение, выполнив BGSAVE.команда и проверка файла журнала для соответствующих строк (т. е. * Фоновое сохранение, запущенное pid nnn *, указывает, что процесс запущен, тогда как * Фоновое сохранение, завершенное с успехом *, указывает на его завершение). Затем, сколько времени вам потребуется, чтобы скопировать получившийся RDB-файл с мастера на диск подчиненного устройства. Наконец, вам нужно определить время, необходимое для фактической загрузки данных с диска (например, путем перезапуска Redis и поиска * DB, загруженного со строки диска в файле журнала). Сумма этих измерений может служить приблизительной оценкой желаемого значения времени ожидания репликации, но вы, вероятно, захотите добавить 10-20% к нему для безопасности.
После того, как вы установили тайм-аут на основе оценки, вы можете проверить, сколько времени на самом деле занимает репликация, выполнив несколько раз полную синхронизацию подчиненного устройства и изучив файл журнала. Если возможно, попробуйте повторить это упражнение в разное время дня, чтобы лучше оценить поведение системы при разных нагрузках. Наконец, имейте в виду, что значение параметра тайм-аута следует периодически пересматривать в зависимости от роста вашей базы данных.
На этом мы завершаем обзор проблем с репликацией в Redis. Репликация — это мощный инструмент, позволяющий поддерживать доступность вашей базы данных и масштабировать ее пропускную способность чтения, но соблюдайте настройки по умолчанию и убедитесь, что вы настроили базу данных в соответствии со своим вариантом использования.
Если вы закончили читать эту статью и хотите погрузиться в очередную распространенную причину головной боли Devops, продолжайте читать о клиентских буферах .
— Подробнее см .:
http://redislabs.com/blog/top-redis-headaches-for-devops-replication-timeouts#.U-Tw4EjeMaE.