既知の問題
トピック
- ソフトウェアのアップグレード中にトポロジの変更が失敗することがある
- Enterprise ManagerプラグインはEM 13.4.0.0以降と互換性がない
- このリリースでのマルチリージョン表の制限
- リリース18.1以降のJavaメモリー設定の更新回避策
- Streams APIおよびパーティションの移行中の順不同処理
- Oracle Big Data SQLで使用されるHiveはJava 9、10および11と互換性がない
- 移行ツールを使用したOCIへのインポート/エクスポートにはJava 8が必要
- 19.1より前の非Javaドライバには依然としてJava 8が必要
- IDENTITY列の定義がエクスポート・パッケージにない
- シンクでディスクがいっぱいになるとエクスポートがハングする
- 管理をホストするストレージ・ノードをデプロイするには、最小で5GBの空きディスク領域が必要
- ユーザーが管理ディレクトリ・サイズを管理する必要があり、すべての管理者を「RUNNING,UNKNOWN」状態にできる
- 全文検索付きのストアが非同期になる場合がある
- Data Verifierがデフォルトで無効になっている
- サブスクリプションが接続できず、InternalExceptionで失敗する
ソフトウェアのアップグレード中にトポロジの変更が失敗することがある
ストアが新しいソフトウェア・バージョンにアップグレードされている間に変更が実行されると、パーティションの移行を含むストア・トポロジの変更が失敗する場合があります。新しいトポロジをデプロイする計画を実行し、パーティションの移行中に計画で問題が発生した場合は、ストアのノードで異なるソフトウェア・バージョンが実行されているかどうかを確認し、古いバージョンを実行しているノードをアップグレードしてから計画を再試行してください。
次のトポロジ・コマンドのいずれかを使用してトポロジを変更すると、パーティションの移行が必要になる場合があります。結果のトポロジをplan deploy - topologyコマンドでデプロイすると、計画がストア・ソフトウェア・バージョンのアップグレード時に実行された場合に失敗する可能性があります。パーティション移行を生成する可能性があるトポロジ・コマンドは、次のとおりです。
- topology change-repfactor
- topology contract
- topology rebalance
- topology redistribute
他のトポロジ・コマンドは、パーティションの移行を生成せず、この問題を引き起こしません。
トポロジのデプロイメントが失敗した場合、次のようなエラーを探すことにより、ソフトウェア・バージョンのアップグレード中のパーティションの移行に関連しているかどうかを確認できます。
Plan 24 ended with errors. Use "show plan -id 24" for more information
Plan Deploy Topo
Id: 24
State: ERROR
Attempt number: 1
Started: 2020-04-10 15:19:59 UTC
Ended: 2020-04-10 15:24:48 UTC
Plan failures:
Failure 1: 17/MigratePartition PARTITION-2 from rg1 to rg2
failed. target=rg2-rn1 state=ERROR java.lang.Exception:
Migration of PARTITION-2 failed. Giving up after 10 attempt(s)
このようなパーティションの移行に関連する計画の障害が発生した場合、特にすべてのパーティション移行タスクで同様の障害が発生している場合は、'ping'または'verify topology'コマンドを使用してストアに関する情報を表示し、異なるストレージ・ノードが異なるメジャーまたはマイナー・ソフトウェア・バージョンで実行されているかどうかを確認します。その場合は、古いソフトウェアを実行しているノードを最新のバージョンにアップグレードしてから、'plan deploy - topology'コマンドを再試行してください。
Enterprise ManagerプラグインがEM 13.4.0.0以降と互換性がない
Oracle NoSQLのEnterprise Manager (EM)プラグインは、EMバージョン13.3.0.0およびそれ以前のEMバージョンと互換性があります。EMのプラグイン・サポートのアーキテクチャの変更のため、このプラグインはEMバージョン13.4.0.0およびそれ以降のバージョンと互換性がありません。
[KVSTORE-141]このリリースでのマルチリージョン表の制限
このリリースのマルチリージョン表機能には、次の制限があります。
- マルチリージョン表で行を挿入または更新するときにゼロ以外のTTLを指定することは、ドライバのアップグレード後にのみサポートされます。ローカル・ストアが完全にアップグレードされるまでは、失敗する可能性があります。さらに、複数リージョン・エージェントや、そのリージョンのストアがアップグレードされていない場合に、行がリモート・リージョンにレプリケートされると、TTLの有効期限が失われます。[#28165]
- 各リモート・リージョンでサポートされるサービス・エージェントは1つのみです。[#28166]
- 拡張度操作は、マルチリージョン表を含むストアでは実行しないでください。[#28164]
- ネットワーク障害、ストア障害、またはその他の理由によるエージェントの障害が原因で、マルチリージョン・エージェントがリモート・リージョンから長期間データをレプリケートできない場合、障害期間中にリモート・リージョンで削除された表エントリがローカル・リージョンで削除できなくなる可能性があります。[#28136]
- 複数リージョン表のリストアには、import、exportおよびsnapshotコマンドを使用しないでください。これらのコマンドでは、現在、リージョン情報や変更時間が考慮されていません。そのため、これらのコマンドを使用して複数リージョン表を以前のコンテンツにリストアすると、一貫性のない結果が生じる可能性があります。[KVSTORE-444]
- 19.5リリースを使用して作成されたマルチリージョン表は、このリリースまたはそれ以降のリリースでは使用できません。19.5リリースで作成された表のデータに対する競合解消は、その後のリリースでは正しく解決されない可能性があります。つまり、マルチリージョン表に、リモート表で更新された最新エントリが含まれていない可能性があります。マルチリージョン表を後続のリリースにアップグレードする場合も、限られたテストしか受けていないため検出されていない他の問題が発生する可能性があることに注意してください。
- 1つのストアに許可されるXRegionサービス・エージェントは1つのみです。[KVSTORE-984]
- マルチリージョン表を初期化すると、リモート・リージョンで削除が失われる可能性があります。[KVSTORE-986]
これらの制限はすべて、将来のリリースで削除される予定です。
リリース18.1以降のJavaメモリー設定の更新回避策
リリース18.3以降、Javaヒープのオーバーヘッドは、jvmOverheadPercentという名前の新しいストレージ・ノード・パラメータによって明示的に考慮され、デフォルト値は25%です。18.3より前のバージョンを使用してストアを実行しており、18.1リリース・ノートのメモリー割当てアルゴリズムでJavaメモリーのオーバーヘッドを考慮できずOutOfMemoryErrorsが発生する可能性があるの項で推奨された回避策でストアが構成されていた場合、18.3またはそれ以降のリリースへのアップグレード時に次の変更を行う必要があります。実行する変更は、RNごとに48GiBを超えるメモリー構成があるかどうかに基づいて、最初の回避策と2番目の回避策のどちらを実行したかによって異なります。
change-policy -params rnHeapPercent=68
-
ストレージ・ノードごとに、必要に応じてsnXを置換します。
plan change-parameters -service snX -wait -params rnHeapPercent=68
-
アップグレード後、各ストレージ・ノードに対して次の管理CLIコマンドを実行し、必要に応じてsnXを置き換えます。
plan change-parameters -service snX -wait -params memoryMB=0
これで完了です。
change-policy -params systemPercent=10
-
ストレージ・ノードごとに、必要に応じてsnXを置換します。
plan change-parameters -service snX -wait -params systemPercent=10 memoryMB=0
これで完了です。
複数のストレージ・ノードを変更してJavaメモリー設定を更新すると、次のようなキャッシュ・サイズの不一致に関する警告がデバッグ・ログに出力される場合があることに注意してください。
2019-11-14 15:26:40.762 UTC WARNING - [rg1-rn3] JE: Mismatched cache sizes, feeder:516738252 replica: 375809638 feeder off-heap: 0 replica off-heap: 0
すべてのストレージ・ノードに対する変更が完了したら、これらの警告がレポートされ続けることはなくなり、一時的な警告は問題なくなります。
[#27855]Streams APIおよびパーティションの移行中の順不同処理
アプリケーションが、複数のサブスクライバを持つサブスクリプションでStreams APIを使用し、パーティションの移行を伴う拡張度操作を実行する場合、アプリケーションはサブスクライバ間で操作を調整する必要がある場合があります。拡張度変更により、特定のキーに対して配信されているイベントが別のサブスクライバに切り替わることがあります。Streams APIは、2つのサブスクライバにイベントを適切な順序で配信しますが、サブスクライバがこれらのイベントに対するアクションを正しい順序で実行するようにするのはアプリケーションの責任です。将来のリリースでは、この調整の必要性をなくす予定です。
[#27541]Oracle Big Data SQLで使用されるHiveはJava 9、10および11と互換性がない
Oracle NoSQL Databaseは、Apache Hive (TM) 1.2.1およびHadoop-2.3.0-cdh5.1.0を使用してOracle Big Data SQLをサポートします。Java 9、10または11を使用してHiveを起動すると、次の警告が生成されます。
Logging initialized using configuration in file:/scratch/kmtest/release/hadoop/hive/conf/hive-log4j.properties
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.apache.hadoop.security.authentication.util.KerberosUtil (file:/scratch/kmtest/release/hadoop/hadoop-2.6.0-cdh5.4.8/share/hadoop/common/lib/hadoop-auth-2.6.0-cdh5.4.8.jar) to method sun.security.krb5.Config.getInstance()
WARNING: Please consider reporting this to the maintainers of org.apache.hadoop.security.authentication.util.KerberosUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: Unable to instantiate org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClient
at org.apache.hadoop.hive.ql.session.SessionState.start(SessionState.java:522)
at org.apache.hadoop.hive.cli.CliDriver.run(CliDriver.java:677)
at org.apache.hadoop.hive.cli.CliDriver.main(CliDriver.java:621)
...
Caused by: java.lang.RuntimeException: Unable to instantiate org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClient
at org.apache.hadoop.hive.metastore.MetaStoreUtils.newInstance(MetaStoreUtils.java:1523)
at org.apache.hadoop.hive.metastore.RetryingMetaStoreClient.<init>(RetryingMetaStoreClient.java:86)
at org.apache.hadoop.hive.metastore.RetryingMetaStoreClient.getProxy(RetryingMetaStoreClient.java:132)
このバージョンのHiveはJava 9で導入されたモジュールのサポートと互換性がないため、非互換性の警告が生成されます。Java 8を使用して、Oracle NoSQL Database 19.1でBig Data SQL問合せ用のHiveを起動します。
[#27565]移行ツールを使用したOCIへのインポート/エクスポートにはJava 8が必要
Oracle NoSQL Databaseオンプレミス移行ツールを使用し、データをOCI classicオブジェクト・ストアにインポート/エクスポートする場合は、Java 8を使用する必要があります。他のバージョンのJavaはサポートされていません。
19.1より前の非Javaドライバには依然としてJava 8が必要
プロキシの非互換性の問題のため、19.1より前にリリースされたOracle NoSQL非Javaドライバは、Java 10または11を使用するOracle NoSQL Database 19.1サーバーに接続する場合、引き続きJava 8を使用してプロキシを実行する必要があります。
IDENTITY列の定義がエクスポート・パッケージにない
インポート/エクスポート・ユーティリティでは、表のIDENTITY
列プロパティはエクスポート・パッケージDDLファイル(tableSchema.ddl
)にエクスポートされません。これはバグであり、将来のリリースで修正される予定です。ユーザーは、エクスポート・パッケージを使用した既存の表へのインポート時にのみ、欠落しているIDENTITY
列のプロパティを認識します。考えられるシナリオは次のとおりです。
- インポート表がすでに存在し、空ではなく、
IDENTITY
列がGENERATED ALWAYS
として定義されていると、ユーザーがGENERATED ALWAYS
に値を指定できないというエラーがOracle NoSQL Databaseから返されます。 - インポート表がすでに存在し、空ではなく、
IDENTITY
列がGENERATED BY DEFAULT
として定義されていると、レコードがすでに存在するというエラーがインポート/エクスポート・ユーティリティから返されます。ユーザーはインポート構成ファイルのオプションoverwrite
をtrue
に設定して、レコードを上書きすることを選択できます。 - インポート表が存在し、空であり、
IDENTITY
列がGENERATED ALWAYS
として定義されていると、ユーザーがGENERATED ALWAYS
に値を指定できないというエラーがOracle NoSQL Databaseから返されます。 - インポート表が存在し、空であり、
IDENTITY
列がGENERATED BY DEFAULT
として定義されていると、インポートは成功し、エクスポート・パッケージから値を取得します。ユーザーは、ALTER TABLE
コマンドを使用して、START WITH
値を順序内の次の値に設定できます。 - インポート表が存在しない場合、インポートは、
IDENTITY
列プロパティを持っていないエクスポート・パッケージのDDLを使用して表を作成するため、元のIDENTITY
列の情報が失われます。この問題は、将来のリリースで修正される予定です。インポートは、IDENTITY
列のない表のセマンティクスに従って成功します。
これらのすべてのオプションで、ALTER TABLE
コマンドを使用してIDENTITY
列プロパティを追加または変更できます。詳細は、IDENTITY
列のドキュメントを参照してください。
シンクでディスクがいっぱいになるとエクスポートがハングする
エクスポート中にシンクでディスク領域を使い果たすと、インポート/エクスポート・ツールがハングします。この問題は、将来のリリースで修正される予定です。ユーザーは、シンクでディスク領域を解放した後、エクスポートを再開する必要があります。ユーザーが-verbose
モードでエクスポートを開始した場合、java.io.IOException: No space left on device
が表示されます。
java -jar /home/jinzha/mywork/kv/lib/kvtool.jar export -helper-hosts 192.168.56.1:5000 \
-store kvstore -export-all -config /home/jinzha/mywork/export.cfg -verbose
Enter command: export
2019-04-22 23:55:16.316 UTC Start migration with configuration:
{
"configFileVersion" : 1,
"abortOnError" : true,
"source" : {
"type" : "nosqldb",
"helperHosts" : [ "192.168.56.1:5000" ],
"storeName" : "kvstore"
},
"sink" : {
"type" : "file",
"format" : "binary",
"path" : "/home/jinzha/mywork/data"
}
}
2019-04-22 23:55:16.338 UTC TaskWaiter thread spawned.
2019-04-22 23:55:16.693 UTC Exporting table schema: users. TableVersion: 1
2019-04-22 23:55:16.695 UTC Creating a new RecordStream for SchemaDefinition. File segment number: 1. Chunk sequence: abcdefghijlk
2019-04-22 23:55:16.701 UTC WriteTask worker thread spawned for SchemaDefinition
2019-04-22 23:55:16.704 UTC [binary]: Exported 1 record from tableSchema: 0min 0sec 361ms
2019-04-22 23:55:16.729 UTC Exporting store data with configuration: consistency=null; requestTimeout=0ms
2019-04-22 23:55:16.773 UTC Creating a new RecordStream for users. File segment number: 1. Chunk sequence: abcdefghijlk
2019-04-22 23:55:16.788 UTC WriteTask worker thread spawned for users
2019-04-22 23:55:18.954 UTC Exception exporting users. Chunk sequence: abcdefghijlk
java.io.IOException: No space left on device
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:326)
at oracle.kv.util.expimp.utils.exp.LocalStoreOutput.exportDataStream(LocalStoreOutput.java:211)
at oracle.kv.util.expimp.utils.exp.LocalStoreOutput.doExport(LocalStoreOutput.java:149)
at oracle.kv.util.expimp.utils.exp.AbstractStoreOutput$WriteTask.call(AbstractStoreOutput.java:639)
at oracle.kv.util.expimp.utils.exp.AbstractStoreOutput$WriteTask.call(AbstractStoreOutput.java:620)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2019-04-22 23:56:06.705 UTC Exception exporting SchemaDefinition. Chunk sequence: abcdefghijlk
java.io.IOException: No space left on device
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:326)
at oracle.kv.util.expimp.utils.exp.LocalStoreOutput.exportDataStream(LocalStoreOutput.java:211)
at oracle.kv.util.expimp.utils.exp.LocalStoreOutput.doExport(LocalStoreOutput.java:149)
at oracle.kv.util.expimp.utils.exp.AbstractStoreOutput$WriteTask.call(AbstractStoreOutput.java:639)
at oracle.kv.util.expimp.utils.exp.AbstractStoreOutput$WriteTask.call(AbstractStoreOutput.java:620)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2019-04-22 23:56:16.708 UTC [binary]: Writing continue.., wait 1 minutes
[#27574]管理をホストするストレージ・ノードをデプロイするには、最小で5GBの空きディスク領域が必要
管理者をホストするストレージ・ノードが、空きディスク領域が5GB未満のシステムにデプロイされている場合、次の例外が発生します。
Connected to Admin in read-only mode
(JE 18.1.8) Database AdminSchemaVersion not found. (18.1.3)
ストレージ・ノードを正常にデプロイするには、少なくとも5GBの空きディスク領域があることを確認してください。これと同じ問題は、KVLiteをデプロイしたときに発生します。この制限は将来のリリースで削除される予定です。[#26818]
ユーザーが管理ディレクトリ・サイズを管理する必要があり、すべての管理者を「RUNNING,UNKNOWN」状態にできる
すべての管理者にデフォルトで最大3GBのディスク領域が割り当てられます。これは、多くのインストールに十分な領域です。ただし、まれな状況では、特に管理者がディスクをストレージ・ノードと共有している場合は、この3GBの制限を変更する必要がある場合があります。詳細は、管理ディレクトリ・サイズの管理を参照してください。
管理者がディスク領域を使い果たすと、ディスク使用量がje.maxDiskまたはje.freeDiskの制限内にないため書込み操作が禁止されていることを示すエントリが管理ログに記録され、pingコマンドの出力に「RUNNING,UNKNOWN」状態にある管理者がすべて表示されます。管理ディレクトリ・サイズの管理の手順に従って、管理者を「RUNNING,MASTER」または「RUNNING,REPLICA」状態に戻します。
kv-> ping
Connected to Admin in read-only mode
Pinging components of store kvstore based upon topology sequence #106
90 partitions and 3 storage nodes
Time: 2018-04-03 08:20:22 UTC Version: 18.3.0
Shard Status: healthy:3 writable-degraded:0 read-only:0 offline:0 total:3
Admin Status: read-only
Zone [name=Houston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
RN Status: online:9 offline:0 maxDelayMillis:0 maxCatchupTimeSecs:0
Storage Node [sn1] on localhost:10000
Zone: [name=Houston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
Status: RUNNING Ver: 18.3.0 2018-04-03 05:36:25 UTC Build id: ec627ef967d6 Edition: Enterprise
Admin [admin1] Status: RUNNING,UNKNOWN
Rep Node [rg1-rn1] Status: RUNNING,REPLICA sequenceNumber:93 haPort:10011 delayMillis:0 catchupTimeSecs:0
Rep Node [rg2-rn1] Status: RUNNING,REPLICA sequenceNumber:93 haPort:10012 delayMillis:0 catchupTimeSecs:0
Rep Node [rg3-rn1] Status: RUNNING,MASTER sequenceNumber:92 haPort:10013
Storage Node [sn2] on localhost:11000
Zone: [name=Houston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
Status: RUNNING Ver: 18.3.0 2018-04-03 05:36:25 UTC Build id: ec627ef967d6 Edition: Enterprise
Admin [admin2] Status: RUNNING,UNKNOWN
Rep Node [rg1-rn2] Status: RUNNING,REPLICA sequenceNumber:93 haPort:11021 delayMillis:0 catchupTimeSecs:0
Rep Node [rg2-rn2] Status: RUNNING,MASTER sequenceNumber:93 haPort:11022
Rep Node [rg3-rn2] Status: RUNNING,REPLICA sequenceNumber:92 haPort:11023 delayMillis:0 catchupTimeSecs:0
Storage Node [sn3] on localhost:12000
Zone: [name=Houston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
Status: RUNNING Ver: 18.3.0 2018-04-03 05:36:25 UTC Build id: ec627ef967d6 Edition: Enterprise
Admin [admin3] Status: RUNNING,UNKNOWN
Rep Node [rg1-rn3] Status: RUNNING,MASTER sequenceNumber:93 haPort:12011
Rep Node [rg2-rn3] Status: RUNNING,REPLICA sequenceNumber:93 haPort:12012 delayMillis:0 catchupTimeSecs:0
Rep Node [rg3-rn3] Status: RUNNING,REPLICA sequenceNumber:92 haPort:12013 delayMillis:0 catchupTimeSecs:0
2018-04-03 08:18:52.254 UTC SEVERE [admin1] JE: Disk usage is not within
je.maxDisk or je.freeDisk limits and write operations are prohibited:
maxDiskLimit=2,097,152 freeDiskLimit=5,368,709,120
adjustedMaxDiskLimit=2,097,152 maxDiskOverage=83,086
freeDiskShortage=-6,945,071,104 diskFreeSpace=12,313,780,224
availableLogSize=-83,086 totalLogSize=2,180,238 activeLogSize=2,180,238
reservedLogSize=0 protectedLogSize=0 protectedLogSizeMap={}
2018-04-03 08:19:34.808 UTC SEVERE [admin2] JE: Disk usage is not within
je.maxDisk or je.freeDisk limits and write operations are prohibited:
maxDiskLimit=2,097,152 freeDiskLimit=5,368,709,120
adjustedMaxDiskLimit=2,097,152 maxDiskOverage=97,346
freeDiskShortage=-6,944,923,648 diskFreeSpace=12,313,632,768
availableLogSize=-97,346 totalLogSize=2,194,498 activeLogSize=2,194,498
reservedLogSize=0 protectedLogSize=0 protectedLogSizeMap={}
2018-04-03 08:19:36.063 UTC SEVERE [admin3] JE: Disk usage is not within
je.maxDisk or je.freeDisk limits and write operations are prohibited:
maxDiskLimit=2,097,152 freeDiskLimit=5,368,709,120
adjustedMaxDiskLimit=2,097,152 maxDiskOverage=101,698
freeDiskShortage=-6,944,923,648 diskFreeSpace=12,313,632,768
availableLogSize=-101,698 totalLogSize=2,198,850 activeLogSize=2,198,850
reservedLogSize=0 protectedLogSize=0 protectedLogSizeMap={}
全文検索付きのストアが非同期になる場合がある
全文検索のサポートを有効にしたストアでは、まれに、マスター・レプリケーション・ノードの内部コンポーネントが非同期になり、そのレプリケーション・ノードからの更新がElasticsearchエンジンへのフローを停止するというバグが発生する場合があります。この問題によって、ストアとElasticsearch間でデータが同期されなくなります。
問題が発生すると、Elasticsearchの索引への移入が停止します。この問題には、TextIndexFeederと呼ばれるコンポーネントのフィーダ・チャネルの停止が含まれ、レプリケーション・ノードのデバッグ・ログに記録されます。たとえば:
2018-03-16 11:23:46.055 UTC INFO [rg1-rn1] JE: Inactive channel: TextIndexFeeder-rg1-rn1-b4e92291-3c73-4128-9557-62dbd4e9ac78(2147483647) forced close. Timeout: 10000ms.
2018-03-16 11:23:46.059 UTC INFO [rg1-rn1] JE: Shutting down feeder for replica TextIndexFeeder-rg1-rn1-b4e92291-3c73-4128-9557-62dbd4e9ac78 Reason: null write time: 32ms Avg write time: 100us
2018-03-16 11:23:46.060 UTC INFO [rg1-rn1] JE: Feeder Output for TextIndexFeeder-rg1-rn1-b4e92291-3c73-4128-9557-62dbd4e9ac78 soft shutdown initiated.
2018-03-16 11:23:46.064 UTC WARNING [rg1-rn1] internal exception Expected bytes: 6 read bytes: 0
com.sleepycat.je.utilint.InternalException: Expected bytes: 6 read bytes: 0
at com.sleepycat.je.rep.subscription.SubscriptionThread.loopInternal(SubscriptionThread.java:719)
at com.sleepycat.je.rep.subscription.SubscriptionThread.run(SubscriptionThread.java:180)
Caused by: java.io.IOException: Expected bytes: 6 read bytes: 0
at com.sleepycat.je.rep.utilint.BinaryProtocol.fillBuffer(BinaryProtocol.java:446)
at com.sleepycat.je.rep.utilint.BinaryProtocol.read(BinaryProtocol.java:466)
at com.sleepycat.je.rep.subscription.SubscriptionThread.loopInternal(SubscriptionThread.java:656)
... 1 more
2018-03-16 11:23:46.064 UTC INFO [rg1-rn1] SubscriptionProcessMessageThread soft shutdown initiated.
2018-03-16 11:23:46.492 UTC INFO [rg1-rn1] JE: Feeder output for TextIndexFeeder-rg1-rn1-b4e92291-3c73-4128-9557-62dbd4e9ac78 shutdown. feeder VLSN: 4,066 currentTxnEndVLSN: 4,065
TextIndexFeederチャネルが停止されている場合、ユーザーはダミーの全文検索索引を作成することでリストアできます。次に、その実行方法の例を示します。
Elasticsearchがすでに登録されていると仮定して、管理CLIから次のコマンドを実行します。
execute 'CREATE TABLE dummy (id INTEGER,title STRING,PRIMARY KEY (id))'
execute 'CREATE FULLTEXT INDEX dummytextindex ON dummy (title)'
execute 'DROP TABLE dummy'
dummyは、前もって存在できない一時表の名前であることに注意してください。
全文検索索引を作成すると、ストアからElasticsearchへのチャネルが再構築され、データが最新の状態で同期されます。[#26859]
Data Verifierがデフォルトで無効になっている
データ検証はデフォルトでオフになっています。場合によっては、データ検証で大量のI/O帯域幅が使用され、システムの速度が低下しました。ユーザーは、管理CLIから次の2つのコマンドを発行して、データ検証を有効にできます。
plan change-parameters -wait -all-rns -params "configProperties=je.env.runVerifier=false"
change-policy -params "configProperties=je.env.runVerifier=false"
configProperties
パラメータに既存の設定があるサービスがストアにある場合、ユーザーは現在の値を取得して新しい設定とマージし、検証を無効にする必要があることに注意してください。
show param -service rg1-rn1
show param -policy
たとえば、rg1-rn1
で次のようなクリーナ・パラメータが設定されているとします。
kv-> show param -service rg1-rn1
[...]
configProperties=je.cleaner.minUtilization=40
configProperties
パラメータを更新するときは、検証の新しい設定を追加し、既存の設定をセミコロンで区切ります。
plan change-parameters -wait -all-rns -params "configProperties=je.cleaner.minUtilization=40;je.env.runVerifier=false"
[KVSTORE-639]サブスクリプションが接続できず、InternalExceptionで失敗する
パブリッシャの起動後、サブスクライバが接続する前に障害が原因でマスター転送が発生した場合、サブスクライバが接続しようとしたときにInternalException
が発生する可能性があります。例外メッセージに「Failed to connect, will retry after sleeping 3000 ms」と表示されます。この問題を回避するにはパブリッシャを再起動してください。[#27723]