ServBay MariaDB/MySQL パッケージトラブルシューティングガイド

概要

MariaDBおよびMySQLは、業界をリードするオープンソースのリレーショナルデータベース管理システムであり、多くのWebアプリケーションやビジネスシーンに広く利用されています。ServBayはmacOSおよびWindows環境で複数バージョンのMariaDB/MySQLパッケージを統合し、開発者にとって便利かつ高効率なローカルデータベース環境を提供します。安定性に優れていますが、開発・運用時にパッケージが起動しない・接続できない・パフォーマンスが低下するなどの問題が発生する場合もあります。

本ガイドでは、ServBayユーザーがMariaDB/MySQLパッケージの一般的なトラブルを診断・解決するための方法を解説します。代表的な問題・診断手順・解決策、ServBay環境固有のパスやコマンドも記載しています。

重要事項：

設定やデータを変更する前に、必ずデータベースのバックアップを取ってください！ServBayにはバックアップ機能が内蔵されており、定期的なバックアップを強く推奨します。
コマンドやパスの例で特定のバージョン（例: 11.3や11.5）を示していますが、実際に使用するServBayのMariaDB/MySQLのバージョンに置き換えてください。利用中のバージョンはServBay画面で確認できます。
コマンド例の<username>、<database>、<your_backup.sql>はプレースホルダーです。ご自身のユーザー名・データベース名・バックアップファイル名などに置き換えてください。
macOS/Windows両対応の内容で、OSごとに適したパスやコマンド例を記載しています。

基本的な診断手順

詳細な問題調査の前に、まず以下の基本チェックを実施ください：

ServBayパッケージの状態確認： ServBayの画面で対象MariaDB/MySQLのバージョンが「稼働中」であることを確認します。また、コマンドラインでも確認できます：
bash
```
servbayctl status mariadb <version>
# 例：MariaDB 11.3の状況確認
servbayctl status mariadb 11.3
```
1
2
3
ServBayアプリのログ確認： ServBayがパッケージの起動や制御に失敗した場合、エラーログが記録されます。ServBay画面のログや、主ログファイルを確認してください。
MariaDB/MySQLエラーログ確認： データベースパッケージの起動失敗・ランタイムエラーの特定には、エラーログの確認が最重要です。代表的パスは以下の通りです。
macOS:
bash
```
/Applications/ServBay/logs/mariadb/<version>/<version>.err
# MariaDB 11.3の最新50行ログ確認
tail -n 50 /Applications/ServBay/logs/mariadb/11.3/11.3.err
```
1
2
3
Windows:
cmd
```
C:\ServBay\logs\mariadb\<version>\<version>.err
# MariaDB 11.3の最新50行ログ確認
powershell "Get-Content -Path 'C:\ServBay\logs\mariadb\11.3\11.3.err' -Tail 50"
```
1
2
3
ログ末尾のエラーメッセージから直接原因が特定できることが多いです。

よくある問題とその解決策

1. 接続エラー：`SQLSTATE[HY000] [2002] No such file or directory`

これは、クライアントがUnixソケットファイルを通してMariaDB/MySQLサーバーへ接続できない場合に発生します。macOSではUnixソケットはローカルプロセス同士の高速通信に使われます。アプリやコマンドが指定したソケットファイルを見つけられない場合、このエラーになります。

主な原因と対策：

