У меня проблема с хранилищем. Я получил эту ошибку
Got error 28 from storage engine
Я проверил емкость хранилища, и он все еще был доступен, и он не был заполнен. что может быть причиной этого? Я проверил все без успеха
Возможно, что у меня заканчивается основной каталог данных mysql или в mysql tmp. Может ли кто-нибудь сказать мне, как найти свое место, чтобы проверить его тоже?
Возможно, что у меня заканчивается основной каталог данных mysql или в mysql tmp. Может ли кто-нибудь сказать мне, как найти свое место, чтобы проверить его тоже?
Выполните следующие команды для проверки местоположения ваших данных сервера и временных каталогов:
SHOW GLOBAL VARIABLES LIKE 'datadir'
SHOW GLOBAL VARIABLES LIKE 'tmpdir'
Значения этих переменных обычно являются абсолютными путями (относительно любой chroot
тюрьмы, в которой работает сервер), но если они являются относительными путями, они будут относиться к рабочему каталогу процесса, который запустил сервер.
Как описано в разделе "Каталог данных MySQL" (выделено мной):
В следующем списке кратко описаны элементы, которые обычно находятся в каталоге данных...
Некоторые элементы в предыдущем списке могут быть перемещены в другом месте путем перенастройки сервера. Кроме того, опция
--datadir
позволяет--datadir
местоположение самого каталога данных. Для данной установки MySQL проверьте конфигурацию сервера, чтобы определить, были ли перемещены элементы.
Поэтому вы можете также проверить значения ряда других переменных, в том числе:
pid_file
ssl_%
%_log_file
innodb_data_home_dir
innodb_log_group_home_dir
innodb_temp_data_file_path
innodb_undo_directory
innodb_buffer_pool_filename
Вы также можете проверить конфигурацию запуска сервера.
Как указано в разделе " Параметры программы", конфигурация запуска сервера определяется "путем изучения переменных среды, затем путем обработки файлов параметров, а затем путем проверки командной строки", причем более поздние параметры имеют приоритет над более ранними параметрами.
В документации также перечислены местоположения файлов опций, прочитанных в Unix и Unix-подобных системах, если вы этого потребуете. Обратите внимание, что разделы тех файлов, которые читает сервер, определяются способом запуска сервера, как описано во втором и третьем параграфах параметров командной строки сервера.
Когда вы найдете места, где хранит файлы MySQL, запустите команду в оболочке:
df -Ph <pathname>
Где <pathname>
- это каждое из мест, которые вы хотите проверить. Некоторые из них могут быть на том же диске, поэтому они будут отображаться одинаково, когда сообщается df
.
[vagrant@localhost ~]$ mysql -e 'select @@datadir'
+-----------------+
| @@datadir |
+-----------------+
| /var/lib/mysql/ |
+-----------------+
[vagrant@localhost ~]$ df -Ph /var/lib/mysql
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00 38G 3.7G 34G 10% /
Это говорит мне, что объем диска для моего datadir - это корневой том, включая каталог верхнего уровня " /
" и все, что ниже этого. Объем 10% заполнен, а 34G не используется.
Если объем, в котором ваш datadir достигает 100%, тогда вы начнете просматривать ошибки errno 28 при вставке новых данных и необходимо расширить табличное пространство MySQL или записать в файл журнала.
В этом случае вам нужно выяснить, что занимает столько места. Это может быть что-то в каталоге MySQL, или, как в моем случае, ваш datadir может быть частью большего объема диска, где существуют все ваши другие файлы. В этом случае любое накопление файлов в системе может привести к тому, что диск будет заполнен. Например, файлы журналов или временные файлы, даже если они не связаны с MySQL.
Я хотел бы начать в верхней части объема диска и использовать du
, чтобы выяснить, какие каталоги настолько полны.
[vagrant@localhost ~]$ sudo du -shx /*
33M /boot
34M /etc
40K /home
28M /opt
4.0K /tmp
2.0G /usr
941M /vagrant
666M /var
Примечание. Если ваша команда df
сообщила вам, что ваш datadir находится на отдельном томе диска, вы должны начать с этой точки монтирования тома. Пространство, используемое одним дисковым томом, не учитывается для другого тома диска.
Теперь я вижу, что /usr
занимает больше всего места, из каталогов верхнего уровня. Разверните и посмотрите, что занимает место под этим:
[vagrant@localhost ~]$ sudo du -shx /usr/*
166M /usr/bin
126M /usr/include
345M /usr/lib
268M /usr/lib64
55M /usr/libexec
546M /usr/local
106M /usr/sbin
335M /usr/share
56M /usr/src
Продолжайте сверление вниз по уровню.
Обычно виновник оказывается довольно ясным. Например, если у вас есть огромный файл журнала /var/log
500G, который растет месяцами.
Примером типичного виновника является журнал HTTP-сервера.
Ваши комментарии:
Похоже, у вас есть отдельный том для хранения базы данных. Это хорошо.
Вы только что добавили выходной файл du
на свой вопрос выше. Я вижу, что в вашем томе диска 1.4T наибольший одиночный файл - это:
1020G /vol/db1/mysql/_fool_Gerg_sql_200e_4979_main_16419_2_18.tokudb$
Кажется, это табличное пространство TokuDB. Здесь представлена информация о том, как TokuDB обрабатывает полные диски здесь: https://www.percona.com/doc/percona-server/LATEST/tokudb/tokudb_faq.html#full-disks
Я бы не удалял эти файлы. Я не так хорошо знаком с TokuDB, поскольку я с InnoDB, но я предполагаю, что эти файлы являются важными файлами данных. Если вы удалите их, вы потеряете часть своих данных, и вы можете повредить остальную часть ваших данных.
Я нашел этот пост, в котором подробно объясняется, какие файлы используются для: https://www.percona.com/blog/2014/07/30/examining-the-tokudb-mysql-storage-engine-file-structure/
В руководстве также говорится:
Удаление большого количества строк из существующей таблицы, а затем закрытие таблицы может освободить некоторое пространство, но это может и не так. Удаление строк может просто оставить неиспользуемое пространство (доступное для новых вставок) внутри файлов данных TokuDB, а не сокращать файлы (внутренняя фрагментация).
Таким образом, вы можете удалять строки из таблицы, но физический файл на диске не может сокращаться. В конце концов, вы можете освободить достаточно места, чтобы создать новый файл данных TokuDB с помощью ALTER TABLE <tablename> ENGINE=TokuDB ROW_FORMAT=TOKUDB_SMALL;
(см. https://dba.stackexchange.com/questions/48190/tokudb-optimize-table-does-not-reclaim-disk-space)
Но для создания новой таблицы потребуется достаточно свободного места на диске.
Так что, боюсь, вы нарисовали себя в углу. У вас больше нет свободного места на диске, чтобы перестроить вашу большую таблицу. Вы не должны допускать, чтобы свободное место на диске было меньше места, необходимого для перестройки вашей самой большой таблицы.
На данный момент вам, вероятно, придется использовать mysqldump
для вывода данных из вашей самой большой таблицы. Не обязательно всю таблицу, а только то, что вы хотите сохранить (читайте о опции mysqldump --where
). Затем DROP TABLE
удалите эту большую таблицу. Я предполагаю, что освободит место на диске, где использование DELETE не будет.
У вас недостаточно места на вашем томе db1, чтобы сохранить файл дампа, поэтому вам придется сохранить его на другой том. Похоже, у вас есть больший объем на /vol/cbgb1, но я не знаю, полно ли это.
Я бы сбросил все это, для целей архивирования. Затем сбросьте снова подмножество.
mkdir /vol/cbgdb1/backup
mysqldump fool Gerg | gzip -c > /vol/cbgdb1/backup/Gerg-dump-full.sql.gz
mysqldump fool Gerg --where "id > 8675309" | gzip -c > /vol/cbgb1/backup/Gerg-dump-partial.sql.gz
Я полностью догадываюсь о аргументах --where
. Вам нужно будет решить, как вы хотите выбрать частичный дамп.
После того как большая таблица будет удалена, перезагрузите частичные данные, которые вы сбросили:
gunzip -c /vol/cbgb1/backup/Gerg-dump-partial.sql.gz | mysql fool
Если в моих примерах есть какие-то команды, которые вы еще не знаете хорошо, я предлагаю вам изучить их, прежде чем пытаться их использовать. Или найдите кого-нибудь, кто поделится с тем, кто более знаком с этими командами.
df -Ph
и я вижу это /dev/mapper/vg_db1-lv_db1
с размером 1.4T и использовал 1.3T, который использовал 95%
363M /lib
и 4.8M / tmp 3.3G / usr 2.0G / var 16K / vol довольно большие, остальные в порядке
log_bin
. Скорее всего, двоичные файлы журналов будут расти по мере фиксации INSERT. Скорее, чем другие файлы, такие как pid-файл или журнал повторов InnoDB.