MySQLバージョンの選択とアップグレード戦略

データベースシステムを運用する際、使用するMySQLのバージョンは安定性と新機能のバランスを考慮して決定されます。多くの企業では、数年間にわたり安定稼働している既存のMySQLバージョン（例: 5.6.38）を継続して使用することがあります。これは、そのバージョンが業務要件を満たし、既知の問題が少なく、安定性が高いと判断されているためです。しかし、データベース管理者は、たとえ本番環境が古いバージョンであっても、MySQL 5.7や8.0といった新しいバージョンの機能や変更点について常に把握しておく必要があります。

新しいバージョンへのアップグレードは、計画的に行われるべき重要なプロジェクトです。アップグレードの際には、新しい機能の活用だけでなく、互換性の問題、パフォーマンスへの影響、セキュリティ強化などを総合的に評価し、慎重に進める必要があります。

MySQLの初期化と起動に関する一般的な問題解決

ライブラリ不足による初期化エラー

MySQLの初期化プロセス中に、共有ライブラリが見つからないというエラーが発生することがあります。特にlibaio.so.1が見つからないというエラーは、Linux環境でよく遭遇します。

$ /usr/local/mysql/bin/mysqld --initialize-insecure --user=mysql --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data
/usr/local/mysql/bin/mysqld: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory

この問題は、必要なAIO（Asynchronous I/O）ライブラリがシステムにインストールされていないために発生します。解決策としては、該当するライブラリパッケージをインストールします。

$ sudo yum install -y libaio-devel

MySQL 5.7以降の初期化コマンドの変更点

MySQL 5.7以降では、データベースの初期化コマンドが大きく変更されました。それ以前のバージョンで使用されていたmysql_install_dbスクリプトは非推奨となり、代わりにmysqld --initializeコマンドが導入されました。

MySQL 5.6以前の初期化

MySQL 5.6以前のバージョンでは、以下のスクリプトを使用して初期化が行われました。この方法では、デフォルトでrootユーザーのパスワードは設定されません。

$ /usr/local/mysql/scripts/mysql_install_db --user=mysql --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data

MySQL 5.7以降の初期化

MySQL 5.7以降では、mysqld --initializeコマンドが利用できます。このコマンドには2つの主要なモードがあります。

1. --initialize (一時パスワードとセキュリティポリシーを有効)
   このオプションを使用すると、rootユーザーに一時的なパスワードが生成され、標準出力またはエラーログに出力されます。また、MySQLのパスワードポリシーがデフォルトで有効になります。

$ /usr/local/mysql/bin/mysqld --initialize --user=mysql --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data
# ログに以下のような一時パスワードが出力されます:
# 2019-04-03T03:40:15.595883Z 1 [Note] A temporary password is generated for root@localhost: **MWht)!4%sa,3**
    

2. --initialize-insecure (パスワードなしで初期化)
   このオプションは、rootユーザーにパスワードを設定せず、セキュリティポリシーも適用しない点で、以前のバージョンと同様の動作をします。テスト環境や、後でセキュリティ設定を手動で行う場合に便利です。

$ /usr/local/mysql/bin/mysqld --initialize-insecure --user=mysql --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data
    

一時パスワードを使用した場合、初回ログイン後に必ずパスワードを変更する必要があります。

MySQL起動エラーの診断と解決

MySQLサーバーが起動しない場合、以下の手順で問題を診断します。

1. エラーログの確認: 最も重要な手順です。MySQLのエラーログファイル（通常datadirの下にhostname.errという名前で存在）を調べ、[ERROR]タグが付いている行を探します。エラーメッセージは問題の根本原因を示していることが多いです。
2. 設定ファイルの確認: my.cnfなどの設定ファイルに構文エラーがないか、または存在しないパスを参照していないかを確認します。
3. データディレクトリの確認: データディレクトリが正しく、破損していないかを確認します。ファイルシステムの権限も重要です。
4. プロセス競合の確認: 別のMySQLインスタンスが既に実行されていないか、またはポートやソケットファイルが他のプロセスによって占有されていないかを確認します。
5. 最終手段: 手動起動と詳細ログ: 問題が解決しない場合、詳細なログ出力オプションを付けて手動でmysqldコマンドを実行し、問題を特定するための追加情報を収集します。

MySQLへの接続問題とRootパスワードのリセット

一般的な接続失敗の原因

