基本ユーザー認証

MariaDB ColumnStoreはユーザーアカウントにパーミッションを設定することができます。それらの構文はMariaDBの標準の構文に従います(GRANT参照)。

rootユーザーは、ColumnStoreのあらゆる権限を有します。ユーザーアカウントを適切に設定または制限するためには、権限の設定または制限を適切に行う必要があります。ColumnStoreはクエリの処理でで使用するすべての一時テーブルの作成の際にinfinidb_vtableと呼ばれる専用のスキーマを使用します。rootユーザーはデフォルトでこのスキーマへの権限を有しますが、すべてのユーザーに対しても、この専用のスキーマに対するあらゆる権限を許可する必要があります。

grant ALL on infinidb_vtable.* to user_account; ここで、user_accountはログインユーザー、サーバーそしてパスワード文字列です。

そして、さらなる権限または制限の設定を、あらゆるオブジェクト(テーブル、関数、プロシージャー、ビュー)に対して行うことができます。以下の例では、ユーザーに対しデータベース内の全テーブルへのパスワードによるフルアクセスを設定しています。

use mysql;
grant ALL on my_schema.* to ‘someuser’@’somehost’
identified by ‘somepassword’;
flush privileges;

また以下の例では、あるテーブルへのパスワードによる読み込みのみのアクセスを設定しています。

use mysql;
grant SELECT on my_schema.table1 to ‘someuser’@’somehost’
identified by ‘somepassword’;
flush privileges;

PAM認証

ColumnStore 1.0.8から、PAM(Pluggable Authentication Module)認証のサポートに必要となるプラグインを含んでいます。詳細は pam-authentication-plugin を参照してください。ここでは、OS認証を構成する際にColumnStoreで必要となる手順の概要を説明します。

最初に、mysqlが /etc/shadow ファイルの読み込み権限があることを確認してください。この例では、グループを利用して読み取り権限を付与しています。

$ sudo groupadd shadow 
$ sudo usermod -a -G shadow mysql 
$ sudo chown root:shadow /etc/shadow 
$ sudo chmod g+r /etc/shadow

unixのパスワード認証を構成するため、pam.dエントリを生成します。

$ vi /etc/pam.d/mysql
auth required pam_unix.so
account required pam_unix.so

auth_pam.soプラグインをロードし、ユーザーを作成します。

$ mcsmysql
> INSTALL SONAME 'auth_pam';
> GRANT SELECT ON test.* TO david IDENTIFIED VIA pam;
> GRANT ALL ON infinidb_vtable.* TO david;

mariadbサーバープロセスへ認証プラグインとグループの変更を反映させるため、ColumnStoreを再起動します。 Restart ColumnStore so that the mariadb server process picks up the auth plugin and group changes:

$ sudo su - 
$ mcsadmin restartSystem

設定が正しく行われたかを確認するために、ログイン操作を行い、アカウント(ここではdavid)に対するunixのパスワードを入力します。

$ mcsmysql -u david -p

もし失敗するようであれば、一度システムの再起動を実行し、再度ログイン操作を行ってみてください。

ユーザーリソース管理

MariaDB ColumnStoreは、ユーザーごとにCPUリソースを割り当てる機能を有しています。ユーザーに対して、優先度の設定によりCPUの最低使用率を割り当てることが可能です。ある特定のユーザーまたは、複数のユーザーに対して、ある量のリソースを使用するよう設定できます。例えば、

• ユーザー1は最低40%のCPUリソースを使用可能
• ユーザー2は最低30%のCPUリソースを使用可能
• もしユーザー1とユーザー2が何らかのクエリーを処理している間に、他のユーザー(ユーザー3、ユーザー4、ユーザー5など)がログインしても、残りの30%のリソースしか使用することができません。

ユーザーのPriority管理

ユーザに対するPriorityの設定、削除、表示を行うための3つのストアド・プロシージャが infinidb_querystats スキーマに用意されています。Priorityテーブルは、ユーザーとそのPriorityレベルからなります。エントリーのないユーザーはデフォルトでは低いPriorityが付与されています。

CalSetUserPriority (host varchar, user varchar, priority varchar)

• Priorityレベルをuser@hostに設定します。
• Priorityは大文字小文字の区別ありで、'high', 'medium' または 'low' を設定します。
• ホストとユーザーのMariaDB内での存在が検証済みとなります。

CalRemoveUserPriority(host varchar, user varchar)

• ユーザーエントリ―を削除し、デフォルトである 'low' に設定します。
• ユーザーの存在が検証されていない状態になります。

CalShowProcessList()

• MariaDBの 'show processlist'とユーザー権限の組み合わせを表示します。

MariaDBユーザーは、これらのプロシージャを実行する権限と、infinidb_querystats テーブルをselectする権限を有する必要があります。または、スーパーユーザーにとって、次のことが実行可能です。

GRANT ALL ON infinidb_querystats.* TO 'user'@'host'; // user will now have the privilege to use the priority procedures and view query stats.

ユーザーPriorityを有効にする

本機能を有効にするには、MariaDB ColumnStore設定ファイルの<UserPriority><Enabled>要素にYが設定されている必要があります(既定の状態はNです)。

<UserPriority>
     <Enabled>Y</Enabled>
</UserPriority>

クロスエンジンサポートも有効でなければなりません。"Cross-Engine Table Access"の項を参照してください。

ユーザーPriorityプロセス

PrimProcプロセスはそれぞれのPriorityレベルに対して一つのジョブキューを持っており、それぞれのキューにスレッドを割り当てています。それぞれのキューに割り当てるスレッド数は、設定ファイルの次の要素で設定可能です。

<PrimitiveServer><HighPriorityPercentage>
<PrimitiveServer><MediumPriorityPercentage>
<PrimitiveServer><LowPriorityPercentage>

デフォルトではそれぞれ、60(High, 高)、30(Medium, 中)、10(Low, 低)が割り当てられています。それぞれのキューには少なくとも1スレッドは割り当てられているため、'idle' priority設定が可能でもなく、枯渇することもありません。開始するスレッド数は、100%がマシン上のコア数の2倍になるように正規化されます。ユーザは、必要とあらば、搭載CPUコア数以上に割り当てることも、搭載CPUコア数以下を割り当てることも可能です。

以下は8コアのシステムでどのようにスレッド数が割り当てられるかの一例です。

• 16の10% = 1.6。低 priorityのキューには1スレッドが割り当てられます。
• 16の30% = 4.8。中 priorityのキューには4スレッドが割り当てられます。
• 高 priorityのキューには残りの11スレッドが割り当てられます。

それぞれのスレッドはキューを割り当てられます。もしスレッドのキューが空の倍、高、中、低の順番でキューからジョブを取得します。もし、低 priorityのクエリのみが実行中であれば、8コアのシステム上の全16スレッドで低 priority ジョブのみが実行されます。もし、中priorityのクエリが開始された場合、設定に従い、15スレッドが高または中priorityのクエリにアサインされ、中priorityクエリの処理を行います。そして残る1スレッドのみが、低priorityのクエリを処理します。その後、もし高priorityクエリが開始された場合、11スレッドが高priorityクエリにアサインされ、4スレッドが中priorityクエリにアサインされ、引き続き1スレッドで低priorityクエリを処理します。
つまり、このアルゴリズムにより、設定値は各priorityの最低処理レベルと考えることが可能です。
この実装はPrimProcによって行われる処理にのみ影響することに注意してください。特定のクエリの作業分散状況によっては、優先順位レベルに比例した全体的なパフォーマンスを得られる場合、または得られない場合があります。