Linuxのアーカイブ

管理しているサーバのMySQLが停止して監視システムからのメールが届き始めた。
思い当たることがなく慌ててサーバに接続して確認してみたが、メモリーが不足したり、アクセスが過大になったような形跡はなかった。MySQLを再起動してみても失敗と表示されるだけで起動できない。何度か試行錯誤しているうちに原因がyumの自動アップデートではないかと思い当たった。MySQLの起動時のメッセージか2点を修正すれば動作すると予測した。

エラーメッセージの原因は以下の2点。
1. MySQL5.5.16では、利用できないオプション名をmy.cnfで使っている
2. データ側のアップグレードが必要

項目1は、エラーメッセージに従い下記のように修正した。

default-character-set=utf8
↓↓↓
character-set-server=utf8

record_buffer
↓↓↓
read_buffer_size

その他、詳細はこのページで確認できます。
http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html

mysql_upgrade -p

mysqlのrootのパスワードで実行すると正しくチェックを行いエラーは表示されなくなった。

この方法で複数台を修正した。
最後に1台だけyumのアップデートが途中で停止するサーバがあった。
管理しているサーバの中では一番古いので、ファイル構成などが違っているようだ。
エラーの出るレポジトリが存在していたので、正常なサーバと見比べて不要だと確認してファイルを削除した。
その後、以下のコマンドを実行して

yum clean all
yum repolist

yum -y update

アップデートすると、更新されていなかった208ファイルをダウンロードして更新できた。

訳あって、osCommerceを別のサーバに引っ越す場合もっとも簡単な方法は、scpでまるごと転送する方法です。
旧サーバから新サーバへ直接転送するので、大量の画像ファイルがあるときもストレスなく移転作業ができます。
どちらのサーバもsshでの接続が許可されている必要があります。

まず、dfでディスクの残量を確認したあと、コンテンツ全体を圧縮します。
下記コマンドでは、public_htmlディレクトリ以下をすべて圧縮しています。

tar czfp public_html.tar.gz  public_html

次に、scpで旧サーバの圧縮ファイルを新サーバへ転送します。

scp public_html.tar.gz ユーザID@新サーバのIPアドレス:転送先ディレクトリ

圧縮ファイルが転送先ディレクトリに届いたら

tar xzf public_html.tar.gz

として、展開して適切なディレクトリに設置します。

この方法で圧縮ファイル14GBを転送したことがありますが、展開したファイルはオーナや権限が元のままなので、
画面がまったく表示されませんでした。
はじめは何が原因なのかわからず、ファイルをひとつひとつ確認していましたが、
ファイルのオーナーが新サーバのそれと違うことがわかり、chownコマンドでオーナを変更して画面を表示できました。

使えるネットでレンタルしたサーバで、Pleskの構成を考えずにMySQLをバージョンアップしたらPleskの各機能が動作しなくなった。Pleskの上位の管理画面がありそこを確認していたら、修復モードというのがあった。ボタンを押してみると、修復モードになったようで、これで修正できるかなと期待した。時間がかかりそうなのでブラウザを閉じてその日は眠った。

翌日、管理画面からログインしようとしたらパスワードが違うというメッセージが出てログインできない。SSHでのログインはできたので内部を見て修復モードの意味がやっと飲み込めた。/repair/ディレクトリにこれまでの「/」以下がマウントされた状態でそれまでの機能がまったく使用できなくなっていて、FTPなども動作せず、各コマンドもCannot allocate memoryとメッセージがでて起動できない。
PleskのPDFのマニュアルやフォーラムなど1日かけて調べたが修復モードに関する記事はなかった。ログインできれば「修復の終了」ボタンでいまのモードを解除できるが、どうしてもログイン方法を見つけられなかった。あれこれ考えているうちに2日めになり、思いついたのは、ログインせずに修復モードを抜けられたらいまの状況を解決できるのではということ。そこで、コマンドラインから修復モードを停止する方法をさがした。解決策をいくつか試してみたが、コマンドが起動できなかったり、コマンド自身がなかった。どうしようもなくなって、一度散歩に出て頭を冷やすつもりが、猛暑で汗だくになった。
rebootとumountのどちらかを実行することにした。再起動したらもしかしたら通常モードで起動するような気がした。だめだったら、明日サーバ会社に連絡することにしてもっとも傷が浅くなるようにrebootを実行した。コマンドが実行され、サーバが停止した。SSHが停止してしばらく待ってサーバが再起動できた頃に、Webの管理画面からログインすると無事に管理画面が表示できた。なんと、再起動したら修復モードを解除できた。よかった。

相変わらずMySQLは起動できていない。
振り出しに戻ったようなものだけど、なんだかうれしい。

MySQLは/etc/my.cnfを削除して再起動するとうまく動作した。