MariaDB/MySQLパッケージが起動していない:
- ServBay画面またはservbayctl status mariadb <version>コマンドで稼働中か確認してください。
- 稼働していなければ、servbayctl start mariadb <version>で起動を試し、.errログで失敗原因を調査してください。
ソケットファイルのパス不一致（macOS/Linuxのみ）:
- クライアントが接続に使うソケットパスと、サーバー側my.cnf設定のソケットパスが一致していない場合です。
- macOS: MariaDB/MySQLの設定ファイル(/Applications/ServBay/etc/mariadb/<version>/my.cnf)のsocketパラメータを確認。
- Windows: Unixソケットは利用されず、主にネームドパイプやTCP/IP接続を利用します。
- macOS: クライアントやアプリが正しいソケットパスを指定しているか見直してください。ServBayの標準ソケットパスは通常 /Applications/ServBay/tmp/または/tmp/内です。例：/Applications/ServBay/tmp/mysql.sockや /tmp/mysql.sock。
ServBayのデフォルト設定に問題がある場合:
- ServBayの「設定」→「デフォルトSQLサーバー」で、正しいMariaDB/MySQLバージョンを選択してください。一部クライアント（mysqlコマンドなど）は、-Sや-h未指定時にデフォルトのソケットに接続します。
権限の問題:
- macOS: MariaDB/MySQLプロセスがソケットディレクトリへの書き込み権限、またはクライアント側がソケットファイルへの読み込み権限を持っていない場合です。ServBayは通常権限設定まで自動化しますが、手動で/Applications/ServBay/tmp/や/tmp/の権限変更が影響している可能性もあります。
- Windows: ServBay実行ユーザーが指定ポートでリッスン・パイプ生成の権限を持っているか確認してください。

代替案（TCP/IP接続強制使用）：

localhostの代わりに127.0.0.1を指定して接続してみてください。これによりUnixソケットではなくTCP/IP接続となります。127.0.0.1で接続できる場合は、原因がソケットファイルにあると判断できます。
bash
```
mysql -u <username> -p -h 127.0.0.1 -P 3306
```
1

2. ネットワーク接続に関するエラー（`Connection refused`, `Can't connect to MySQL server`など）

TCP/IPを介したMariaDB/MySQLサーバーへの接続が失敗している場合に表示されるエラーです。

主な原因と対策：

MariaDB/MySQLパッケージが起動していない: （先述の内容で確認・エラーログ調査）
ポートの競合:
- デフォルトの3306番ポートが他のプロセスで使用されていないか確認します。
macOS:
bash
```
lsof -i :3306
# または
netstat -anv | grep LISTEN | grep 3306
```
1
2
3
Windows:
cmd
```
netstat -an | findstr :3306
# または PowerShellで
Get-NetTCPConnection -LocalPort 3306
```
1
2
3
ポートが占有されている場合は、該当プロセス停止またはMariaDB/MySQLのportパラメータ変更後に再起動しましょう。
- macOS: /Applications/ServBay/etc/mariadb/<version>/my.cnf
- Windows: C:\ServBay\etc\mariadb\<version>\my.cnf

ファイアウォールによるブロック:

macOS:

macOSシステム設定->ネットワーク->ファイアウォールを確認。

一時的にmysqldプロセスに通信許可を与える例：

bash

# パスは環境に応じて調整
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/ServBay/bin/mariadb/<version>/bin/mysqld
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /Applications/ServBay/bin/mariadb/<version>/bin/mysqld

Windows:

Windows Defenderファイアウォールや他社製ファイアウォール設定を確認。

許可するアプリやポートルール追加:

cmd

# 特定プログラムを許可
netsh advfirewall firewall add rule name="ServBay MariaDB" dir=in action=allow program="C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe"

設定ミス（bind-address）:
- my.cnf内のbind-addressが127.0.0.1やlocalhostになっている場合、ローカルからのみTCP/IP接続が可能です。他のPCやVMからの接続が必要なら0.0.0.0（全IP許可）または特定IPに設定し、ファイアウォールも対応させましょう。
ネットワーク設定ミス（localhostの解決）:
- localhostが127.0.0.1（IPv4）や::1（IPv6）に正しく解決されているか確認してください。
macOS:
bash
```
ping localhost
# hostsファイル確認
cat /etc/hosts
```
1
2
3
Windows:
cmd
```
ping localhost
# hostsファイル確認
type C:\Windows\System32\drivers\etc\hosts
```
1
2
3
hostsファイルに正しいlocalhost記述があるか確認し、プロキシソフト等でlocalhostや127.0.0.1への通信が妨害されていないかも確認してください。

3. MariaDB/MySQLパッケージが起動しない

主な原因と対策：

