このページはClickHouse Cloudには該当しません。ここで説明している手順は、ClickHouse Cloud サービスでは自動化されています。
実装の詳細
clickhouse-keeper-converter ツールを使用すると、ZooKeeper のデータを ClickHouse Keeper のスナップショットに変換できます。ClickHouse Keeper のサーバー間プロトコルも ZooKeeper とは互換性がないため、ZooKeeper と ClickHouse Keeper が混在するクラスターを構成することはできません。
ClickHouse Keeper は、ZooKeeper と同様にアクセス制御リスト (ACL) をサポートしています。ClickHouse Keeper は同じ権限セットをサポートしており、組み込みのスキームも world、auth、digest の 3 つで完全に同一です。digest 認証スキームでは username:password の組を使用し、パスワードは Base64 でエンコードされます。
外部インテグレーションはサポートされていません。
設定
.xml ファイルで行います。
Keeper 設定項目
<keeper_server> で、以下のパラメータを使用できます。
その他の一般的なパラメータは、ClickHouse server の設定 (
listen_host、logger など) から継承されます。
内部協調設定
<keeper_server>.<coordination_settings> セクションにあり、次のパラメータがあります。
クォーラム設定は
<keeper_server>.<raft_configuration> セクションにあり、サーバーの説明が含まれます。
クォーラム全体に対する唯一のパラメータは secure で、クォーラム参加者間の通信に暗号化接続を有効にします。ノード間の内部通信用に SSL 接続が必要な場合は、このパラメータを true に設定できます。それ以外の場合は指定しないままにできます。
各 <server> の主なパラメータは次のとおりです。
id— クォーラム内でのサーバー識別子。hostname— このサーバーが配置されているホスト名。port— このサーバーが接続を待ち受けるポート。can_become_leader— サーバーをlearnerとして構成するにはfalseに設定します。省略した場合の値はtrueです。
ClickHouse Keeper クラスターのトポロジーが変更される場合 (たとえばサーバーの置き換え時) は、
server_id と hostname の対応関係を常に一貫させ、異なるサーバーに対して既存の server_id を入れ替えたり再利用したりしないようにしてください (たとえば、ClickHouse Keeper のデプロイに自動化スクリプトを使っている場合に起こりえます) 。Keeper インスタンスのホストが変わる可能性がある場合は、IP アドレスを直接使うのではなく、ホスト名を定義して使用することを推奨します。ホスト名の変更は、サーバーを削除して再度追加し直すのと同じであり、場合によってはそれが不可能なことがあります (たとえば、クォーラムを満たすのに十分な Keeper インスタンス数がない場合) 。async_replication は後方互換性を損なわないよう、デフォルトで無効になっています。クラスター内のすべての Keeper インスタンスが async_replication をサポートするバージョン (v23.9+) で動作している場合は、欠点なくパフォーマンスを向上できるため、有効にすることを推奨します。test_keeper_ プレフィックスを持つ 結合テスト にあります。サーバー #1 の設定例:
実行方法
/etc/your_path_to_config/clickhouse-server/config.xml に <keeper_server> の設定を追加し、通常どおり ClickHouse server を起動するだけです。スタンドアロンの ClickHouse Keeper を実行する場合も、同様に次のように起動できます。
clickhouse-keeper) がない場合は、それを作成するか、clickhouse の引数として keeper を指定できます。
4文字コマンド
mntr、stat などのように 4 文字で構成されています。さらに、いくつかの便利なコマンドがあります。stat は server と接続中のクライアントに関する一般的な情報を返し、srvr は server の詳細情報を返し、cons は connections の詳細情報を返します。
4lw コマンドには four_letter_word_white_list というホワイトリスト設定があり、そのデフォルト値は conf,cons,crst,envi,ruok,srst,srvr,stat,wchs,dirs,mntr,isro,rcvr,apiv,csnp,lgif,rqld,ydld です。
これらのコマンドは、クライアントポートに対して telnet または nc 経由で ClickHouse Keeper に送信できます。
ruok: サーバーがエラーのない状態で稼働しているかどうかをテストします。稼働している場合、サーバーはimokを返します。そうでない場合は、まったく応答しません。imokという応答は、サーバーがクォーラムに参加していることを必ずしも意味せず、サーバープロセスがアクティブで、指定されたクライアントポートにバインドされていることを示すだけです。クォーラムに関する状態やクライアント接続情報の詳細については、“stat” を使用してください。
mntr: クラスターの健全性の監視に使用できる変数の一覧を出力します。
srvr: サーバーの詳細情報を一覧表示します。
stat: サーバーと接続中のクライアントの概要を一覧表示します。
srst: サーバーの統計情報をリセットします。このコマンドはsrvr、mntr、statの結果に影響します。
conf: 現在の設定の詳細を表示します。
cons: このサーバーに接続しているすべてのクライアントの接続/セッションの詳細を一覧表示します。受信/送信したパケット数、セッション ID、操作レイテンシ、最後に実行された操作などの情報が含まれます…
crst: すべての接続の connection/session 統計をリセットします。
envi: 実行環境の詳細を表示
dirs: スナップショットおよびログファイルの合計サイズをバイト単位で表示
isro: サーバーが読み取り専用モードで稼働しているかどうかを確認します。読み取り専用モードの場合、サーバーはroを返し、そうでない場合はrwを返します。
wchs: サーバーのウォッチに関する概要を一覧表示します。
wchc: サーバーのウォッチに関する詳細情報を、セッションごとに一覧表示します。ウォッチ (パス) に関連付けられたセッション (接続) の一覧が出力されます。なお、ウォッチ数によってはこの操作の負荷が高くなり、サーバーのパフォーマンスに影響する可能性があるため、注意して使用してください。
wchp: サーバーのウォッチに関する詳細情報を、パスごとに一覧表示します。関連するセッションとともに、パス (znode) の一覧が出力されます。なお、ウォッチ数によってはこの操作のコストが高くなり (つまり、サーバーのパフォーマンスに影響する可能性があり) 、慎重に使用してください。
dump: 残っているセッションとエフェメラルノードを一覧表示します。これはリーダーでのみ機能します。
csnp: スナップショット作成タスクをスケジュールします。成功した場合は、スケジュールされたスナップショットの最後にコミットされたログインデックスを返し、失敗した場合はFailed to schedule snapshot creation task.を返します。スナップショットが完了したかどうかは、lgifコマンドで確認できます。
lgif: Keeper のログ情報。first_log_idx: ログストア内の最初のログインデックス;first_log_term: 最初のログターム;last_log_idx: ログストア内の最後のログインデックス;last_log_term: 最後のログターム;last_committed_log_idx: ステートマシン内で最後にコミットされたログインデックス;leader_committed_log_idx: 自分から見たリーダーのコミット済みログインデックス;target_committed_log_idx: コミットされるべき対象のログインデックス;last_snapshot_idx: 最後のスナップショットにおける、コミット済みログインデックスの最大値。
rqld: 新しいリーダーになるよう要求します。要求の送信に成功した場合はSent leadership request to leader.を、送信できなかった場合はFailed to send leadership request to leader.を返します。ノードがすでにリーダーである場合も、結果は要求の送信に成功した場合と同じです。
ftfl: すべての機能フラグと、それぞれがKeeperインスタンスで有効かどうかを一覧表示します。
ydld: リーダーシップを譲ってフォロワーになるよう要求します。要求を受信したサーバーがリーダーの場合、まず書き込み処理を一時停止し、後継ノード (現在のリーダーが後継ノードになることはありません) が最新のログへの追従を完了するまで待ってから、リーダーを退任します。後継ノードは自動的に選択されます。要求が送信された場合はSent yield leadership request to leader.、送信されなかった場合はFailed to send yield leadership request to leader.を返します。ノードがすでにフォロワーである場合も、結果は要求が送信された場合と同じです。
pfev: 収集されたすべてのイベントの値を返します。各イベントについて、イベント名、イベント値、イベントの説明を返します。
HTTP 制御
/ready エンドポイントを有効にする設定例:
機能フラグ
keeper_server.feature_flags 設定で有効にできます。
すべての機能を明示的に無効にすることもできます。
Keeper クラスターで新しい機能を有効にする場合は、まずクラスター内のすべての Keeper インスタンスをその機能をサポートするバージョンに更新してから、機能自体を有効にすることを推奨します。
multi_read を無効にし、check_not_exists を有効にする機能フラグ設定の例:
一部の機能フラグは、バージョン 25.7 以降でデフォルトで有効になります。
Keeper を 25.7+ にアップグレードする推奨手順は、まずバージョン 24.9+ にアップグレードすることです。
ZooKeeper からの移行
clickhouse-keeper-converter ツールは、ZooKeeper のログとスナップショットを ClickHouse Keeper のスナップショットに変換します。ZooKeeper 3.4 以降が必要です。
移行前の準備
移行手順
- すべての ClickHouse ノードへのデータのインジェストを停止します。
- すべての ClickHouse ノードで、すべてのバックグラウンドタスクを停止します (上記を参照) 。
- すべての ZooKeeper ノードを停止します。
- 任意ですが、推奨します: ZooKeeper のリーダーノードを特定し、起動してから再度停止します。これにより、変換前に ZooKeeper が整合性のあるスナップショットをディスクに書き込むよう強制できます。
-
リーダーノードで
clickhouse-keeper-converterを実行します。ClickHouse の完全なバイナリがインストールされている場合は、代わりにkeeper-converterサブコマンド (clickhouse keeper-converter) を使用します。どちらも利用できない場合は、バイナリをダウンロードしてください。
- スナップショットをすべての ClickHouse Keeper ノードにコピーします。どのノードも起動する前に、すべてのノードにスナップショットが存在している必要があります。スナップショットがないままノードが起動すると、空の状態で自らをリーダーに選出してしまう可能性があります。
- 新しい Keeper クラスターを参照するように ClickHouse の設定を更新します。
- すべてのノードで ClickHouse Keeper を起動し、その後 ClickHouse を再起動します。
- 整合性を確認するため、移行前のベースラインとメトリクスを比較します。
- バックグラウンドタスクを再開し、データのインジェストを再開します。
複数の ZooKeeper クラスターの統合
clickhouse-keeper-converter ツールがサポートしているのは 1 対 1 の変換 (1 つの ZooKeeper クラスターから 1 つの Keeper スナップショットへの変換) のみであるため、統合するには converter のソースコードを修正し、複数のスナップショットをマージする必要があります。
- 各 ZooKeeper クラスターに対して
clickhouse-keeper-converterを個別に実行し、それぞれの出力を別々のディレクトリに書き込みます。 - スナップショットファイルを順番にデシリアライズします。マージ時には、異なるソースクラスターのネームスペース間でノード ID の競合が発生しないよう、
numChildrenの値を再計算します。 - マージした出力を、対象の ClickHouse Keeper スナップショット用ディレクトリに書き込みます。
暗号化とACLの取り扱い
world、auth、digest) をサポートしています。変換時に ACL をどのように扱うかは、ZooKeeper の構成によって異なります。
- 完全に暗号化されている、またはまったく暗号化されていない: そのまま変換できます。コンバーターは既存の ACL 情報を保持します。
- 部分的に暗号化されている: 変換前にスーパー管理者アカウントに権限を付与し、影響を受けるパスで
setAcl -Rを使って ACL をクリアします。変換後、必要に応じて ClickHouse Keeper で暗号化を再度有効にしてください。
移行の検証
- 共通パス: 複数のソースクラスターに同一データで存在するパス。これらは、マージ後の出力で重複排除する必要があります。
- 固有のパス: 特定のクラスター配下にのみ存在するパス (例: 各分片グループの
/clickhouse/tables配下) 。これらは、正しいソースのものを保持する必要があります。
移行後のチューニング
これらの設定は、Keeper の設定 の
coordination_settings で構成します。
クォーラム喪失後の復旧
- 障害が発生したノードが再びクラスターに接続できないことを確認してください。
- 手順で指示があるまでは、新しいノードをいずれも起動しないでください。
- 新しいリーダーとする Keeper ノードを 1 つ選びます。そのノードのデータがクラスター全体で使われるため、できるだけ最新の状態を持つノードを使用することを推奨します。
- ほかの作業を行う前に、選択したノードの
log_storage_pathおよびsnapshot_storage_pathフォルダーのバックアップを作成します。 - 使用する予定のすべてのノードでクラスターを再構成します。
- 選択したノードに 4 文字コマンド
rcvrを送信してそのノードを復旧モードに移行するか、または選択したノード上の Keeper インスタンスを停止し、--force-recovery引数を付けて再起動します。 - 新しいノード上で Keeper インスタンスを 1 つずつ起動し、次のノードを起動する前に
mntrがzk_server_stateに対してfollowerを返すことを確認します。 - 復旧モード中、リーダーノードは新しいノードとのクォーラムが成立するまで、
mntrコマンドに対してエラーメッセージを返し、クライアントおよびフォロワーからのあらゆるリクエストを拒否します。 - クォーラムが成立すると、リーダーノードは通常動作モードに戻り、すべてのリクエストを受け付けます。
mntrで確認すると、zk_server_stateに対してleaderが返るはずです。
Keeper でディスクを使用する
- s3_plain
- s3
- local
keeper_server.log_storage_disk 設定にディスク名を指定する必要があります。
スナップショット用にディスクを使用するには、keeper_server.snapshot_storage_disk 設定にディスク名を指定する必要があります。
さらに、最新のログには keeper_server.latest_log_storage_disk、最新のスナップショットには keeper_server.latest_snapshot_storage_disk を使用できます。
その場合、新しいログまたはスナップショットが作成されると、Keeper は自動的にファイルを適切なディスクに移動します。
state ファイル用にディスクを使用するには、keeper_server.state_storage_disk 設定にディスク名を指定する必要があります。
ディスク間でのファイル移動は安全で、転送の途中で Keeper が停止してもデータが失われることはありません。
ファイルが新しいディスクに完全に移動されるまでは、元のディスクから削除されません。
keeper_server.coordination_settings.force_sync を true に設定した Keeper (デフォルトは true) では、すべての種類のディスクに対して一部の保証を満たせません。
現時点で永続 sync をサポートしているのは、local 型のディスクのみです。
force_sync を使用する場合、latest_log_storage_disk を使用しないのであれば、log_storage_disk は local ディスクである必要があります。
latest_log_storage_disk を使用する場合は、常に local ディスクである必要があります。
force_sync を無効にすると、どの種類のディスクでも、どの構成でも使用できます。
Keeper インスタンスのストレージ構成例は、次のようになります。
log_s3_plain に保存され、最新のログはディスク log_local に保存されます。
同様に、スナップショットについても、最新のスナップショットを除くすべてのスナップショットは snapshot_s3_plain に保存され、最新のスナップショットはディスク snapshot_local に保存されます。
ディスク構成の変更
keeper_server.old_snapshot_storage_disk と keeper_server.old_log_storage_disk を複数定義できます。
次の設定は、以前の 2 ディスク構成から、まったく新しい単一ディスク構成へ移行する方法を示しています。
log_local と log_s3_plain から log_local2 ディスクに移動されます。
また、すべてのスナップショットファイルは snapshot_local と snapshot_s3_plain から snapshot_local2 ディスクに移動されます。
ログキャッシュの設定
latest_logs_cache_size_threshold- キャッシュに保存される最新ログの合計サイズcommit_logs_cache_size_threshold- 次にコミットする必要がある後続ログの合計サイズ
pfev コマンドを使用すると、各キャッシュおよびファイルから読み取られたログ量を確認できます。
また、Prometheus エンドポイントのメトリクスを使用して、両方のキャッシュの現在のサイズを追跡することもできます。Prometheus
endpoint– Prometheus サーバーがメトリクスをスクレイピングするための HTTP エンドポイント。’/’ で始まる必要があります。port–endpointに使用するポート。metrics– system.metrics テーブルのメトリクスを公開するかどうかを設定するフラグ。events– system.events テーブルのメトリクスを公開するかどうかを設定するフラグ。asynchronous_metrics– system.asynchronous_metrics テーブルの現在のメトリクス値を公開するかどうかを設定するフラグ。
127.0.0.1 はご利用の ClickHouse server の IPアドレスまたはホスト名に置き換えてください) :
ClickHouse Keeper ユーザーガイド
1. Keeperの設定でノードを構成する
-
3 台のホスト (
chnode1、chnode2、chnode3) に、3 つの ClickHouse インスタンスをインストールします。 (ClickHouse のインストール方法の詳細については、クイックスタートを参照してください。) -
各ノードで、ネットワークインターフェイス経由の外部通信を許可するために、以下のエントリを追加します。
-
以下のClickHouse Keeperの設定を3台すべてのサーバーに追加し、各サーバーの
<server_id>設定を更新します。たとえば、chnode1は1、chnode2は2となります。上記で使用した基本設定は以下のとおりです。 -
ZooKeeper コンポーネントを有効にします。このコンポーネントでは ClickHouse Keeper エンジンを使用します:
上記で使用した基本設定は以下のとおりです。
-
ClickHouse を再起動し、各 Keeper インスタンスが稼働していることを確認します。各サーバーで次のコマンドを実行してください。Keeper が稼働しており正常な状態であれば、
ruokコマンドはimokを返します。 -
systemデータベースには、ClickHouse Keeper の各インスタンスの詳細が格納されたzookeeperという名前のテーブルがあります。では、このテーブルを見てみましょう。表は次のとおりです。
2. ClickHouse でクラスターを構成する
-
3 台のノードのうち 2 台に、2 分片・各 1 レプリカのシンプルなクラスターを構成します。3 台目のノードは、ClickHouse Keeper の要件であるクォーラムを満たすために使用します。
chnode1とchnode2の設定を更新してください。次のクラスター定義では、各ノードに 1 つの分片を割り当てることで、合計 2 分片、レプリケーションなしの構成になります。この例では、データの一部は一方のノードに、残りはもう一方のノードに配置されます。 -
ClickHouse を再起動し、クラスターが作成されたことを確認します。
クラスターが表示されるはずです。
3. 分散テーブルを作成してテストする
-
chnode1上で ClickHouse client を使用し、新しいクラスターに新しいデータベースを作成します。ON CLUSTER句により、両方のノードにデータベースが自動的に作成されます。 -
db1データベースに新しいテーブルを作成します。今回も、ON CLUSTERによって両方のノードにテーブルが作成されます。 -
chnode1ノードで 2 行のデータを追加します。 -
chnode2ノードでも 2 行のデータを追加します。 -
各ノードで
SELECTステートメントを実行しても、そのノード上のデータしか表示されないことに注意してください。たとえば、chnode1では次のようになります。chnode2では: -
-
2 つの分片上のデータを表す
Distributedテーブルを作成できます。Distributedテーブルエンジンを使用するテーブルは、それ自体ではデータを保存しませんが、複数のサーバーに対する分散クエリ処理を可能にします。読み取りはすべての分片に対して実行され、書き込みは各分片に分散できます。chnode1で次のクエリを実行します。 -
dist_tableにクエリを実行すると、2 つの分片から 4 行すべてのデータが返されることを確認してください。
まとめ
一意のパスでClickHouse Keeperを設定する
このページはClickHouse Cloudには該当しません。ここで説明している手順は、ClickHouse Cloud サービスでは自動化されています。
説明
{uuid} マクロ設定を使って、
ClickHouse Keeper または ZooKeeper に一意のエントリを作成する方法を説明します。一意の
パスは、テーブルの作成と削除を頻繁に行う場合に役立ちます。これは、
パスが作成されるたびにその
パス内で新しい uuid が使用されるため、パスのエントリを削除する Keeper のガベージコレクションが完了するまで
数分待つ必要がないからです。
パスが再利用されることはありません。
環境例
クラスターの設定例:
テーブルで {uuid} を使用するための設定手順
- 各サーバーでマクロを設定します サーバー 1 の例:
shard と replica にはマクロを定義していますが、{uuid} はここでは定義していない点に注意してください。これは組み込みのため、定義する必要はありません。- データベースを作成する
- マクロと
{uuid}を使用して、クラスター上にテーブルを作成します
- 分散テーブルを作成する
動作確認
- 最初のノード (例:
chnode1) にデータを挿入します
- 2つ目のノードにデータを挿入します (例:
chnode2)
- 分散テーブルを使ってレコードを表示する
別の方法
{uuid} を使ってあらかじめ定義できます
- 各ノードでテーブルのデフォルト設定を行う
- パラメータを明示せずにテーブルを作成します:
- デフォルト設定と同じ設定が使われていることを確認します
トラブルシューティング
データベースは
Atomic である必要があります。以前のバージョンからアップグレードする場合、
default データベースは Ordinary である可能性が高いです。ClickHouse Keeper の動的再設定
このページはClickHouse Cloudには該当しません。ここで説明している手順は、ClickHouse Cloud サービスでは自動化されています。
説明
keeper_server.enable_reconfiguration が有効な場合、ClickHouse Keeper はクラスターを動的に再構成するための ZooKeeper の reconfig
コマンドを部分的にサポートします。
この設定が無効な場合は、各レプリカの
raft_configuration
セクションを手動で変更することでクラスターを再構成できます。変更を適用するのはリーダーのみであるため、
すべてのレプリカ上のファイルを編集してください。
また、ZooKeeper 互換クライアント経由で reconfig クエリを送信することもできます。/keeper/config には、最後にコミットされたクラスター構成が次のフォーマットで格納されています。
- 各サーバーのエントリは改行で区切られます。
server_typeはparticipantまたはlearnerのいずれかです (learner はリーダー選出に参加しません) 。server_priorityは、リーダー選出でどのノードを優先するか を示す 0 以上の整数です。 優先度が 0 の場合、そのサーバーがリーダーになることはありません。
reconfig コマンドを使用すると、新しいサーバーの追加、既存サーバーの削除、既存サーバーの
優先度の変更ができます。以下はその例です (clickhouse-keeper-client を使用) :
kazoo の例を以下に示します。
joining 内のサーバーは、上記で説明したサーバー形式に従っている必要があります。サーバーエントリはカンマで区切る必要があります。
新しいサーバーを追加する際は、server_priority (デフォルト値は 1) と server_type (デフォルト値
は participant) を省略できます。
既存サーバーの優先度を変更する場合は、変更先の優先度を指定してそのサーバーを joining に追加します。
サーバーのホスト、ポート、タイプは、既存のサーバー設定と一致している必要があります。
サーバーの追加と削除は、joining と leaving に記載された順序で行われます。
joining の更新はすべて、leaving の更新より先に処理されます。
Keeper の再構成実装には、いくつかの注意点があります。
-
サポートされているのは増分再構成のみです。
new_membersが空でないリクエストは拒否されます。 ClickHouse Keeper の実装では、メンバーシップを動的に変更するために NuRaft API を使用しています。NuRaft では、 1 回につき 1 台のサーバーを追加または削除できます。つまり、設定に対する各変更 (joiningの各要素、leavingの各要素) は、それぞれ個別に決定される必要があります。そのため、一括での 再構成は提供されていません。エンドユーザーに誤解を与えるおそれがあるためです。 サーバータイプ (participant/learner) の変更もできません。これは NuRaft でサポートされていないためです。また、 唯一の方法はサーバーを削除して再度追加することですが、これもやはり誤解を招くおそれがあります。 -
返された
znodestatの値は使用できません。 -
from_versionフィールドは使用されません。from_versionが設定されたリクエストはすべて拒否されます。 これは、/keeper/configが仮想ノードであるためです。つまり、このノードは永続ストレージには保存されず、 代わりに指定されたノード設定に基づいて、リクエストごとにその場で生成されます。 このような設計になっているのは、NuRaft がすでにこの設定を保存しているため、データの重複を避けるためです。 -
ZooKeeper とは異なり、
syncコマンドを送信してクラスターの再構成が完了するまで待機する方法はありません。 新しい設定はいずれ適用されますが、適用時期は保証されません。 -
reconfigコマンドは、さまざまな理由で失敗する可能性があります。クラスターの状態を確認して、更新が 適用されたかどうかを確認できます。
単一ノードの Keeper をクラスター化する
- 重要: 新しいノードは、現在のクォーラム未満の単位で追加する必要があります。そうしないと、それらのノード間でリーダーが選出されてしまいます。この例では、1 台ずつ追加します。
- 既存の Keeper ノードでは、
keeper_server.enable_reconfiguration設定パラメーターを有効にしておく必要があります。 - Keeper クラスターの新しい完全な設定で 2 台目のノードを起動します。
- 起動後、
reconfigを使用してノード 1 に追加します。 - 次に、3 台目のノードを起動し、
reconfigを使用して追加します。 - 新しい Keeper ノードを追加するように
clickhouse-serverの設定を更新し、変更を適用するために再起動します。 - ノード 1 の raft 設定を更新し、必要に応じて再起動します。
サポートされていない機能
createはStatオブジェクトを返すことをサポートしていませんcreateは 有効期限 (TTL) をサポートしていませんaddWatchはPERSISTENTウォッチでは動作しませんremoveWatchとremoveAllWatchesはサポートされていませんsetWatchesはサポートされていませんCONTAINER型の znode は作成できませんSASL authenticationはサポートされていません