検索
連載

Oracle DatabaseとMySQLは「何」が違うのか　「アーキテクチャの違い」を理解する：実践 OSSデータベース移行プロジェクト（2）（2/3 ページ）

本連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。今回は「Oracle DatabaseとMySQLのアーキテクチャの違い」を解説するとともに、正しい設定／移行計画に向けたポイントを紹介します。

Share
Tweet
LINE
Hatena
前のページへ | 次のページへ

【3】「権限」「ロール」の違いを理解し、正しく設定する

　権限については、Oracle DatabaseもMySQLも、考え方は共通しています。

　しかしMySQLは、権限の「種類」が少なく、システム権限とオブジェクト権限を合わせても、たった32種類しかありません（MySQL 5.7／2016年7月現在）。Oracle Databaseは100以上ありますので、これまで細かくアクセス権限を設定して管理していたシステムからの移行では注意が必要です。

photo MySQL 5.7 権限の種類（出典：MySQL 5.7 Reference Manual）

　ユーザーに権限を付与するには、Oracle Databaseと同じくGRANT文を使用します。例えば、ユーザーアカウント「ap_user@192.168.0.1」に「testデータベース（≒スキーマ）」の「t1テーブル」に対する「SELECT権限」を与えたい場合は、以下のようなSQLとなります。

GRANT SELECT ON test.t1 TO ‘ap_user’@’192.168.0.1’;

　Oracle Databaseでは、権限を束ねて管理する「ロール」と呼ばれる概念も存在します。MySQLにはロールはありませんが、プロキシユーザを利用することで、同様の役割を持たせることができます。しかし、そもそもMySQLは権限の種類がそれほど多くはないことから、ユーザーアカウントごとに権限を付与する管理方法でもよいでしょう。管理しきれないほどに複雑にはならないと思います。

　※初出時より一部内容を追記しました。

ポイント

  • MySQLは、ユーザー権限の種類がOracle Databaseより少ない
  • 権限の付与は、Oracle Databaseと同じく「GRANT」文で行える
  • MySQLにはロールがないため、ユーザーアカウントごとに権限を付与する

【4】「表領域管理の違い」を理解し、正しく設定する

　Oracle DatabaseとMySQLでは、物理ファイルの構成／名称が以下のように違います。

内容 Oracle Database MySQL
データファイル .dbfファイル（データファイル） .ibdファイル／ibdataファイル
一時ファイル 一時ファイル 一時ファイル
コミットしたクエリを記録（循環利用）するファイル REDOログファイル ib_logfile
更新前のデータを保持するファイル UNDOファイル なし（ibdataファイルと一体化）
システム情報／メタ情報を保持するファイル 制御ファイル なし
サーバパラメータを記載するファイル PFILE、SPFILE my.cnf（PFILEに相当）
コミットしたクエリを記録（循環なし）するファイル アーカイブログファイル バイナリログ
エラーログファイル アラートログ エラーログ

　これらのうち、データベースの設計要素として必要なのは、「データファイル」「一時ファイル」「REDOログファイル」「UNDOファイル」になります。これら4つのファイルは、ディスク負荷や障害時を想定して、書き込み先のディスクを分散させる設計をしておく場合があるからです。

　MySQLでも、データファイル、一時ファイル、REDOログファイル（MySQLでは、「ib_logfile」）、UNDOログファイルの出力先は変更できます。これらは、以下のパラメータで出力先を指定できます。

  • データファイル：innodb_data_file_path
  • 一時ファイル：tmpdir
  • REDOログファイル（ib_logfile）：innodb_log_group_home_dir
  • バイナリログファイル：log_bin
  • UNDOログファイル：innodb_undo_directoryおよびinnodb_undo_tablespaces

　通常、I/O負荷が上昇する原因になるのは「REDOログファイル」「UNDOログファイル」です。MySQLでも書き込み負荷を分散させたい場合は、REDOログファイルに当たる「ib_logfile」、UNDOログファイル「undoXXX」（XXXには連番の数字が入ります）を別ディスクに保管するよう指定することでOracle Databaseと同様に対応できます。

　※初出時より一部内容を追記しました。

ポイント

  • Oracle DatabaseとMySQLでは、（一部を除き）物理ファイルの構成／名称に違いがある
  • 可能ならば、ディスク負荷や障害時を想定して「データファイル」「一時ファイル」「REDOログファイル」「UNDOファイル」を分散させる設計をしておく
  • 「ib_logfile（REDOログファイル）」はコミットごとにアクセスがあり、I/O負荷が上昇する原因になるため、別ディスクに保管するよう設定することで書き込み負荷を分散できる

【5】「監査の違い」を理解して、正しく設定する

　Oracle Databaseには、監査機能として「必須監査」「標準監査」「DBA監査」「FGA（Fine-Grained Auditing）監査」があります。これに対してMySQLでの監査機能には、「一般クエリログの利用」「MySQL Enterprise Audit」「MySQL Enterprise Firewallの利用」などの選択肢があります。

　一般クエリログとは、「MySQLで実行された全てのクエリをログに出力する」ものです。監査の観点からは有用な一方で、ログの出力量が膨大になるため、本番環境での利用はあまり推奨されません。一般クエリログを利用するならば、MySQL側ではローテーションの仕組みを持たないことから、Linuxに備わるlogrotate（ログを定期的にリネーム／削除する機能）などを利用して、別途ログローテーションの仕組みを構築しておく必要があります。

　MySQL Enterprise Auditでは、「MySQLで実行したクエリの監査機能」を提供します。ポリシーベースでの監査条件を設定でき、条件に適合したクエリが、いつ／どこで／誰によって実行されたのかをログに出力します。

　MySQL Enterprise Firewallは、「あらかじめ想定したクエリ以外の実行をブロックする」機能です。ホワイトリスト形式でのクエリ実行制限を行うため、前もって実行を許可するクエリを登録しておきます。クエリの登録には、機能を有効にしている間に実行されたクエリをホワイトリストへ自動登録していく「自動学習モード」も利用できます。自動学習モードに有効にしてからアプリを一通り動かせば、運用において実行されるクエリをホワイトリストに容易に登録できるでしょう。

　この他、ホワイトリストにないクエリが検知されたら、「クエリの実行を許可しない」か、「クエリの実行は許可するが、監査ログに出力する」かを選択できます。ホワイトリストの登録漏れがあったときにアプリケーションが停止しては困るという環境では、後者のモードにするとよいでしょう。

ポイント

  • 全てのクエリをログに出力する「一般クエリログ」を利用するならば、Linuxの「logrotate」などでログローテーションの仕組みを構築しておく
  • 普段使われるクエリ以外の実行をブロックするには、ホワイトリスト形式の「MySQL Enterprise Firewall」を使う
  • ホワイトリストを自動的に作成する「自動学習モード」がある
  • 未許可のクエリが検知されたら「拒否」か「許可するが、監査ログに記録する」かを選べる

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ | 次のページへ
ページトップに戻る