ずいぶん前にWordPressのアクセスカウンタ（解析）をCounterize IIからCount Per Dayに変更し、便利に使っていたのですが、ふとおかしなことに気がつきました。
それがこれ。
Count Per Dayの「検索文字列」というボックスなのですが、この内容がまったく更新されないのです。
8月に入って以降もずっとこの状態（7月24日の情報）で止まったままなんです。
別に検索文字列を調べてアクセスアップのためになにがしかの対策を講じたりするわけではないのですが、他のボックス（例えばアクセスカウンタとか、ページビューとか）はきちんと各日付ごとに更新されていく中、検索文字列だけが更新されないのは何となく気持ちが悪いもの。
そこでこれの修正を試みることに。
Count Per Day自体はmysqlデータベースを利用しているようなので、真っ先に疑ったのはこのデータベースのうちの検索文字列に関するテーブルの破損です。
もちろん、検索文字列に関するテーブルというのがあるのかどうかはわからないのですが、データベースに起因する不具合であるならば、それを修復すれば正常に動作するようになるはずです。
そこで早速SSHでサーバにログインし、mysqlコマンドを使ってデータベースの確認を行いました。
# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 6476
Server version: 5.1.73 Source distribution
Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.
mysql> show databases;
+——————–+
| Database |
+——————–+
| information_schema |
| thisblog |
| mysql |
| test |
+——————–+
4 rows in set (0.01 sec)
mysql> use thisblog;
Reading table information for completion of table and column
names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+————————–+
| Tables_in_thisblog |
+————————–+
| wp_Counterize |
| wp_Counterize_Countries |
| wp_Counterize_Keywords |
| wp_Counterize_Pages |
| wp_Counterize_Referers |
| wp_Counterize_UserAgents |
| wp_blog_versions |
| wp_blogs |
| wp_commentmeta |
| wp_comments |
| wp_cpd_counter |
| wp_links |
| wp_options |
| wp_postmeta |
| wp_posts |
| wp_registration_log |
| wp_signups |
| wp_site |
| wp_sitemeta |
| wp_term_relationships |
| wp_term_taxonomy |
| wp_termmeta |
| wp_terms |
| wp_usermeta |
| wp_users |
+————————–+
25 rows in set (0.00 sec)
mysql>
この中から、とりあえず検索文字列に該当しそうなテーブルを選んでチェックしてみることに。
文字列なんだから、termとか入っている奴がそうなのかな？それとも付加的な機能なんだから、optionかしら？
ここではwp_optionsをテストテーブルとして選定し、チェック及び（必要なら）修復を行うことにしてみました。
mysqlにログインした状態でのテーブルチェックは以下のように行います。
mysql> check table wp_options;
+———————-+——-+———-+————————————–——————-+
| Table | Op | Msg_type | Msg_text |
+———————-+——-+———-+————————————–——————-+
| thisblog.wp_options | check | warning | 8 clients are using or
haven’t closed the table properly |
| thisblog.wp_options | check | error | Wrong record length 212
of 319 at 107472 |
| thisblog.wp_options | check | error | Corrupt
|
+———————-+——-+———-+————————————–——————-+
3 rows in set (0.01 sec)
Corruptってことは、つまり壊れてるってことですし、errorってことはエラーがあるってことですよね。
というわけで、このwp_optionsテーブルを修復します。
mysql> repair table wp_options;
+———————-+——–+———-+——————————————————–+
| Table | Op | Msg_type | Msg_text |
+———————-+——–+———-+—————————–
————————–+
| thisblog.wp_options | repair | info | Wrong block with
wrong total length starting at 107472 |
| thisblog.wp_options | repair | info | Found block that
points outside data file at 107544 |
| thisblog.wp_options | repair | info | Wrong bytesec: 167
129-227 at 1322468; Skipped |
| thisblog.wp_options | repair | info | Found block that
points outside data file at 1339692 |
| thisblog.wp_options | repair | warning | Number of rows
changed from 316 to 315 |
| thisblog.wp_options | repair | status | OK
|
+———————-+——–+———-+—————————–
————————–+
6 rows in set (0.08 sec)
これでエラーが修復されたはず（rapairのstatusがOKになってますからね）。それでは再度確認してみましょう。
mysql> check table wp_options;
+———————-+——-+———-+———-+
| Table | Op | Msg_type | Msg_text |
+———————-+——-+———-+———-+
| thisblog.wp_options | check | status | OK |
+———————-+——-+———-+———-+
1 row in set (0.01 sec)
checkのstatusがOKになりました！
あとはこの手順を、他の破損テーブルに対して行えばいいのですが・・・。
関連しそうなテーブルをひとつずつ目視で確認して潰していくのもいいのですが、mysqlにログインせず、コマンドを使ってmysqlデータベースのチェック、修復を行うこともできるようで、しかもなんとその方法だと、該当するデータベースのテーブルを一括でチェックし、その結果を見ることができるそうなんです！
こんな便利なコマンドがあるなら是非使ってみたいですし、早速そちらを試してみることに。
そのために、mysqlからexitコマンドで一度mysqlから抜け出て、コマンドラインに戻ります。
# mysqlcheck -c thisblog -u root -p
Enter password:
thisblog.wp_Counterize OK
thisblog.wp_Counterize_Countries OK
thisblog.wp_Counterize_Keywords OK
thisblog.wp_Counterize_Pages OK
thisblog.wp_Counterize_Referers OK
thisblog.wp_Counterize_UserAgents OK
thisblog.wp_blog_versions OK
thisblog.wp_blogs OK
thisblog.wp_commentmeta
warning : 5 clients are using or haven’t closed the table
properly
status : OK
thisblog.wp_comments
warning : 5 clients are using or haven’t closed the table
properly
status : OK
thisblog.wp_cpd_counter OK
thisblog.wp_links OK
thisblog.wp_options OK
thisblog.wp_postmeta
warning : 5 clients are using or haven’t closed the table
properly
status : OK
thisblog.wp_posts
warning : 4 clients are using or haven’t closed the table
properly
status : OK
thisblog.wp_registration_log OK
thisblog.wp_signups OK
thisblog.wp_site OK
thisblog.wp_sitemeta OK
thisblog.wp_term_relationships OK
thisblog.wp_term_taxonomy OK
thisblog.wp_termmeta OK
thisblog.wp_terms OK
thisblog.wp_usermeta
warning : 5 clients are using or haven’t closed the table
properly
status : OK
thisblog.wp_users OK
いくつかwarningが返されてますね。
しかしこのmysqlcheckコマンドだと、全てのテーブルに対して一括して修復を行えるのです。
# mysqlcheck -r thisblog -u root -p
Enter password:
thisblog.wp_Counterize OK
thisblog.wp_Counterize_Countries OK
thisblog.wp_Counterize_Keywords OK
thisblog.wp_Counterize_Pages OK
thisblog.wp_Counterize_Referers OK
thisblog.wp_Counterize_UserAgents OK
thisblog.wp_blog_versions OK
thisblog.wp_blogs OK
thisblog.wp_commentmeta OK
thisblog.wp_comments OK
thisblog.wp_cpd_counter OK
thisblog.wp_links OK
thisblog.wp_options OK
thisblog.wp_postmeta OK
thisblog.wp_posts OK
thisblog.wp_registration_log OK
thisblog.wp_signups OK
thisblog.wp_site OK
thisblog.wp_sitemeta OK
thisblog.wp_term_relationships OK
thisblog.wp_term_taxonomy OK
thisblog.wp_termmeta OK
thisblog.wp_terms OK
thisblog.wp_usermeta OK
thisblog.wp_users OK
これでデータベース（内の全テーブル）の修復が完了しました。おそらく問題は解決したはずですし、そのように考えて早速WordPressのダッシュボードからCount Per Dayにアクセスしてみたところ・・・。
この状態のままでした・・・orz
どうやらデータベースの破損が原因ではなかったようです。
実際のところ、検索文字列で表示されている文字列が含まれるようなデータベース（テーブル）は見てないんですよね〜。
すると原因はどこか他に・・・？
どうしてもダメだったら、最悪このボックスをダッシュボード内で表示しない設定にしてお茶を濁してしまおうかとも考えたのですが、それは根本的な解決になっていませんし、自分でそれを隠すわけですからダッシュボードを見るたびに悶々とすることになりそう。
そんな時、Count Per Dayの「ツール」タブを見ていたら・・・。
こういうボックスを発見しました。
もしかしてこの「検索文字列を削除する」ボタンをクリックすれば、何かの原因で更新されなくなった検索文字列が一度リセットされ、新たに記録され始めるのでは？
どのみち現状では役に立っていない「検索文字列」ボックスですから、そのデータがなくなったところで痛くもかゆくもありません。
なら、ダメ元でこれを削除してみることに。
ポチッとなっ！！
押下すると、検索文字列ボックスは（当たり前ですが）全くの空白になります。これで今日以後新たに検索文字列が書き込まれていけば問題解決なのですが、この状態で数日放置し、状況を見守ることに。
結論から言うと。
日付ごとに新たにきちんと更新されて検索文字列が記録されるようになりました！（笑）
何てことはない、データベースをいじらなくてもこのボタンをクリックするだけで問題は解決した（のかもしれない）ということですね（笑）
というわけで、無事に検索文字列も更新されることになり、Count Per Dayは元の動作を取り戻したのでした。
めでたしめでたし（笑）