最重要: エラーログ調査: 先述の通り、エラーログから起動失敗の明確な理由を探ります。
- macOS: /Applications/ServBay/logs/mariadb/<version>/<version>.err
- Windows: C:\ServBay\logs\mariadb\<version>\<version>.err

設定ファイルエラー: 設定ファイルの記述ミスや、無効なパラメータ、パス間違いなど。

設定ファイル場所:

macOS: /Applications/ServBay/etc/mariadb/<version>/my.cnf
Windows: C:\ServBay\etc\mariadb\<version>\my.cnf

設定記述の検証:

bash

# macOS
/Applications/ServBay/bin/mariadb/<version>/bin/mysqld --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf --validate-config

# Windows
C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf --validate-config

ポート競合: （先述のlsof -i :<port>やnetstatコマンドで重複確認）
ディスク容量不足: データディレクトリやログディレクトリのあるドライブに十分な空きがない場合、新しいデータ・ログ・一時ファイルを書き込めません。
ディレクトリパス:
- macOS: データ/Applications/ServBay/db/mariadb/<version>/、ログ/Applications/ServBay/logs/mariadb/<version>/
- Windows: データC:\ServBay\db\mariadb\<version>\、ログC:\ServBay\logs\mariadb\<version>\
権限ミス: MariaDB/MySQLの実行ユーザーが設定ファイルやデータ・ログディレクトリの読み書き権限を持っているか調査します。（ServBayは初期設定で権限調整済みですが、手動変更時に問題が起こることも）
macOS 権限確認例:
bash
```
ls -ld /Applications/ServBay/db/mariadb/<version>
ls -l /Applications/ServBay/etc/mariadb/<version>/my.cnf
ls -ld /Applications/ServBay/logs/mariadb/<version>
```
1
2
3
MariaDB/MySQL実行ユーザー（例: _mysql）が十分なアクセス権限を持っているか確認します。
Windows 権限確認: Windowsでは、エクスプローラーから対象フォルダやファイルのプロパティで、ServBayサービス用ユーザーのアクセス権確認を行います。
データファイル破損: （後述「データベースクラッシュ・破損」の項目参照）強制終了などによりデータファイルが破損し、起動できなくなることがあります。

解決後：

パッケージ再起動: servbayctl restart mariadb <version>

4. ユーザー認証・権限の問題

データベースサーバーに接続後、ユーザー名・パスワードや権限不足によりAccess deniedが表示されることがあります。

主な原因と対策：

ユーザー名・パスワード間違い: 正しい認証情報を入力してください。ServBayはrootパスワードのリセット機能も提供しているので、忘れた場合はそちらを利用できます。
ユーザーホスト制限: DBユーザーが特定ホストだけに制限されている（例: '<username>'@'localhost'）。'<username>'@'127.0.0.1'など別ホストからの接続は失敗します。'%'は全ホスト許可です。
権限不足: データベースや操作（SELECT, INSERT, UPDATE, DELETE, CREATE, DROPなど）へのアクセス権が不足しています。
ユーザー権限の確認:
- 権限が十分な（例: root）ユーザーでMariaDB/MySQLにログイン:
  bash
```
mysql -u root -p
```
  1
- SQLでユーザー権限詳細確認:
  sql
```
SHOW GRANTS FOR '<username>'@'<hostname>';
-- 例：ユーザー 'webapp' が 'localhost' から接続する場合の権限確認
SHOW GRANTS FOR 'webapp'@'localhost';
-- ユーザー 'admin' が任意ホストから接続する場合
SHOW GRANTS FOR 'admin'@'%';
```
  1
  2
  3
  4
  5
- 必要に応じてGRANTやREVOKEコマンドで権限を調整、または新規ユーザー作成時に適切な権限を付与してください。

5. パフォーマンス問題

DBのパフォーマンスが悪化すると、アプリ全体の応答が遅くなります。

主な原因と対策：

