【MariaDB】レプリケーションとは

MariaDBのレプリケーションはデータのバックアップや負荷分散に役立つ重要な技術です。

本ブログでは、Windows環境でMariaDBの非同期レプリケーションを設定する方法を初心者～中級者向けに紹介します。

【MariaDB】レプリケーションの目的

データの冗長化とバックアップ

Masterサーバーが障害を起こした場合でもSlaveサーバーにデータが複製されているため、システムの可用性を向上させることができます。

負荷分散

読み取り専用のクエリをSlaveサーバーに振り分けることで、Masterサーバーの負荷を軽減しシステム全体のパフォーマンスを向上させる事ができます。

災害復旧

データセンターやサーバーの障害が発生した際、別の場所にあるSlaveサーバーからデータを復旧することが可能になります。

テスト環境の構築

本番環境のデータを複製しテスト用の環境を作成することで、リスクを抑えた検証作業が可能になります。

【MariaDB】レプリケーションの種類

MariaDBのレプリケーションには以下の種類があります。

非同期レプリケーション

• 最も一般的なレプリケーション方式であり、Masterサーバーがトランザクションをコミットした後、即座に処理を完了とみなします。
  
  
• SlaveサーバーはMasterのバイナリログを非同期で取得して適用します。
  
  
• MasterとSlaveの間でデータのズレが生じる可能性があるため、障害発生時にデータの不整合が発生することがあります。

セミ同期レプリケーション

• Masterサーバーはトランザクションをコミットした後、少なくとも1つのSlaveサーバーがデータを受信したことを確認するまで次の処理を実行しません。
  
  
• 非同期レプリケーションよりもデータ整合性が向上し、Masterの障害発生時にデータの欠落を最小限に抑えることができます。
  ただし、Masterの処理速度が遅くなる可能性があるため、パフォーマンスへの影響を考慮する必要があります。

マルチソースレプリケーション

• 1つのSlaveサーバーが複数のMasterサーバーからデータを取得し、統合する方式です。
  
  
• 複数のデータソースを集約したい場合や、分散データベースを統合する際に役立ちます。
  
  
• 複雑な設定が必要であり、データの競合を適切に管理する必要があります。

本ブログのでのシステム環境

• Masterサーバー
  • ＯＳ：Windows 10 Pro 22H2
  • MariaDB：Community版 11.4.4
• Slaveサーバー
  • ＯＳ：Windows 10 Home 22H2
  • MariaDB：Community版 11.4.4

【MariaDB】Ｍasterサーバーの設定

設定ファイルの編集

設定ファイル my.ini をＭasterサーバー用に変更します。

[mysqld]
datadir=C:/Program Files/MariaDB 11.4/data
port=3306
innodb_buffer_pool_size=1527M
character-set-server=utf8mb4

# ------- 追加パラメータ ----------------------------------------------------
server-id=1  # サーバーごとに一意のIDを設定（Masterは1）
log-bin=mysql-bin  # バイナリログを有効化
bind-address = 0.0.0.0   # 外部からの接続を許可
binlog-format=row  # 行ベースのバイナリログフォーマットを使用（推奨）
expire_logs_days=7  # バイナリログの保存期間（7日間）
max_binlog_size=500M  # バイナリログの最大サイズ（500MB）
gtid_strict_mode=1　# GTID整合性に関するチェックを有効化
#----------------------------------------------------------------------------

[client]
port=3306
plugin-dir=C:\Program Files\MariaDB 11.4/lib/plugin

• log-bin=mysql-bin
  バイナリログを有効化します。
  バイナリログ（Binary Log）は、MariaDBの変更履歴を記録するログであり、データベースの更新（INSERT、UPDATE、DELETEなど）の情報が保存されます。レプリケーションでは、Masterサーバーがこのバイナリログを記録し、Slaveサーバーがそれを取得してデータを同期します。
  
  
  
• binlog-format=row
  バイナリログの記録形式を行ベースに設定します。（推奨）
  行形式は各行のデータの変更内容を直接記録する為、再実行時にデータの不整合が発生し難くなるますが、ログのサイズが大きくなりがちです。
  • その他の形式
    • STATEMENT（ステートメントベース）
      SQLクエリ（INSERT, UPDATE, DELETEなど）をそのままログに記録する方法ですが、NOW() や RAND() を含むクエリ等、再実行時に異なる結果になる可能性があります。
    • MIXED（ミックス）
      STATEMENTとROWのハイブリッドで、MariaDBがクエリの内容に応じて適切なフォーマットを自動で選択します。
      
      
• expire_logs_days=7
  バイナリログの保存期間（7日間）に設定しています。
  
  
• max_binlog_size=500M
  バイナリログ（binlog）の最大サイズを指定します。このサイズに達すると新しいバイナリログファイルが自動的に作成されます。
  • 推奨サイズ
    • デフォルト値: 1G (1GB)
    • 小規模環境（低トラフィック）: 100M ～ 500M
    • 中規模環境（中程度のトラフィック）: 500M ～ 1G
    • 大規模環境（高トラフィック）: 1G 以上（適宜調整）
      
      
• gtid_strict_mode=1
  GTIDモードを有効にします。すべてのトランザクションにGTIDが割り当てられデータの不整合を防ぐことができます。
  
  

• binlog-do-db=replication_db
  特定のデータベースのみをレプリケーションしたい場合に指定します。指定しない場合は全ての変更がバイナリログに記録されます。

設定を変更したらMariaDBを再起動します。

【MariaDB】レプリケーションユーザーの作成

レプリケーション専用のユーザーを作成し、Slaveサーバーからの接続を許可します。

MariaDB [(none)]> CREATE USER 'repl_user'@'%' IDENTIFIED BY '********';
Query OK, 0 rows affected (0.012 sec)

MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
Query OK, 0 rows affected (0.007 sec)

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]>

【MariaDB】Slaveサーバーの設定

設定ファイルの編集

設定ファイル my.ini をSlaveサーバー用に変更します。

[mysqld]
datadir=C:/Program Files/MariaDB 11.4/data
port=3306
innodb_buffer_pool_size=1018M
character-set-server=utf8mb4

# ------- 追加パラメータ ----------------------------------------------------
server-id=2  # スレーブサーバーの一意なID
log-bin=mysql-bin  # バイナリログを有効化
bind-address = 0.0.0.0  # 外部からの接続を許可
relay-log=relay-bin  # リレーログを設定
relay-log-index=relay-bin.index  # リレーログインデックスファイル名
read-only=1  # スレーブサーバーを読み取り専用に設定
skip-slave-start=1  # スレーブの自動開始を無効化
relay-log-recovery=1　# 破損したリレーログを自動的に修復します。
# ---------------------------------------------------------------------------

[client]
port=3306
plugin-dir=C:\Program Files\MariaDB 11.4/lib/plugin

• server-id=2
  スレーブサーバーの一意なIDを指定します。Masterサーバーは1です。
  
  
• relay-log=relay-bin
  リレーログのファイル名が relay-bin.000001, relay-bin.000002 … のように作成されます。リレーログファイルはrelay-log-index によって管理され、どのリレーログが現在適用されているかを管理します。
  
  
• relay-log-index=relay-bin.index
  リレーログのインデックスファイルを指定します。

【MariaDB】レプリケーションの開始

Ｍasterサーバー　バイナリログの確認

Masterサーバーの現在のバイナリログファイルと位置を確認し、その情報をレプリケーション開始時Slave側で設定します。

MariaDB [(none)]> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 |     2763 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.000 sec)

Slaveサーバー　レプリケーションの開始

レプリケーションを開始するために、SlaveサーバーでCHANGE MASTER TO コマンドを実行します。Masterサーバーの現在のバイナリログファイルと位置情報は以下の様に設定します。

MariaDB [(none)]> CHANGE MASTER TO
    ->     MASTER_HOST='192.168.0.80',
    ->     MASTER_USER='repl_user',
    ->     MASTER_PASSWORD='********',
    ->     MASTER_LOG_FILE='mysql-bin.000003',   -- Masterから得たファイル名
    ->     MASTER_LOG_POS=2763;                  -- Masterから得た位置
Query OK, 0 rows affected, 1 warning (0.029 sec)

MariaDB [(none)]>

Slaveサーバーでレプリケーションを開始します。

MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.007 sec)

レプリケーション動作の確認

正常に動作していれば Slave_IO_Running と Slave_SQL_Running が Yes になります。

■Slaveサーバーで「SHOW SLAVE STATUR\G」コマンドを実行

MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: 192.168.0.80
                   Master_User: repl_user
                   Master_Port: 3306
                 Connect_Retry: 60
               Master_Log_File: mysql-bin.000003
           Read_Master_Log_Pos: 2763
                Relay_Log_File: relay-bin.000002
                 Relay_Log_Pos: 555
         Relay_Master_Log_File: mysql-bin.000003
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
               Replicate_Do_DB:
           　　　　　　　　　・
           　　　　　　　　　・
           　　　　　　　　　・
           SQL_Remaining_Delay: NULL
       Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Slave_DDL_Groups: 0
Slave_Non_Transactional_Groups: 0
    Slave_Transactional_Groups: 0
          Replicate_Rewrite_DB:
1 row in set (0.001 sec)

Ｍasterサーバー側にレコードを追加して確認

Ｍasterサーバー側にレコードを追加してSlaveサーバーに反映されるか確認します。

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| books_db           |
| customers_db       |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
6 rows in set (0.003 sec)

MariaDB [(none)]> use books_db
Database changed
MariaDB [books_db]> show tables;
+--------------------+
| Tables_in_books_db |
+--------------------+
| books              |
+--------------------+
1 row in set (0.003 sec)

MariaDB [books_db]> select * from books;
Empty set (0.000 sec)

MariaDB [books_db]> INSERT INTO books (title, author, genre, price, stock_quantity, publication_date)VALUES ('The Great Adventure', 'John Doe', 'Adventure', 1200.00, 10, '2023-05-10');
Query OK, 1 row affected (0.007 sec)

MariaDB [books_db]> select * from books;
+---------+---------------------+----------+-----------+---------+----------------+------------------+
| book_id | title               | author   | genre     | price   | stock_quantity | publication_date |
+---------+---------------------+----------+-----------+---------+----------------+------------------+
|       7 | The Great Adventure | John Doe | Adventure | 1200.00 |             10 | 2023-05-10       |
+---------+---------------------+----------+-----------+---------+----------------+------------------+
1 row in set (0.001 sec)

MariaDB [books_db]>

Slaveサーバー側の確認

