このトピックでは、JindoData 4.X の既知の問題について説明します。
JindoData 4.6.X
4.6.2
デフォルトでは、JindoSDK 4.6.0 以降のバージョンで fs.oss.checksum.crc64.enable パラメーターは true に設定されています。これにより、CRC-64 を使用して書き込みパスのデータ整合性を検証できます。
ただし、この構成はOSS-HDFSへのデータ書き込みのパフォーマンスに影響します。パフォーマンスが最優先事項である場合は、CRC-64ベースの検証を無効にすることをお勧めします。CRC-64ベースの検証を無効にするには、次の操作を実行します。E-MapReduce (EMR) コンソールのHadoop-Commonサービスページの[構成] タブに移動します。[core-site.xml] タブをクリックし、キーが fs.oss.checksum.crc64.enable、値が false の構成項目を追加します。構成項目の追加方法の詳細については、「構成項目の管理」をご参照ください。
4.6.2
JindoSDK 4.6.1 がデプロイされている EMR クラスタで、パスワードなしモードで OSS-HDFS にアクセスすると、アクセストークンを更新する必要があることを示すエラーが発生します。その結果、複数のジョブが中断されます。
この問題を解決するには、固定の AccessKey ペアを使用するか、JindoSDK のバージョンを 4.6.2 以降に更新します。 JindoSDK のバージョンの更新方法の詳細については、「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
JindoSDK 4.6.1 がデプロイされている EMR クラスタで、パスワードなしモードで JindoUtil を使用すると、権限エラーが発生します。
この問題を解決するには、固定の AccessKey ペアを使用するか、JindoSDK のバージョンを 4.6.2 以降に更新します。 JindoSDK のバージョンの更新方法の詳細については、「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
デフォルトでは、fs.oss.checksum.crc64.enable パラメータは、JindoSDK 4.6.0 以降のバージョンで true に設定されています。これにより、CRC-64 を使用して書き込みパスのデータ整合性を検証できます。
ただし、この構成は OSS-HDFS へのデータ書き込みのパフォーマンスに影響します。主な懸念事項がパフォーマンスである場合は、CRC-64 ベースの検証を無効にすることをお勧めします。 CRC-64 ベースの検証を無効にするには、次の操作を実行します。E-MapReduce(EMR)コンソールの Hadoop-Common サービスページの [構成] タブに移動します。 [core-site.xml] タブをクリックし、キーが fs.oss.checksum.crc64.enable、値が false の構成項目を追加します。構成項目の追加方法の詳細については、「構成項目を管理する」をご参照ください。
4.6.0
JindoSDK 4.6.0 がデプロイされている EMR クラスタで、パスワードなしモードで OSS-HDFS にアクセスすると、アクセストークンを更新する必要があることを示すエラーが発生します。その結果、複数のジョブが中断されます。
この問題を解決するには、固定の AccessKey ペアを使用するか、JindoSDK のバージョンを 4.6.2 以降に更新します。JindoSDK のバージョンの更新方法の詳細については、「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
JindoSDK 4.6.0 および JindoFSx 4.6.0 がデプロイされ、Kerberos 認証が有効になっている EMR クラスタで、fs.oss.credentials.provider パラメータを com.aliyun.jindodata.oss.auth.RangerCredentialsProvider に設定すると、JindoFSx Namespace Service でメモリリークが発生します。
この問題を解決するには、JindoFSx と JindoSDK のバージョンを 4.6.2 以降に更新します。詳細については、「新しい EMR コンソールで EMR クラスタの JindoData をアップグレードする」および「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
JindoSDK 4.6.0 がデプロイされている EMR クラスタで、パスワードなしモードで JindoUtil を使用すると、権限エラーが発生します。
この問題を解決するには、固定の AccessKey ペアを使用するか、JindoSDK のバージョンを 4.6.2 以降に更新します。JindoSDK のバージョンの更新方法の詳細については、「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
デフォルトでは、JindoSDK 4.6.0 以降のバージョンで fs.oss.checksum.crc64.enable パラメータは true に設定されています。これにより、CRC-64 を使用して書き込みパスのデータ整合性を検証できます。
ただし、この構成は OSS-HDFS へのデータ書き込みのパフォーマンスに影響します。主な懸念事項がパフォーマンスである場合は、CRC-64 ベースの検証を無効にすることをお勧めします。 CRC-64 ベースの検証を無効にするには、次の操作を実行します。E-MapReduce(EMR)コンソールの Hadoop-Common サービスページの [構成] タブに移動します。 [core-site.xml] タブをクリックし、キーが fs.oss.checksum.crc64.enable、値が false の構成項目を追加します。構成項目の追加方法の詳細については、「構成項目の管理」をご参照ください。
JindoData 4.5.X
4.5.2
JindoSDK 4.5.2 と JindoFSx 4.5.2 がデプロイされ、Kerberos 認証が有効になっている EMR クラスタで、fs.oss.credentials.provider パラメーターを com.aliyun.jindodata.oss.auth.RangerCredentialsProvider に設定すると、JindoFSx Namespace Service でメモリリークが発生します。
この問題を解決するには、JindoFSx と JindoSDK のバージョンを 4.6.2 以降に更新します。詳細については、「新しい EMR コンソールで EMR クラスタの JindoData をアップグレードする」および「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
JindoSDK 4.5.2 がデプロイされている EMR クラスタで、パスワードなしモードで JindoUtil を使用すると、権限エラーが発生します。
この問題を解決するには、固定の AccessKey ペアを使用するか、JindoSDK のバージョンを 4.6.2 以降に更新します。JindoSDK のバージョンの更新方法の詳細については、「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
4.5.1
JindoSDK 4.5.1 と JindoFSx 4.5.1 がデプロイされ、Kerberos 認証が有効になっている EMR クラスタで、fs.oss.credentials.provider パラメーターを com.aliyun.jindodata.oss.auth.RangerCredentialsProvider に設定すると、JindoFSx Namespace Service でメモリリークが発生します。
この問題を解決するには、JindoFSx と JindoSDK のバージョンを 4.6.2 以降に更新します。詳細については、「新しい EMR コンソールで EMR クラスタの JindoData をアップグレードする」および「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
JindoSDK 4.5.1 がデプロイされている EMR クラスタで、パスワードなしモードで JindoUtil を使用すると、権限エラーが発生します。
この問題を解決するには、固定の AccessKey ペアを使用するか、JindoSDK のバージョンを 4.6.2 以降に更新します。JindoSDK のバージョンの更新方法の詳細については、「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
4.5.0
JindoSDK 4.5.0 と JindoFSx 4.5.0 がデプロイされ、Kerberos 認証が有効になっている EMR クラスタで、fs.oss.credentials.provider パラメーターを com.aliyun.jindodata.oss.auth.RangerCredentialsProvider に設定すると、JindoFSx Namespace Service でメモリリークが発生します。
この問題を解決するには、JindoFSx と JindoSDK のバージョンを 4.6.2 以降に更新します。詳細については、「新しい EMR コンソールで EMR クラスタの JindoData をアップグレードする」および「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
JindoSDK 4.5.0 がデプロイされている EMR クラスタで、パスワードなしモードでオブジェクトストレージサービス(OSS)または OSS-HDFS へのアクセスに失敗した後に再試行を実行すると、アクセストークンが更新されません。その結果、複数のジョブが中断されます。
この問題を解決するには、固定の AccessKey ペアを使用するか、JindoSDK のバージョンを 4.6.2 以降に更新します。JindoSDK のバージョンの更新方法の詳細については、「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
JindoSDK 4.5.0 がデプロイされている EMR クラスタで、パスワードなしモードで JindoUtil を使用すると、権限エラーが発生します。
この問題を解決するには、固定の AccessKey ペアを使用するか、JindoSDK のバージョンを 4.6.2 以降に更新します。JindoSDK のバージョンの更新方法の詳細については、「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
JindoData 4.4.X
JindoSDK 4.4.0、4.4.1、または 4.4.2 と JindoFSx 4.4.0、4.4.1、または 4.4.2 がデプロイされ、Kerberos 認証が有効になっている EMR クラスタで、fs.oss.credentials.provider パラメータを com.aliyun.jindodata.oss.auth.RangerCredentialsProvider に設定すると、JindoFSx Namespace Service でメモリリークが発生します。
この問題を解決するには、JindoFSx と JindoSDK のバージョンを 4.6.2 以降に更新します。詳細については、「新しい EMR コンソールで EMR クラスタの JindoData をアップグレードする」および「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
JindoSDK 4.4.0 がデプロイされている EMR クラスタで、パスワードなしモードで OSS または OSS-HDFS への高並列アクセスを開始すると、コアダンプが発生する場合があります。
この問題を解決するには、固定の AccessKey ペアを使用するか、JindoSDK のバージョンを 4.6.2 以降に更新します。 JindoSDK のバージョンの更新方法の詳細については、「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
JindoData 4.3.X
JindoSDK 4.3.0 がデプロイされた EMR V3.40.0 または V5.6.0 クラスタでは、ディレクトリが最後に更新された時刻を表示できません。これは、ディレクトリ時刻の表示により、ls コマンドのパフォーマンスが低下するためです。
時刻を表示するには、JindoSDK のバージョンを 4.3.1 以後に更新します。詳細については、「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
JindoSDK 4.3.0 がデプロイされた EMR V3.40.0 または V5.6.0 クラスタで MagicCommitter を使用すると、「Part number must be an integer between 1 and 10000」 というエラーメッセージが表示されます。これは、uploadPart 操作が過剰に呼び出されていることが原因です。
この問題を解決するには、JindoSDK のバージョンを 4.3.1 以後に更新します。詳細については、「新しい EMR コンソールで EMR クラスタの JindoSDK をアップグレードする」をご参照ください。
バージョン 4.3.0 の JindoFSx サーバー上の特定のパスにあるキャッシュデータを読み取ると、エラーが発生しますが、エラーはクライアントに返されません。その結果、クライアントは無効なデータを返します。
この問題を解決するには、JindoFSx のバージョンを 4.3.1 以後に更新します。詳細については、「新しい EMR コンソールで EMR クラスタの JindoData をアップグレードする」をご参照ください。
バージョン 4.3.0 の JindoFSx サーバーは、データキャッシュのためにデータをメモリにプリロードするために使用されるコマンドを処理できません。その結果、メモリにデータを読み込むときにエラーが発生し、キャッシュから無効なデータが読み取られる可能性があります。
この問題を解決するには、JindoFSx のバージョンを 4.3.1 以後に更新します。詳細については、「新しい EMR コンソールで EMR クラスタの JindoData をアップグレードする」をご参照ください。
バージョン 4.3.0 または 4.3.1 の JindoFSx サーバーでファイルハンドルリークが発生します。サーバーが長時間実行された後、オペレーティングシステムのプロセスによって開かれるファイルハンドルの数が上限に達する可能性があります。その結果、サーバーは新しいファイルハンドルを開くことができなくなり、サービスは利用できなくなります。
この問題を解決するには、JindoFSx のバージョンを 4.3.2 以後に更新します。詳細については、「新しい EMR コンソールで EMR クラスタの JindoData をアップグレードする」をご参照ください。
JindoData 4.2.X
JindoSDK 4.2.0 では、大きなファイルに対して seek メソッドを呼び出すと、オーバーフローの問題が発生する可能性があります。その結果、seek メソッドを使用する複数のジョブが OSS から大きなファイルを読み取ることができなくなる可能性があります。
JindoData 4.1.X
JindoSDK 4.1.0 では、大きなファイルに対して seek メソッドを呼び出すと、オーバーフローの問題が発生する可能性があります。その結果、seek メソッドを使用する複数のジョブが OSS から大きなファイルを読み取れない場合があります。
JindoData 4.0.X
JindoSDK 4.0.0 (EMR V3.39.0 または EMR V5.5.0) では、大きなファイルに対して seek メソッドを呼び出すと、オーバーフローの問題が発生する可能性があります。その結果、seek メソッドを使用する複数のジョブが OSS から大きなファイルを読み取れない場合があります。
その他の問題
JindoSDK では、80 GB を超えるサイズのファイルを OSS に書き込むことはできません。
JindoSDK では、追加モードで OSS にデータを書き込むことはできません。
JindoSDK では、クライアント側でアップロードされたデータを OSS で暗号化することはできません。
JindoSDK は、ブロックモードまたはキャッシュモードの以前のバージョンの JindoFS をサポートしていません。
OSS-HDFS では、ブロックモードの以前のバージョンの JindoFS を更新することはできません。
JindoDistCp を使用して、以前のバージョンから最新バージョンにデータを移行できます。