Почему «объем используемых байтов» всегда увеличивается в кластере Amazon Aurora?


11

У меня есть кластер Amazon (AWS) Aurora DB, и с каждым днем [Billed] Volume Bytes Usedон растет.

VolumeBytesUsed CloudWatch метрика с течением времени

Я проверил размер всех моих таблиц (во всех моих базах данных в этом кластере), используя INFORMATION_SCHEMA.TABLESтаблицу:

SELECT ROUND(SUM(data_length)/1024/1024/1024) AS data_in_gb, ROUND(SUM(index_length)/1024/1024/1024) AS index_in_gb, ROUND(SUM(data_free)/1024/1024/1024) AS free_in_gb FROM INFORMATION_SCHEMA.TABLES;
+------------+-------------+------------+
| data_in_gb | index_in_gb | free_in_gb |
+------------+-------------+------------+
| 30         | 4           | 19         |
+------------+-------------+------------+

Всего: 53 ГБ

Так почему в настоящее время мне выставляют счет почти на 75 ГБ?

Я понимаю, что выделенное пространство никогда не может быть освобождено, так же, как файлы ibdata на обычном сервере MySQL никогда не могут уменьшаться; Я в порядке с этим. Это задокументировано и приемлемо.

Моя проблема в том, что с каждым днем ​​пространство, которое мне выставляют, увеличивается. И я уверен, что я НЕ использую 75 ГБ пространства временно. Если бы я сделал что-то подобное, я бы понял. Это как если бы пространство памяти, которое я освобождаю, удаляя строки из моих таблиц, или удаляя таблицы, или даже удаляя базы данных, никогда не используется повторно.

Я несколько раз обращался в службу поддержки AWS (premium) и так и не смог получить хорошее объяснение, почему это так.
Я получил предложения запустить OPTIMIZE TABLEтаблицы, в которых их много free_space(по INFORMATION_SCHEMA.TABLESтаблице), или проверить длину истории InnoDB, чтобы убедиться, что удаленные данные все еще не сохраняются в сегменте отката (ссылка: MVCC ). и перезапустите экземпляр (ы), чтобы убедиться, что сегмент отката очищен.
Никто из них не помог.

Ответы:


19

Здесь есть несколько вещей ...

  1. Каждая таблица хранится в своем собственном табличном пространстве

    По умолчанию группа параметров для кластеров Aurora (именованная default.aurora5.6) определяет innodb_file_per_table = ON. Это означает, что каждая таблица хранится в отдельном файле в кластере хранения Aurora. Вы можете увидеть, какое табличное пространство используется для каждой из ваших таблиц, используя этот запрос:

    SELECT name, space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES;

    Примечание: я не пытался изменить innodb_file_per_tableна OFF. Может быть, это поможет ..?

  2. Пространство памяти, освобожденное удалением табличных пространств, НЕ используется повторно

    Цитирование поддержки AWS Premium:

    Благодаря уникальной конструкции движка Aurora Storage для повышения его производительности и отказоустойчивости Aurora не обладает функциональностью для дефрагментации табличных пространств файлов на таблицы так же, как стандартный MySQL.

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

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

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

    Как только ваш общий набор данных превысит определенный размер (приблизительно 160 ГБ), вы можете начать освобождать пространство в блоках по 160 ГБ для повторного использования, например, если у вас есть 400 ГБ в томе кластера Aurora и DROP 160 ГБ или более таблиц, то Aurora может затем автоматически повторно использовать 160 ГБ данных. Однако это может быть медленно, чтобы восстановить это пространство.
    Причиной большого объема данных, которые необходимо освободить за один раз, является уникальная конструкция Auroras как ядра БД корпоративного масштаба, в отличие от стандартного MySQL, который нельзя использовать в этом масштабе.

  3. ОПТИМИЗИРУЙ СТОЛ - ЗЛО!

    Поскольку Aurora основан на MySQL 5.6, OPTIMIZE TABLEон сопоставлен с ALTER TABLE ... FORCEтаблицей, которая перестраивает таблицу для обновления статистики индекса и освобождения неиспользуемого пространства в кластерном индексе. По сути, innodb_file_per_table = ONэто означает, что запуск OPTIMIZE TABLEсоздает новый файл табличного пространства и удаляет старый. Поскольку удаление файла табличного пространства не освобождает используемое хранилище, это OPTIMIZE TABLEвсегда приводит к выделению большего объема памяти. Ой!

    Ссылка: https://dev.mysql.com/doc/refman/5.6/en/optimize-table.html#optimize-table-innodb-details

  4. Использование временных таблиц

    По умолчанию группа параметров для экземпляров Aurora (named default.aurora5.6) определяется default_tmp_storage_engine = InnoDB. Это означает, что каждый раз, когда я создаю TEMPORARYтаблицу, она хранится вместе со всеми моими обычными таблицами в кластере хранения Aurora. Это означает, что для хранения этих таблиц предусмотрено новое пространство, что увеличивает общий объем VolumeBytesUsed.
    Решение для этого достаточно простое: измените default_tmp_storage_engineзначение параметра на MyISAM. Это заставит Аврору создавать TEMPORARYтаблицы в локальном хранилище экземпляра.
    Примечательно: локальное хранилище экземпляров ограничено; Посмотрите Free Local Storageметрику в CloudWatch, чтобы увидеть, сколько памяти у ваших экземпляров. Большие (более дорогие) экземпляры имеют больше локального хранилища.

    Ссылка: пока нет; текущая документация Amazon Aurora не упоминает об этом. Я попросил группу поддержки AWS обновить документацию и обновлю свой ответ, если / когда они это сделают.


1
Это отличный ответ, и да , вот некоторые основные предостережения. Рад, что увидел это.
ceejayoz

То же самое. Заметил, что один сервер БД занимал до 300 ГБ для базы данных размером 54 ГБ, о которой сообщалось в MySQL ... если пространство никогда не используется, это хороший пример того, что происходит, когда у вас много часто записываемых таблиц ( например, таблицы журналов, таблицы индексов и т. д.).
geerlingguy

0

Когда данные Aurora удаляются, например, путем удаления таблицы или раздела, общее выделенное пространство остается неизменным. Свободное пространство используется повторно автоматически при увеличении объема данных в будущем. https://docs.amazonaws.cn/en_us/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.