у меня есть Amazon (AWS) Аврора Кластер БД, и каждый день его [Billed] Volume Bytes Used
растет.
Я проверил размер всех своих таблиц (во всех моих базах данных в этом кластере), используя 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 (премиум) несколько раз и так и не смог получить подробного объяснения того, почему это так.
Я получил предложения по запуску OPTIMIZE TABLE
на столах, на которых много free_space
(согласно INFORMATION_SCHEMA.TABLES
table), или чтобы проверить длину истории InnoDB, чтобы убедиться, что удаленные данные все еще не хранятся в сегменте отката (ссылка: MVCC) и перезапустите экземпляр (ы), чтобы убедиться, что сегмент отката опустошен.
Ничего из этого не помогло.
Здесь задействовано несколько вещей ...
Каждая таблица хранится в собственном табличном пространстве
По умолчанию группа параметров для кластеров Aurora (с именем default.aurora5.6
) определяет innodb_file_per_table = ON
. Это означает, что каждая таблица хранится в отдельном файле в кластере хранения Aurora. Вы можете увидеть, какое табличное пространство используется для каждой из ваших таблиц, используя этот запрос:
SELECT name, space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES;
Примечание: я не пробовал менять innodb_file_per_table
к OFF
. Может, это поможет ..?
Пространство для хранения, освобожденное при удалении табличных пространств, НЕ используется повторно
Цитата из премиальной поддержки AWS:
Из-за уникального дизайна движка 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, который нельзя использовать в таком масштабе.
ОПТИМИЗАЦИЯ ТАБЛИЦЫ - зло!
Поскольку 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
Использование временных таблиц
По умолчанию группа параметров для экземпляров Aurora (с именем default.aurora5.6
) определяет default_tmp_storage_engine = InnoDB
. Это означает, что каждый раз, когда я создаю TEMPORARY
таблица, она хранится вместе со всеми моими регулярный таблицы в кластере хранения Aurora. Это означает, что для этих таблиц выделяется новое пространство, что увеличивает общий объем VolumeBytesUsed.
Решение для этого достаточно простое: измените default_tmp_storage_engine
значение параметра для MyISAM
. Это заставит Аврору создать TEMPORARY
таблицы в локальном хранилище экземпляра.
Обратите внимание: локальное хранилище экземпляров ограничено; увидеть Free Local Storage
метрика CloudWatch, чтобы узнать, сколько хранилища есть у ваших экземпляров. Более крупные (более дорогие) экземпляры имеют больше локального хранилища.
Ссылка: пока нет; в текущей документации Amazon Aurora об этом не упоминается. Я попросил службу поддержки AWS обновить документацию и обновлю свой ответ, если / когда они это сделают.
Когда данные Aurora удаляются, например, при удалении таблицы или раздела, общее выделенное пространство остается прежним. Свободное пространство повторно используется автоматически при увеличении объема данных в будущем. https://docs.amazonaws.cn/en_us/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html