2013年5月8日水曜日

MySQLの5.1から直接アップグレード:サーバーは、PIDファイルを更新せずに終了

Original post: http://anothermysqldba.blogspot.com/2013/05/upgrading-directly-from-mysql-51-server.html

私は先日、この全体に走った... 


システムがインストールされ、他の誰かによって作成された非常に基本的なOracleのLinuxをインストールしました。
(OracleのLinuxサーバアンブレイカブルエンタープライズカーネル(2.6.39-400.17.1.el6uek.x86_64))
それは、彼らがして私は残りの部分を行うことになってきたシステムを望んで、実行することが登場。

ちなみに、OracleはRedHatのLinuxのを取ると、独自のバージョンを作ること、それを高めるために起こっている場合、彼らは少なくともそれで動作するように自社製品を更新するだろうか? 人々が分布から取得することは簡単だったので、MySQLが人気となり、独自のディストリビューションではまだ 5.1を持つことはちょうど異様です。

まあ最初に行うことは、OracleのLinuxは、MySQL 5.1が付属していますので、アップグレードです。

# rpm -qa |grep mysql
mysql-server-5.1.66-2.el6_3.x86_64
mysql-5.1.66-2.el6_3.x86_64
mysql-libs-5.1.66-2.el6_3.x86_64

私は、この例では5.5を使用した....
-rw-r--r--. 1 root root 14976016 Apr 30 06:07 MySQL-client-5.5.31-2.el6.x86_64.rpm
-rw-r--r--. 1 root root 4968092 Apr 30 06:08 MySQL-devel-5.5.31-2.el6.x86_64.rpm
-rw-r--r--. 1 root root 41827172 Apr 30 06:09 MySQL-server-5.5.31-2.el6.x86_64.rpm
-rw-r--r--. 1 root root 3970056 Apr 30 06:09 MySQL-shared-compat-5.5.31-2.el6.x86_64.rpm 

# rpm -Uhv *.rpm
error: Failed dependencies

だから私は、依存パッケージが最初に削除する必要がありましたし、実際にそれらがインストールされていたその理由さえわからない。

# rpm -Uhv *.rpm 
今、あなたは私たちの多くが見ているという悲しい事実を付属しています...

"mysqldumpを使用して手動でダンプとリストアをお勧めします。

手動アップグレードが必要です。

-あなたは完全に、作業データのバックアップとmy.cnfファイルを持っていることを確認
ファイル
- MySQLサーバーのきれいをシャットダウン
-既存のMySQLパッケージを削除します。 通常、このコマンドは、意志
を削除すべきパッケージを一覧表示:
します。rpm-qa | grep-iの'^のmysql-'

削除するには、 -あなたは'nodepsを-EV <package-name>回転'を使用することもできます
あるmysqlclient共有ライブラリを含むパッケージ。 
ライブラリは、MySQL-共有互換パッケージが再インストールされます。
- Oracleおよび/ ​​またはその関連会社によって提供される新しいMySQLパッケージをインストールします
- MySQLサーバが起動していることを確認
- "'mysql_upgradeを"プログラムを実行し

彼らはこれらの変更を行うための死を怖がっているので、非常に多くの人々がMYSQL 5.1で立ち往生することができた理由です。 これがそうでないはい、バックアップが次のステップとなる維持新規インストールだったので、私はラッキーだった。

それは私は、MySQL 5.6に移動のでMySQLを5.5と言っても理由はその後、私はすべてのものを削除したいと思っていないので。 前のパッケージ(RPM-e)を削除し、新しい(RPM-IHV)をインストールした後、私は次のを持っていた
# rpm -qa | grep MySQL
MySQL-client-5.6.11-2.el6.x86_64
perl-DBD-MySQL-4.013-3.el6.x86_64
MySQL-shared-compat-5.6.11-2.el6.x86_64
MySQL-server-5.6.11-2.el6.x86_64
MySQL-devel-5.6.11-2.el6.x86_64

だから私は最初にmy.cnfファイルを確認してください。 私が作りたいかもしれないので、誰かが代わりに上に置かれていれば編集します。
# ls -al /etc/my.cnf
ls: cannot access /etc/my.cnf: No such file or directory


私は、この例の目的のためにデフォルトに維持することを決定し、私はそれが行方不明のままに。
# /etc/init.d/mysql start
Starting MySQL..The server quit without updating PID file ([FAILED]/mysql/localhost.localdomain.pid).

それはmysql_upgradeを適用する開始できるようにする必要がありません

私はスキップの助成金を試してみました

# /etc/init.d/mysql start --skip-grant
Starting MySQL..The server quit without updating PID file ([FAILED]/mysql/localhost.localdomain.pid). 

現実には、エラー·ログには、真の問題を示した: "InnoDBは:システム表領域を開いたり、作成できませんでした "

問題は、彼らは恐ろしくパーティションを構築し、単にデータベースのためのスペースを持っていませんでした。 するときは、これを実現する必要がありますか? すぐに 。 あなたが最初にすべきことは、システムのパーティションを作成しているシステムのために何であるかをチェックすることです。 私は先入れ先出し指摘あればそれはこのブログの記事のポイントが無効になるでしょう。

このすべてのモラルとは何ですか? あなたがこれまで" サーバがPIDファイルを更新せずに終了する "というエラーが表示される場合はあなたがすべき非常に最初の事は、エラー·ログをチェックしています。 それは問題が正確に何を教えてくれます。