Slaveサーバー側にも同一内容のレコードが作成されているか確認します。下記のように同一レコードが作成されており非同期レプリケーションの正常動作が確認できました。

MariaDB [books_db]> show databases;
+--------------------+
| Database           |
+--------------------+
| books_db           |
| customers_db       |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
6 rows in set (0.001 sec)

MariaDB [books_db]> use books_db;
Database changed
MariaDB [books_db]> show tables;
+--------------------+
| Tables_in_books_db |
+--------------------+
| books              |
+--------------------+
1 row in set (0.001 sec)

MariaDB [books_db]> select * from books;
+---------+---------------------+----------+-----------+---------+----------------+------------------+
| book_id | title               | author   | genre     | price   | stock_quantity | publication_date |
+---------+---------------------+----------+-----------+---------+----------------+------------------+
|       7 | The Great Adventure | John Doe | Adventure | 1200.00 |             10 | 2023-05-10       |
+---------+---------------------+----------+-----------+---------+----------------+------------------+
1 row in set (0.000 sec)

MariaDB [books_db]>

まとめ

非同期レプリケーションではMasterデータベースからSlaveデータベースにデータが複製されます。しかし、コミットした時点でSlaveへのデータ転送が即時に実行される訳ではありません。その為、データの整合性がリアルタイムに保たれない場合があります。

非同期レプリケーションの場合は特に以下の点に留意しましょう。

• データ遅延
  アプリケーションを開発する場合、遅延を考慮した設計をする
  
  
• 監視とログ管理
  SHOW SLAVE STATUS等のコマンドを実行して、エラーや警告がないか定期的にチェックする
  
  
• レプリケーションの再同期
  同期が取れなくなった場合、STOP SLAVEとSTART SLAVEを使って再同期を行うがデータ損失の可能性があるため慎重に行う
  
  
• バックアップの実施
  定期的にバックアップを実施しデータ損失リスクを最小限に抑える

【MariaDB】バックアップ/リストア mariadb-backupコマンド編

データベースのバックアップとリストアは、システム管理者や開発者にとって重要な業務です。本ブログではMariaDB（Community Edition版）でのバックアップとリストアの基本的な方法を、初心者/中級者向けに紹介します。

MariaDB（Community Edition版）のバックアップ方法には主に「mysqldump¹」と「mariadb-backupコマンド」がありますが、本ブログでは「mariadb-backupコマンド」を紹介します。

【MariaDB】mariadb-backupコマンドとは

MariaDBのmariadb-backupコマンドは、データベースのデータを物理フォルダごとコピーするバックアップ手法です。
この方法はmysqldumpのようにSQLテキストを生成するのではなく、バイナリデータをそのまま保存するため、大規模データに適しています。

• 主な特徴
  • 物理バックアップをサポート
    • データベース内のすべてのデータファイルを直接コピーする方法
    • 大規模なデータベースでも高速にバックアップが可能

• フルバックアップと増分バックアップに対応
  • フルバックアップ
    • データベース全体のデータをバックアップ（初回のバックアップとして推奨）。

• 増分バックアップ
  • 前回のバックアップ以降に変更されたデータのみをバックアップします。ストレージを節約しつつバックアップスピードを向上できます。

• トランザクションの一貫性を維持
  • InnoDBストレージエンジンのトランザクションログを含めてバックアップするため、トランザクションの一貫性を確保できます。
  • 稼働中でもバックアップが可能（ホットバックアップ対応）

• バックアップ後のデータ検証が可能
  • バックアップファイルが正しい状態かどうかを検証できます。

• MyISAMとAriaストレージエンジンもサポート
  • デフォルトではInnoDBストレージエンジンに最適化されていますが、MyISAMやAriaなど他のストレージエンジンにも使用可能です。

• 主な利用場面
  • データベースが大規模で、運用中にバックアップを取得する必要がある場合
  • 定期的なインクリメンタルバックアップを利用したい場合
  • バックアップファイルのセキュリティやストレージ効率を重視する場合
    

【MariaDB】mariadb-backupの基本的な使い方

mariadb-backupの基本

フルバックアップの作成

C:¥>mariadb-backup --backup --target-dir=D:\Backup --user=root --password=your_password

• –backup：バックアップモードを指定
• –target-dir：バックアップファイルを保存するディレクトリを指定
• –user/–password：MariaDBの接続情報を指定

■実行例

C:¥>C:\>mariadb-backup --backup --target-dir=H:\Backup --user=root --password=********
[00] 2025-01-29 20:37:05 Connecting to MariaDB server host: localhost, user: root, password: set, port: 3306, socket: C:\Program Files\MariaDB 11.4\data\mysql.sock
　　　　　　　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　　　　　　　・
[00] 2025-01-29 20:37:17 All tables unlocked
[00] 2025-01-29 20:37:17 Backup created in directory 'H:\Backup\'
[00] 2025-01-29 20:37:17 Writing backup-my.cnf
[00] 2025-01-29 20:37:17         ...done
[00] 2025-01-29 20:37:17 Writing mariadb_backup_info
[00] 2025-01-29 20:37:17         ...done
[00] 2025-01-29 20:37:17 Redo log (from LSN 74243 to 74259) was copied.
[00] 2025-01-29 20:37:17 completed OK!

C:\>

インクリメンタルバックアップの作成

• フルバックアップ後に変更された部分だけをバックアップする場合
  • –incremental-basedir
    • フルバックアップ（または前回のバックアップ）のディレクトリを指定。

C:\>mariadb-backup --backup --target-dir=D:\Backup\incremental --incremental-basedir=D:\Backup\full --user=root --password=your_password

圧縮したバックアップ

• バックアップを7-zip等の圧縮ソフトで圧縮するとディスク容量を節約できます。

C:¥>mariadb-backup --backup --target-dir=D:\Backup --user=root --password=your_password && 7z a D:\Backup\backup.7z D:\Backup

• 説明
  • MariaDB Backup
    • –backup: バックアップモードを指定
    • –target-dir=D:\Backup: バックアップデータの保存先
    • –user=rootと–password=your_password：MariaDBの認証情報
  • 7-zipのオプション
    • a
      圧縮ファイルを作成します（add）
    • D:\Backup\backup.7z
      作成される圧縮ファイルのパス
    • D:\Backup
      圧縮対象のディレクトリ
  • &&
    1つ目のコマンド（MariaDB Backup）が成功した場合にのみ、2つ目のコマンド（7-Zipの圧縮）が実行される

バックアップファイルだけを圧縮したい場合

• mariadb-backupのバックアップ出力を標準出力（–streamオプション）で直接圧縮することも可能です。

C:¥>mariadb-backup --backup --stream=xbstream --user=root --password=your_password | 7z a -si D:\Backup\backup.7z

• 説明
  • –stream=xbstream
    標準出力にバックアップデータを出力。
  • -si
    標準入力（stdin）からデータを受け取る。

mariadb-backupコマンドの主なオプション

• –backup
  バックアップを作成するモードを有効にします。

c:\>mariadb-backup --backup --target-dir=D:¥Backup\to\backup --user=root --password=your_password

• –prepare
  バックアップデータを復元可能な状態に準備する（トランザクションログを適用し一貫性を確保）

c:\>mariadb-backup --prepare --target-dir=D:¥Backup\to\backup

• –copy-back
  準備済みのバックアップデータを元のデータディレクトリに復元します
  ※）MariaDBサーバーを停止した状態で使用する

c:\>mariadb-backup --copy-back --target-dir=D:¥Backup\to\backup

• –target-dir
  バックアップデータを保存するディレクトリを指定します。

c:\>mariadb-backup --backup --target-dir=D:¥Backup\to\backup

• –incremental-basedir
  増分バックアップを作成する際に、基となるフルバックアップや以前の増分バックアップのディレクトリを指定します。

c:\>mariadb-backup --backup --incremental-basedir=D:¥Backup\to\full_backup --target-dir=D:¥Backup\to\incremental_backup

• –parallel
  バックアップを並列処理するスレッド数を指定します。大規模なデータベースでバックアップの速度を向上させる際に有用です。

c:\>mariadb-backup --backup --parallel=4 --target-dir=D:¥Backup\to\backup

• –stream
  バックアップデータを標準出力（STDOUT）に送信します。他のツール（例: gzipや7-Zip）とパイプ処理する場合に使用します。

C:\>mariadb-backup --backup --stream=xbstream --user=root --password=your_password | 7z a -si D:\Backup\backup.7z

• –databases
  特定のデータベースだけをバックアップします。

c:\>mariadb-backup --backup --databases="db1 db2" --target-dir=D:\Backup\backup

• –tablespaces
  特定のテーブルスペースのみをバックアップします。

c:\>mariadb-backup --backup --tablespaces=ts1,ts2 --target-dir=D:\Backup\backup

• –no-lock
  テーブルのロックをスキップします。バックアップ中にデータベースを利用可能にしたい場合に使用します（ただし、一貫性が保証されない場合があります）。

c:\>mariadb-backup --backup --no-lock --target-dir=D:\Backup\backup

【MariaDB】mariadb-backupリストアの手順

MariaDBサーバーの停止

データを安全に復元するため管理者権限でMariaDBサーバーを停止します。

c:\>net stop mariadb

バックアップデータを準備する（–prepare）

バックアップデータをリストア可能な状態に準備します。

c:\>mariadb-backup --prepare --target-dir=D:\Backup\Full

データをリストアする（–copy-back）

バックアップデータの保存先または復元元のディレクトリを指定する(–target-dir)

データディレクトリにバックアップデータをコピーします。データディレクトリが既存の場合、空にしておく必要があります。

c:¥>mariadb-backup --copy-back --target-dir=D:\Backup\Full

データディレクトリの権限を修正する

MariaDBサービスが正しく動作するよう、データディレクトリの権限を確認・修正します（Windowsでは通常不要ですが、エラー発生時等に確認）

MariaDBサーバーを起動する

リストア後、管理者権限でMariaDBサーバーを起動します。

c:\>net start mariadb

【MariaDB】mariadb-backup リストア時の注意点

データディレクトリの場所

MariaDBのmy.ini設定ファイルでデータディレクトリ（datadir）がカスタマイズされている場合、その場所を確認する必要ありますす。

バックアップが圧縮されている場合

gzipや7-Zipで圧縮したバックアップを使用する場合は、まず解凍してからリストアを実行します。

c:¥>7z x backup.7z -oD:\Backup\Full

増分バックアップの適用順序

• 最初にフルバックアップを–prepareで準備
• 次に、順番に増分バックアップを–prepare –incremental-dirで適用

まとめ

