Oracle から Cloud SQL for MySQL への移行: セキュリティ、オペレーション、モニタリング、ロギング

このドキュメントは、Oracle® 11g/12c データベースから Cloud SQL for MySQL バージョン 5.7 の第 2 世代インスタンスへの移行を計画し、実施する際に必要な情報とガイダンスを提供するシリーズの一部です。このシリーズは次のパートから構成されています。

Oracle から Cloud SQL for MySQL への移行: 用語と機能
Oracle から Cloud SQL for MySQL への移行: データ型、ユーザー、テーブル
Oracle から Cloud SQL for MySQL への移行: クエリ、ストアドプロシージャ、関数、トリガー
Oracle から Cloud SQL for MySQL への移行: セキュリティ、オペレーション、モニタリング、ロギング（このドキュメント）

セキュリティ

このセクションでは、Oracle と Cloud SQL for MySQL 間のデータ暗号化の違いと、Cloud SQL for MySQL のアクセス制御の監査について説明します。

Oracle のデータ暗号化

Oracle では基本的なユーザー認証とユーザー権限管理のほか、TDE（透過的データ暗号化）メカニズムを使用してオペレーティングシステムレベルで保存データのセキュリティを強化できるようになっています。Oracle TDE を構成するとシステムによって自動的に実装されるため、ユーザーが手動で操作する必要は一切ありません。Oracle TDE を実装するには、このような暗号化を受け入れられる、サポート対象の必須データベースオブジェクト（テーブルスペース、テーブル、列など）に明示的に（コマンドで）構成することをおすすめします。転送中のデータのセキュリティに対処するには、ネットワークセキュリティソリューションの実装をおすすめします。

Cloud SQL for MySQL のデータ暗号化

Google Cloud では、複数の暗号化レイヤを提供して、Cloud SQL を含む Google Cloud プロダクト内にあるお客様の保存データを保護しています。Cloud SQL は AES-128 または AES-256 暗号化を使用して暗号化されます。詳細については、保存時の暗号化に関する次のトピックをご覧ください。構成アクションによって実装する必要がある Oracle 暗号化とは異なり、Google Cloud では何もしなくてもお客様の保存データが暗号化されます。スキーマ変換の観点では必要なアクションはありません。暗号化はユーザーに対して透過的です。

Google Cloud が転送データの暗号化を処理する方法について詳しくは、転送中のデータの暗号化の管理方法をご覧ください。

監査

Oracle では複数の監査方法（標準監査、ファイングレイン監査など）を提供しています。一方、MySQL では同等の監査ソリューションをデフォルトで提供していません。Google Cloud ダッシュボード / モニタリングを使用してこの制限をある程度克服することも可能ですが、さらに堅牢な監査ソリューションとして低速クエリログ、一般ログ、エラーログを使用すると、データベースの DML / DDL オペレーションをキャプチャできます。

このソリューションを実装するには、インスタンス FLAGS を使用して低速クエリログと一般ログを有効にすることをおすすめします。また、これらのログの保持はビジネスニーズに応じて管理する必要があります。

Google Cloud 監査ログを使用して、監査情報を収集できます。これらのログは、主に次の 3 つのレベルに対応しています。

管理アクティビティ監査ログ（デフォルトで有効）
データアクセス監査ログ（デフォルトでは無効）
- データアクセスログを構成する方法を確認してください。
- データアクセス監査ログには、Google Cloud にログインせずにアクセスできるリソース上のデータアクセスのオペレーションは記録されないことに注意してください。
システムイベント監査ログ（デフォルトで有効）

Google Cloud 監査ログの表示

監査ログを表示するためのアクセスパスは次のとおりです。[Google Cloud コンソール] > [ホーム] > [アクティビティ]

監査レベルの間で情報の粒度をフィルタできます。次のスクリーンショットは、管理アクティビティ監査を示しています。

監査レベル間の粒度のフィルタリング。

Cloud Logging ページ

ロギングページのアクセスパスは次のとおりです。[Google Cloud コンソール] > [Cloud Logging]

ログタイプ間で情報の粒度をフィルタできます。次のスクリーンショットは、一般的なログ監査（ユーザー、ホスト、SQL ステートメントの監査データ）を示しています。

一般的な監査ログ。

Cloud SQL for MySQL のアクセス制御

Cloud SQL for MySQL インスタンスに接続するには、承認済みの静的 IP アドレスを指定して MySQL クライアントを使用するか、他のデータベース接続の場合と同様の方法で Cloud SQL Proxy を使用します。App Engine や Compute Engine などの他のソースから接続する場合は、Cloud SQL Proxy などのいくつかのオプションを使用できます。これらのオプションについて詳しくは、インスタンスのアクセス制御をご覧ください。