MySQLデータベースに接続できない場合、以下の原因が考えられます。

• MySQLサービスが起動していない。
• ユーザー名やパスワードが間違っている。
• 指定されたホスト名、IPアドレス、ポート番号が間違っている。
• Unixソケットファイルへのパスが間違っている。
• ネットワークの問題（ファイアウォール、ネットワーク設定）。
• MySQLサーバーのリソース不足（接続スレッドの枯渇など）。

MySQL Rootパスワードのリセット手順

MySQLのrootパスワードを忘れてしまった場合でも、以下の手順でリセットできます。

1. MySQLサービスを停止します。

$ sudo systemctl stop mysqld
    

2. グラントテーブルをスキップしてMySQLを起動します。
   これにより、パスワードなしで接続できるようになります。また、--skip-networkingオプションでリモートからの接続を禁止し、セキュリティを確保します。

$ sudo mysqld_safe --skip-grant-tables --skip-networking &
    

3. 新しいターミナルセッションを開き、パスワードなしでMySQLに接続します。

$ mysql -uroot
    

4. 新しいパスワードを設定し、権限をフラッシュします。
   ALTER USER文を使用する前にFLUSH PRIVILEGESを実行することが重要です。これにより、システムがグラントテーブルの変更を認識します。

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewSecurePassword123!';
Query OK, 0 rows affected (0.00 sec)
    

5. MySQLプロセスを終了し、通常モードで再起動します。

$ sudo pkill mysqld
$ sudo systemctl start mysqld
    

6. 新しいパスワードでログインできることを確認します。

$ mysql -uroot -p
Enter password: NewSecurePassword123!
    

MySQL設定の優先順位とコマンドラインのカスタマイズ

設定ファイルの適用順序

MySQLの設定は、複数のソースから読み込まれる可能性があり、それぞれに優先順位があります。優先順位は一般的に以下の通りです。

1. コマンドラインオプション: mysqldコマンド実行時に直接指定されるオプションが最も優先されます。
2. 設定ファイル（my.cnfなど）: コマンドラインで指定されたものがない場合、設定ファイルの内容が適用されます。複数の設定ファイルがある場合、読み込み順序によって優先順位が決まります。
3. コンパイル時のデフォルト値: どのオプションも指定されなかった場合、MySQLがコンパイルされたときに組み込まれたデフォルト値が使用されます。

MySQLクライアントプロンプトのカスタマイズ

mysqlクライアントのプロンプトは、現在のデータベース名などの情報を表示するようにカスタマイズできます。これは、複数のデータベースやサーバーを扱う際に非常に便利です。

mysql> PROMPT Master [\d]>
PROMPT set to 'Master [\d]>'
Master [NULL]> USE mydatabase;
Master [mydatabase]>

データ型とインデックスの最適化

CHARとVARCHARの比較と選択

MySQLの文字列データ型であるCHARとVARCHARは、異なる特性を持ち、適切な選択はパフォーマンスに大きく影響します。

• CHAR(N): 固定長文字列型です。指定された長さN（文字数）のストレージスペースが常に確保されます。短い文字列が挿入されても残りのスペースは空白で埋められます。検索効率は高いですが、スペースが無駄になる可能性があります。
• VARCHAR(N): 可変長文字列型です。実際の文字列の長さに応じてストレージスペースが割り当てられます。先頭に1バイトまたは2バイトのオーバーヘッド（文字列長を記録するため）が追加されます。スペースの節約には優れますが、読み書きの際に文字列長を計算するオーバーヘッドがあります。

選択の指針:

• 固定長の場合: 性別コード（'M', 'F'）やHASH値（MD5, SHA1）など、常に長さが一定のデータにはCHARが適しています。挿入時のパフォーマンスが向上します。
• 可変長の場合: 氏名、住所、コメントなど、長さが変動するデータにはVARCHARが適しています。ストレージスペースを節約し、特にデータ量が多い場合にディスクI/Oを削減できます。
• インデックスへの影響: VARCHAR型で非常に長い文字列が格納されると、インデックスの高さが増加し、クエリパフォーマンスに悪影響を与える可能性があります。

データベース/テーブル名の命名規則

データベースやテーブル名、カラム名には、大文字と小文字の区別に注意が必要です。特にWindows環境（通常大文字小文字を区別しない）で開発し、Linux環境（通常大文字小文字を区別する）で本番運用する場合に問題が発生しやすいです。一貫した運用のため、すべての識別子を小文字で統一するのがベストプラクティスです。