MariaDBのデータを安全に保護するためには適切なバックアップ計画と実行が欠かせません。
特に、mariadb-backup は物理バックアップを取得できる強力なツールであり大規模なデータベースの運用に欠かせません。

本記事では、mariadb-backup を使ったフルバックアップ・増分バックアップの取得方法と、それをリストアする手順について紹介しました。

バックアップの頻度や方法は、データベースの規模や業務要件に応じて調整する必要があります。定期的なバックアップとテストリストアを行い、「いざという時」に確実に復元できる状態を維持しましょう。

1. 「mysqldump」は下記ブログを参照ください。
   　　ブログ：【MariaDB】バックアップ/リストア mysqldump編  ↩︎

【MariaDB】バックアップ/リストア ｍysqldump編

データベースのバックアップとリストアは、システム管理者や開発者にとって重要な業務です。本ブログではMariaDB（Community Edition版）でのバックアップとリストアの基本的な方法を、初心者/中級者向けに紹介します。

MariaDB（Community Edition版）のバックアップ方法には主に「mysqldump」と「mariadb-backup」¹がありますが、本ブログでは「mysqldump」を紹介します。

【MariaDB】ｍysqldumpとは

mysqldumpは、MariaDBに含まれるバックアップ用コマンドラインツールです。データをSQL形式のファイルにエクスポートし、リストア時にそのファイルをインポートして復元します。

• 主な特徴
  • SQLスクリプト形式：読みやすくバックアップファイルの編集が可能
  • 軽量かつポータブル：別の環境にデータを簡単に移行できる
  • 多様なバックアップ対象：特定のテーブル/データベース/全データベースを選択可能

• 利用場面
  • 簡単にデータを移行したい場合
  • テキスト形式で編集や変更が必要な場合

【MariaDB】バックアップの基本

基本コマンド

特定のデータベースをバックアップする方法

C:\>mysqldump -u root -p test_db > H:\Backup\test_db_backup.sql

• -u root：ユーザー名（ここではroot）
• -p：パスワードを入力するプロンプトを表示
• test_db：バックアップ対象のデータベース名
• > H:\Backup\test_db_backup.sql：バックアップファイルの出力先

■実行例

C:¥>mysqldump -u root -p test_db > H:\Backup\test_db_back.sql
Enter password: ******

C:\>

■test_db_back.sqlの内容（例）

　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　・
--
-- Table structure for table `customers`
--

DROP TABLE IF EXISTS `customers`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `customers` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `customer_name` text NOT NULL,
  `customer_address` text DEFAULT NULL,
  `customer_email` text DEFAULT NULL,
  `customer_age` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `customers`
--

