[jira] [Created] (HBASE-28539) Merge of incremental backups fails if backups are on a separate FileSystem
Benny Colyn created HBASE-28539: --- Summary: Merge of incremental backups fails if backups are on a separate FileSystem Key: HBASE-28539 URL: https://issues.apache.org/jira/browse/HBASE-28539 Project: HBase Issue Type: Bug Affects Versions: 2.6.0, 4.0.0-alpha-1 Reporter: Benny Colyn When the backups are stored on a location that is not the DistributedFilesystem underpinning HBase itself merging of incremental backups fails. Detected with backups stored on S3A, but can be reproduced with any other (like LocalFilesystem). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28540) Cache Results in org.apache.hadoop.hbase.rest.client.RemoteHTable.Scanner
Istvan Toth created HBASE-28540: --- Summary: Cache Results in org.apache.hadoop.hbase.rest.client.RemoteHTable.Scanner Key: HBASE-28540 URL: https://issues.apache.org/jira/browse/HBASE-28540 Project: HBase Issue Type: Improvement Components: REST Reporter: Istvan Toth Assignee: Istvan Toth The implementation of org.apache.hadoop.hbase.rest.client.RemoteHTable.Scanner is very inefficient, as the standard next() methods makes separate a http request for each row. Performance can be improved by not specifying the row count in the REST call and caching the returned Results. Chunk size can still be influenced by scan.setBatch(); -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28541) RegionServer abort when max sequence id wrong
chaijunjie created HBASE-28541: -- Summary: RegionServer abort when max sequence id wrong Key: HBASE-28541 URL: https://issues.apache.org/jira/browse/HBASE-28541 Project: HBase Issue Type: Bug Affects Versions: 2.2.3 Reporter: chaijunjie When we disable a table, some region close failed because max sequence id is less than the old max sequence id, then RS abort...Then the region close success on another RS.. we just use bulkload...is it releated? 2024-04-20 23:44:20,611 | INFO | RpcServer.default.FPBQ.Fifo.handler=483,queue=33,port=21302 | Bulk-load file hdfs://hacluster/hbase/staging/cdr__boss20240420__t20amapi48eb4ce0k0t80jatvnnhpm5rohaj26a5rdsp0s7kifokcdd32ko89u7n/info/4f43f6cf569643da8ecc140668fa726e is on different filesystem than the destination store. Copying file over to destination filesystem. | org.apache.hadoop.hbase.regionserver.HRegionFileSystem.bulkLoadStoreFile(HRegionFileSystem.java:540) 2024-04-20 23:44:20,645 | INFO | RpcServer.default.FPBQ.Fifo.handler=483,queue=33,port=21302 | Copied hdfs://hacluster/hbase/staging/cdr__boss20240420__t20amapi48eb4ce0k0t80jatvnnhpm5rohaj26a5rdsp0s7kifokcdd32ko89u7n/info/4f43f6cf569643da8ecc140668fa726e to temporary path on destination filesystem: viewfs://ClusterX/hbase/data/default/boss20240420/dc30be37cbd0ddee2f49712c55fd36cd/.tmp/6f7e97f2e3994881a6e04b36759f495e | org.apache.hadoop.hbase.regionserver.HRegionFileSystem.bulkLoadStoreFile(HRegionFileSystem.java:544) 2024-04-20 23:44:20,648 | INFO | RpcServer.default.FPBQ.Fifo.handler=483,queue=33,port=21302 | Loaded HFile viewfs://ClusterX/hbase/data/default/boss20240420/dc30be37cbd0ddee2f49712c55fd36cd/.tmp/6f7e97f2e3994881a6e04b36759f495e into dc30be37cbd0ddee2f49712c55fd36cd/info as viewfs://ClusterX/hbase/data/default/boss20240420/dc30be37cbd0ddee2f49712c55fd36cd/info/3946dc15ea1c49b582a2ed175fe12ec3_SeqId_26_ - updating store file list. | org.apache.hadoop.hbase.regionserver.HStore.bulkLoadHFile(HStore.java:908) 2024-04-20 23:44:20,664 | INFO | RpcServer.default.FPBQ.Fifo.handler=483,queue=33,port=21302 | Loaded HFile viewfs://ClusterX/hbase/data/default/boss20240420/dc30be37cbd0ddee2f49712c55fd36cd/info/3946dc15ea1c49b582a2ed175fe12ec3_SeqId_26_ into dc30be37cbd0ddee2f49712c55fd36cd/info | org.apache.hadoop.hbase.regionserver.HStore.bulkLoadHFile(HStore.java:942) 2024-04-20 23:44:20,664 | INFO | RpcServer.default.FPBQ.Fifo.handler=483,queue=33,port=21302 | Successfully loaded viewfs://ClusterX/hbase/data/default/boss20240420/dc30be37cbd0ddee2f49712c55fd36cd/.tmp/6f7e97f2e3994881a6e04b36759f495e into dc30be37cbd0ddee2f49712c55fd36cd/info (new location: viewfs://ClusterX/hbase/data/default/boss20240420/dc30be37cbd0ddee2f49712c55fd36cd/info/3946dc15ea1c49b582a2ed175fe12ec3_SeqId_26_) | org.apache.hadoop.hbase.regionserver.HStore.bulkLoadHFile(HStore.java:914) 2024-04-20 23:44:23,592 | INFO | RpcServer.default.FPBQ.Fifo.handler=483,queue=33,port=21302 | Validating hfile at viewfs://ClusterX/tenant/hw_cdr/dsttab/load_20240420232000/boss20240420/info/a97bb2bfcb5244279bcedbe20ec8322b for inclusion in b3d102e51ca3b78a1078580ed8a002de/info | org.apache.hadoop.hbase.regionserver.HStore.assertBulkLoadHFileOk(HStore.java:817) 2024-04-20 23:44:23,669 | INFO | RpcServer.default.FPBQ.Fifo.handler=483,queue=33,port=21302 | Bulk-load file hdfs://hacluster/hbase/staging/cdr__boss20240420__t20amapi48eb4ce0k0t80jatvnnhpm5rohaj26a5rdsp0s7kifokcdd32ko89u7n/info/a97bb2bfcb5244279bcedbe20ec8322b is on different filesystem than the destination store. Copying file over to destination filesystem. | org.apache.hadoop.hbase.regionserver.HRegionFileSystem.bulkLoadStoreFile(HRegionFileSystem.java:540) 2024-04-20 23:44:23,743 | INFO | RpcServer.default.FPBQ.Fifo.handler=483,queue=33,port=21302 | Copied hdfs://hacluster/hbase/staging/cdr__boss20240420__t20amapi48eb4ce0k0t80jatvnnhpm5rohaj26a5rdsp0s7kifokcdd32ko89u7n/info/a97bb2bfcb5244279bcedbe20ec8322b to temporary path on destination filesystem: viewfs://ClusterX/hbase/data/default/boss20240420/b3d102e51ca3b78a1078580ed8a002de/.tmp/f40ec16d10ab4474ace7af41d9126aa0 | org.apache.hadoop.hbase.regionserver.HRegionFileSystem.bulkLoadStoreFile(HRegionFileSystem.java:544) 2024-04-20 23:44:23,747 | INFO | RpcServer.default.FPBQ.Fifo.handler=483,queue=33,port=21302 | Loaded HFile viewfs://ClusterX/hbase/data/default/boss20240420/b3d102e51ca3b78a1078580ed8a002de/.tmp/f40ec16d10ab4474ace7af41d9126aa0 into b3d102e51ca3b78a1078580ed8a002de/info as viewfs://ClusterX/hbase/data/default/boss20240420/b3d102e51ca3b78a1078580ed8a002de/info/7cfcf858a6b34bd1b9d47ccce5dde9e4_SeqId_41_ - updating store file list. | org.apache.hadoop.hbase.regionserver.HStore.bulkLoadHFile(HStore.java:908) 2024-04-20 23:44:23,760 | INFO | RpcServ
[jira] [Resolved] (HBASE-28466) Integration of time-based priority logic of bucket cache in prefetch functionality of HBase.
[ https://issues.apache.org/jira/browse/HBASE-28466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wellington Chevreuil resolved HBASE-28466. -- Resolution: Fixed Merged into feature branch. Thanks for the contribution, [~vinayakhegde] ! > Integration of time-based priority logic of bucket cache in prefetch > functionality of HBase. > > > Key: HBASE-28466 > URL: https://issues.apache.org/jira/browse/HBASE-28466 > Project: HBase > Issue Type: Task > Components: BucketCache >Reporter: Janardhan Hungund >Assignee: Vinayak Hegde >Priority: Major > Labels: pull-request-available > > This Jira tracks the integration of the framework of APIs (implemented in > HBASE-28465) related to data tiering into prefetch logic of HBase. The > implementation should filter out the cold data and enable the prefetching of > hot data into bucket cache. > Thanks, > Janardhan > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28542) Refactoring Data Tiering Management for Improved Extensibility and Maintainability
Vinayak Hegde created HBASE-28542: - Summary: Refactoring Data Tiering Management for Improved Extensibility and Maintainability Key: HBASE-28542 URL: https://issues.apache.org/jira/browse/HBASE-28542 Project: HBase Issue Type: Task Components: BucketCache Reporter: Vinayak Hegde Assignee: Vinayak Hegde This Jira focuses on refactoring the Data Tiering Management module to enhance modularity and remove the Singleton pattern. The objective is to restructure the codebase for better separation of concerns and increased flexibility. This includes migrating away from the Singleton pattern in favor of a more modular approach, enabling easier integration of new data tiering types and handlers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28543) org.apache.hadoop.hbase.rest.PerformanceEvaluation does not read hbase-site.xml
Istvan Toth created HBASE-28543: --- Summary: org.apache.hadoop.hbase.rest.PerformanceEvaluation does not read hbase-site.xml Key: HBASE-28543 URL: https://issues.apache.org/jira/browse/HBASE-28543 Project: HBase Issue Type: Bug Components: REST Reporter: Istvan Toth Assignee: Istvan Toth I am trying to run org.apache.hadoop.hbase.rest.PerformanceEvaluation. It cannot connect to the ZK quorum specified in hbase-site.xml. It implements the Configurable interface incorrectly. Fixing the Configurable implementation results in connecing to ZK properly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Looking to create next RC for 2.6.0 this week
Please let me know if you have any blockers
[jira] [Created] (HBASE-28544) org.apache.hadoop.hbase.rest.PerformanceEvaluation does not evaluate REST performance
Istvan Toth created HBASE-28544: --- Summary: org.apache.hadoop.hbase.rest.PerformanceEvaluation does not evaluate REST performance Key: HBASE-28544 URL: https://issues.apache.org/jira/browse/HBASE-28544 Project: HBase Issue Type: Bug Components: REST Reporter: Istvan Toth org.apache.hadoop.hbase.rest.PerformanceEvaluation only uses the REST interface for Admin tasks like creating tables. All data access is done via the native RPC client, which makes the whole tool a big red herring. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Looking to create next RC for 2.6.0 this week
Thank you Bryan! I would like to get one improvement included as that would greatly help coprocessors implementing atomic updates. I will create Jira today and ping you, hopefully we get it in soon. In the worst case, it’s not a blocker and we can still proceed but it’s really going to make life better for some of the usecases. On Mon, Apr 22, 2024 at 5:41 AM Bryan Beaudreault wrote: > Please let me know if you have any blockers >
Re: Looking to create next RC for 2.6.0 this week
This might take some time from my side. Sorry Bryan, please go ahead as per your convenience. On Mon, Apr 22, 2024 at 10:45 AM Viraj Jasani wrote: > Thank you Bryan! I would like to get one improvement included as that > would greatly help coprocessors implementing atomic updates. I will create > Jira today and ping you, hopefully we get it in soon. > In the worst case, it’s not a blocker and we can still proceed but it’s > really going to make life better for some of the usecases. > > > On Mon, Apr 22, 2024 at 5:41 AM Bryan Beaudreault > wrote: > >> Please let me know if you have any blockers >> >