NOT NULL制約とインデックスの効率

テーブル設計において、可能な限りカラムにNOT NULL制約を設定することが推奨されます。特にセカンダリインデックス（補助インデックス）において、NULL値が多く含まれるとインデックスの効率が低下し、オプティマイザがインデックスを適切に利用できない場合があります。NULL値は特殊な値であり、インデックス構造での扱いが異なるためです。

複合インデックスの設計原則

複数のカラムからなる複合インデックスは、特定のクエリのパフォーマンスを向上させるために重要です。設計の際には以下の原則を考慮します。

1. 等値条件が多い場合: WHERE句で複数のカラムが等値条件（=, AND, OR, IN）で使われる場合、これらのカラムを複合インデックスに含めます。インデックスの先頭には、カーディナリティ（値の多様性）が高いカラムを配置することで、インデックスの絞り込み効果を高めます。
2. クエリの実行順序との一致: WHERE句、GROUP BY句、ORDER BY句で使われるカラムは、これらの句の実行順序に合わせてインデックスを作成すると、オプティマイザがより効率的にインデックスを利用できます。例えば、WHERE A GROUP BY B ORDER BY Cというクエリに対しては、(A, B, C)という複合インデックスが理想的です。

VARCHAR(255)がよく使われる理由

多くの開発者がVARCHAR(255)を好んで使用しますが、これにはいくつかの技術的な背景があります。

1. InnoDBのインデックス制限: InnoDBストレージエンジンでは、単一カラムまたはインデックスプレフィックスの長さは最大767バイト（MySQL 5.6以前ではこの制限があり、5.7以降では3072バイトに緩和されたが、デフォルトのページサイズや行フォーマットに依存する）です。UTF-8文字セットでは1文字あたり最大3バイト、UTF8mb4では最大4バイトを使用するため、UTF8では767/3 = 255、UTF8mb4では767/4 = 191となり、255文字が一般的な上限として意識されていました。
2. 文字列長格納のオーバーヘッド: VARCHAR型は文字列の長さを格納するためのオーバーヘッドを必要とします。実際のデータ長が255バイト以下の場合、このオーバーヘッドは1バイトです。256バイト以上になると2バイトが必要になります。このため、多くの文字列が255バイト以下に収まることが多いことを考慮すると、1バイトのオーバーヘッドで済むVARCHAR(255)が効率的と見なされてきました。

これは慣習的な選択であることが多いですが、上記の理由から合理的な側面も持ち合わせています。ただし、必要以上に大きな長さを設定することは無駄になる可能性もあるため、データの特性に応じた適切な長さを設定することが重要です。

SQLの標準と特定の挙動

SQL92とは

SQL92は、リレーショナルデータベース管理システム（RDBMS）で使用されるSQL言語の標準仕様の一つで、1992年にISOによって策定されました。MySQL、Oracle、Microsoft SQL Server、DB2、PostgreSQLなど、主要なRDBMSはSQL92をベースとしていますが、それぞれ独自の拡張機能や方言を持っています。SQL92に準拠したクエリは、異なるRDBMS間でのポータビリティを高く保ちやすいという利点があります。

UNIONとUNION ALLの違い

複数のSELECT文の結果セットを結合する際に使用されるUNIONとUNION ALLには重要な違いがあります。

• UNION: 結合された結果セットから重複行を排除します。重複排除の処理のため、パフォーマンスオーバーヘッドが発生します。
• UNION ALL: 結合された結果セットから重複行を排除しません。重複排除の処理がないため、UNIONよりも高速に動作します。

重複行を排除する必要がない場合は、パフォーマンスの観点からUNION ALLを使用することが推奨されます。

MySQL 5.7+のONLY_FULL_GROUP_BYモード

MySQL 5.7以降のデフォルトsql_modeには、ONLY_FULL_GROUP_BYが含まれています。このモードが有効な場合、SELECTリストの非集約カラムは、GROUP BY句に含めるか、集約関数で囲む必要があります。このルールに違反するとエラーが発生します。

-- エラーが発生するクエリ例 (ONLY_FULL_GROUP_BY有効時)
mysql> SELECT category, item_name, COUNT(*) FROM products GROUP BY category;
-- ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'products.item_name' ...