LOCK TABLES `customers` WRITE;
/*!40000 ALTER TABLE `customers` DISABLE KEYS */;
INSERT INTO `customers` VALUES
(1,'田中 太郎','東京都新宿区1-2-3','tanaka.taro@example.com',30),
(2,'佐藤 花子','大阪府大阪市北区4-5-6','sato.hanako@example.com',25),
(3,'鈴木 次郎','北海道札幌市中央区7-8-9','suzuki.jiro@example.com',40),
(4,'高橋 美咲','福岡県福岡市博多区10-11-12','takahashi.misaki@example.com',35),
(5,'山本 健','愛知県名古屋市中区13-14-15','yamamoto.ken@example.com',50);
/*!40000 ALTER TABLE `customers` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　・

すべてのデータベースをバックアップする方法

• –all-databasesオプションを指定する

C:\>mysqldump -u root -p --all-databases > H:\Backup\all_databases_backup.sql

特定のテーブルだけをバックアップ

C:\>mysqldump -u root -p test_db table1 table2 > H:\Backup\tables_backup.sql

圧縮したバックアップ

• バックアップを7-zip等の圧縮ソフトで圧縮するとディスク容量を節約できます。

C:¥>mysqldump -u root -p test_db | 7z a -si H:\Backup\test_db_backup.7z -mx=9

• 説明
  • mysqldump
    • MariaDBのtest_dbデータベースをエクスポートします
    • -u root -pでユーザー名を指定し、プロンプトでパスワードを入力します
  • |（パイプ）
    • mysqldumpの出力を直接7-zipに渡します
  • 7-zipのオプション
    • a
      圧縮ファイルを作成します（add）
    • -si
      標準入力（Standard Input）を使用してデータを受け取ります
    • test_db_backup.7z
      作成される圧縮ファイル名
    • -mx=9
      圧縮レベルを最大（9）に指定。但し、圧縮スピードを優先したい場合は -mx=1 を指定

• バックアップファイルをフォルダ単位で管理している場合、フォルダ全体を圧縮すると便利です。

7z a -t7z backup_folder.7z H:\backup_folder -mx=9

• backup_folder.7z：出力するフォルダ名
• H:\backup_folder：圧縮するフォルダ名

バックアップのオプション

mysqldumpには多数のオプションがあり、要件に応じて使い分けることができます。

• ロックを防ぐ
  –single-transaction：バックアップ中にテーブルがロックされるのを防ぎたい場合
  • 推奨用途
    InnoDBストレージエンジンを使用している場合

c:\>mysqldump -u root -p --single-transaction test_db > H:\Backup\test_db_backup.sql

• データだけをバックアップ
  –no-create-info：データベース構造を除きデータのみをバックアップしたい場合

c:\>mysqldump -u root -p --no-create-info test_db > H:\Backup\data_only.sql

• スキーマのみをバックアップ
  –no-data：テーブルの構造だけをバックアップしたい場合

c:\>mysqldump -u root -p --no-data test_db > H:\Backup\schema_only.sql

• 特定の条件でデータをバックアップ
  –where：条件付きでデータをバックアップ（例: 特定の日付以降のデータ）したい場合

c:\>mysqldump -u root -p --where="created_at > '2025-01-01'" test_db > H:\Backup\filtered_backup.sql

【MariaDB】リストアの基本

基本コマンド

リストアするにはリストア先のデータベースが存在している必要があるので、無い場合は作成しておく必要があります。データベース名は変更してもかまいません。

バックアップした特定のSQLファイルのリストア

c:\>mysql -u root -p test_db < H:\Backup\test_db_backup.sql

圧縮ファイルのリストア

圧縮されたバックアップファイル（例: backup.7z）を解凍し、解凍したSQLファイルをmysqlコマンドでリストアします

• 圧縮されたバックアップファイル（例: backup.7z）の解凍

c:¥>7z x H:\Backup\test_db_backup.7z -oH:\Backup
C:\>mysql -u root -p test_db < H:\Backup\test_db_backup

• 説明
  • 7z.exe x
    解凍（extract）コマンド
  • H:\Backup\test_db_backup.7z
    圧縮したファイル
  • -oH:\Backup
    解凍先フォルダ
    
    

• 解凍したSQLファイルのリストア

C:\>mysql -u root -p test_db < H:\Backup\test_db_backup

• 解凍とリストアを一つのコマンドにまとめる事もできます

c:¥>7z e -so D:\Backup\test_db_backup.7z | mysql -u root -p test_db

• 説明
  • e -so
    解凍し、内容を標準出力（stdout）に送るオプション。
  • |
    解凍した内容を直接mysqlに渡します。

mysqldumpバックアップ　データの整合性

mysqldumpはMariaDBサーバーと通信してデータを取得するツールであり、通常は稼働中のデータベースサーバーから直接バックアップを取得します。

ただし、MariaDBを停止すべきケースもあるので紹介します。

MariaDBを停止させないでバックアップを取得する方法

• –single-transaction オプションを使用する
  バックアップの開始時にトランザクションを開始し、そのトランザクションのスナップショットを基にデータをエクスポートします。このオプションは、InnoDBで使用する場合に非常に有効です。
  ※MyISAMテーブルではこのオプションは有効ではありません。

c:¥>mysqldump -u root -p --single-transaction test_db > H:\Backup\test_db_backup.sql

• テーブルをロックする（デフォルト）
  テーブルをロックしてデータの変更を防ぎます（デフォルト動作）。ただし、全テーブルがロックされるため、バックアップ中のクエリ実行に影響が出ることがあります。
  ※データの整合性よりもパフォーマンスを優先する場合は、–skip-lock-tables オプションを
  　使用します。

c:¥>mysqldump -u root -p --lock-tables test_db > H:\Backup\test_db_backup.sql

MariaDBを停止させるべきケース

MariaDBを停止してバックアップを取る必要があるのは以下のケースに限られます

1. データの完全性を100%確保したい場合
   サーバーを停止させることで完全な状態でバックアップを取得できます。ただし、停止中はMariaDBを使用できなくなるため、メンテナンスウィンドウを確保する必要があります。
   
   
2. ファイルベースのバックアップを使用する場合
   データディレクトリを丸ごとコピーするファイルベースのバックアップを取る場合は、MariaDBを停止させる必要があります。
   
   但しxtrabackupのようなツールを使用すると、停止させずにファイルベースのバックアップが可能です。

まとめ

mysqldumpはそのシンプルさと柔軟性からMariaDBのバックアップツールとして非常に便利です。

基本的なバックアップ・リストア手順だけでなくオプションを活用して効率を最大化し、セキュリティやパフォーマンスを考慮した運用が可能です。

1. 「mariadb-backup」は下記ブログを参照ください。
   　　ブログ：【MariaDB】バックアップ/リストア mariadb-backupコマンド編 ↩︎

【MariaDB】ユーザーの権限管理（付与/確認/取り消し/ロール 他）

ユーザーに与える権限はデータベースのセキュリティと安定性に直結する重要な要素です。適切な権限設定を行うことで以下のメリットが得られます。

1. セキュリティの向上
2. 誤操作の防止
3. 責任範囲の明確化

最小権限の原則
各ユーザーには業務に必要な最低限の権限のみを付与し、セキュリティリスクを最小限に抑えることが重要です。

【MariaDB】root ユーザー

インストール直後に作成されるデフォルトのルートユーザー (root)は全ての権限を持っています。通常、このユーザーが新しいユーザーを作成し権限を設しします。

MariaDB 権限の付与

作成したユーザーに権限を付与する基本的なSQL構文は以下の通りです。

GRANT 権限 ON データベース名.テーブル名 TO 'ユーザー名'@'ホスト';

• すべての権限を付与

GRANT ALL PRIVILEGES ON my_database.* TO 'example_user'@'localhost';

• 特定の権限を付与

GRANT SELECT, INSERT ON my_database.my_table TO 'example_user'@'localhost';

• 特定のデータベースのみにアクセスを許可

GRANT SELECT ON reports.* TO 'report_viewer'@'%';

MariaDB 権限の確認

• 以下のコマンドで、ユーザーに付与されている権限を確認できます。

SHOW GRANTS FOR 'ユーザー名'@'ホスト';

• 自分の権限を確認する場合

SHOW GRANTS FOR CURRENT_USER;

MariaDB 権限の取り消し

• 不要な権限は以下のコマンドで削除します

REVOKE 権限 ON データベース名.テーブル名 FROM 'ユーザー名'@'ホスト';

【MariaDB】権限の種類

MariaDB ユーザー作成に必要な権限

ユーザーを作成するには、CREATE USER 権限または SUPER 権限が必要です。

• CREATE USER 権限
  • 新しいユーザーを作成するための基本的な権限です。
    
    
• SUPER 権限
  • データベース全体を管理できる権限です。
    CREATE USERを含む全権限を持ちますが、運用上は特定の管理者にのみ付与します。

CREATE USER 権限を付与する方法
*.*：すべてのデータベースに対する権限（ユーザー作成に対しては通常これを指定します）

GRANT CREATE USER ON *.* TO 'user_admin'@'localhost';

MariaDB 基本的な権限

データベースやテーブルに対する基本的な操作を管理するための権限です。

MariaDB 高度な権限

データベースの管理やシステムレベルの操作に関連します。

MariaDB セキュリティ関連の権限

セキュリティに関連する権限で、データの暗号化や認証に影響を与えるものです。

MariaDB 特定の操作に関連する権限

特定の機能や操作に関連する権限です。

MariaDB グローバルレベルで利用可能な権限

この権限はサーバー全体に影響を与える権限です。

【MariaDB】ロール

MariaDBのロール (Role)は、ユーザーの権限管理を簡素化するための仕組みです。複数の権限をロールにまとめ、ロールをユーザーに割り当てることで権限の付与や管理を効率的に行うことができます。これは特に、多くのユーザーが異なる権限を持つような環境で便利です。

MariaDB ロールの特徴

• 権限のグループ化:
  • ロールに権限を付与し、そのロールをユーザーに割り当てることでユーザー個別に権限を管理する必要がなくなります。
• 柔軟性:
  • 複数のロールを1人のユーザーに割り当てることが可能です。
  • ロール自体にも権限を付与したり削除したりできます。
• 有効化と無効化:
  • ロールをアクティブ（有効化）または非アクティブ（無効化）にすることができます。

MariaDB ロールの作成

新しいロールを作成するには、CREATE ROLEコマンドを使用します。

CREATE ROLE 'role_name';

MariaDB ロールへの権限付与

ロールに権限を付与するには、GRANTコマンドを使用します。

GRANT 権限名 ON データベース名.テーブル名 TO 'role_name';

MariaDB ロールのユーザーへの割り当て

ユーザーにロールを割り当てるには、GRANTコマンドを使用します。

GRANT 'role_name' TO 'username'@'host';

MariaDB ロールの有効化

割り当てたロールを有効化するには、SET ROLEコマンドを使用します。

SET ROLE 'role_name';

• 複数のロールを有効化

SET ROLE 'role_name1', 'role_name2';

• すべてのロールを有効化

SET ROLE ALL;

MariaDB ロールを無効化

ＳET ROLE NONE コマンドを使用します。

SET ROLE NONE;

MariaDB ロールの権限確認

現在のロールに付与されている権限の確認はＳHOW ＧRANTS コマンドを使用します。

SHOW GRANTS FOR 'role_name';

MariaDB ロールの削除

ロールを削除するには、DROP ROLEコマンドを使用します。

DROP ROLE 'role_name';

MariaDB ロールの利用例

• データベース：company_db
• ユーザー：employeeとmanager
• 要件
  • employeeは読み取り専用アクセスが必要。
  • managerはすべての

• ロールの作成と権限の付与

CREATE ROLE 'read_only';
CREATE ROLE 'full_access';
GRANT SELECT ON company_db.* TO 'read_only';
GRANT ALL PRIVILEGES ON company_db.* TO 'full_access';

• ロールの割り当て

GRANT 'read_only' TO 'employee'@'localhost';
GRANT 'full_access' TO 'manager'@'localhost';

• employeeのロールの有効化
  employee接続時にロールを有効化

SET ROLE 'read_only';

• managerのロールの有効化
  manager接続時にロールを有効化

SET ROLE 'full_access';

MariaDB ロールの注意事項

• ロールはデフォルトでは無効
  • 割り当てたロールを使用するには、SET ROLEで有効化が必要です。
    
• ロールと直接権限の競合
  • ユーザーに直接付与された権限とロールによる権限が競合する場合、どちらも有効になります。
    
• 最小権限の原則
  • セキュリティの観点から不要な権限をロールに含めないようにします。

まとめ

ユーザー権限やロールは、MariaDBでアクセス制御や操作範囲を効率的に管理する手段です。
権限はユーザーごとに細かく設定でき、ロールを利用すれば複数のユーザーに共通の権限を一括で付与・管理可能です。

便利な一方で、最小権限の原則を守り不必要な権限やロールを付与しないことが重要です。また、定期的に権限やロールを監査し不要な設定を削除することでセキュリティリスクを軽減できます。適切な設定により運用効率と安全性の向上を図りましょう。

【MariaDB】ｒｏｏｔユーザー（管理者アカウント）

インストール直後に作成されるMariDBの管理者アカウントです。すべての権限を持ち、通常はローカルホストからのみ接続可能です。

※インストール直後には、mariadb.sysユーザーも作成されますがこれについては後述します。

現在 存在するユーザーは以下のコマンドを使用して確認できます。

SELECT User, Host FROM mysql.user;

C:\>mysql -u root -p
Enter password: ******
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 6
Server version: 11.4.4-MariaDB-log mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> SELECT User, Host FROM mysql.user;
+-------------+-------------+
| User        | Host        |
+-------------+-------------+
| root        | 127.0.0.1   |
| root        | ::1         |
| root        | asroc-win10 |
| mariadb.sys | localhost   |
| root        | localhost   |
+-------------+-------------+
5 rows in set (0.003 sec)

【MariaDB】ユーザーの操作

ユーザーの作成

ユーザーを作成する際の基本的なSQL構文は以下の通りです。

CREATE USER 'ユーザー名'@'ホスト' IDENTIFIED BY 'パスワード';

基本的なユーザーの作成例

• ローカルホストからのみアクセス可能なユーザーを作成。
  このユーザーはMariaDBがインストールされたサーバーからのみ接続可能です。

CREATE USER 'example_user'@'localhost' IDENTIFIED BY 'secure_password';

• 任意のホストからアクセス可能なユーザーを作成。
  @’%’は、どのホストからでも接続を許可する設定です。ただし、セキュリティリスクを伴うため注意が必要です。

CREATE USER 'remote_user'@'%' IDENTIFIED BY 'secure_password';

• 特定のIPアドレスからのみ接続可能なユーザーを作成

CREATE USER 'restricted_user'@'192.168.1.100' IDENTIFIED BY 'secure_password';

ユーザーの削除

ユーザーを削除する際の基本的なSQL構文は以下の通りで、パスワードは不要です

DROP USER 'ユーザー名'@'ホスト';

基本的なユーザーの削除例

• 特定のホストに紐付けられたユーザーの削除

DROP USER 'user1'@'localhost';

• 全ホストからアクセス可能なユーザーの削除

DROP USER 'global_user'@'%';

• 複数のユーザーを同時に削除

DROP USER 'user1'@'localhost', 'user2'@'%';

ユーザーのロック・アンロック（無効化・有効化）

ユーザーの使用を一時的に無効にしたり有効にしたりします。

ユーザーのロック

• アカウントを無効化するには、ACCOUNT LOCKを使用します。

ALTER USER 'username'@'host' ACCOUNT UNLOCK;

ユーザーのアンロック

• アカウントを無効化するには、ACCOUNT UNLOCKを使用します。

ALTER USER 'username'@'host' ACCOUNT UNLOCK;

ユーザー情報の確認

• MariaDBに存在する全ユーザーを確認する。

SELECT User, Host FROM mysql.user;

• 特定ユーザーの詳細情報を確認する。

MariaDB [(none)]> SHOW GRANTS FOR 'test_user1'@'%';

ユーザー有無の確認

• 特定のユーザーが存在するか否かを確認します。

SELECT User, Host FROM mysql.user WHERE User = 'username';

• ユーザーが存在する場合

MariaDB [(none)]> SELECT User, Host FROM mysql.user WHERE User = 'test_user1';
+------------+------+
| User       | Host |
+------------+------+
| test_user1 | %    |
+------------+------+

• ユーザーが存在しない場合

MariaDB [(none)]> SELECT User, Host FROM mysql.user WHERE User = 'username';
Empty set (0.001 sec)

パスワードの管理

パスワードの変更

• 既存ユーザーのパスワードを変更するには、ALTER USER又はSET PASSWORD文を使用します。

ALTER USER 'username'@'host' IDENTIFIED BY 'new_password';

SET PASSWORD FOR 'username'@'host' = PASSWORD('new_password');

• パスワード無しに変更

ALTER USER 'username'@'host' IDENTIFIED BY '';

ユーザー名の変更

MariaDBでは直接ユーザー名を変更することはできませんが次の手順で名前変更が可能です。

CREATE USER 'new_username'@'host' IDENTIFIED BY 'password';

• 既存の権限をコピー

GRANT ALL PRIVILEGES ON *.* TO 'new_username'@'host';

• 古いユーザーを削除

DROP USER 'old_username'@'host';

【MariaDB】mariadb.sysユーザー

MariaDB 10.4以降で追加されたシステムユーザーです。このユーザーは、主に内部的な管理目的で使用されます。

主な特徴

1. 内部管理用ユーザー
   • MariaDBの内部的な操作やパフォーマンススキーマ関連のクエリに使用されます。
   • 管理者や一般ユーザーが直接使用することは想定されていません。
     
     
2. 権限
   • MariaDBが特定の内部処理で必要とする最低限の権限が付与されています。
     
     
3. ホストの制限
   • Host列にlocalhostが設定されており、リモート接続は許可されていません。
     
     
4. セキュリティ
   • MariaDBの内部的な処理以外には使用されないため、通常、追加のセキュリティ対策は不要です。
     
     

使用目的

1. パフォーマンススキーマや情報スキーマのクエリ実行
   • MariaDBの内部でパフォーマンススキーマや情報スキーマに関連するクエリを実行するために使用されます。
     
     
2. メンテナンス操作のサポート
   • 特定の内部プロセスや自動メンテナンスタスクで必要な操作を実行するために利用されます。

まとめ

ユーザー管理においては、最小権限の原則や適切な認証設定、不要なユーザーや権限の削除が重要です。また、定期的な監査やセキュリティ対策を実施し、データベース全体の保護を確実にすることが求められます。

本ブログでは、MariaDBのWindows環境における設定ファイル（my.ini）について、設定例を元に各パラメータの内容や利用シーン、推奨設定を紹介します。

MariaDBの設定ファイルを最適化する理由

MariaDBの設定ファイルは、データベースの動作を細かく制御するために使用されます。

デフォルトでは、通常C:\Program Files\MariaDB XX\data\my.iniに配置されており、設定ファイルの形式はセクション（[セクション名]）とキーと値のペア（キー=値）で構成されます。

MariaDBの設定ファイルを最適化する理由は以下の通りです。

• パフォーマンス向上
• スケーラビリティ強化
• エラー管理の向上
• リソースの効率化
• 安定性の向上

設定ファイルの例

Windows Server上でMariaDBを効率的に運用するための[mysqld]セクションと[client]セクションの設定例を紹介します。

下記はMariaDB11.4を使用する条件で、メモリ16GB・接続人数200人・レコード件数100万件、エラー管理・性能を考慮した設定例です。

下記の設定例を元に内容を紹介していきます。

• [mysqld]セクションの例

[mysqld]
# 基本設定
port = 3306
bind_address = 0.0.0.0
datadir = "C:\Program Files\MariaDB 11.4\data"
socket = "C:\Program Files\MariaDB 11.4\data\mysql.sock"
log_error = "C:\Program Files\MariaDB 11.4\log\mariadb_error.log"

# 接続とスレッド管理
max_connections = 200
thread_cache_size = 64
thread_stack = 256K

# パフォーマンス設定
innodb_buffer_pool_size = 8G
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 1
innodb_io_capacity = 2000
innodb_lock_wait_timeout = 50

# ストレージ管理
tmp_table_size = 128M
max_heap_table_size = 128M
table_open_cache = 4000
query_cache_size = 256M
max_allowed_packet = 64M

# ログ設定
slow_query_log = 1
slow_query_log_file = "C:\Program Files\MariaDB 11.4\log\slow_query.log"
long_query_time = 1
general_log = 0

• [client]セクションの設定例

[client]
# 接続設定
port = 3306
socket = "C:\Program Files\MariaDB 11.4\data\mysql.sock"

# クエリと接続の最大パケットサイズ
max_allowed_packet = 64M

# クエリの簡易化
default-character-set = utf8mb4

#プラグインディレクトリ
plugin-dir="C:\Program Files\MariaDB 11.4/lib/plugin"

[mysqld]セクションの考察

• [mysql]セクションとは
  • MariaDBサーバープロセスの動作を制御するための設定を記述するセクション。

基本設定

1. port = 3306（デフォルト）
   MariaDBがリッスンするポート番号。一般的にデフォルトの3306を使用。ただし、セキュリティ上の理由で変更も可能。
   
   
   
2. bind_address = 0.0.0.0（デフォルト：127.0.0.1）
   接続を受け付けるIPアドレスを指定する。0.0.0.0はすべてのIPから接続を許可するがァイアウォールでIPを制限して安全性を確保します。
   
   bind_address = 0.0.0.0は、複数クライアントや外部接続が必要な場合に便利であり、適切なセキュリティ対策を講じれば安全に運用できます。ただし、セキュリティ要件が厳しい場合は、127.0.0.1または特定のIPアドレスに制限する方が安全です。
   
   
   
3. datadir = “C:\Program Files\MariaDB 11.4\data”（デフォルト）
   データベースのデータを保存するディレクトリのパスを指定します。データ容量の関係やデータをシステムを切り離して管理したい場合等は、他のディレクトリを指定します。
   
   
   
4. socket = “C:/ProgramData/MariaDB/mysql.sock”
   名前付きパイプとして利用されており、ローカルマシン内でのデータ転送が軽減されます。
   例えば、クライアントとMariaDBサーバーが同一ホスト上に存在する場合、この方法が最適です。

接続とスレッド管理

1. max_connections = 200
   条件通り同時接続の上限を200としています。但し、200以上に余裕を持たせる場合もあります。
   
   
   
2. thread_cache_size = 64
   クライアントがMariaDBに接続するたびに、サーバーはスレッドを生成します。接続が終了したスレッドをキャッシュに保存し再利用することでスレッドの生成コストを削減します。
   一般的な推奨値は、最大接続数（max_connections）の25%から50%程度です。
   
   
   
3. thread_stack = 256K
   各スレッドに割り当てるスタックメモリのサイズです。スタックは、関数呼び出しやローカル変数の保存に使用されるメモリ領域です。
   
   thread_stack の値は、MariaDBの運用環境やクエリの複雑さによって異なりまが標準的な設定は256K または 512Kです。

パフォーマンス設定

1. innodb_buffer_pool_size = 8G
   innoDBストレージエンジンが使用するバッファプールのサイズです。テーブルのデータやインデックスがバッファプールにキャッシュされ、ディスクI/Oを減らしてデータベースのパフォーマンスを向上しています。
   
   innodb_buffer_pool_size の値は、サーバーの利用状況やシステムのメモリ容量に基づいて設定しますが、推奨値はサーバー全体のメモリ容量の 50% ～ 75% をです。
   
   
   
2. innodb_log_file_size = 1G
   InnoDB ストレージエンジンで使用されるredoログファイルの1つあたりのサイズを指定します。Redoログはトランザクション中のデータ変更を記録し、クラッシュ時にRedoログを使ってデータの一貫性を確保してトランザクションをリカバリします。
   
   一般的には、バッファプールサイズ（innodb_buffer_pool_size）の25%～50%の範囲が推奨されます。
   
   
   
3. innodb_flush_log_at_trx_commit = 1
   トランザクションのコミット時にRedoログ（トランザクションログ）をディスクに書き込むタイミングを制御する設定です。
   推奨値は１（デフォルト）で、各トランザクションのコミット時に必ずログをディスクにフラッシュします。
   
   
   
4. innodb_io_capacity = 2000
   InnoDB ストレージエンジンのバックグラウンドタスクが1秒間に実行するI/O操作の上限を設定します。値が低いと処理の遅延やスループットの低下を引き起こす場合があります。
   
   適切な値は、使用しているストレージデバイスの性能（I/Oスループット）に大きく依存しますが参考値は以下の通りです。
   
   • HDD（ハードディスクドライブ）
     • 100～200
   • SSD（ソリッドステートドライブ）
     • 2000～10000
   • NVMe SSD
     • 推奨値: 10000～50000
       
       
       
5. innodb_lock_wait_timeout = 50（デフォルト）
   InnoDB ストレージエンジンで、トランザクションがロックを獲得するために待機する最大秒数を指定します。デッドロックが発生する状況を未然に防ぎ、システム全体のスループットを確保します。
   
   
   • 設定の考え方
     
     • 低い値（例: 10～30秒）
       • 利点：ロックが長時間保持される状況を早く検出でき、スループットを改善します。
       • 欠点:：一時的なロック競合が頻発する環境では、タイムアウトが多発してアプリケーション側でのリトライ処理が増える可能性があります。
         
     • 高い値（例: 60～300秒以上）
       • 利点：複雑なクエリやバッチ処理がロック競合を解消するまで待機できます。
       • 欠点：ロック保持が長引くと、他のトランザクションに悪影響を及ぼす可能性があります。

ストレージ管理

1. tmp_table_size = 128M
   クエリ実行中に一時的なデータを格納するために作成されるメモリ内テーブルの最大値を指定します。この値を超えた場合一時テーブルはディスク上に作成されため、パフォーマンスに影響を与える可能性があります。
   
   • 設定値の考え方
     
     • 小規模なシステム（8GB以下のメモリ）
       • 推奨値: 16MB ～ 32MB
     • 中規模なシステム（16GB以上のメモリ）
       • 推奨値: 64MB ～ 256MB
     • 大規模なシステム（32GB以上のメモリ）
       • 推奨値: 256MB ～ 1GB
         
         
         
2. max_heap_table_size = 128M
   メモリ内で作成されるHEAP（MEMORY）ストレージエンジンのテーブルの最大サイズを定義するパラメータです。この値を超えると新しいデータを追加できなくなりエラーが発生します。
   
   • 設定値の考え方
     
     • 小規模システム（メモリ 8GB以下）
       • 32MB ～ 64MB
     • 中規模システム（メモリ 16GB以上）
       • 128MB ～ 256MB
     • 大規模システム（メモリ 32GB以上）
       • 256MB ～ 512MB
         
         
         
3. table_open_cache = 4000（デフォルト）
   サーバー全体で同時にキャッシュできる「開いているテーブル」の最大数を指定します。このキャッシュは、テーブルを効率的に再利用することでディスクアクセスを減らし、パフォーマンスを向上させます。
   
   • 設定の考え方
     
     • 小規模システム（10～50ユーザー）
       • 推奨値: 1000 ～ 4000
     • 中規模システム（50～200ユーザー）
       • 推奨値: 4000 ～ 8000
     • 大規模システム（200ユーザー以上）
       • 8000 ～ 20000
         
         
         
4. query_cache_size = 256M（デフォルト：0）
   クエリ結果キャッシュするサイズを指定します。この値が設定されていると、クエリ結果が一時的にキャッシュされ、同じクエリが繰り返し実行された場合に、再計算する必要がなくなります。
   
   • 設定値の考え方
     
     • 小規模システム
       • 32M ～ 256M
     • 中規模システム
       • 256M ～ 512M
     • 大規模システム
       • 1G ～ 2G 以上
         
         
         
5. max_allowed_packet = 64M（デフォルト：16M）
   データの最大送信サイズを制御するためのパラメータです。この値が設定されていると、クライアントからサーバーに送信できる最大データサイズを制限します。
   
   • 設定値の考え方
     
     • 小規模システム:
       • 16MB ～ 64MB
     • 中規模システム:
       • 64MB ～ 256MB
     • 大規模システム
       • 256MB ～ 1024MB 以上

ログ設定

1. slow_query_log = 1（デフォルト：0）
   実行時間が遅いクエリをログに記録するか否かを設定です。この設定を有効にすると特定のクエリの実行時間が閾値を超えた場合に、ログファイルに記録されます。
   
   
   
2. slow_query_log_file = “C:\Program Files\MariaDB 11.4\log\slow_query.log”
   実行時間が遅いクエリが記録されるログファイルの場所を指定します。
   
   
   
3. long_query_time = 1
   ログに記録する遅いクエリ実行時間のしきい値を秒数で指定します。監視、トラブルシューティング、パフォーマンス最適化のために使用されます。
   
   • 設定値の考え方
     
     • 小規模システム:
       • OFF ～ 1 秒
     • 中規模システム:
       • 1 ～ 10 秒
     • 大規模システム
       • 10 秒以上
         
         
         
4. general_log = 0（デフォルト）
   すべてのクエリをログに記録するか否かを設定します。この設定を有効にすると、サーバー上で実行されるすべてのクエリ（SELECT、INSERT、UPDATE、DELETEなど）がログファイルに記録されます。
   エラー発生時や特定のクエリの詳細情報を収集する際に使用されます。

[client]セクションの紹介

接続設定

1. port = 3306
   複数のMariaDBサーバーがある場合異なるポートを使用するケースがあるため、接続先のportを明確にする為記述しています。
   
   
   
2. socket = “C:\Program Files\MariaDB 11.4\data\mysql.sock”
   Windows サーバー など、リモートアクセスが少ない環境では、ネットワークのオーバーヘッドを減らすためにソケット接続が使用されます。socketを指定する事により、クライアントがローカルソケットを通じてMariaDBサーバーに接続するように指示します。
   

クエリと接続の最大パケットサイズ

1. max_allowed_packet = 64M（デフォルト推奨値）
   1つのネットワークトランザクションやクエリ処理中にサーバーが受信できる最大のデータサイズ（バイト数）を指定します。
   大量のデータを一度に送信する際に、クライアントが制限内に収まることで通信の安定性が向上し、エラーやデータ損失、パフォーマンス低下を防ぐ効果があります。
   

クエリの簡易化

• default-character-set = utf8mb4
  クライアントがMariaDBサーバーに接続した際に使用する文字セットを指定します。utf8mb4 は、多言語データ（例えば、日本語、韓国語、絵文字など）の取り扱いに対応しており、UTF-8 よりも多くの文字をサポートしています。

プラグインディレクトリ

• plugin-dir=”C:\Program Files\MariaDB 11.4/lib/plugin”
  MariaDBサーバーがプラグインファイルを探すディレクトリを指定します。設定されたディレクトリ内にプラグインのバイナリファイル（通常は .dll や .so ファイル）が格納されており、サーバーはそのファイルをロードします。

その他の主な[セクション]

[mariadbd] セクション

• 用途
  • MariaDB 10.5以降で追加されたセクションで、MariaDB専用のサーバープロセス（mariadbd）を設定する。
    
    
• 特徴
  • MariaDB専用のセクションであり、MySQLでは無視される。
    
    

[mariadb] セクション

• 用途
  • MariaDB全体に適用される汎用設定で、特定のコンポーネント（クライアントやサーバー）に依存しない、MariaDB専用の設定を記述する。
    
    
• 特徴
  • MariaDBの拡張機能やプラグインに関連した設定を行うのに適している。
    
    

[server] セクション

• 用途
  • MariaDBやMySQLのサーバー共通設定。特定のプロセスセクション（[mysqld]や[mariadbd]）に依存せず、広く適用される。
    
    
• 特徴
  • MariaDBとMySQLの両方で使用可能。
    
    

MariaDB設定の最適化のポイント

1. 利用状況に応じた調整
   使用するアプリケーションの特性に合わせてパラメータを設定します。
   
   
2. リソースの有効活用
   メモリやディスクI/Oを効率的に活用するため、innodb_buffer_pool_sizeやtmp_table_sizeを適切に設定。
   
   
3. セキュリティ
   本番環境ではbind-addressを適切に設定し、不要なリモートアクセスを防ぎます。
   
   

MariaDBとMySQLの関係

MariaDBはMySQLからフォーク（分岐）したオープンソースのデータベース管理システム（RDBMS）です。

MySQLがオラクル（Oracle Corporation）に買収された後、MySQLの創設者がMySQLのオープン性を守るために作られたデータベースです。

MySQLからMariaDBへ移行する利点

1. オープンソースの完全性
   GPLライセンスに基づく完全なオープンソースです。商用ライセンスに依存しません。
   
   
2. 高速なパフォーマンス
   特定のクエリやストレージエンジンでMySQLよりも高速な処理が可能です（例: AriaやTokuDB）。
   
   
3. 拡張機能
   新しい機能が追加されています（例: 仮想列、JSON対応の拡張、分散SQL機能など）。
   
   
4. より多くのストレージエンジン
   MariaDBは多様なストレージエンジン（例: Aria, TokuDB, ColumnStoreなど）をサポートしています。

以上の様にオープンソース性/拡張性/パフォーマンス/互換性の観点で優位性がある点がメリットです。

MySQLからMariaDBへの移行環境

1. OS
   Windows 10 Pro 22H2
2. Mysql
   Server version: 8.0.40
3. MariaDB
   Server version: 11.4.4-MariaDB

MySQLからMariaDBへの移行方法

本ブログではユーザーデータベースを移行しシステムデータベースはMariaDBを使用します。

• システムデータベースも移行しようとしたのですが、私の場合、Mysqlのdumpファイル内に不具合があったり、MariaDBがサポートしていない部分が有ったして、リストア時にエラーが散発しました。その為、ユーザーデータのみの移行方法を紹介します。

MySQL設定情報の確認

MySQLの以下の項目の内容を確認しておきます。確認の方法は以降で紹介します。

1. SQLモード（sql_mode）の設定
2. 使用しているストレージエンジン
3. gtid_mode（GTIDの使用）
4. ユーザー情報の取得 —– 今回は（MariaDB）で再作成するので権限等詳細に調査して下さい
5. 設定ファイルの確認と移行

MySQL ユーザーデータベースのバックアップ

今回はユーザー情報や権限等は新規に作成するつもりなので、ユーザーデータベースとストアドプロシージャ、イベント等をバックアップします。

但し、移行の失敗に備えてMySQLの全てのバックアップも取得しておきます。

C:\>mysql --version
mysql  Ver 8.0.40 for Win64 on x86_64 (MySQL Community Server - GPL)

C:\>mysqldump --version
mysqldump  Ver 8.0.40 for Win64 on x86_64 (MySQL Community Server - GPL)

-- ユーザーデータベースのバックアップ
C:\>mysqldump -u root -p --databases testdb --routines --events --triggers --single-transaction --complete-insert --column-statistics=0 --set-gtid-purged=OFF --default-character-set=utf8mb4 > C:\Users\testuser\bkup\backup.sql
Enter password: ******

-- 全データベースのバックアップ
C:\>mysqldump -u root -p --all-databases --routines --events --triggers --single-transaction --complete-insert --column-statistics=0 --set-gtid-purged=OFF --default-character-set=utf8mb4 > C:\Users\testuser\bkup\backup_all.sql

1. –set-gtid-purged=OFF
   GTIDはレプリケーションの管理を簡単にするために使用されます。MariaDBとは完全な互換性は無い為、レプリケーションを使用していてもここではMySQLのGTID情報はバックアップに含めていません。
   
   
2. –column-statistics=0
   ServerもmysqldumpもVer. 8.0 なのでカラム統計情報（column statistics）はサポートされている筈ですが、警告メッセージ（Warning: column statistics not supported by the server.）が表示されたので表示しないようにしました。　

ＭySQL 文字セットと照合順序のデファオルト値確認方法

下記コマンドで確認しておきます。

mysql> SHOW VARIABLES LIKE 'character_set%';
+--------------------------+---------------------------------------------------------+
| Variable_name            | Value                                                   |
+--------------------------+---------------------------------------------------------+
| character_set_client     | cp932                                                   |
| character_set_connection | cp932                                                   |
| character_set_database   | utf8mb4                                                 |
| character_set_filesystem | binary                                                  |
| character_set_results    | cp932                                                   |
| character_set_server     | utf8mb4                                                 |
| character_set_system     | utf8mb3                                                 |
| character_sets_dir       | C:\Program Files\MySQL\MySQL Server 8.0\share\charsets\ |
+--------------------------+---------------------------------------------------------+
8 rows in set, 1 warning (0.00 sec)

mysql> SHOW VARIABLES LIKE 'collation%';
+----------------------+--------------------+
| Variable_name        | Value              |
+----------------------+--------------------+
| collation_connection | cp932_japanese_ci  |
| collation_database   | utf8mb4_0900_ai_ci |
| collation_server     | utf8mb4_0900_ai_ci |
+----------------------+--------------------+
3 rows in set, 1 warning (0.01 sec)

mysql>

バックアップデータの修正

1. 文字セットと照合順序のデファオルト値確認方法
   ＭySQLのサーバーでは「utf8mb4_0900_ai_ci」が使用されています。「utf8mb4_0900_ai_ci」はMariaDBではサポートされていないので、バックアップデータ内の全てのutf8mb4_0900_ai_ciをutf8mb4_general_ciに変更します。

• 例）変更前

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `testdb` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ /*!80016 DEFAULT ENCRYPTION='N' */;

