前回の記事では、rootpasswordの設定、データベースの作成、データベースのユーザーの作成など、CentOSLinuxでの基本的なMariaDB®サーバーのセットアップについて説明しました。次に、MariaDBをもう少し詳しく見て、構成を微調整し、問題が発生した場合に備えます。
デフォルトでは、MariaDBの構成ファイルは次の場所にあります：
/etc/my.cnf
そこにない場合は、mysqldを使用できます 次のコマンドを実行して構成ファイルを検索するには：
/usr/libexec/mysqld --help --verbose
たくさんのテキストが返されます。最初の部分では、サーバーを起動したときにサーバーに送信できるオプションについて説明します。 2番目の部分は、サーバーのコンパイル時に設定されたすべての構成情報です。
出力の開始近くで、次の行のように見える2行を見つけます。
Default options are read from the following files in the given order:
/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf
サーバーは、構成ファイルが見つかるまでリストを下に移動します。
my.cnf
my.cnfを開きます ファイルを作成して内部を確認してください。
#で始まる行 コメントであり、ほとんどの場合、さまざまな設定の目的を文書化しています。ログファイルの場所やデータベースファイルが保存されている場所などの詳細が表示されます。
設定ファイルには、 [client] のように、角括弧内の単語のみを含む行があります。 または[mysqld] 。これらは構成グループです そして、構成ファイルを読み取るプログラムに、どの部分に注意を払うべきかを伝えます。
MariaDBは、技術的にはサーバー（ mysqld ）を含むツールのコレクションです。 ）、クライアント（ mysql ）、およびその他のツール。プログラムはmy.cnfを調べます 彼らがどのように振る舞うべきかを見るために。
基本的に、 mysql 構成セクションは、クライアントと mysqldを制御します セクションはサーバーを制御します。
何か問題が発生した場合、プログラムのトラブルシューティングを開始するのに最適な場所はログです。デフォルトでは、MariaDBはログファイルを次のディレクトリに保存します：
/var/log/mariadb
注 ：sudoを使用する必要がある場合があります そのディレクトリ内のファイルのリストを取得します。
デフォルトディレクトリにログが見つからない場合は、MariaDBの構成を確認する必要があります。 my.cnfを見てください ファイルを作成し、log_errorを探します 次のような行：
log_error = /var/log/mariadb/mariadb.log
そのような行が表示されない場合は、 mysqldで作成してください MariaDBが独自のエラーログを使用するようにセクションを設定します。例の場所を使用して、 / var / log / mariadbを作成することをお勧めします まだ存在しない場合はディレクトリ。次のコマンドでMariaDBを再起動して、変更を適用します。
systemctl restart mariadb
選択したログディレクトリに、MariaDBプロセスを制御するユーザーが書き込むことができることを確認してください。
ポートがあるかもしれません クライアントとサーバーの両方の構成セクションで設定します。サーバーセクションの下のポートは、サーバーがリッスンするポートを制御します。デフォルトでは3306ですが、好きなように変更できます。
クライアントセクションのポートは、デフォルトで接続するポートをクライアントに指示します。通常、2つのポート設定を一致させる必要があります。
構成ファイルにポートエントリが表示されない場合は、ポートがデフォルトを使用していることを意味します。ポートを変更する場合は、次の例に示すように、適切なカテゴリに行を追加します。
[client]
port = 3306
[mysqld]
port = 3306
探すべき他のネットワーク設定はbind-addressです 価値。通常、ローカルホストのアドレス127.0.0.1に設定されます。サーバーはlocalhostにバインドすることで、ローカルマシンの外部から誰もサーバーに接続できないようにします。
アプリケーションとは別のマシンでMariaDBサーバーを実行している場合は、ローカルホストではなくリモートアクセス可能なアドレスにバインドする必要があります。 バインドアドレスを変更します パブリックIPアドレスと一致するように設定します（または、さらに良いことに、より少ないマシンがアクセスできるネットワーク上のバックエンドIPアドレスと一致させます）。
バインドアドレスが表示されない場合 エントリの場合は、1つを mysqldに入れる必要があります 次の例のように、サーバーへのアクセスを制御するのに役立つカテゴリ：
[mysqld]
bind-address = 127.0.0.1
データベースユーザーを設定するときはクライアントのホスト名を考慮し、iptablesを実行している場合はファイアウォールを構成することを忘れないでください。
mysqldおよびmysqld_safe
舞台裏では、実際には2つのバージョンのMariaDBサーバー mysqld があります およびmysqld_safe 。どちらも同じ構成セクションを読み取ります。主な違いは、 mysqld_safe クラッシュやその他の問題からの回復を容易にするために、いくつかの安全機能を有効にして起動します。
両方のmysqld およびmysqld_safe mysqldの構成エントリを読み取ります セクション。 mysqld_safeを含める場合 セクション、次に mysqld_safe のみ それらの値を読み取ります。
デフォルトでは、 mysql サービスはmysqld_safeを起動します 。自分が何をしているかについて本当に確信がある場合にのみ、これを変更する必要があります。
mysqladmin
mysqladmin ツールを使用すると、コマンドラインからいくつかの管理機能を実行できます。この記事では、起動して実行するための基本について説明しているため、このツールについては説明していません。特に、チェックなどの機能を実行するスクリプトを作成する必要がある場合は、このツールを後で詳しく見て、何ができるかを確認できます。サーバーのステータスまたはデータベースの作成と削除。
データベースのバックアップを作成する場合（マシン全体をバックアップする方法は別として）、いくつかのオプションがあります。主なオプションは、データベースファイルをコピーし、 mysqldumpを使用することです。 。
デフォルトでは、MariaDBは、次の例のように、データディレクトリにデータベースごとにディレクトリを作成します。
/var/lib/mysql
データディレクトリを見つけたら、すぐにそのコピーを作成しないでください。データベースサーバーがアクティブな場合、いつでもテーブルに新しい値を書き込んでいる可能性があります。コピーの途中でテーブルに書き込むと、一部のファイルが変更され、バックアップが破損します。災害復旧を計画している場合、これは良いことではありません。
データベースファイルが正常にコピーされるようにするには、コピーする前にMariaDBサーバーを完全にシャットダウンします。これは安全ですが、常に理想的とは限りません。
実行できるもう1つのアプローチは、コピーの間、データベースを読み取り専用としてロックすることです。完了したら、ロックを解除します。これにより、ファイルをバックアップしている間も、アプリケーションはデータを読み取ることができます。
コマンドラインから次のコマンドを実行して、データベースを読み取り専用にロックします。
mysql -u root -p -e "FLUSH TABLES WITH READ LOCK;"
完了したらデータベースのロックを解除するには、次のコマンドを実行します。
mysql -u root -p -e "UNLOCK TABLES;"
オプション-e mysqlを使用 クライアントは、 mysql で入力されたかのように、クエリを引用符で囲んで実行するようにクライアントに指示します。 シェル。
これらのコマンドをスクリプトで設定する場合は、 -pの直後にパスワードを引用符で囲むことができます。 次の例のように、2つの間にスペースはありません：
mysql -u root -p"password" -e "FLUSH TABLES WITH READ LOCK;"
mysql -u root -p"password" -e "UNLOCK TABLES;"
注： パスワードを保護するために読み取りアクセスを制限するために、そのファイルにアクセス許可を設定していることを確認してください。
mysqldump
データベースをバックアップする別のアプローチは、 mysqldumpを使用することです。 道具。データベースファイルを直接コピーするのではなく、 mysqldump データベースを表すテキストファイルを生成します。デフォルトでは、テキストファイルにはデータベースの再作成に使用するSQLステートメントのリストが含まれていますが、CSVやXMLなどの別の形式でデータベースをエクスポートすることもできます。 mysqldumpを読むことができます すべてのオプションを確認するには、マニュアルページを参照してください。
mysqldumpによって生成されたステートメント 標準出力に移動します。実行時に出力をリダイレクトするファイルを指定します。例：
mysqldump -u root -p demodb > dbbackup.sql
そのコマンドはmysqldumpに通知します demodbを再作成します データベースのinSQLステートメントとそれらをファイルdbbackup.sqlに書き込む 。ユーザー名とパスワードのオプションはmysqlと同じように機能することに注意してください クライアントなので、 -pの直後にパスワードを含めることができます スクリプトで。
mysqldumpから復元
mysqldumpでコピーされたデータベースの復元 作成に使用されたものと似ていますが、 mysqlを使用します mysqldumpの代わりに 、次のコマンドに示すように：
mysql -u root -p demodb < dbbackup.sql
また、大なり記号の使用から小なり記号の使用に変更します。これにより、コマンドは、出力のリダイレクトから、既存のファイルからの入力を読み取るように指示するように切り替わります。入力はmysqlに送信されます commandandは、 mysqldumpで作成されたコピーの命令を引き起こします データベースを再作成します。
デフォルトでは、生成されたSQLステートメントは、既存のデータベーステーブルを上書きせずに追加します。既存のデータベースにバックアップを復元する場合は、最初にデータベースのテーブルを削除するか、データベース自体を削除して再作成する必要があります。 –add-drop-table を使用して、その動作を変更できます。 mysqldumpを作成するコマンドを指定したオプション 。これを行うと、 mysqldumpが発生します 書き込むバックアップファイルにコマンドを追加して、テーブルを再作成する前にテーブルを削除します。
この記事で取り上げる最後の概念は、データベースエンジンです。 。エンジンは、舞台裏でかき回され、ファイルへの書き込みとファイルからの読み取りを行うプロセスです。通常、そこにあること以外は何も知る必要はありませんが、特定のデータベースエンジン用に最適化されたアプリケーションを実行したい場合があります。
エンジンタイプは、テーブルの作成時に設定されます。テーブルは通常、それらを使用するアプリケーションによって作成されます。
データベースのテーブルで使用されているエンジンを確認するには、MariaDBシェルで次のコマンドを実行し、 demodbを変更します。 データベースの名前に：
SHOW TABLE STATUS FROM demodb;
理想的には、エンジンを選択する必要はありません。 MariaDBにあまり詳しくない場合は、これが最も安全な方法です。アプリケーションにこれを処理させます。アプリケーションを作成する場合は、オプションに慣れるまでdefaultengineを使用します。
MariaDBで最も頻繁に使用されるデータベースエンジンはMyISAM およびInnoDB 。
MyISAM
MyISAMはしばらくの間MySQLのデフォルトであったため、MariaDBと最も互換性があります。特定の種類の検索は、InnoDBよりもMyISAMで優れたパフォーマンスを発揮します。 2つのうち古い方であるからといって、特定のアプリケーションタイプに最適であるとは限りません。
InnoDB
InnoDBは、MyISAMよりもフォールトトレラントであり、クラッシュとリカバリを処理し、データベースが破損する可能性ははるかに低くなります。これは良いことです。
ただし、最高のパフォーマンスを得るには、InnoDBで環境とアクセスパターンを微調整する必要があります。 aDBAをお持ちの場合、この作業は問題にならない可能性があります。ただし、テストサーバー用にデータベースを稼働させたい開発者の場合は、おそらくInnoDBのチューニングに対処したくないでしょう。
この時点で、MariaDBを十分に理解している必要があります。詳細については、MariaDBのドキュメントサイトを参照してください。