-- 修正後のクエリ例 (item_nameもGROUP BYに含める)
mysql> SELECT category, item_name, COUNT(*) FROM products GROUP BY category, item_name;

-- 修正後のクエリ例 (集約関数を使用する。どのitem_nameが選ばれるかは非決定的)
mysql> SELECT category, ANY_VALUE(item_name), COUNT(*) FROM products GROUP BY category;

このモードはSQL標準に準拠した厳格な振る舞いを強制し、データの一貫性を高めます。もし、この挙動が問題となる場合は、sql_modeからONLY_FULL_GROUP_BYを削除することも可能ですが、その影響を十分に理解しておく必要があります。

インデックス構造と性能: B-TreeとB+Tree

MySQLのInnoDBストレージエンジンでは、主にB+Treeインデックスが使用されます。B-TreeとB+Treeはどちらもツリー構造のインデックスですが、重要な違いがあります。

• B-Tree: 各ノードにキーとデータが格納されます。
• B+Tree: データはリーフノードにのみ格納され、中間ノードはキーのみを保持します。すべてのリーフノードは双方向リンクリストでつながっています。

このリーフノード間のリンクが、B+Treeの大きな利点です。特に、<, >, <=, >=などの範囲クエリを実行する際に、リーフノードを順次たどるだけで効率的にデータを取得できるため、パフォーマンスが大幅に向上します。

データベースの調査とSQLクエリの例

既存のデータベース構造を理解することは、データベース管理者にとって重要なスキルです。ER図がない場合でも、以下のSQLコマンドを活用してスキーマを把握できます。

• USE database_name;: 対象データベースを選択します。
• SHOW TABLES;: データベース内のテーブル一覧を表示します。
• DESCRIBE table_name;またはDESC table_name;: テーブルのカラム、データ型、NULL許可、キー情報などを表示します。
• SHOW CREATE TABLE table_name;: テーブルの作成に使用されたSQL文を表示し、インデックスやストレージエンジンなどの詳細を確認できます。

mysql> USE sample_db;
Database changed
mysql> SHOW TABLES;
+---------------------+
| Tables_in_sample_db |
+---------------------+
| departments         |
| employees           |
| courses             |
| enrollments         |
+---------------------+
4 rows in set (0.00 sec)

mysql> DESCRIBE employees;
+----------+--------------+------+-----+---------+----------------+
| Field    | Type         | Null | Key | Default | Extra          |
+----------+--------------+------+-----+---------+----------------+
| emp_id   | int          | NO   | PRI | NULL    | auto_increment |
| emp_name | varchar(100) | NO   |     | NULL    |                |
| dept_id  | int          | YES  | MUL | NULL    |                |
+----------+--------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

mysql> SHOW CREATE TABLE courses;
+---------+--------------------------------------------------------------------------------------------------------------------------+
| Table   | Create Table                                                                                                             |
+---------+--------------------------------------------------------------------------------------------------------------------------+
| courses | CREATE TABLE `courses` (
  `course_id` int(11) NOT NULL AUTO_INCREMENT,
  `course_name` varchar(100) NOT NULL,
  `instructor` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`course_id`)
  ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci |
+---------+--------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

以下に、実用的なSQLクエリの例をいくつか示します。仮に以下のテーブル構造が存在するとします。

CREATE TABLE departments (
    dept_id INT PRIMARY KEY AUTO_INCREMENT,
    dept_name VARCHAR(50) NOT NULL
);

CREATE TABLE employees (
    emp_id INT PRIMARY KEY AUTO_INCREMENT,
    emp_name VARCHAR(100) NOT NULL,
    dept_id INT,
    FOREIGN KEY (dept_id) REFERENCES departments(dept_id)
);

CREATE TABLE courses (
    course_id INT PRIMARY KEY AUTO_INCREMENT,
    course_name VARCHAR(100) NOT NULL,
    instructor VARCHAR(100)
);

CREATE TABLE enrollments (
    enrollment_id INT PRIMARY KEY AUTO_INCREMENT,
    emp_id INT,
    course_id INT,
    score INT,
    FOREIGN KEY (emp_id) REFERENCES employees(emp_id),
    FOREIGN KEY (course_id) REFERENCES courses(course_id)
);

例1: 特定の部署に所属する従業員のコース受講状況

「開発部」に所属する各従業員が受講したコースの総数を取得します。