スロークエリ: クエリ自体が非効率的・インデックス不足・実行計画が悪い場合。
- スロークエリログ有効化: my.cnfでslow_query_log = 1およびlong_query_time = 1（1秒超のクエリを記録）、ログファイルはslow_query_log_fileで指定します。再起動後はログを分析し、処理に時間のかかるクエリを特定します。
- EXPLAINで実行計画調査: クエリ前にEXPLAINを付けて、インデックス使用・スキャン行数等からボトルネックを検出します。
  sql
```
EXPLAIN SELECT * FROM your_table_name WHERE column_name = 'value';
```
  1
- クエリの最適化: EXPLAIN調査結果を元にクエリを書き直し、SELECT *やWHEREで関数利用を避ける、実用的なインデックス活用を推進します。
インデックス不足/過多: よく検索・ソート・グループ化に使用する列にインデックスが無い場合は全件検索になるため、必要な列にインデックス追加を検討。
- テーブル構造と主要クエリを分析し、適切にインデックスを追加：
  sql
```
CREATE INDEX idx_column_name ON your_table_name(column_name);
```
  1
  ※インデックス追加は書き込み処理やディスク消費が増えるため、バランスを考慮しましょう。
キャッシュ設定不適切: my.cnf内のinnodb_buffer_pool_sizeやkey_buffer_size（MyISAM）の値が小さすぎ/大きすぎなど。
- 設定の調整: お使いのmacOSメモリや用途に応じて、innodb_buffer_pool_size等を調整します（DB専用サーバなら全体RAMの50～70%推奨）。設定後はパッケージ再起動が必要です。
  ini
```
[mysqld]
# 例（用途・環境に応じて変更）
innodb_buffer_pool_size = 2G
# MyISAMテーブル主体の場合
# key_buffer_size = 256M
```
  1
  2
  3
  4
  5
ハードウェアリソースの限界: CPU過負荷・メモリ不足・ディスクI/Oボトルネックなど。macOSのアクティビティモニターやtop/htopでシステムリソースを監視し、問題発生箇所を特定します。

6. データベースクラッシュ・データ破損

DBが起動しない・頻繁にクラッシュする・データ取得に異常が発生する場合、データファイルの破損が疑われます。

主な原因と対策：

エラーログ確認: 最初に確認すべき項目。InnoDBエラー、ファイルシステム異常、ハードウェアイベントなどが記録されます。
- macOS: /Applications/ServBay/logs/mariadb/<version>/<version>.err
- Windows: C:\ServBay\logs\mariadb\<version>\<version>.err
ハード故障: ディスク障害・メモリエラー等によるデータ書込・読込失敗。システムログ（Console.app）や診断ツールで確認可能です。
ソフト競合やバグ: MariaDB/MySQLの特定バージョンのバグ、または他のソフトウェアとの競合による影響。
設定ミス: my.cnfの誤ったパラメータ値が安定性やクラッシュに繋がることも。
強制終了・中断: ServBayアプリの強制終了やプロセスの直接killなどで、データファイルの整合性が失われる場合があります。

対応策：

セーフモードで再起動: ServBay画面やコマンドラインからservbayctl restart mariadb <version>で通常起動を試みる。これだけで自己修復するケースもあります。

mysqlcheckでテーブル検査/修復: テーブルの整合性チェックと自動修復（主にMyISAMに有効）。

bash

# ServBayのmy.cnfとrootで全テーブル検査
mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --check --all-databases
# MyISAMテーブルでは自動修復も可能
# mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --auto-repair --check --all-databases

※--auto-repairは主にMyISAM向け。InnoDBの修復はより複雑かつ、後述の強制リカバリーやバックアップ復元が必要です。

InnoDB強制リカバリー（innodb_force_recovery）: InnoDBが起動できない場合、強制リカバリーモードで起動→データバックアップの手順です。データ消失や不整合リスクがあるため通常は非推奨で、緊急時のみ利用ください。
1. 必ずデータディレクトリのバックアップを取得: /Applications/ServBay/db/mariadb/<version>/を別場所へコピーします。
2. 問題バージョンのmy.cnfファイル(/Applications/ServBay/etc/mariadb/<version>/my.cnf)編集。
3. [mysqld]セクションにinnodb_force_recovery = N（Nは1から始め、起動できなければincrementalに6まで試す。毎回レベル変更後、起動・失敗確認）を追加。
4. MariaDB/MySQL起動: servbayctl start mariadb <version>
5. 起動成功（只読・制限付きでも）は直ちにmysqldumpで全データをバックアップしてください。
  bash
