Информация о таблице:
Database name: user_motiva
Table name: wp_options.frm wp_options.MYD wp_options.MYI wp_options.TMD
когда я выполняю mysqlcheck -r --all-databases, он зависает на этой таблице, даже если вы позволяете ему сидеть весь день. Даже просто чек висит на одном месте.
Есть ли другой способ исправить / восстановить / восстановить эту таблицу?
Стоит ли использовать myisamchk? Я видел что-то вроде:
shell> myisamchk --recover City
Вы даже не можете получить доступ / просмотреть базу данных из phpMyAdmin или даже "USE;" в mysql без этого просто зависает.
Моя конфигурация на 16 ГБ оперативной памяти
cat /etc/my.cnf
[mysqld]
default-storage-engine=MyISAM
local-infile=0
symbolic-links=0
skip-networking
max_connections = 500
max_user_connections = 20
key_buffer = 512M
myisam_sort_buffer_size = 64M
join_buffer_size = 64M
read_buffer_size = 12M
sort_buffer_size = 12M
read_rnd_buffer_size = 12M
table_cache = 2048
thread_cache_size = 16K
wait_timeout = 30
connect_timeout = 15
tmp_table_size = 64M
max_heap_table_size = 64M
max_allowed_packet = 64M
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 64M
query_cache_type = 1
low_priority_updates=1
concurrent_insert=ALWAYS
log-error=/var/log/mysql/error.log
tmpdir=/home/mysqltmp
myisam_repair_threads=4
[mysqld_safe]
open_files_limit = 8192
log-error=/var/log/mysql/error.log
[mysqldump]
quick
max_allowed_packet = 512M
[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M
Это из-за того, что таблица сработала в результате выполнения killall -9 mysqld, потому что она не завершилась и не перезапустилась?
root@server [/var/lib/mysql/user_motiva]# myisamchk -e *.MYI
Checking MyISAM file: wp_options.MYI
Data records: 1827 Deleted blocks: 3
myisamchk: warning: 3 clients are using or haven't closed the table properly
- check file-size
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
- check data record references index: 2
- check records and index references
MyISAM-table 'wp_options.MYI' is usable but should be fixed
root@server [/var/lib/mysql/user_motiva]# myisamchk --safe-recover wp_options.MYI
- recovering (with keycache) MyISAM-table 'wp_options.MYI'
Data records: 1827
myisamchk: error: Can't create new tempfile: 'wp_options.TMD'
MyISAM-table 'wp_options.MYI' is not fixed because of errors
Try fixing it by using the --safe-recover (-o), the --force (-f) option or by not using the --quick (-q) flag
root@ns2 [/var/lib/mysql/user_motiva]# myisamchk -o -f wp_options.MYI
- recovering (with keycache) MyISAM-table 'wp_options.MYI'
Data records: 1827
Значит ли это, что теперь это исправлено? Если да, то как мне вернуть его обратно? (это было сделано на другом сервере) Есть ли способ, возможно, отключить MySQL на главном сервере и запустить команду для исправления всех файлов?
mysqlcheck выполняет ряд действий: проверка, восстановление, анализ и оптимизация. В настоящее время вы переходите к «ремонту» (-r), но на самом деле лучше начать с «проверить», чтобы увидеть, что происходит, и увидеть, есть ли какой-либо ответ:
mysqlcheck --check --quick user_motiva wp_options
Добавьте «-p», если требуется пароль (например, не в файле конфигурации).
Если это пройдет, попробуйте без "--quick". После того, как вы определили проблему (если таковая имеется), действовать будет проще.
Кстати, myisamchk - это еще один способ проверки таблиц. Главное отличие здесь в том, что он используется, когда база данных не запущена. Что использовать, зависит от того, нужно ли вам продолжать работу ради других данных.
У меня возникла точно такая же проблема при запуске базы данных mysqlrepair.
Проблема 1 была: неправильный groupid в /etc/passwd файл для пользователя mysql. Хотя это отличалось от groupid of group mysql в файле /etc/group Пожалуйста, проверьте и при необходимости исправьте перед переходя к следующему шагу.
Проблема 2 заключалась в следующем: во время восстановления файлы * .TMD обычно создаются для каждой таблицы базы данных в /var/lib/mysql/database каталог. Это исправляется запуском:
rm /var/lib/mysql/*/*.TMD
а затем успешно запустить:
mysqlrepair -p database
где -p для предоставленного пароля. При необходимости также добавьте -uusername.
Значит ли это, что теперь это исправлено?
Нет. В вашем вставленном выводе четко указано
MyISAM-table 'wp_options.MYI' is not fixed because of errors
И причина тому, кажется,
myisamchk: error: Can't create new tempfile: 'wp_options.TMD'
Вы можете проверить, есть ли у пользователя, с которым вы запускаете myisamchk, необходимые разрешения для создания файлов в каталоге данных, если файл еще не присутствует с "неправильными" разрешениями и могут ли файлы вообще создаваться в файловой системе (т. Е. не смонтирован только для чтения, содержит ошибки или заполнен).
Обратите внимание, что вы восстанавливаете файлы .MYI, которые содержат только индекс информация (хранящиеся копии индексированных столбцов базы данных, отсортированные в заданном порядке для ускорения поиска). Поэтому, если проблема связана с индексным файлом (.MYI) при восстановлении / монтировании базы данных, рассмотрите возможность простого удаления его из каталога данных, запуска демона MySQL и запуска REPAIR TABLE wp_options для восстановления информации индекса из данных в файле данных.
Если поврежден сам файл данных (.MYD), следует запустить myisamchk в файле .MYD без используя -e вариант сначала как myisamchk docs прямо указать «[не] использовать этот вариант, если вы не в отчаянии».