SELECT
    e.emp_name,
    COUNT(en.course_id) AS enrolled_courses_count
FROM
    employees e
JOIN
    departments d ON e.dept_id = d.dept_id
LEFT JOIN
    enrollments en ON e.emp_id = en.emp_id
WHERE
    d.dept_name = '開発部'
GROUP BY
    e.emp_name;

例2: 部署とコースごとの合格者数

スコアが60点以上の合格者を部署とコースごとにカウントします。

SELECT
    d.dept_name,
    c.course_name,
    COUNT(DISTINCT e.emp_id) AS passed_students_count
FROM
    employees e
JOIN
    departments d ON e.dept_id = d.dept_id
JOIN
    enrollments en ON e.emp_id = en.emp_id
JOIN
    courses c ON en.course_id = c.course_id
WHERE
    en.score >= 60
GROUP BY
    d.dept_name, c.course_name;

例3: 特定の講師のコースを受講した従業員の成績評価

「山田太郎」が担当するコースを受講した従業員の成績を評価します。

SELECT
    e.emp_name,
    co.course_name,
    CASE
        WHEN en.score < 60 THEN '不合格'
        WHEN en.score >= 60 AND en.score < 70 THEN '合格'
        WHEN en.score >= 70 AND en.score < 85 THEN '良好'
        WHEN en.score >= 85 THEN '優秀'
        ELSE '未評価'
    END AS evaluation
FROM
    employees e
JOIN
    enrollments en ON e.emp_id = en.emp_id
JOIN
    courses co ON en.course_id = co.course_id
WHERE
    co.instructor = '山田太郎';

例4: 複数の特定コースを受講し、平均点が計算された従業員

「データベース」と「Javaプログラミング」の両方のコースを受講した従業員の平均スコアを取得します。

SELECT
    e.emp_name,
    AVG(en.score) AS average_score
FROM
    employees e
JOIN
    enrollments en ON e.emp_id = en.emp_id
JOIN
    courses co ON en.course_id = co.course_id
WHERE
    co.course_name IN ('データベース', 'Javaプログラミング')
GROUP BY
    e.emp_name
HAVING
    COUNT(DISTINCT co.course_name) > 1; -- 複数の指定コースを確実に受講していることを保証

バックアップとリカバリの高度なテクニック

mysqldumpからの特定要素の抽出

完全なmysqldumpバックアップファイルから、特定のテーブル構造、データ、または単一のデータベースを抽出する必要がある場合があります。これはsedやgrepのようなコマンドラインツールを使って実現できます。

• 特定のテーブルの構造のみを抽出する:

$ sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `mytable`/!d;q' full_backup.sql > mytable_schema.sql
    

• 特定のテーブルのデータのみを抽出する:

$ grep -i 'INSERT INTO `mytable`' full_backup.sql > mytable_data.sql
    

• 特定のデータベースのバックアップを抽出する:

$ sed -n '/^-- Current Database: `mydatabase`/,/^-- Current Database: `/p' full_backup.sql > mydatabase_only.sql
    

mysqldumpでAUTO_INCREMENT値を除外する

テーブル構造をコピーする際、AUTO_INCREMENTの現在の値を除外したい場合があります。これは、mysqldumpの出力にsedをパイプすることで実現できます。

$ mysqldump -uroot -p --no-data sample_db | sed 's/AUTO_INCREMENT=[0-9]*\s*//g' > sample_db_schema_no_ai.sql

--no-dataオプションは、データを含まずにテーブル構造のみをダンプすることを指定します。

オンラインDDLとアーキテクチャ設計

ALTER TABLEのロック問題とオンラインDDL

MySQLでALTER TABLE（例: カラムの追加、削除、データ型の変更など）を実行すると、特に大規模なテーブルの場合、長時間のテーブルロックが発生し、本番環境のサービスに大きな影響を与える可能性があります。これを避けるために、オンラインDDLツールが広く利用されています。

pt-online-schema-change: Percona Toolkitの一部であるpt-online-schema-changeは、テーブルロックを最小限に抑えながらDDL操作を実行できるツールです。元のテーブルのコピーを作成し、DDL操作をコピーに対して実行し、元のテーブルへの変更をコピーにレプリケートしながら、最後にテーブルを入れ替えるという仕組みで動作します。これにより、ほとんど中断なしにスキーマ変更を行うことができます。

データベースアーキテクチャの変換とスケーリング

データベースの負荷状況に応じて、アーキテクチャを調整することは運用上不可欠です。

• リードレプリカによる読み込み負荷分散 (Master-Slave): 主データベース（マスター）への書き込み負荷が高い、または読み込み要求が多数ある場合、複数のリードレプリカ（スレーブ）を構築し、読み込みクエリをこれらに分散させることで、マスターの負荷を軽減し、全体的なスループットを向上させることができます。
• 高可用性ソリューションの導入 (MHAなど): データベース障害に対する堅牢性を高めるために、MHA (Master High Availability) のような高可用性（HA）ソリューションを導入します。MHAは、マスターデータベースに障害が発生した場合に、自動的にスレーブの中から新しいマスターを選出し、フェイルオーバープロセスを自動化することで、サービスの中断時間を最小限に抑えます。

MySQL 5.7+の特定機能設定

独立したUndoログテーブルスペースの設定

MySQL 5.7以降では、Undoログを専用のテーブルスペースに分離して管理できるようになりました。これにより、Undoログの自動切り詰め（truncate）が可能になり、ファイルサイズの肥大化を防ぎ、ディスクスペースの管理が容易になります。my.cnfで以下のパラメータを設定します。

[mysqld]
innodb_max_undo_log_size = 128M        # 各Undoログファイルの上限サイズ
innodb_undo_log_truncate = ON          # Undoログの自動切り詰めを有効化
innodb_undo_logs = 128                 # Undoログセグメントの数
innodb_undo_tablespaces = 3            # Undoログテーブルスペースの数
innodb_purge_rseg_truncate_frequency = 10 # 切り詰め頻度

これらの設定は、MySQLインスタンスの再起動を必要とします。

MySQL 5.7でSSL機能を有効にする手順

MySQLサーバーとクライアント間の通信を暗号化するために、SSL（Secure Sockets Layer）/TLS（Transport Layer Security）を有効にすることができます。MySQL 5.7では、mysql_ssl_rsa_setupコマンドを使って必要な証明書とキーファイルを簡単に生成できます。

1. 証明書ファイルの生成:
   mysqldプロセスがアクセスできるデータディレクトリ内に、以下のコマンドでSSL/RSA証明書ファイルを生成します。

$ mysql_ssl_rsa_setup --datadir=/usr/local/mysql/data
    

2. 生成される証明書ファイルの種類:
   上記のコマンドを実行すると、指定されたディレクトリ（例: /usr/local/mysql/data）に以下のファイルが生成されます。

$ ls -l /usr/local/mysql/data/*.pem
-rw------- 1 mysql mysql 1675 Jun 10 16:00 /usr/local/mysql/data/ca-key.pem         # CA秘密鍵
-rw-r--r-- 1 mysql mysql 1107 Jun 10 16:00 /usr/local/mysql/data/ca.pem             # 自己署名CA証明書（クライアントも必要）
-rw-r--r-- 1 mysql mysql 1107 Jun 10 16:00 /usr/local/mysql/data/client-cert.pem    # クライアント証明書
-rw------- 1 mysql mysql 1675 Jun 10 16:00 /usr/local/mysql/data/client-key.pem     # クライアント秘密鍵
-rw------- 1 mysql mysql 1679 Jun 10 16:00 /usr/local/mysql/data/private_key.pem    # 秘密鍵/公開鍵ペアの秘密鍵
-rw-r--r-- 1 mysql mysql  451 Jun 10 16:00 /usr/local/mysql/data/public_key.pem     # 秘密鍵/公開鍵ペアの公開鍵
-rw-r--r-- 1 mysql mysql 1107 Jun 10 16:00 /usr/local/mysql/data/server-cert.pem    # サーバー証明書
-rw------- 1 mysql mysql 1675 Jun 10 16:00 /usr/local/mysql/data/server-key.pem     # サーバー秘密鍵
    

3. my.cnfへの設定追加:
   生成されたファイルパスをmy.cnfに設定し、MySQLサーバーを再起動します。

[mysqld]
ssl-ca=/usr/local/mysql/data/ca.pem
ssl-cert=/usr/local/mysql/data/server-cert.pem
ssl-key=/usr/local/mysql/data/server-key.pem
    

4. SSL接続の確認:
   サーバー再起動後、SHOW STATUS LIKE 'Ssl_cipher';コマンドでSSLが有効になっているか確認できます。