EMR における Kudu に関するよくある質問への回答です。
一般
Kudu ログファイルの保存場所
Kudu ログファイルは /mnt/disk1/log/kudu にあります。
Kudu がサポートするパーティショニング方法
Kudu は、レンジパーティショニングとハッシュパーティショニングをサポートしています。この 2 つの方法は組み合わせて使用できます。詳細については、「Apache Kudu Schema Design」をご参照ください。
Kudu Web UI へのアクセス方法
Kudu は Knox と統合されていません。代わりに SSH トンネルを作成して Web UI にアクセスしてください。手順については、「Create an SSH tunnel to access web UIs of open source components」をご参照ください。
Kudu コミュニティの FAQ
Apache Kudu Troubleshooting ページをご参照ください。
起動エラー
Kudu クライアント接続時の NonRecoverableException
このエラーは、クライアント側で設定されているマスターノードの数が、クラスターが想定している数と一致しない場合に発生します。
org.apache.kudu.client.NonRecoverableException: Could not connect to a leader master. Client configured with 1 master(s) (192.168.0.10:7051) but cluster indicates it expects 3 master(s) (192.168.0.36:7051,192.168.0.11:7051,192.168.0.10:7051)
必要なすべてのマスターノードをデプロイし、Kudu クライアントをプライマリマスターノードに接続してください。
Bigboot モニターの不具合による Kudu の起動失敗
Bigboot V3.5.0 の不具合により、クラッシュ後に Kudu を再起動できません。Bigboot モニターがデータベースから古いサービス情報を削除できないため、その後の再起動に失敗します。
Kudu を停止し、次のコマンドを使用してマシン上で直接起動してください。
次のコマンドは、コアノードまたはタスクノードで実行します。マスターノードで実行する場合は、kudu-tserver を kudu-master に置き換えます。
/usr/lib/b2monitor-current/bin/monictrl -stop kudu-tserver
/usr/lib/b2monitor-current/bin/monictrl -start kudu-tserver
これらのコマンドはマシン自体で実行してください。サービスはすでに終了しているため、EMR コンソールでは停止操作を実行できない場合があります。
時刻同期エラーによる Kudu の起動失敗
このエラーは、ntpd が設定された NTP サーバーに接続できない場合に発生します。
Service unavailable: RunTabletServer() failed: Cannot initialize clock: timed out waiting for clock synchronisation: Error reading clock. Clock considered unsynchronized
ログには次のような出力も含まれる場合があります。
E1010 10:37:54.165313 29920 system_ntp.cc:104] /sbin/ntptime
------------------------------------------
stdout:
ntp_gettime() returns code 5 (ERROR)
time e6ee0402.2a452c4c Mon, Oct 10 2022 10:37:54.165, (.165118697),
maximum error 16000000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
modes 0x0 (),
offset 0.000 us, frequency 187.830 ppm, interval 1 s,
maximum error 16000000 us, estimated error 16000000 us,
status 0x2041 (PLL,UNSYNC,NANO),
time constant 6, precision 0.001 us, tolerance 500 ppm,
サーバーを再起動して、もう一度お試しください。
ランタイムエラー
ネットワークエラー: ホスト名を解決できない
Bad status: Network error: Could not obtain a remote proxy to the peer.: unable to resolve address for <hostname>: Name or service not known
このエラーは、ホスト名を IP アドレスに解決できない場合に発生します。有効なマッピングがないと、Kudu タブレットの Raft ピアがピアを識別できず、接続が終了します。
解決策 1: ホスト名と IP アドレスのマッピングを /etc/hosts に追加します。
ソリューション 2: ホスト名に対応するホストが解放されている場合は、ホスト名と任意の IP アドレス間のマッピングを /etc/hosts に追加します。 IP アドレスは到達可能である必要はありません。 マッピングが存在すると、Kudu タブレットサーバーは、利用できない Raft サーバーから Raft グループ内の新しい Raft サーバーにデータを複製します。
ファイルシステムレイアウトの整合性エラー
Bad status: I/O error: Failed to load Fs layout: could not verify integrity of files: <directory>, <number> data directories provided, but expected <number>
-fs_data_dirs で指定されたディスク数が、-fs_metadata_dir に記録されているディスク数と一致しません。 -fs_data_dirs を更新して、ディスク数が -fs_metadata_dir に記録されているものと一致するようにしてください。
スレッド作成失敗(pthread_create エラー 11)
pthread_create failed: Resource temporarily unavailable (error 11)
次の原因を順番に確認してください。
プロセス制限の不足
最大ユーザープロセス数の現在の制限を確認してください。
ulimit -a
値が低すぎる場合は、/etc/security/limits.conf を変更するか、/etc/security/limits.d/kudu.conf を作成することで値を大きくします。
ハイブリッドデプロイにおける Kudu クライアント V0.8 のスレッドリーク
ハイブリッドデプロイでは、Kudu クライアント V0.8 を使用すると、Spark エグゼキューターがスレッドをリークする可能性があります。これは KUDU-1453 に記載されている既知のイシューです。この問題を解決するには、Kudu クライアント V0.9 にアップグレードしてください。
Trino シャットダウンのスレッドリーク
Trino が終了すると、シャットダウンフックスレッドは要素を待機して BlockingQueue の take メソッドでブロックされます。このスレッドは中断できないため、EMR コントロールは SIGTERM シグナルを送信し続け、プロセス制限に達するまで新しい SIGTERM ハンドラースレッドを生成します。
Trino 側で問題を修正するか、kill -9 でプロセスを強制終了してください。
Jindo SDK のスレッドプールリーク
Spark は、書き込みジョブに JindoOssCommitter クラスを使用します。このクラスは、oss-committer-pool という名前のスレッドプールを生成する JindoOssMagicCommitter オブジェクトを作成します。このスレッドプールは静的ではなく、シャットダウンされることはありません。新しい JindoOssMagicCommitter オブジェクトが作成されると、スレッドプールは解放されることなく蓄積されます。これは特に Spark Streaming または Structured Streaming のワークロードで発生しやすくなります。
この問題を回避するには、次の Spark パラメーターを追加してください。
spark.sql.hive.outputCommitterClass=org.apache.hadoop.mapreduce.lib.output.FileOutputCommitter
spark.sql.sources.outputCommitterClass=org.apache.hadoop.mapreduce.lib.output.FileOutputCommitter
最も多くのスレッドを消費しているプロセスの特定
次の threads_monitor.sh スクリプトを使用して、最も多くのスレッドを消費しているプロセスを特定してください。
#!/bin/bash
total_threads=0
max_pid=-1
max_threads=-1
for tid in `ls /proc`
do
if [[ $tid != *self && -f /proc/$tid/status ]]; then
num_threads=`cat /proc/$tid/status | grep Threads | awk '{print $NF}'`
((total_threads+=num_threads))
if [[ ${max_pid} -eq -1 || ${max_threads} -lt ${num_threads} ]]; then
max_pid=${tid}
max_threads=${num_threads}
fi
# echo "Thread ${pid}: ${num_threads}"
fi
done
echo "Total threads: ${total_threads}"
echo "Max threads: ${max_threads}, pid is ${max_pid}"
ps -ef | grep ${max_pid} | grep -v grep
ソフトメモリ制限の超過
Rejecting Write request: Soft memory limit exceeded
書き込みスループットがソフトメモリ制限を超えています。この問題を解決するには、次のいずれかのパラメーターを調整してください。
メモリサイズを増やすには、 memory_limit_hard_bytes パラメーターを設定します。 デフォルト値は
0で、最大メモリ使用量がシステムによって自動的に設定されることを示します。 値を-1に変更すると、メモリ使用量は無制限になります。使用可能なメモリの割合を調整するには、memory_limit_soft_percentage パラメーターを設定します。デフォルト値は
80です。
Kudu の許可リスト設定とトークンの更新
期限切れトークンの更新と Kudu サービスの再起動
問題:Kudu サービスのトークンの有効期限が切れており、トークンを更新したい。
解決策:はい。トークンを更新するには、Kudu サービスを再起動する必要があります。
Impala から Kudu テーブルをクエリする際の「Unable to open the Kudu table」または「Unable to initialize the Kudu scan node」エラー
問題:Impala を使用して Kudu テーブルをクエリすると、次のいずれかのエラーが表示されます。
Kudu テーブルを開くことができませんKudu スキャンノードを初期化できません
原因:このエラーは通常、Kudu Master トークンの有効期限切れ、リーダーの取得の失敗、または認証の失敗が原因で発生します。このエラーは Ranger の設定とは関係ありません。
解決策:
Kudu の許可リスト設定に、クライアントサブネット (たとえば、
10.85.0.0/16) を追加します。Kudu サービスを再起動してください。
Kudu の再起動に関するよくある質問
Kudu サービスを再起動すると、コンソールが読み込み中のままになる
問題:Kudu サービスを再起動すると、コンソールページに読み込み中のスピナーが表示され続けます。
解決策:この問題は、ログオンセッションの有効期限が切れたことによりページの更新に問題が発生した場合、またはサービスの再起動プロセスでステータスの更新に時間がかかる場合に発生する可能性があります。ページを更新するか、操作履歴を確認してください。
Kudu サービス再起動中の Impala クエリの使用可否
問題:Kudu サービスの再起動中にデータをクエリできるか知りたい。
解決策:再起動中はクエリを実行しないことを推奨します。Impala サービス自体は使用可能な状態を維持する可能性がありますが、Kudu テーブルに関連するクエリは接続の中断により失敗します。
Kudu 再起動後のサービスの異常ステータスと手動起動プロンプト
問題:Kudu サービスを再起動すると、コンソールに異常なステータスが表示されるか、他のサービスを手動で起動するように求められます。
解決策:手動での操作は不要です。異常なステータスは通常、ヘルスチェックによってサービスが完全に起動していないことが検出されたために表示されます。サービスが自動的に回復し、マスターノードでクエリを実行できる場合は、再起動は完了しています。他のサービスを手動で起動する必要はありません。