Некоторое время назад на сервере, на котором был запущен мой экземпляр, было 20 ГБ хранилища EBS. Затем он начал получать ошибки дискового хранилища, поэтому я увеличил его до 40 ГБ. Опять же, ошибки отсутствия хранилища, поэтому я снова увеличил до 60 ГБ. (Итак, это экземпляр RDS объемом 60 ГБ)
Вы можете увидеть здесь Свободное место для хранения (МБ) диаграмма. Каждый раз, когда он запускается, я добавляю больше места для хранения ..
Если я выполню этот запрос ..
SELECT CONCAT(table_schema, '.', table_name),
CONCAT(ROUND(table_rows / 1000000, 2), 'M') rows,
CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), 'G') DATA,
CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), 'G') idx,
CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), 'G') total_size,
ROUND(index_length / data_length, 2) idxfrac
FROM information_schema.TABLES
ORDER BY data_length + index_length DESC
LIMIT 10;
Получаю такой ответ ...
Ничто так не выделяется, как занимающее огромное количество места.
Если я тогда бегу
select table_schema, CONCAT(ROUND( sum((data_length+index_length)/1024/1024)/1024, 2), 'G') AS MB from information_schema.tables group by 1;
Я вижу, что в самой большой таблице около 10 ГБ. (Это включает data_length и index_length)
Моя следующая мысль: медленная нехватка памяти - это general_log или медленная запись журналов запросов на диск ...
Если я проверю группы параметров в моем экземпляре RDS, я вижу, что ведение журнала отключено.
Кто-нибудь знает, почему мой сервер RDS медленно утекает в хранилище?
ОБНОВИТЬ:
Мне помогли добрые люди на #mysql
После запуска
show global variables like 'log_bin';
Было ясно, что бинарные логи включены.
Я тогда побежал
show binary logs
и было 41674+ логов.
Прокручивая мои журналы, я увидел, что один из файлов размером 2064636
Затем я попытался удалить все двоичные журналы до этого файла журнала изменений.
purge binary logs to "mysql-bin-changelog.152193"
Однако RDS не предоставляет File_priv
или Super_priv
главному пользователю.
Я хотел бы думать, что это место на диске ... однако 2064636 - это всего лишь около 2 МБ ... Итак, вернемся к чертежной доске?
Вы можете проверить период хранения двоичного журнала с помощью следующей команды в MySQL:
mysql> call mysql.rds_show_configuration;
Чтобы установить срок хранения 1 день, используйте команду:
mysql> call mysql.rds_set_configuration('binlog retention hours', 24);
Это означает, что служба MySQL будет очищать двоичный журнал каждый день.
Кроме двоичного журнала, я думаю, вы можете проверить настройку innodb_file_per_table, все данные будут сохранены в файле ibdata, если ему присвоено "0".
Я предлагаю вам присвоить этой опции значение «1», чтобы ваша таблица хранилась отдельно, и вы могли вернуть использованное пространство следующим образом:
mysql> OPTIMIZE TABLE <table_name>
Проверьте ссылки ниже, чтобы узнать, отражают ли они вашу проблему:
Как освободить место в InnoDB, когда innodb_file_per_table включен
Почему файл ibdata1 в MySQL постоянно растет?
Еще одна вещь, согласно веб-сайту, у вас будет быстрорастущий файл ibdata1, потому что у вас есть длительная транзакция. Постарайтесь зафиксировать их как можно скорее, чтобы не выполнять восстановление системы для освобождения места.
Я думаю, что потерянное свободное пространство находится в файлах табличных пространств механизма хранения InnoDB. После разговора со службой поддержки AWS они предложили мне воссоздать их, настроив новый экземпляр, выгрузив все данные и импортировав в этот новый экземпляр, а затем переключившись. Создание реплики для чтения в этом случае не работает, поскольку реплики для чтения при создании используют то же хранилище, что и главный экземпляр.
В этом процессе мне пришлось настраивать репликацию вручную. Я следил за руководством здесь (http://www.ruempler.eu/2014/06/15/external-non-mysql-slaves-with-rds-reloaded/) и создал сценарий для автоматизации этого процесса. Вы можете найти его: