Блог

Описание среды: Служба сбора данных, которая получает от 10 до 17 миллионов строк данных в день, хранящихся в базе данных.

Проблема: Наша база данных была перегружена, и было настроено «включить автоматическое масштабирование». Автоматического масштабирования так и не произошло, и наша база данных не смогла собрать данные из-за переполнения хранилища, поэтому у нас произошел сбой.

Доступное хранилище неуклонно сокращается

Мышь зависает точно в тот момент, когда произошло отключение

Вот конфигурация для рассматриваемой БД

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

Возможное Объяснение 1:

Из документов:

Автоматическое масштабирование не происходит, если максимальный порог хранения будет равен или превышен приращением хранилища.

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

Возможное Объяснение 2:

Кроме того, из документов:

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

Я заметил этот статус RDS Снимок экрана был сделан в понедельник в 18:54 по восточному времени, а отключение произошло в среду в 10:48 по восточному времени, т. е. > 6 часов спустя. И статус RDS вернулся к состоянию Доступно в промежутке между состоянием оптимизации хранилища и отключением. Так что я не думаю, что это тот самый.

Мой вывод: я думаю, что автоматическое масштабирование не сработало, потому что наш максимальный порог хранения был установлен только на 1000.

Чтобы избежать этой проблемы в будущем: если бы мы установили Максимальный порог хранения на 6500, выглядела бы диаграмма так?

У нас все равно был бы сбой, но автоматическое масштабирование дало бы нам больше времени (где синий круг, где произошел бы сбой)? Если я ошибаюсь в этом последнем утверждении, то я не уверен, как правильно использовать автоматическое масштабирование.

Я на правильном пути, или я здесь далек от истины? Спасибо, что прочитали.

Как работает «автоматическое масштабирование»? MySQL предназначен для работы в любом объеме оперативной памяти, при условии, что он правильно настроен. То есть MySQL не будет «исчерпывать оперативную память», вместо этого он будет работать медленнее.

В случае ввода-вывода расскажите нам, как обстоят дела с «17 миллионами строк данных в день» INSERTed . IOPS вряд ли поймет это. Вместо этого вставки, скорее всего, будут задерживаться все дольше и дольше.

Для обоих из них, возможно, удастся переписать, как прием пищи может масштабироваться далеко за пределы 17 м, даже без увеличения. Пожалуйста, предоставьте подробную информацию о том, откуда берутся данные, как они собираются, как они группируются (или не группируются) и как INSERT выглядит заявление(заявления). Включите в обсуждение вопрос о том, есть ли несколько потоков, выполняющих обработку.

Если он не включен, пожалуйста, включите slowlog с низким значением для long_query_time . Этот вывод может помочь нам найти основной запрос для работы над оптимизацией.

Есть ли у вас другие приложения, запущенные на том же сервере? Пилообразная природа немного похожа на сборку мусора в Java (которую MySQL не использует).

Если вы запускаете приложения на той же машине, что и MySQL, вам следует серьезно рассмотреть возможность их разделения.

Что означает «ситуации с полным хранилищем«? Относится ли это к количеству материала, хранящегося на диске? Если да, то давайте обсудим имеющиеся у вас таблицы. Некоторые методы, которые мы можем обсудить:

• Меньшие типы данных
• Очистка «старых» данных (возможно, с PARTITIONing указанием даты)
• Нормализация

AWS мало что может сделать для очистки диска без серьезного уничтожения ваших данных. Возможно, это как на пределе, и «быстрое решение» состоит в том, чтобы переместить экземпляр на следующий диск большего размера. (Между тем, мы можем сделать другие предложения здесь-так что вы можете вернуться к этому размеру диска, чтобы снова сэкономить деньги.)