ошибка с хранилищем 28 из хранилища с MySQL

0

У меня проблема с хранилищем. Я получил эту ошибку

 Got error 28 from storage engine 

Я проверил емкость хранилища, и он все еще был доступен, и он не был заполнен. что может быть причиной этого? Я проверил все без успеха

Возможно, что у меня заканчивается основной каталог данных mysql или в mysql tmp. Может ли кто-нибудь сказать мне, как найти свое место, чтобы проверить его тоже?

Теги:
database
centos

2 ответа

1

Возможно, что у меня заканчивается основной каталог данных mysql или в mysql tmp. Может ли кто-нибудь сказать мне, как найти свое место, чтобы проверить его тоже?

TL; DR

Выполните следующие команды для проверки местоположения ваших данных сервера и временных каталогов:

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-подобных системах, если вы этого потребуете. Обратите внимание, что разделы тех файлов, которые читает сервер, определяются способом запуска сервера, как описано во втором и третьем параграфах параметров командной строки сервера.

  • 1
    Также log_bin . Скорее всего, двоичные файлы журналов будут расти по мере фиксации INSERT. Скорее, чем другие файлы, такие как pid-файл или журнал повторов InnoDB.
  • 0
    @eggyal спасибо за ваш комментарий, подскажите, пожалуйста, как проверить эти файлы?
Показать ещё 3 комментария
0

Когда вы найдете места, где хранит файлы 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

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

  • 0
    Большое спасибо за ваше великолепное объяснение. Я мог легко понять первую часть. Я делаю df -Ph и я вижу это /dev/mapper/vg_db1-lv_db1 с размером 1.4T и использовал 1.3T, который использовал 95%
  • 0
    для второй части я вижу только 363M /lib и 4.8M / tmp 3.3G / usr 2.0G / var 16K / vol довольно большие, остальные в порядке
Показать ещё 8 комментариев

Ещё вопросы

Сообщество Overcoder
Наверх
Меню