オペレーション

このセクションでは、エクスポートとインポート、インスタンスレベルのバックアップと復元、MySQL イベントスケジューラ（データベースジョブ用）、読み取り専用オペレーションと障害復旧用のスタンバイインスタンスについて説明します。

エクスポートとインポート

Oracle で論理エクスポート / インポートオペレーションを行う主な方法は、Data Pump ユーティリティで EXPDP / IMPDP コマンドを実行することです（古いバージョンの Oracle のエクスポート / インポート機能には、exp と imp コマンドが含まれていました）。MySQL の同等のコマンドは、mysqldump と mysqlimport ユーティリティです。これらのユーティリティではダンプファイルを生成してから、データベース / オブジェクトレベルでインポートを実行します（これは、メタデータのみをエクスポート / インポートする場合にも該当します）。

MySQL には、Oracle の DBMS_DATAPUMP ユーティリティ（DBMS_DATAPUMP パッケージを直接操作する EXPDP / IMPDP 機能を適用する Oracle メソッド）に直接対応するソリューションはありません。Oracle の DBMS_DATAPUMP PL/SQL コードから変換するには、代替コード（Bash または Python など）を使用して論理要素を実装し、MySQL の mysqldump および mysqlimport を使用してエクスポート / インポートオペレーションを実行します。

MySQL の mysqldump および mysqlimport ユーティリティは、クライアントレベルで（MySQL クライアントプログラムの一部として）動作し、Cloud SQL for MySQL インスタンスにリモート接続します。ダンプファイルはクライアント側で作成されます。

mysqldump:

クライアントユーティリティが（sql として）論理バックアップおよびデータインポートを実行します。これにより生成される一連の SQL ステートメントを実行して、元のデータベースオブジェクトの定義とテーブルデータを再現できます。また、mysqldump ユーティリティは CSV 形式、他の区切り文字形式のテキスト、あるいは XML 形式で出力を生成できます。この出力形式の主なメリットは、テキストファイルであるため、復元前にエクスポート出力を表示または編集できることです。主なデメリットは、大量のデータを高速またはスケーラブルにバックアップするためのソリューションとしては意図されていないことです。

mysqldump の使用方法:

-- Single database backup & specific tables backup
# mysqldump database_name > outpitfile.sql
# mysqldump database_name tbl1 tbl2 > outpitfile.sql

-- Back up all databases
# mysqldump --all-databases > all_databases.sql

-- Ignore a given table
# mysqldump --databases db1 --ignore-table db1.tbl > outpitfile.sql

-- Back up metadata only - Schema only
# mysqldump --no-data db1 > bck.sql

-- Include stored procedures and functions (routines)
# mysqldump db1 --routines > db1.sql

-- Back up only rows by a given WHERE condition
# mysqldump db1 tbl1 --where="col1=1" > bck.sql

-- Include triggers for each dumped table (default)
# mysqldump db1 tbl1 —triggers > bck.sql

mysqlimport:

これは、LOAD DATA INFILE SQL ステートメントへのコマンドラインインターフェースを提供するクライアントプログラムです。mysqlimport はテキストファイルまたは CSV ファイルに含まれるデータを、対応する構造を持つ MySQL テーブルにインポートするためによく使用されます。Oracle SQL*Loader は mysqlimport に変換できます。どちらにも、外部ファイルからデータを読み込む機能があります。

mysqlimport の使用方法:

-- Example of loading data from a CSV file into a table:
-- Create a table named csv_file
mysql> create table file(col1 int, col2 varchar(10));

-- Create a CSV file (delimited by tab)
# echo 1    A > file.csv
# echo 2    B >> file.csv
# echo 3    C >> file.csv

-- Import the CSV file into the csv_file table
-- Note that the file and table name must be named identically
# mysqlimport -u USER -p -h HOSTNAME/IP DB_NAME --local file.csv
csv_file: Records: 3  Deleted: 0  Skipped: 0  Warnings: 0

-- Verify
# mysql -u USER -p -h HOSTNAME/IP DB_NAME -e "SELECT * FROM file"
+------+------+
| col1 | col2 |
+------+------+
|    1 | A    |
|    2 | B    |
|    3 | C    |
+------+------+

-- Example of using LOAD DATA INFILE to load a CSV file (using the same
   table from the previous example, with the CSV delimiter defined by
   comma)
