FAQ（よくある質問と回答）

メインページ »» MySQL運用

目次


ストレージエンジン??
MySQL は、データの保存形式を複数持っています。
その保存形式により、機能や特徴、パフォーマンスが変わります。
これをストレージエンジンと呼んでいます。

このモデルの利点は:
- 用途にあったストレージエンジンを選択することで、特別なチューニングを施すことなく、
その目的に合った能力を得ることができる。
- 古いバージョンのMySQLで作成したファイルは、MySQLをバージョンアップをしてもそのまま使い続けることができる。
MySQL のバージョンアップに際して、データの吸い上げ、入れ直しは発生しない。
- 新しい手法が登場したとき、簡単にその手法を取り入れ、よりよい環境を提供できる。
- あるストレージエンジンは他のストレージエンジンに影響を及ぼさない。
このため、バグの影響が少ない

実際の使い方は
CREATE TABLE ..... (.....) TYPE=InnoDB;
のようにするだけ。
ALTER TABLE .... TYPE=MyISAM;
のように、テーブルのストレージエンジンを ALTER TABLE 文で変えることも可能。(TYPEのかわりに ENGINE キーワードでも OK)

代表的なストレージエンジン:
MyISAM : 検索に強い
InnoDB : トランザクション
HEAP(MEMORY) : メモリ内で動作するテーブル

標準のストレージエンジンは MyISAM。
すなわち、TYPE とか ENGINE を指定しなければ、テーブルの型は MyISAM になるということ。
複数のMySQLを同居させるには/MySQLを違うディレクトリで動かすには
mysqld --basedir=/usr/local/mysql-4.0.22 --datadir=/usr/local/mysql-4.0.22/data --socket=/tmp/sock4.0.22 --port=4022 &

もしくは

/usr/local/mysql-4.0.22/my.cnf
に
[mysqld]
basedir=/usr/local/mysql-4.0.22
datadir=/usr/local/mysql-4.0.22/data
socket=/tmp/sock4.0.22
port=4022
と書いて

mysqld --defaults-file=/usr/local/mysql-4.0.22/my.cnf &
I/O分散
MyISAMの場合
CREATE TABLE .... (...) DATA DIRECTORY = '/path/to/directory/MYD' INDEX DIRECTORY = '/path/to/directory/MYI'

InnoDB の場合1
[mysqld]
innodb_data_home_dir =
innodb_data_file_path=/path/to/file1:10M;/path/to/file2:50M

InnoDBの場合2
[mysqld]
innodb_file_per_table

OSでの対処の場合
データベースは単なるディレクトリなので、
違うdiskをそのディレクトリにマウント
ログ
log-bin (バイナリ更新ログ) が肝です。
# 3.22 までは、log-update (更新ログ) を使います。

log-bin 採取開始時のデータに対して、log-bin の内容(テキストのSQL文) を順に全て当てていけば、現在のデータになります。
もちろん、ログの途中まであてれば、その時までの状態になります。

どういう運用ができるかはあなたのアイデア次第。

max_binlog_size :
1つのバイナリ更新ログファイルの最大サイズ。これに達すると、自動でローテート

log-bin=名前
バイナリ更新ログファイルの名前の指定。ディレクトリを含めることが出来る。 log-bin=/disk1/logfile とすると、/disk1/logfile.###### ファイルになる。
3.X,4.0 -> 4.1 以上
1. クライアントの upgrade
Ruby, PHP, Perl など、C クライアントを 4.1 (以上)の libmysqlclient にリンクし直してインストール
なお、文字の自動変換機能による弊害が発生する可能性があるので、他のFAQを参考のこと。


2. 念のため、mysqldump でバックアップ


3. upgrade
[mysqld]
default-character-set = ujis
old-passwords

[mysqldump]
default-character-set = ujis

old-passwords オプションは、4.1以上のサーバーの認証方法を、4.0 までの認証方法のままにするということ。


4. 権限テーブル upgrade
mysql_fix_privilege_tables もしくは
mysql -f -uroot mysql < mysql_fix_privilege_tables.sql
4.1サーバーと4.0クライアント
[mysqld-4.1]
old-passwords

MySQL 4.1 サーバーを 4.0 までの認証で動かす。
version 4.1 以上の文字コード変換機能とうまくつきあうには?
MySQL version 4.1 から、utf8 が組み込まれたり、文字コードの自動変換が組み込まれたりと、けっこう文字周りがかわりました。
4.0までの MySQL とは感覚が変わるので、一応、こうした方がトラブルは少ないね、という経験上のものを書いておきます。

