Мы используем две базы данных, одна для read-only, а вторая для «read and write», и мы можем достичь того, что мы получаем.
Но иногда нашей базе данных, предназначенной только для чтения, требовалось больше времени для выполнения одного и того же запроса, и это выглядело так, будто запросы помещались в очередь.
Это связано с тем, что мы используем базу данных с высокой конфигурацией «Чтение, запись» по сравнению с базой данных «Только для чтения». (Amazon RDS)
Да тот же запрос, это реплика "базы данных для чтения и записи" только для чтения
Возможно, кэш на реплике еще не прогрелся. Недавно об этом была статья: percona.com/blog/2019/06/25/adaptive-hash-index-on-aws-aurorа
Когда вы говорите «иногда», как часто? И «больше времени» это как 10 мс против 20 мс или 10 мс против 200 мс? Всегда ли ведомый медленнее или лидер тоже иногда медленнее? Я спрашиваю, потому что ожидаются некоторые колебания производительности. Выполняли ли вы обычные действия по проверке журнала медленных запросов и частоты попаданий в кэш? Актуальны ли таблица статистики и таблицы оптимизированы?
@Schwern это случилось дважды за последний месяц, только «10 мс против 200 мс», только ведомый медленнее, а не лидер, поскольку лидер имеет лучшую конфигурацию, чем ведомый.
Конфигурация сервера read-only ниже, чем у сервера read and write? Поскольку read-only выполняет всю часть запросов, конфигурация должна быть лучше, чем у основного сервера (чтение и запись).
Сервер @James такой же, только база данных другая
какой экземпляр вы используете для обоих?
Сервер находится на Heroku и базе данных M4 Large (чтение и запись) && T2 Mid (только чтение)
Аааа ... Поскольку у вас 8 ГБ ОЗУ (чтение и запись) и только 4 ГБ (только чтение). Часто запрос извлекается из реплики чтения, поэтому он должен быть более мощным, чем (чтение и запись). Это та же концепция, что и репликация Master-Slave.
@ Джеймс, я не понял, что ты хочешь сказать, конфигурация хороша или ее нужно изменить?
Изменить.. сделать (только для чтения) выше
Фактически, только чтение используется, когда ваше приложение обращается к БД в основном при выборе, а не при обновлении или вставке, поэтому, когда добавляется только чтение, лидер позаботится об операции записи, а ведомый позаботится о чтении, чтобы сбалансировать рабочую нагрузку, если у вас есть более высокий ведомый, лидер может выполнять операции записи без каких-либо задержек, поскольку запрос на чтение обрабатывается ведомым.






Server is on Heroku and database M4 Large (Read & Write) && T2 Mid (Read Only) – Arvind 7 mins ago
Ваши базы данных находятся на другом "железе", у них будет разная производительность.
Самое существенное отличие, которое я вижу, это память: 4 ГБ против 8 ГБ. Это повлияет на объем кэширования каждой базы данных. Ваш лидер (чтение и запись) имеет больше памяти и может кэшировать больше. Ваш последователь (только для чтения) с меньшим объемом памяти может вытолкнуть из кеша то, что осталось у вашего лидера.
Существует также производительность сети. t2.medium имеет рейтинг «от низкого до среднего», а m4.large — «умеренный». Что это на самом деле означает, я понятия не имею, кроме того, что у T2 их меньше.
Наконец, инстанс T2 — это "взрывной", что означает, что он обычно работает примерно на 20% мощности ЦП с пиками до максимальной производительности, используя кредиты ЦП. Если у вас заканчиваются кредиты ЦП в стандартный режим (по умолчанию для T2), производительность ЦП упадет. Возможно, ваш соратник T2 находится в стандартном режиме, и у него периодически заканчиваются кредиты процессора.
@Arvind Мне любопытно, было ли это что-то конкретное, например, нехватка кредитов ЦП.
это было связано с использованием процессора
Это одни и те же запросы с одной и той же схемой, данными и индексами? Если нет, то они не сопоставимы. Когда вы говорите «только для чтения», вы имеете в виду читать реплику или что-то еще?