```
mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --all-databases --routines --triggers --events > /path/to/your_emergency_backup.sql
```
  1
  バックアップファイルの生成・容量も念入りに確認してください。
6. バックアップ後はMariaDB/MySQLを停止: servbayctl stop mariadb <version>
7. my.cnfからinnodb_force_recovery = N記載を削除またはコメントアウト。
8. データ復元: 新たなデータディレクトリを初期化し、手順5で作成したバックアップをインポートします。
バックアップからの復元: データ修復できない・整合性問題が解消しない場合は、正常な最新バックアップから復元するのが最も確実です。ServBayバックアップ機能のファイルは/Applications/ServBay/backup/mariadb/<version>/に保存されます（ServBay起動下でバックアップ取得時）。
- バックアップファイルを特定データベースへインポートする例：
  bash
```
# まずは復元先DB（<target_database_name>）を作成
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# インポートコマンド
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>
```
  1
  2
  3
  4
  5
  ※<version>は復元に用いるMariaDB/MySQLのバージョンに合わせてください。

7. バックアップ・復元関連のトラブル

ServBayの内蔵バックアップやmysqldumpでバックアップ・復元する際に発生しやすい問題について。

主な原因と対策：

バックアップファイルが不完全・破損:
- バックアップファイルサイズ(ls -lh /path/to/your_backup.sql)が異常に小さくないか確認。
- テキストエディタやlessコマンドで中身を確認し、SQLファイル形式になっていることをチェック。
- mysqldump実行時のエラーや、ServBayのアプリログでバックアップ経過を確認してください。
復元コマンドのミス:
- ユーザー名・パスワード・DB名の誤り
- インポートを担当するユーザーが十分な権限を持っていない場合
- SQL構文エラー（MySQL用のバックアップをMariaDBで復元/逆も同様）により、バージョン差・種類差で互換性問題が発生することがあります。
外部キー制約の問題: テーブルのインポート順が外部キー参照関係に合致せず失敗するケース。インポート前に一時的に外部キー検証を禁止し、完了後に再度有効化します。
sql
```
-- インポート前に実行
SET foreign_key_checks = 0;
-- インポートコマンド例
source /path/to/your_backup.sql; -- mysqlクライアント上で実行
-- またはコマンドラインで: mysql ... < /path/to/your_backup.sql

-- 完了後に外部キー検証を有効化
SET foreign_key_checks = 1;
```
1
2
3
4
5
6
7
8
※外部キー検証を無効化すると、データの整合性が損なわれる場合があります。インポート作業中のみ利用してください。
文字コード・照合順序の不一致: バックアップファイル内の定義やデータと、復元先DBの文字コード・照合順序（例：utf8mb4）が合わずエラーや文字化けが起きる場合があります。DB・テーブル作成時には互換性を確認しましょう。

正しい復元手順（コマンド例）:

macOS:

bash

# バックアップファイルが特定データベース向け（単一DB用）の場合
# 事前に対象DB（<target_database_name>）を作成
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# インポート時は正しい設定ファイル・ユーザー名・パスワード・DB名で
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

# 全DB用バックアップの場合（--all-databases）はDB指定不要
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

Windows:

cmd

REM 単一データベース用バックアップの場合
REM 復元先DB（<target_database_name>）を事前に作成
REM C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

REM 設定ファイル・ユーザー名・パスワード・DB名を指定してインポート
C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u <username> -p <target_database_name> < C:\ServBay\backup\mariadb\<version>\<your_backup.sql>

REM 全DB用バックアップの場合（--all-databases）はDB名指定不要
REM C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u <username> -p < C:\ServBay\backup\mariadb\<version>\<your_backup.sql>