• 例）変更後

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `testdb` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci */ /*!80016 DEFAULT ENCRYPTION='N' */;

MariaDBのインストール

MySQL（本番環境）が動作しているサーバーとは別の機器に推奨するMariaDBのバージョンをインストールします。インストール方法は下記ブログを参考下さい。

【参考ブログ】：MariaDBのインストール

ＭyＳQLバックアップデータのリストア

リストア先のデータベースを作成します。

MariaDB [(none)]> create database testdb;
Query OK, 1 row affected (0.010 sec)

MariaDB [(none)]>

mysqlコマンドを使用して、バックアップファイルを指定したデータベースにリストアします。

C:\>mysql -u root -p testdb < C:\Users\Cool_Kabachan\bkup\backup.sql
Enter password: ******

リストア結果の確認

下記の内容を確認するとデータベースは正しくリストアされています。

MariaDB [testdb]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| testdb             |
+--------------------+
5 rows in set (0.003 sec)

MariaDB [testdb]> use testdb
Database changed
MariaDB [testdb]> show tables;
+------------------+
| Tables_in_testdb |
+------------------+
| users            |
+------------------+
1 row in set (0.001 sec)

MariaDB [testdb]> select * from users;
+----+--------------+--------------------------+
| id | username     | email                    |
+----+--------------+--------------------------+
|  1 | john_doe     | john.doe@example.com     |
|  2 | jane_smith   | jane.smith@example.com   |
|  3 | alice_wonder | alice.wonder@example.com |
+----+--------------+--------------------------+
3 rows in set (0.001 sec)

