OpenGroove

MySQLで作成済みのテーブル型（ストレージエンジン）を確認するには、以下のコマンドを実行して”engine”列を見る。mysql > SHOW TABLE STATUS FROM db_name;※データベース名を指定する。

MySQLのアップグレード時に必要な作業を調べてみたが、いざとなるとズバリ、という内容は見つからないものだ。軽くイラっとしつつも、これでいいだろうか？とまとめてみた。

MySQLのrootパスワードを忘れた場合の対処法はどこにでも書かれているが、いちいち調べるのは面倒だからここにも書いておこう。。と思っていたら、今日さっそく利用した。人生、どのタイミングで何が起きるか分かりません。

何かとハマる、MySQLユーザアカウント設定。以前の記事「MySQLインストール時のお約束」でもrootパスワードのセットだの匿名ユーザの削除だのごちゃごちゃ書いたが、もっと思いきった方法があるようなので書いておく。

MySQLサーバの起動と停止について。Oracleでは起動状態として、停止、NOMOUNT、MOUNT、OPEN、という段階があるが、MySQLでは停止か起動かのどちらかしかない。

mysqld_multiの実装においてやるべきことをまとめてみた。ざっくり言うと、やるべきことは複数のMySQLインスタンス用にOS上でのユーザ作成とディレクトリ作成、my.cnfの設定変更。

mysqldとmysqld_safeの関係について。mysqld_safeはMySQLを安全に起動するためのプログラム、くらいの認識はあったのだが、では具体的に何がどう安全なの？．．．と、なると答えに詰まるので、改めて書いておく。

mysqldumpの実行ユーザに与える権限として何を指定すればいいか、あっさり調べてみた。

MySQLレプリケーションにおいて、スレーブをマスタとしてフェイルオーバーさせる時にやることをざっくりまとめてみた。マスタでは障害等によりMySQLインスタンスが停止していることが前提。

MySQLのERROR 1045 (28000): Access denied”エラーはログイン時に限らず、様々な局面で遭遇する。認証が失敗した時だけではなく、コマンドを実行しようとしているMySQL上のユーザに適切な権限が与えられていない場合にもこのエラーになる。

MySQLのユーザアカウント削除とパスワード変更。基本中の基本ではあるけれど、いざとなるといちいち調べるはめになるので、ここに書いておく。

MySQLコマンド実行時のパスワードはオプション-pで指定し、プロンプトから入力しているが、シェルに組み込む時などにオプションで直接パスワードを指定する必要が生じたりする。

MySQLサーバにおいてMySQLのプロセスがトータルで使用するメモリは、どれくらいに見積もっておけばいいだろうか。参考書やネット上では以下のような計算式が紹介されている。max_connections x [スレッド領域用メモリ合計値] に、[グローバル領域用メモリ合計値]をプラス。

telnetでの疎通確認やネットワークログインなど、MySQLとネットワークが絡む辺りの小ネタを。

MySQLのInnoDBは複数のデータファイルを構成することで巨大なテーブルの構築も可能。しかし当初必要なデータサイズの見当がつかない場合もある。後からファイルを追加したり、サイズを変更したくなったらどうしたらよいか。

MySQLのInnoDBデータファイルの仕様について、覚え書き。InnoDBデータファイルに格納されるものは、InnoDBテーブル、インデックスデータ、データディクショナリ、トランザクションのロールバックのためのデータ領域等である。

InnoDBログファイルとバイナリログファイルの違いについて。両者の違いは「InnoDBログファイルはクラッシュリカバリ時に使用され、バイナリログファイルはロールフォワードリカバリ時に使用される」と捉えているが、そもそもそれぞれの本質は何かというと、、、

MySQLをLinuxにインストールすると、デフォルトのデータディレクトリは/var/lib/mysqlになるものと想定される。これを変更しようとして、ちょっとハマってしまったので記録を。

ごく初歩的なミスで起こる、以下のMySQL接続時エラーについて。ERROR 1045 (28000): Access denied for use ‘user01′@ localhost’ (using password: YES)

InnoDBの重要な機能であるクラッシュリカバリと、それに深い関係があるInnoDBログについて。この辺の仕様がなかなか脳内に定着しないので、書いておく。 InnoDBログは、ロールフォワードリカバリには使用されない。では、InnoDBログの存在意義とは。ひと言でいうと、クラッシュリカバリである。クラッシュリカバリは、電源断など突然の障害が発生した際に、障害直前にコミットされた時点まで回復させる処理をする。MySQLはインスタンス起動時に、InnoDBデータファイルとInnoDBログファイル間に不整合があるかどうかを検出し、不整合があった場合にクラッシュリカバリを自動で行う。（MyISAMテーブルにはこの機能がない）MySQLではロールフォワードリカバリはバイナリログ、クラッシュリカバリではInnoDBログという役割分担がなされているわけだ。このため、もしバイナリログを消失するアクシデントがあった場合は、ロールフォワードリカバリは不要なんである、、、などと言いつつ、実はまだよく分かっていない（汗） ※出典：「現場で使えるMySQL」松信嘉範著 もう少しクラッシュリカバリについて書いておこう。 例えばいくつかのSQL文が実行された直後、システムがクラッシュしたとする。ここでMySQLを再起動すると、復旧処理が始まる。ハードディスクには最後のチェックポイント時でのデータが保存されており、それ以降の変更はトランザクションログにだけ保存されている。そこで、トランザクションログに記録されたSQL文を順に再実行(REDO)することで、クラッシュ直前の状態にまで復旧できる。、、、うーむ。ここで言っている「トランザクションログ」とはバイナリログではなく、ib_logfileを指しているようだが、、、 （http://www.interdb.jp/techinfo/mysql/m-2-08.htmlより） こっちの方が分かりやすいかな。 「MySQLは再起動時にib_logfileからコミットされたトランザクションを読み出し、それが実データ（デフォルトだと ibdata）に反映されていなければ反映させるという処理が走る」 （http://nkjmkzk.net/?p=60より） あぁ、やっぱり「トランザクションログ」とはib_logfile、つまりInnoDBログファイルなんだな。 やっとうっすら掴めてきたよ。。 それからinnodb-flush-log-at-trx-commitの値は余程のことがない限り1にしておく方がよいみたいだ。 「トランザクションがコミットする度にディスクへの書き込みとフラッシュを実行する」ってことなんだが、詳しいことはやはり上記参照サイトに書いてある。追求すればまだまだ出てきそうだが、ざっくり仕組みが理解できたので（多分）今回はこの辺で。