mysql> LOAD DATA LOCAL INFILE 'file.csv' INTO TABLE file
       FIELDS TERMINATED BY ','
       LINES TERMINATED BY '\n' (col1, col2);

mysql> SELECT * FROM file;
+------+------+
| col1 | col2 |
+------+------+
|    1 | A    |
|    2 | B    |
|    3 | C    |
+------+------+

Cloud SQL for MySQL のエクスポート / インポート:

次のドキュメントのリンクは、エクスポート / インポートオペレーションを適用するために gsutil/gcloud を使用して Cloud SQL インスタンスおよび Cloud Storage とやり取りする方法を示しています。

インスタンスレベルのバックアップと復元

Oracle の RMAN やデータパンプから Cloud SQL for MySQL に移行する際に、バックアップや復元のオプション（VM スナップショット、コールドバックアップ、サードパーティ製ツールなど）を追加するのは単純なオペレーションです。コードも他の知識も必要ありません。このプロセスは、Google Cloud コンソールまたは Google Cloud CLI で管理できます（上記の例では第 2 世代の Cloud SQL インスタンスでコンパイルされています）。

MySQL データベースのバックアップ方法の種類には、オンデマンドバックアップと自動バックアップがあります。

Cloud SQL for MySQL のデータベースインスタンスの復元を使用して同じインスタンスに復元すると、既存のデータを上書きするか、別のインスタンスに復元できます。また、Cloud SQL for MySQL で自動バックアップオプションを有効にすると、バイナリロギングを使用して MySQL データベースを特定の時点に復元できます。

Cloud SQL for MySQL では、独立したバージョンのソースデータベースのクローンを作成できます。この機能はプライマリ（マスター）データベースまたは別のクローンのみに適用され、リードレプリカインスタンスのクローンは作成できません。また、この機能を使用して、必要に応じて特定の時点から MySQL インスタンスを復元し、データ復旧を行うこともできます。Google Cloud コンソールまたは gcloud CLI を使用して、Cloud SQL for MySQL データベースの復元を適用できます。

MySQL イベントスケジューラ（データベースジョブ）

事前定義されたデータベースプロシージャを開始する MySQL イベントスケジューラの機能は、Oracle DBMS_JOBS または Oracle DBMS_SCHEDULER と同等です。デフォルトでは、event_scheduler データベースパラメータは OFF に設定されています。必要に応じて、Cloud SQL フラグを使用して ON に切り換えてください。

MySQL イベントスケジューラを使用して、明示的な DML / DDL コマンドを実行できます。また、特定の時間に特定のロジックでストアドプロシージャまたは関数をスケジュールできます。

Oracle DBMS_JOBS または DBMS_SCHEDULER を使用する際の変換に関する注記:

Oracle ジョブは、すべて手動または市販の PL/SQL 変換ツールで MySQL の構文と機能に変換する必要があります。

次のステートメントを使用して、クライアントの実行から現在の event_scheduler パラメータ値を確認します。

mysql> SHOW VARIABLES LIKE '%event_s%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| event_scheduler | ON    |
+-----------------+-------+

イベントスケジューラの例:

Oracle DBMS_SCHEDULER

SQL> BEGIN
DBMS_SCHEDULER.CREATE_JOB (
   job_name             => 'job_sessions_1d_del',
   job_type             => 'PLSQL_BLOCK',
   job_action           => 'BEGIN DELETE FROM sessions WHERE
                                  session_date &lt; SYSDATE - 1;
                            END;',
   start_date           => SYSTIMESTAMP,
   repeat_interval      => 'FREQ=DAILY',
   end_date             => NULL,
   enabled              =>  TRUE,
   comments             => 'Deletes last day data from the sessions table');
END;
/

MySQL イベントの変換:

mysql> CREATE EVENT job_sessions_1d_del
       ON SCHEDULE EVERY 1 DAY
       COMMENT 'Deletes last day data from the sessions table'
       DO
       DELETE FROM sessions
          WHERE session_date < DATE_SUB(SYSDATE(), INTERVAL 1 DAY);

MySQL イベントスケジューラのメタデータ:

mysql> SELECT * FROM INFORMATION_SCHEMA.EVENTS \G;

-- OR

mysql> SHOW EVENTS FROM HR;

読み取り専用オペレーションと障害復旧の実装のためのスタンバイインスタンス