MariaDB [testdb]>

【1】SQLモード（sql_mode）の設定

MySQLやMariaDBのサーバーでSQLの構文や動作を制御する設定のことです。
SQLモードを移行後も維持する場合は、MySQLとMariaDBでのsql_modeの違いを確認し、必要に応じて調整するします。

SQLモード（sql_mode）が異なる事によって発生する問題

1. データの整合性が保たれない
2. クエリが異なる結果を返してアプリケーションの動作に影響を与える可能性がある。

SQLモード（sql_mode）の確認方法

• MySQL8.0

mysql> SHOW VARIABLES LIKE 'sql_mode';
+---------------+-----------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                                 |
+---------------+-----------------------------------------------------------------------------------------------------------------------+
| sql_mode      | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+---------------+-----------------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.01 sec)

mysql>

• MariaDB11.4

ariaDB [(none)]> SHOW VARIABLES LIKE 'sql_mode';
+---------------+-------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                     |
+---------------+-------------------------------------------------------------------------------------------+
| sql_mode      | STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+-------------------------------------------------------------------------------------------+
1 row in set (0.002 sec)

SQLモード（sql_mode）

今回は相違点を下記のように変更します。

• ONLY_FULL_GROUP_BY
  MySQL では、ONLY_FULL_GROUP_BY が有効だと、GROUP BY に指定されていない非集約カラムが SELECT 句に含まれるとエラーになりますが、MariaDBではエラーにならない場合がありあります。テストをして確認する必要がありますが、MariaDBに設定する事とします。
  
  
