おはようございます。からあげです。
今日はサーバーの移転作業に備えて早めに起きた。
昨日は凄いたくさんの雨が降って、普段水量がほとんど変わらない湧き水に端を発する側溝の水がいつもの倍くらいになっていた。
ロリポップ！からxサーバーに移転作業を始めて3日目になるだろうか。
パソコンに齧りついて作業を続けている。
一難去ってまた一難で、次から次へと問題が発生しているが、確実に前進を続けている。
今後もブログを発展させてゆくためにはサーバーの移転は避けては通れない。
ロリポップは、アクセスが集中する夜の8時から11時過ぎころまでパフォーマンスが極端に落ちる。
早朝・昼間は良いのだが、夜間になると重たくなって、ブログ更新の作業が全然捗らなくなる。
安くていいのだが、不満が積み重なってとうとう耐えられなくなった。
狭い水槽や小さな植木鉢で育てていると、魚や木は大きく成長出来ない。
このブログもロリポップの狭い枠の中では大きくなれない。
おっさんだってそうだ。窮屈なしがらみの中で生きていると人間的に成長できない。
誰にも干渉されない伸び伸びと生活出来る場所で生きてゆきたい。
日本では狭すぎる。
データベースの不要なデータの削除
ところで今日はデータベースの整理について。
今回のサーバー移転であれこれ作業をしていてデーターベースが肥大化しているのに気が付いた。
これはブログのデーターベース。
記事数は1100超
全20テーブル、行数2,823,241、サイズ692.5MiB、オーバーヘッド0バイト
以上のようになっていた。
たまにデーターベースアクセスしてチェックしていたのだが、データの容量については何も気に留めていなかった。
昨日、ロリポップからエクスポートしたデーターベースのデータをxサーバーにインポートしようとしたら、サイズが大きすぎて処理出来ないというようなエラーが出たので、テーブル1つずつやってみても同様のエラーが出た。
そこでxサーバーの電話サポートに電話して聞いてみると、オーバーヘッドが発生しているなんやらかんやらと言われた。
オーバーヘッドキックなら知っているが。（出来ないけど）
コンピューター用語は難しいから、頭が混乱してしまった。
要は不要なデータが溜まってサイズが大きくなっているらしいということだ。
xサーバーのデータベース1個の容量は約500MBとなっている。（ロリポップはもう興味なし）
一番下位のプランのx10でもディスク容量が200GBもあるので大丈夫と思っていた。
データベースはこんなにもサイズが小さいなんて思いもしなかった。
よい勉強になったな！
MySQLで使用できる容量を教えてください。
MySQLデータベース1つにつき、ご利用可能な容量の目安は下記となります。
※使用容量が目安を大きく上回る、データベースの負荷が大きい場合は、リソース制限の対象となる場合があります。
MySQL4 50MB
MySQL5.0・MySQL5.5 500MB
知らぬ間にデータベースが肥大化していたため、データベースの手動バックアップが上手くいかなかったのだ。
途中でダウンロードが止まってしまうのも頷ける。
上の約一月半前の記事でデータベースの使用量がHP分も合わせて221MBだったものが、3倍にも膨れ上がってしまっていた。
それではこれから不要データのテーブルを紹介しよう！
cdp_counter 行数2,595 サイズ607.2MiB
「cdp_counter」というこのテーブルがやけにサイズが大きい。
検索して調べてみると、プラグイン「count per day」が作った残骸であることが分かった。
少し前にこのプラグインを削除していたが、どこかにプログラムが残っていてせっせとログを記録していたらしい。
この他にも気になるものがあった。
ewwwio_images 行数2 サイズ16MiB
プラグイン「EWW Image Optimizer」が作ったテーブルと思われる。
今はプラグインは使用していないので、サイズはほんの僅かだが削除した。
siteguard_history 行数5,945 サイズ368.0KiB
プラグイン「siteguard」が使用しているテーブル。
セキュリティー強化のために導入している。
WordPressの管理画面に不正アクセスしようするログイン履歴を記録していて、このテーブルに書き込まれる。
履歴削除のボタンがないので、Phpmyadminからテーブルの中身を空にした。
ユーザー名adminで執拗に攻撃してくるので脅威を感じる。
もちろん別の名前にしてあるが、安心は出来ない。
この機会にユーザー名とパスワードを変更し、セキュリティーのさらなる強化を行った。
popular postssummary 行数160,266 サイズ31.6MiB
人気記事をリストアップしてれるプラグイン「WordPress Popular Posts」が使用しているテーブル。
サイズが大きいのが気になるが、現在使っているのでそのままにして今後様子を見守ることにした。
postmeta 行数32,499 サイズ9.5MiB posts 行数13,623 サイズ32.3MiB
投稿記事のデータ。
記事数1100超でこれくらいだから10000は行けそうだ。
少なくとも5年は持つだろう。
画像データは、Webサーバーの方に格納されている。
ここもイジらずに様子見だ。
データベースのサイズの単位が、KiBやMiBとなっている。
始めは目の錯覚かと思った。調べてみるとMBとMiBは微妙に違うらしい。
メビバイト (mebibyte) は、コンピュータの容量や記憶装置の大きさをあらわす情報の単位の一つ。MiBと略記される。
1 MiB = 220 B = 1,048,576 B
220 = 1,048,576バイトを表す。本来SI接頭辞の106を表すメガは、1,000,000であり、混乱を避けるため、IECが決めたのが二進接頭辞のメビである。メビバイト = 220バイトと定義し、220バイトという意味ではこの呼び名が推奨される。メガバイトと違い、1,024,000バイトや1,000,000バイトという意味では使えない。
データベースの整理として、他にはコメントのゴミ箱やスパムを空にしておいた。
これで随分とスッキリしたので、サイト管理もやりやすくなるだろう。
さあて今日は天気が回復して晴れるようだから、気合を入れて作業をしてさっさとサーバー移転を済ませてしまおうか。
東北の準備もあるので、いつまでもパソコン作業ばかりしているわけにはいかない。
よし、いい感じだぞ！
おわり
コメント
おはようございます。
プラグインはデータベースを結構肥大化させますね。
私もワードプレスは悪戦苦闘して今のところは安定稼働ですが、長期運用するとなるとMySQLがネックになりそうなんですよね。
エックスサーバのX10プランでもMySQLデータベース 50個までと数は余裕なんですが、ほとんどのサーバが１個当たりの容量制限があるんですよね。
まれに容量無制限のサーバもありますが、安定度やスピードに不安があり、将来的には悩ましい問題になりそうです。
ウィキペディアからの引用分ですが、乗数がちゃんと表示させていないので、意味がわからなくなっています。
「220」と「106」の部分です。
「2の20乗」「10の6乗」と書き換えても良いですが、ワードプレスのテキストエディタで「2<sup>20</sup>」「10<sup>6</sup>」と書き換えるとちゃんと表示されると思います。
ひとまず、サーバー移転の作業がおわりました。
あとはDNSの設定変更が反映されるのを待つのみです。
２つのサーバーに同じデータがあるのは不思議な感じがします。
乗数の件、どうもありがとうございます。
こんなタグがあるのですね。