Oracle Active Data Guard を使用すると、スタンバイインスタンスを読み取り専用エンドポイントとして機能させながら、REDO ログとアーカイブログから引き続き新しいデータを適用できます。Oracle GoldenGate を使用して読み取り目的の追加のインスタンスを有効にすることもできます。データの変更はリアルタイムで適用されるため、Oracle GoldenGate はチェンジデータキャプチャ（CDC）ソリューションとして機能します。

Cloud SQL for MySQL では読み取り / 書き込みの分離をサポートするために、リードレプリカを使用して、読み取りワークロードまたは分析ワークロードをプライマリから別の複製されたソースにほぼリアルタイムでリダイレクトします。Google Cloud コンソールまたは gcloud CLI を使用して、Cloud SQL for MySQL リードレプリカの設定を適用できます。

Cloud SQL for MySQL は、レプリケーションオプションとして、外部 MySQL インスタンスへのレプリケーションと外部 MySQL インスタンスからのレプリケーションもサポートしています。

Oracle Active Data Guard と Oracle GoldenGate は障害復旧（DR）ソリューションとして実装できます。これにより、プライマリインスタンスとすでに同期されているスタンバイインスタンスを追加できます。

Cloud SQL for MySQL リードレプリカは、DR シナリオでのスタンバイインスタンスとして機能するものではありません。代わりに、Cloud SQL では MySQL インスタンスを高可用性向けに構成できます（Google Cloud コンソールまたは gcloud CLI を使用）。

一部のオペレーション（HA を既存のプライマリインスタンスに追加するなど）にはインスタンスの再起動が必要になる場合があります。高可用性（HA）SLA の観点から、プライマリが約 60 秒間応答しない場合、再接続時に HA スタンバイインスタンスが使用可能になります。Cloud SQL for MySQL の HA を有効にするには、次の手順をご覧ください。

ロギングとモニタリング

（主に障害イベントとエラーイベントのトラブルシューティングを目的に）Oracle データベースインスタンスのライフサイクルを理解するには、Oracle のアラートログファイルで一般的なシステムのイベントとエラーイベントを特定できます。

Oracle アラートログには、以下の情報が表示されます。

Oracle データベースインスタンスのエラーと警告（ORA- + エラー番号）。
Oracle データベースインスタンスの起動とシャットダウンイベント。
ネットワークと接続に関連する問題。
データベース REDO ログの切り替えイベント。
特定のデータベースイベントに関する追加の詳細を確認できるように、リンク付きで Oracle トレースファイルが記載されることもあります。

Oracle ではさらに、LISTENER、ASM、Enterprise Manager（OEM）などのサービスごとに専用のログファイルも提供しています。Cloud SQL for MySQL には、これらのサービスに相当するコンポーネントはありません。

Cloud SQL for MySQL ログのタイプ:

MySQL ログタイプ	説明	注
アクティビティログ	Cloud SQL for MySQL インスタンスの構成またはメタデータを変更する API 呼び出しやその他の管理アクションに関するデータが記録されます。	このログは、Cloud Audit Logs グループに属する 3 つのログのうちの 1 つです。
データアクセスログ	リソースの構成やメタデータを読み取る API 呼び出しや、ユーザー指定のリソースデータの作成、変更、読み取りのためのユーザーによる API 呼び出しに関するデータが記録されます。	このログは、Cloud Audit Logs グループに属する 3 つのログのうちの 1 つです。なお、このログには Google Cloud にログインせずにアクセスできるイベントに関する MySQL インスタンスのデータアクセスオペレーションのみが記録されます。
mysql.err	これは MySQL のプライマリログファイルで、Oracle のアラートログに相当します。どちらのログもデータベースインスタンスのイベントロギング（起動 / シャットダウンイベントやエラー / 警告イベントなど）を保持します。	MySQL 5.7 エラーメッセージガイド。
mysql-slow.log	MySQL の低速クエリログには、実行時間が 2 秒（デフォルトは 10 秒）を超えるクエリなど、事前定義した構成を超えるクエリに関するデータが収集されます。	デフォルトでは無効にされています。このログを有効にするには、次の変数（データベースパラメータ）を設定します。 `slow_query_log` `long_query_time`
mysql-general.log	このログには、クライアントの接続と切断に関するデータと、MySQL データベースインスタンスに対して実行されたすべての SQL ステートメントに関するデータが収集されます。このログは、トラブルシューティングに役立ちます。通常は、オペレーションが完了すると `OFF` になります。	デフォルトでは無効です。有効にするには、`general_log` 変数を `ON` に設定してください。
バイナリログ	MySQL サーバーはバイナリロギングを使用して、データを変更したすべてのステートメントを記録します。このログの主な用途はバックアップとレプリケーションです。	復元とリードレプリカのデプロイを可能にするために、Cloud SQL for MySQL ではデフォルトでバイナリロギングバラメータが有効になっています。バイナリロギングを有効にするには、`log_bin` 構成パラメータを `ON` に設定します。
リレーログ	下位インスタンス（リードレプリカ）にすべてのデータ変更を実装するために、プライマリバイナリログから受信したステートメントを保持します。	セカンダリ（スレーブ）インスタンスとリードレプリカにのみ適用されます。