• NO_ZERO_IN_DATE,NO_ZERO_DATE
  日付の０を含まなようにする設定です。MySQLとの互換性を保つ為、MariaDBにも設定します。

SQLモード（sql_mode）設定方法

MariaDBの「my.ini」に以下の様に追加します。

[mysqld]
　・
sql_mode=ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

【２】使用しているストレージエンジンの違い

ストレージエンジンとは、MariaDBがデータを保存し操作する方法を決定するモジュールです。テーブルごとに異なるストレージエンジンを設定できるため、用途に応じた柔軟なデータ管理が可能です。

ストレージエンジンが異なる事によって発生する問題

1. 特定のストレージエンジンでしか動作しない機能を使用している場合、移行後にエラーが発生する。
   
   
2. 代替ストレージエンジンに自動変更され、パフォーマンスや動作が変わる可能性がある。
   
   
3. データ移行時、移行が途中で停止したりデータが一部失われる

ストレージエンジンの確認方法

• MySQL 8.0

SELECT TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'testdb';
+------------+--------+
| TABLE_NAME | ENGINE |
+------------+--------+
| users      | InnoDB |
+------------+--------+
1 row in set (0.00 sec)

mysql>

• MariaDB 11.4

MariaDB [(none)]> SELECT TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'testdb';
+------------+--------+
| TABLE_NAME | ENGINE |
+------------+--------+
| users      | InnoDB |
+------------+--------+
1 row in set (0.008 sec)

MariaDB [(none)]>

MySQLのストレージエンジンがMariaDBでサポートされていない場合

この場合はMariaDBの適切なエンジンに変更する必要があります。

• MySQLからMariaDBへの移行時にサポートされていないエンジン
  • MyISAM → MariaDBではInnoDBやAriaなどのエンジンに変更する必要があります。
  • HEAP → MariaDBでは利用できません。

例）MyISAMテーブルをInnoDB に変更する方法

ALTER TABLE my_table ENGINE = InnoDB;

• 注意点
  • エンジン変更中はテーブルがロックされます。
  • データサイズが大きい場合、時間がかかる可能性があります。
    

【３】gtid_mode（GTIDの使用）

GTID は、分散環境でのレプリケーションを管理しやすくするために、トランザクションごとに一意の識別子を割り当てる仕組みです。

しかし、MariaDBとは完全な互換性は無い為レプリケーションを使用していてもGTID情報はバックアップに含めていませんでした。

MariaDBでGTIDを使用する場合は、MariaDBで設定します。

gtid_modeの設定が異なる事によって発生する問題

1. レプリケーションが失敗する可能性がある
   
   
2. レプリケーションパフォーマンスの低下
   
   
3. 複数のトランザクションが同じデータにアクセスし、データの一貫性や整合性が損なわれる可能性がある

【４】ユーザー情報の取得と設定

MySQLでのユーザー情報の取得

下記のようにしてmysql.userテーブルから詳細なユーザー一覧と権限を取得します。

• ユーザー一覧の取得

mysql> SELECT user,host,plugin,authentication_string,ssl_cipher FROM mysql.user;
+------------------+-----------+-----------------------+------------------------------------------------------------------------+------------------------+
| user             | host      | plugin                | authentication_string                                                  | ssl_cipher             |
+------------------+-----------+-----------------------+------------------------------------------------------------------------+------------------------+
| test_user        | %         | mysql_native_password | *A0F874BC7F54EE086FCE60A37CE7887D8B31086B                              | 0x                     |
| mysql.infoschema | localhost | caching_sha2_password | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | 0x                     |
| mysql.session    | localhost | caching_sha2_password | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | 0x                     |
| mysql.sys        | localhost | caching_sha2_password | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | 0x                     |
| root             | localhost | mysql_native_password | *B9369488AFF3B0F0455CF44AB022B7ABDE6F9761                              | 0x                     |
+------------------+-----------+-----------------------+------------------------------------------------------------------------+------------------------+
5 rows in set (0.00 sec)

• 権限の取得
  下記のように各ユーザー毎に権限を確認します。

mysql> SHOW GRANTS FOR 'test_user'@'%';
+------------------------------------------------------+
| Grants for test_user@%                               |
+------------------------------------------------------+
| GRANT USAGE ON *.* TO `test_user`@`%`                |
| GRANT ALL PRIVILEGES ON `users`.* TO `test_user`@`%` |
+------------------------------------------------------+
2 rows in set (0.00 sec)

mysql>

MariaDBでのユーザー追加と権限の設定

MySQLで確認したユーザーと権限をMariaDBで設定します。

【５】設定ファイルの確認

MySQLで設定されている項目がMariaDBに無かった場合等は、MariaDBの設定ファイルに追加/変更して下さい。

十分なテストを実施する

十分なテストを実施し不具合が無い事を確認してから本番環境に切り替えて下さい。

まとめ：移行を成功させるために

MySQLからMariaDBへの移行を成功させるために重要なポイントを以下に簡潔にまとめます。

• 移行可能なバージョンの互換性を確認する
  • 例）MySQL 8.0 → MariaDB 10.5以降。
    
    
• データと構成のバックアップ
  • 移行前にすべてのデータをmysqldumpでバックアップし設定ファイルも保存する
    
    
• SQLモードの確認
  • MySQLとMariaDBのSQLモード（例: STRICT_TRANS_TABLES, ONLY_FULL_GROUP_BY）の違いを確認し、必要に応じて調整する
    
    
• 認証プラグインの確認　—– ユーザーデータしか移行していない為、今回は対象外
  • MySQL 8.0の**caching_sha2_passwordはMariaDBで非対応のため、mysql_native_password**に切り替える。
    
    
• ストレージエンジンの互換性を確認する
  • MariaDBでサポートされないエンジン（例: MySQLのNDB）を使用していないか確認。
  • 必要に応じてInnoDBやAriaに変更。
    
    
• GTID（グローバルトランザクションID）対応
  • MySQLとMariaDBのGTIDは互換性がないため、必要なら無効化する。
    
    
• 特定機能の互換性確認
  • ストアドプロシージャ、トリガー、イベントなどがMariaDBで動作するか十分テストする。
    
    
• 確実なテスト後の移行
  • 開発環境またはステージング環境で移行テストを実施し、パフォーマンスや互換性を確認する。
    
    
• 移行後の動作検証
  • アプリケーションやクエリの互換性を確認。
  • ログやエラーをチェックして問題を修正。
    
    
    

以上を実施し確実な移行を実施して下さい。

1. パフォーマンスの最適化
2. データの整合性と信頼性の向上
3. 特殊な要件に応じた柔軟な対応
4. リソース利用の最適化
5. アプリケーション要件への適合

適切なストレージエンジンを選択し効果的に使用することは、データベースの設計や運用の成功に不可欠です。

【MariaDB】ストレージエンジンとは？

ストレージエンジンとはデータベースがデータを保存/管理/操作する方法を決定する仕組みです。簡単に言うと、「データをどのように保存して、どう扱うかを決める機能」のことです。

例えばデータベースを普通のノートに例えると、ストレージエンジンは「どんなルールで書くかを決めるツール」の事を言います。

• 罫線付きのノートとして書く（1ページに書ける量が決まっている）
  → 書きやすく整理整頓しやすいけど、柔軟性は少ない。
  
• 白紙のノートとして書く（どんな形式でも自由に書ける）
  → 書く自由度が高いけど、整理しにくいかもしれない。

【MariaDB】ストレージエンジンがある理由は？

データの保存や利用方法は場面ごとに違います。
例えば、

• お店の在庫データ → 正確さと信頼性が必要
• SNSの投稿データ → 検索速度が重要
• 一時的なメモ → 高速で軽い仕組みが必要

こうした用途に合わせて、最適な保存方法を選ぶためにストレージエンジンがあります。

【MariaDB】ストレージエンジンの特徴と用途

InnoDB（最も使用頻度が高い）

• 主な特徴:
  トランザクションに対応。行レベルロック/外部キーをサポートしていて、高い信頼性とパフォーマンスを持つ。
• 用途:
  Webアプリケーションやビジネスシステムなど、データ整合性が重要な環境。

MyISAM

• 主な特徴:
  非トランザクション型。読み取り性能が高速で軽量。外部キーはサポートされない。
• 用途:
  主に読み取りが多いシステムやログ解析。
  データ整合性よりもパフォーマンスを優先する場面。

Aria

• 主な特徴:
  クラッシュセーフで、MyISAMの改良版。
  MariaDBの内部処理（例えば一時テーブルや権限管理）で頻繁に使用。
• 用途:
  一般ユーザーが直接選択することは少ないが、内部一時テーブルや権限テーブルで一時的に使用される。

MEMORY

• 主な特徴:
  データがメモリ上に保存され、高速アクセスが可能。再起動するとデータが消える。
• 用途:
  キャッシュやセッション管理、短期間だけ必要なデータ処理。

SEQUENCE

• 主な特徴:
  特定の範囲で連続した値を生成する仮想テーブル。高速かつ効率的。
• 用途:
  テストデータ生成、数値の範囲指定やループ処理。

CSV

• 主な特徴:
  テーブルをCSVファイルとして保存。非常にシンプルで互換性が高い。
