基本ユーザー認証

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"の項を参照してください。

User Priority Processing

The PrimProc process has one job queue for each priority level and thread assigned to each queue. The number of threads assigned to each queue is configurable using the following elements in the configuration file:

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

The defaults are 60, 30, and 10 respectively. Each queue is given at least 1 thread so there is neither 'idle' priority configuration possible nor starvation. The number of threads started is normalized such that 100% = 2 * (the number of cores on the machine). The user can overbook or underbook their CPUs however they want. This is an example of how threads are assigned on an 8-core system using the defaults.

• 10% of 16 = 1.6, rounds down to 1 thread for the low priority queue.
• 30% of 16 = 4.8, rounds down to 4 threads for the medium priority queue.
• The high priority queue gets the remaining 11 threads.

Each thread is given a preferred queue to get work from. If a thread's preferred queue is empty, it will choose jobs from the high, then medium, then low priority queues. If there are only low priority jobs running, on an 8-core system all 16 threads will process jobs from the low priority queue. If a medium priority query starts, using the defaults, the 15 threads assigned to the high and medium queues will process the medium queue, leaving the 1 assigned to the low queue to process the low priority jobs. Then, if a high priority query starts, the 11 threads assigned to the high priority queue will begin processing the high priority jobs, the 4 assigned to the medium queue will process those jobs, and the 1 assigned to the low queue will process those jobs.
Given this algorithm, the configuration parameters could be thought of as minimum levels for each priority.
Note that this implementation only affects the processing done by PrimProc. Depending on the work distribution of a given query, a user may or may not observe overall performance proportional to their priority level.