Cloud SQL for MySQL オペレーションログを表示する

Cloud Logging は、すべてのログの詳細を表示するためのメインプラットフォームです。さまざまなログを選択し、ログのイベントレベル（重大、エラー、または警告など）でフィルタできます。イベントの時間枠とフリーテキストによるフィルタリングも使用できます。

Cloud Logging でログを表示する

例

次のスクリーンショットは、フィルタ条件としてカスタム時間枠を使用した mysql-slow.log ファイル内の特定のクエリ検索を示しています。

mysql-slow.log でクエリを検索します。

MySQL データベースインスタンスのモニタリング

Oracle の主な UI モニタリングダッシュボードは、OEM、Grid Control、Cloud Control の各プロダクトに統合されています（トップアクティビティグラフなど）。これらのダッシュボードは、セッションまたは SQL ステートメントレベルでのリアルタイムデータベースインスタンスのモニタリングに役立ちます。Cloud SQL for MySQL は、Google Cloud コンソールを使用して同様のモニタリング機能を提供します。CPU 使用率、ストレージ使用量、メモリ使用量、読み取り / 書き込みオペレーション、上り（内向き） / 下り（外向き）バイト、アクティブな接続など、複数のモニタリング指標を持つ Cloud SQL for MySQL データベースインスタンスに関する概要情報を表示できます。

Cloud Logging は、Cloud SQL for MySQL の追加のモニタリング指標をサポートしています。次のスクリーンショットは、過去 12 時間の MySQL クエリ数のグラフを示しています。

過去 12 時間の MySQL クエリ数のグラフ

MySQL リードレプリカモニタリング

Google Cloud コンソールのモニタリング指標（前述）を使用して、プライマリインスタンスと同様の方法でリードレプリカをモニタリングできます。さらに、レプリケーションの遅延モニタリング専用のモニタリング指標もあります。この指標で、プライマリインスタンスとリードレプリカインスタンスのラグ（秒単位）を確認できます（Google Cloud コンソールのリードレプリカインスタンスの概要タブでモニタリングできます）。

gcloud CLI を使用してレプリケーションのステータスを取得できます。

gcloud sql instances describe REPLICA_NAME

MySQL クライアントからコマンドを使用してレプリケーションをモニタリングすることもできます。これにより、プライマリデータベース、下位データベースのステータスと、バイナリログ、リレーログのステータスを確認できます。

次の SQL ステートメントを使用して、リードレプリカのステータスを確認できます。

mysql> SHOW SLAVE STATUS;

MySQL のモニタリング

このセクションでは、MySQL の基本的なモニタリングメソッドについて説明します。これらのメソッドは、DBA（Oracle または MySQL）によって行われるルーティンタスクと見なされます。

セッションモニタリング

Oracle セッションをモニタリングするには、「V$」ビューと呼ばれる動的パフォーマンスビューのクエリを実行します。現在のデータベースアクティビティに関するリアルタイムの分析情報を得るには、一般に、SQL ステートメントで V$SESSION と V$PROCESS ビューを使用します。コマンドと SQL ステートメントを使用して、MySQL のセッションアクティビティをモニタリングできます。たとえば、MySQL SHOW PROCESSLIST コマンドによって、セッションアクティビティに関する次の詳細が提供されます。

mysql> SHOW PROCESSLIST;

SELECT ステートメントを使用して、SHOW PROCESSLIST の結果をクエリおよびフィルタすることもできます。

mysql>  SELECT * FROM information_schema.processlist;

長時間トランザクションのモニタリング

パフォーマンスの問題の要因になる可能性がある、長時間実行されているトランザクションをリアルタイムで識別するために、information_schema.innodb_trx 動的ビューのクエリを実行できます。このビューにより、MySQL データベースインスタンス内で実行されている未完了のトランザクションのレコードのみが表示されます。

ロックのモニタリング

information_schema.innodb_locks 動的ビューを使用して、データベースのロックをモニタリングできます。このビューには、パフォーマンスの問題につながる可能性のあるロック発生に関するリアルタイムの情報が表示されます。