• 用途:
  データのインポート/エクスポート、外部システムとの連携。

MRG_MyISAM

• 主な特徴:
  同じ構造のMyISAMテーブルを1つの仮想テーブルとして統合。書き込みはできず、読み取り専用。
• 用途:
  分割されたデータの統合、ログ管理。

PERFORMANCE_SCHEMA

• 主な特徴:
  データベースのパフォーマンス監視に特化。内部統計を保持。
• 用途:
  管理者がパフォーマンス分析やデバッグで使用。

ストレージエンジンの指定方法

MariaDBで使用するストレージエンジンは、テーブル作成時に指定します。デフォルトのストレージエンジンはInnoDBですが、他のエンジン（例えば、MyISAMやAria）を使用したい場合は、テーブル作成時に明示的に指定します。

テーブル作成時にエンジンを指定する方法

CREATE TABLE文で、ENGINEオプションを使用して指定します。

例１： InnoDBエンジンを使用する場合（デフォルト）

CREATE TABLE users (
    id INT PRIMARY KEY,
    username VARCHAR(50),
    email VARCHAR(100)
) ENGINE=InnoDB;

例２：MyISAMエンジンを使用する場合

CREATE TABLE users (
    id INT PRIMARY KEY,
    username VARCHAR(50),
    email VARCHAR(100)
) ENGINE=MyISAM;

例３： Ariaエンジンを使用する場合

CREATE TABLE users (
    id INT PRIMARY KEY,
    username VARCHAR(50),
    email VARCHAR(100)
) ENGINE=Aria;

既存のテーブルのエンジンを変更する方法

すでに作成されているテーブルのストレージエンジンを変更するには、ALTER TABLE文を使用します。

ALTER TABLE users ENGINE = InnoDB;

デフォルトのストレージエンジンを変更する方法

MariaDBの設定ファイル（my.cnfまたはmy.ini）で、デフォルトのエンジンを変更することもできます。例えば、MyISAMをデフォルトエンジンに設定するには、以下のように設定します。

[mysqld]
default-storage-engine = MyISAM

その後、MariaDBを再起動すると、新しく作成されるテーブルが指定したエンジンを使用するようになります。

まとめ

ストレージエンジンは、データベース内のデータがどのように格納されるかを決定します。例えば、データがどのようにディスク上に書き込まれるか、トランザクションがどのように管理されるか、検索や更新がどのように最適化されるか、などです。ストレージエンジンの選択により、パフォーマンス、信頼性、セキュリティ、機能性が大きく異なります。

よって、適切なストレージエンジンを選択し効果的に使用することは、データベースの設計や運用の成功に不可欠といえます。

MariaDBとは？

MariaDBは、オープンソースのリレーショナルデータベース管理システム（RDBMS）で、高速性/信頼性/スケーラビリティ¹を備えています。MySQL²からフォーク（分岐）されたプロジェクトであり、同じSQLインターフェースを持ちながらも、独自の機能が追加されています。

MariaDBのインストール（Windows編）

MariaDB インストーラーのダウンロード

公式サイトからインストーラー（最新の安定版）をダウンロードし、実行してインストールします。

インストール環境（2024年12月現在）

• Windows 10 22H2
• MariaDB Version 11.4.4 ｘ84-64

公式サイト：https://mariadb.org/

公式サイトの初期画面で「Download」をクリック

2024年12月現在では「MariaDB Server 11.6.2 Rolling」というバージョンが標準で表示されますが、下の赤枠には「これはローリングリリースです。リリース時点で、最新の長期リリースはMariaDB 11.4であり、5年間保守されます。」と表示されています。

本番環境で運用する場合は「安定板で５年間保守される最新バージョン」をインストールします。

ここではリリース形式³がＧA版ではあるものの安定版である「バージョン11.4.4」のインストーラーをダウンロードします。

バージョン11.4.4を選択し「Download」ボタンをクリックしてインストーラーをダウンロードします。

ダウンロード完了後に「MariaDBアカウント」作成画面が表示されます。アカウントを作成するとダウンロードリリース通知や製品の更新情報などを受け取ることができます。

ここではアカウントを作成しないでインストール作業に進みます。

MariaDB インストーラーの実行

下記はダウンロードフォルダ内のインストーラーです。msi形式なのでダブルクリックしてインストールします。

セットアップウィザード開始画面

• 「Next」ボタンをクリックします。

「エンドユーザーライセンス契約」確認画面

• 同意する（□I accept the terms in the License Agreement）にチェックを入れ「Next」ボタンをクリックします。MariaDBはライセンス契約に「GNU GENERAL PUBLIC LICENSE(GPL)⁴」を適用しています。

「デフォルトプロパティ」設定画面（1/2）

• ①管理者ユーザー「root」パスワードの設定
  　パスワードを設定します。確認のため２回入力して下さい。
  
  
• ②リモートで「root」を使用できるようにするか？
  　ここでは必要が無いので✔は入れません。もし必要な場合は✔を入れて下さい。
  
  
• ③「UTF8」をデフォルト文字セットとして使用するか？
  ここでは✔をいれます。UTF-8は、多言語や絵文字を含むアプリケーションで広く利用される推奨設定です。
  
  
• ④「インストール先フォルダ」の指定画面
  特に理由が無ければこのままでOKです。変更したい場合は「Browse…」で変更します。
  
  

設定が完了したら「Next」ボタンで次へ進みます。

「デフォルトプロパティ」設定画面（2/2）

• ①「Enable networking」外部からの接続許可画面
  　外部（社内LAN等）からの接続を許可するか否かを指定します。
  　ローカルで使用する場合は不要ですが通常は✔を入れます。又、通信時に使用するポートは
  　特別な理由が無い限りデフォルト（3306）にしておいて下さい。
  
  
• ②「デフォルトストレージエンジンInnoDB⁵」の設定画面
  　Buffer pool size：データとインデックスをメモリ上に保持するための領域
  　Page size：データとインデックスを格納するために使用する基本的なメモリ領域のサイズ
  
  

Page sizeはデータの読み書きやメモリ管理の効率に影響を与えますが、両方とも良く分からない場合はそのまま「Next」で次に進みます。

インストール実行画面

• 「Install」ボタンをクリックしてMariaDBをインストールします。

インストール完了画面

• 「Finish」ボタンをクリックしてインストールを終了します。

MariaDB インストール後のフォルダ構成

MariaDB 11.4.4 のフォルダ構成は以下のようになっています。

MariaDBの動作確認

スタートメニューからMySQL Client を起動しMariaDBが正常に動作するか確認します。

rootのパスワードを入力して接続し、「show databases;」（SQL)で現在 存在しているデータベースを表示します。データベースが表示されればローカルでの動作確認は完了です。

Enter password: ******
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 4
Server version: 11.4.4-MariaDB mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
4 rows in set (0.001 sec)

MariaDB [(none)]>

MariaDB サービスへの登録確認

「スタート」→「Windows管理ツール」→「サービス」でサービス一覧を表示します。下図のように「MariaDB」が登録されていて、スタートアップの種類が「自動」になっていればOKです。

HeidiSQL によるMariaDB 動作確認

HeidiSQLは、MariaDBやMySQL、PostgreSQLなどのデータベースを簡単に管理・操作するためのGUIツールです。HeidiSQLはMariaDBをインストールすると同時にインストールされます。

HeidiSQLをダブルクリックして起動します。①「新規」ボタンで②「ローカルMariaDBへ接続」し③rootの「パスワード」を入力して、④「開くボタン」をクリックします。
下図のようにデータベースが表示されれば動作確認は終了です。

まとめ

MariaDBは軽量なデータベース管理システムでありながら柔軟性とコスト効率の良さから、多くの業界で採用されています。
又、オープンソースコミュニティと企業サポートの両方から支えられて、現在も積極的に開発が進行しており長期的に信頼できるデータベースとして、これからも多くのユーザーや企業に採用され続けていくでしょう。

このようなRDBMSを学習して習得する事は、今後のあなたの業務においても必ずプラスになります。
これからも一緒に学習していきましょう。

脚注

1. スケーラビリティ
   システムや機器、ソフトウェアなどが規模や利用負荷の増大に対応できる能力や度合いを指します。日本語では「拡張性」「拡張可能性」を意味します
   
   ↩︎
2. MySQL
   MySQLは、1995年にスウェーデンのソフトウェア企業 MySQL AB によって開発されました。
   初期のバージョンから、SQL（Structured Query Language）をサポートし、簡単にデータ操作が行えることが特徴でした。
   その後、MySQLは成長を続け、2008年にアメリカのOracle Corporationによって買収され、この買収を機にMariaDBが分岐して開発されることとなりました。
   
   ↩︎
3. リリース形式
   ①MariaDB Sever 11.8.0 Preview
   　正式リリース前のテスト段階にあるバージョン
   
   ②MariaDB Sever 11.6.2 Rolling
   　ローリングリリース（Rolling Release）**モデルを採用していることを意味します。
   　このモデルでは、ソフトウェアの更新が連続的に行われ、新しいバージョンが定期的に
   　リリースされるのではなく、常に最新の機能や修正がユーザーに提供されます。
   
   ③MariaDB Sever 11.7.1 RC Rolling
   　「リリース候補」であり、同時に「ローリングリリース」モデルで提供されていることを
   　示します。このバージョンは正式リリース前に機能や安定性を最終的に調整するために
   　公開され、ユーザーに頻繁にアップデートを提供する形になります。
   
   ④MariaDB Sever 11.4.4
   　GA（General Availability）リリースです。GA（General Availability）リリースは
   　一般ユーザー向けに公開され、製品が安定していることを示しますが、
   　LTS（Long Term Support）リリースと同じレベルでの長期的なサポートが
   　保証されているわけではありません。
   
   ↩︎
4. GNU GENERAL PUBLIC LICENSE(GPL)
   （GNU一般公衆利用許諾契約書）は、フリーソフトウェア財団（Free Software Foundation、FSF）が定めた、フリーソフトウェアの使用、コピー、配布、改変に関するライセンスの一種です。
   
   GPLは、ソフトウェアを自由に使い、学び、改良し、配布する権利をユーザーに与えることを目的としています。GPLは、特にソフトウェアの自由（free software）を保障するライセンスとして広く知られています。
   
   ↩︎
5. デフォルトストレージエンジンinnodbの設定
   MariaDBには処理に最適化されたストレージエンジンがあります。標準のエンジンはinnodbで高信頼性が求められるトランザクション重視のアプリケーションで、金融システム/eコマースなどで使用されます。 ↩︎