※<version>は、復元するMariaDB/MySQLパッケージのバージョンに合わせてください。ServBayのバックアップ機能で作られるバックアップファイルは、復元に適した形式になっています。

8. 特定バグ：MariaDB 11.5.1 InnoDB起動失敗（`ib_logfile0 was not found` / `Missing FILE_CHECKPOINT`）

本件はMariaDB 11.5.1バージョンで確認されている重大なバグで、InnoDBストレージエンジンが初期化やログファイル復元に失敗、これによりDB起動ができなくなる例です。

代表的なエラーログ例：

macOS例（/Applications/ServBay/logs/mariadb/11.5/11.5.err）:

[ERROR] InnoDB: File /Applications/ServBay/db/mariadb/11.5/ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

Windows例（C:\ServBay\logs\mariadb\11.5\11.5.err）:

[ERROR] InnoDB: File C:\ServBay\db\mariadb\11.5\ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

または

[ERROR] InnoDB: Missing FILE_CHECKPOINT(xxxxx) at xxxxx
[ERROR] InnoDB: Log scan aborted at LSN xxxxx
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

これらはInnoDBエンジンがログファイルを認識できず、初期化に失敗したことを示しています。

解決方法（データ移行が必要なので、必ず事前バックアップを！）：

本バグは通常方法では修復困難です。安全策はバックアップ→別の安定バージョンへのデータ移行です。

強制リカバリ起動を試みてバックアップ取得（リスクあり）:

設定ファイル編集:

macOS: /Applications/ServBay/etc/mariadb/11.5/my.cnf
Windows: C:\ServBay\etc\mariadb\11.5\my.cnf

[mysqld]セクションにinnodb_force_recovery = 6を追加します。

サービス起動試行:

bash

servbayctl start mariadb 11.5

起動できたら即バックアップ:

macOS:

bash

mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/11.5/my.cnf -u root -p --all-databases --routines --triggers --events > /Applications/ServBay/backup/mariadb/11.5/mariadb_11.5_emergency_backup.sql

Windows:

cmd

C:\ServBay\bin\mariadb\11.5\bin\mysqldump.exe --defaults-file=C:\ServBay\etc\mariadb\11.5\my.cnf -u root -p --all-databases --routines --triggers --events > C:\ServBay\backup\mariadb\11.5\mariadb_11.5_emergency_backup.sql

バックアップファイルが正常か・サイズが十分あるかしっかりと確認してください。

問題バージョンのデータディレクトリ処理:
- MariaDB 11.5パッケージ停止: servbayctl stop mariadb 11.5
- my.cnfから innodb_force_recovery...

ServBay MariaDB/MySQL パッケージ トラブルシューティングガイド ​

概要 ​

基本的な診断手順 ​

よくある問題とその解決策 ​

1. 接続エラー：SQLSTATE[HY000] [2002] No such file or directory ​

2. ネットワーク接続に関するエラー（Connection refused, Can't connect to MySQL serverなど） ​

3. MariaDB/MySQLパッケージが起動しない ​

4. ユーザー認証・権限の問題 ​

5. パフォーマンス問題 ​

6. データベースクラッシュ・データ破損 ​

7. バックアップ・復元関連のトラブル ​

8. 特定バグ：MariaDB 11.5.1 InnoDB起動失敗（ib_logfile0 was not found / Missing FILE_CHECKPOINT） ​

ServBay MariaDB/MySQL パッケージトラブルシューティングガイド

概要

基本的な診断手順

よくある問題とその解決策

1. 接続エラー：`SQLSTATE[HY000] [2002] No such file or directory`

2. ネットワーク接続に関するエラー（`Connection refused`, `Can't connect to MySQL server`など）

3. MariaDB/MySQLパッケージが起動しない

4. ユーザー認証・権限の問題

5. パフォーマンス問題

6. データベースクラッシュ・データ破損

7. バックアップ・復元関連のトラブル

8. 特定バグ：MariaDB 11.5.1 InnoDB起動失敗（`ib_logfile0 was not found` / `Missing FILE_CHECKPOINT`）