テーブル情報:
Database name: user_motiva
Table name: wp_options.frm wp_options.MYD wp_options.MYI wp_options.TMD
mysqlcheck -r --all-databasesを実行すると、1日中放置しても、そのテーブルでハングします。小切手だけでも同じ場所にぶら下がっています。
そのテーブルを修正/修復/回復する別の方法はありますか?
Myisamchkを使用する必要がありますか?私は次のようなものを見ました:
Shell> myisamchk --recover City
PhpMyAdminや「USE;」からデータベースにアクセス/表示することもできません。ただぶら下がることなくmysqlで。
16GBのRAMボックスでの私の設定
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」はテーブルをチェックするもう一つの方法です。ここでの主な違いは、データベースが実行されていないときに使用されることです。どちらを使用するかは、他のデータのために実行を継続する必要があるかどうかによって異なります。
これは、現在修正されていることを意味しますか?
いいえ、違います。貼り付けた出力には、明確に記載されています
MyISAM-table 'wp_options.MYI' is not fixed because of errors
そしてその理由は
myisamchk: error: Can't create new tempfile: 'wp_options.TMD'
Myisamchkを実行しているユーザーが、データディレクトリにファイルを作成するために必要なアクセス許可を持っているかどうか、ファイルに「間違った」アクセス許可がまだ存在しないかどうか、ファイルシステム上にファイルを作成できるかどうかを確認できます(つまり、読み取り専用でマウントされていない、エラーがある、またはいっぱいです)。
index情報(検索を高速化するために特定の順序でソートされて格納されたインデックス付きデータベース列のコピー)のみを含む.MYIファイルを修復していることに注意してください。したがって、データベースの修復/マウント中に問題を引き起こしているのがインデックスファイル(.MYI)である場合は、データディレクトリからデータベースを削除し、MySQLデーモンを起動し、REPAIR TABLE wp_options
を実行してインデックス情報を再構築することを検討してください。データファイル内のデータ。
データファイル自体(.MYD)が破損の影響を受ける場合は、.MYDファイルを使用せずにでmyisamchk
を実行する必要があります。 -e
オプションを最初に myisamchk docs 明示的に述べます "[しない]必死でない限り、このオプションを使用しないでください。"
Mysqlrepairデータベースを実行しているときに、まったく同じ問題が発生しました。
問題1は、ユーザーmysql
の/etc/passwd
ファイルのグループIDが間違っていることでした。ファイル/etc/group
のグループmysql
のグループIDとは異なりますが、必要に応じて確認して修正してください前次の手順に進みます。
問題2は、修復の実行中に、通常は/var/lib/mysql/database
ディレクトリ内のデータベーステーブルごとにファイル* .TMDが作成されることでした。これは、以下を実行することで修正されます。
rm /var/lib/mysql/*/*.TMD
その後、正常に実行します。
mysqlrepair -p database
ここで、-pは指定されたパスワードを表します。必要に応じて-uusernameも追加してください。