- mysqldump には必ず --default-character-set= を指定すること。
- MySQL サーバーとクライアントは、必ず同じキャラクターセットにしておくこと。
- 4.1以上対応のアプリケーションには、必ず "SET NAMES キャラクターセット名" という SQL 文を付けておくこと。
- データベース名、テーブル名、フィールド名には、マルチバイト文字は使用しないこと。
- マルチバイトキャラクターセットと、latin1などのシングルバイトキャラクターセットを混在させないようにすること。
- キャラクターセットはデータベース単位、テーブル単位、フィールド単位で指定できるが、フィールド単位でのキャラクターセットの指定はなるべく避けた方がよいだろう
- 文字の自動変換機能を抑止する、--default-character-set=binary の使用が便利。
- 既にコンパイル済みのバイナリを使うときは、そのバイナリが作成されたときに埋め込まれている、標準のキャラクターセットを知っておいた方がよい。
-- !!! MySQL AB のバイナリは latin1 が標準 !!!
- 自分でコンパイルする場合は、binary キャラクターセットを標準に指定してコンパイルすれば、アプリの変更や設定の変更無しに、MySQL 4.0,3.23 対象のアプリが動く。
- --init-connect='SET NAMES キャラクタセット名' は使わない。これはクライアントコマンドオプション --default-character-set= を無効にしてしまうから。
- 4.1 の mysqldump には --hex-blob というオプションが追加されている。これは BLOB のバイナリデータを壊さずに mysqldump 可能になる。
4.1 にupgradeしたら文字が?になります / 4.1 にしたらクエリの結果がおかしいことがある
4.1 から文字の自動変換機能の追加、char() の仕様変更がありました。
なので、サーバーを 4.1 に upgrade すると、文字が ? になったり、文字が変になったり、クエリーの結果がおかしくなったりすることがあります。
4.1 に upgrade するならば、以下のようにします。

1. まず、ソースから MySQL をビルドし直す。charset は binary にして。(後述、備考参照)

2. ビルドしてできた libmysqlclient (windows の場合は libmysql.dll) を使用して、PHP, Perl, Ruby, などの MySQL モジュールをコンパイルし直す。

3. サーバーを 4.1 にする前に、念のためバックアップを取っておく

4. サーバーを 4.1 にする
/etc/my.cnf には
[mysqld-4.1]
old-passwords

[mysqld]
default-character-set=使用するキャラクターセット名

[mysqldump]
default-character-set=使用するキャラクターセット名
skip-opt

を書いて、4.1 の サーバー起動

5. mysql_fix_privilege_tables を実行して、mysql データベースの権限テーブルを upgrade する。
Windows の場合は、
mysql -f -uroot mysql < mysql_fix_privilege_tables.sql
とする

6. すべてのテーブルを ALTER する。
char() の定義がおかしくなっているので、指定し直す。
Unix の場合は、MyNA の http://www.mysql.gr.jp/frame/modules/bwiki/?Contrib にあるシェルスクリプトを使ってもよい。


7. また、mysql コマンド、mysqldump コマンド等は、必ず、default-character-set= を指定して使用しましょう。
character-set はサーバーと同じにしましょう。


8. クライアントプログラムに、'SET NAMES ' 文を追加する方法もあります。この場合は、1,2 の手順は必須ではなくなります。


備考. ソースからのビルド
Unix なら ./configure --with-charset=binary にする。
Windows なら、
include/my_config.h , include/config-win.h の

#define MYSQL_DEFAULT_CHARSET_NAME "latin1"
を
#define MYSQL_DEFAULT_CHARSET_NAME "binary"
に。

#define MYSQL_DEFAULT_COLLATION_NAME "latin1_swedish_ci"
を
#define MYSQL_DEFAULT_COLLATION_NAME "binary"
に。
日本語環境の設定
標準のキャラクターセットが日本語になっていないバイナリを使用するときは、設定をしておきます。

[mysqld]
default-character-set = ujis

[mysqldump]
default-character-set = ujis

[mysql]
default-character-set = ujis

---
なお、language = の指定は、日本語が扱える、扱えないには、全く関係ありません。設定しても無意味。
たんにエラーメッセージが日本語になるだけで、クエリやデータを日本語扱いにするという意味ではありません。
エラーメッセージが日本語になっても邪魔くさい(変な文)ので、通常はlanguageは指定しません。


投稿された内容の著作権はコメントの投稿者に帰属します。
投稿者 スレッド