MySQL Table не восстанавливает
Информация о таблице:
Database name: user_motiva
Table name: wp_options.frm wp_options.MYD wp_options.MYI wp_options.TMD
когда я выполняю mysqlcheck -r --all-database, он зависает на этой таблице, даже если вы позволяете ей сидеть весь день. Даже просто чек повесили в том же месте.
Есть ли другой способ исправить / восстановить / восстановить эту таблицу?
Должен ли я использовать 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 на главном сервере и запустить команду для исправления всех файлов?
3 ответа
mysqlcheck выполняет ряд действий: проверять, восстанавливать, анализировать и оптимизировать. В настоящее время вы переходите к "ремонту" (-r), но на самом деле следует начать с "проверки", просто чтобы посмотреть, что происходит, и посмотреть, есть ли ответ:
mysqlcheck --check --quick user_motiva wp_options
Добавьте "-p", если требуется пароль (например, не в файле конфигурации).
Если это пройдет, попробуйте без "--quick". После того, как вы определили проблему (если есть), вам будет легче продолжить.
Кстати, "myisamchk" - это еще один способ проверки таблиц. Основное отличие состоит в том, что он используется, когда база данных не работает. Какой из них использовать, зависит от того, нужно ли вам продолжать работать ради других данных.
Значит ли это, что это сейчас исправлено?
Нет. Ваш вставленный вывод ясно заявляет
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: "[не использовать] эту опцию, если вы не в отчаянии".
Я столкнулся с точно такой же проблемой при запуске базы данных mysqlrepair.
Проблема 1 была: неправильный groupid в /etc/passwd файл для пользователя mysql, Пока это отличалось от groupid группы mysql в файле /etc/groupПожалуйста, проверьте и исправьте, если необходимо, прежде чем переходить к следующему шагу.
Проблема 2 заключалась в том, что во время прогона восстановления файлы *.TMD создаются для каждой таблицы базы данных в /var/lib/mysql/database каталог. Это исправлено запуском:
rm /var/lib/mysql/*/*.TMD
и затем успешно запустить:
mysqlrepair -p database
где -p для предоставленного пароля. Пожалуйста, также добавьте -uusername, если необходимо.