@Rocky We have a use case where we need to sink data from Flink into StarRocks. We’re currently planning to use the Flink–StarRocks connector, but we’ve seen users raise a few issues with it. Have those issues been fixed/addressed? Another option we’re considering is sinking the data into an intermediate Kafka topic and then using load routines to ingest the data into StarRocks. Which of these two approaches would be preferred, and why? Any guidance on the trade-offs between them would be appreciated.

I'm hitting a wall on this issue after 2 months of repeated efforts to address the issue. We had an issue where our front end node ran out of memory, we have 61 routine loads currently for 61 different kafka topics feeding into their own tables. We had a misconfiguration on our memory limits that had causes a bunch of OOM issues in our staging starrocks environment which causes a bunch of routine loads to fail, and we addressed this and some of the routine loads we simply deleted and recreated some of them were resumed and carried on correctly. The thing is we now have 83 transactions many of which seems completely stuck for 2 months now. They never timeout, they never recover, and there's seemingly no way to get rid of them. Most of these are routine loads, but some of them are stuck compaction transactions, which also seems to mean that subsequent transactions on many of the effected tables doesn't happen anymore at least for the given partition. I'm not really sure how to resolve this, it doesn't seem like I can kill these transactions because everything related to them can be stopped/killed/removed and the transactions continue to exist. This seems like it has a bunch of negative downstream effects. Right now I've killed ALL my routine loads (this is a staging env) and yet I have 64 transactions which are months old and almost all of them are ROUTINE_LOAD_TASK as their LoadJobSourceType. If I try

CANCEL LOAD FROM ...

on the stuck tasks it just said the load job doesn't exist. So these are just completely orphaned transactions that never go away. I'd really like a human (ideally a maintainer) to chime in on this, because Rocky hasn't been able to help with this and it seems like it might be a bug.

@Rocky I was thinking that "timestamp" column having in a create table will fail then i have to provide with a backticks but still it did work without having backticks so help me understand. CREATE TABLE IF NOT EXISTS user_activity_log ( user_id BIGINT NOT NULL COMMENT "Unique user identifier", event_type *VARCHAR*(50) NOT NULL COMMENT "Type of action performed", device_info *VARCHAR*(100) COMMENT "Client device metadata", -- Timestamp column mapping timestamp DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT "Time of the event" ) ENGINE = OLAP DUPLICATE *KEY*(user_id, event_type) PARTITION BY *RANGE*(timestamp) ( PARTITION p20260817 VALUES LESS THAN ("2026-08-18 000000"), PARTITION p20260818 VALUES LESS THAN ("2026-08-19 000000") ) DISTRIBUTED BY HASH(user_id) BUCKETS 8 PROPERTIES ( "replication_num" = "3" );

@Rocky If I need to split a large shared-data cluster into multiple smaller clusters by domain, is there a way to do this without re-ingesting data from upstream sources and does the fact that data already lives in S3 enable any zero-copy or low-cost migration path?

@Rocky currently i have hit with the below error "112829 Error loading schema content Error Code: 1064 Reach user-level(qualifiedUser: user) connection limit, currentUserMaxConn=1024, connectionMap.size=1, connByUser.totConn=15, user.currConn=1024, node=xxx.x.xxx.xxx:9010" how can we resolve this issue without restarting the FE node's / kill processes?

@Rocky would an older batch that has been materialised ever be rematerialised ahead of a newer batch?

@Rocky I have usecases where precomputed results are required which needs to refresh every day but not generally most other queries being used with this logics. is it better to have materialized view or task writing data to table?

@Rocky Getting this error : Unsupported Delta reader features: table requires reader table features [catalogManaged] which is unsupported by this version of Delta Kernel. What can be the issue? Writing using databricks-16.4LTS having catalogManaged property enabled. Reading via starrocks-4.1.1 failed with above error.

@Rocky What is the first time password for root user?

@Rocky I run StarRocks 4.0.0. I noticed that in sometimes some filters in WHERE close are not applied and I have inconsistent results. like 1st query returns 175 rows ( whichc is correct), second can return 178 with rows that supposed to be filtered. What can be the reason?

@Rocky, I am seeing this error in my starrocks logs and all my fe pods are down- OWER ==> /opt/starrocks/fe/log/fe.out <== [2026-08-20 063022] notify new FE type transfer: FOLLOWER [Thu Aug 20 063023 UTC 2026] Waiting to register as follower, retrying... [Thu Aug 20 063028 UTC 2026] Waiting to register as follower, retrying... ==> /opt/starrocks/fe/log/fe.log <== 2026-08-20 063032.442Z WARN (UNKNOWN starrocks-fe-2.starrocks-fe-search.trino.svc.cluster.local_9010_1778607365426(-1)|1) [ColocateTableIndex.cleanupInvalidDbOrTable():940] remove 0 invalid tableid: [] 2026-08-20 063032.693Z WARN (UNKNOWN starrocks-fe-2.starrocks-fe-search.trino.svc.cluster.local_9010_1778607365426(-1)|1) [GlobalStateMgr.loadImage():1699] Miss meta block [20001], This may not be a fatal error. It may be because there are new features in the version you upgraded this time, but there is no relevant metadata. [Thu Aug 20 063033 UTC 2026] Waiting to register as follower, retrying... [Thu Aug 20 063038 UTC 2026] Waiting to register as follower, retrying... 2026-08-20 063042.202Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1001 replayedJournalId: 20143584 2026-08-20 063042.202Z WARN (replayer|134) [GlobalStateMgr$5.setCanRead():2014] meta out of date. current time: 1787207442202, synchronized time: 1787175366668, has log: true, fe type: FOLLOWER 2026-08-20 063043.206Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20143999 [Thu Aug 20 063043 UTC 2026] Waiting to register as follower, retrying... 2026-08-20 063044.211Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20144350 2026-08-20 063045.214Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20144732 2026-08-20 063046.258Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1042 replayedJournalId: 20145200 2026-08-20 063047.262Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20145531 2026-08-20 063047.264Z WARN (replayer|134) [GlobalStateMgr$5.setCanRead():2014] meta out of date. current time: 1787207447264, synchronized time: 1787175386680, has log: true, fe type: FOLLOWER 2026-08-20 063048.269Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 [Thu Aug 20 063114 UTC 2026] Waiting to register as follower, retrying... 2026-08-20 063114.826Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1003 replayedJournalId: 20173278 2026-08-20 063115.830Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20173389 2026-08-20 063116.835Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1003 replayedJournalId: 20173852 2026-08-20 063117.839Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20174320 2026-08-20 063117.840Z WARN (replayer|134) [GlobalStateMgr$5.setCanRead():2014] meta out of date. current time: 1787207477840, synchronized time: 1787176087836, has log: true, fe type: FOLLOWER 2026-08-20 063118.843Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1001 replayedJournalId: 20174680 [Thu Aug 20 063119 UTC 2026] Waiting to register as follower, retrying... 2026-08-20 063119.849Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1004 replayedJournalId: 20175310 2026-08-20 063120.855Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1003 replayedJournalId: 20175640 2026-08-20 063121.860Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1004 replayedJournalId: 20176061 2026-08-20 063123.284Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1421 replayedJournalId: 20176258 2026-08-20 063123.284Z WARN (replayer|134) [GlobalStateMgr$5.setCanRead():2014] meta out of date. current time: 1787207483284, synchronized time: 1787176097841, has log: true, fe type: FOLLOWER [Thu Aug 20 063124 UTC 2026] Waiting to register as follower, retrying... 2026-08-20 063124.289Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1003 replayedJournalId: 20176724 2026-08-20 063125.291Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1001 replayedJournalId: 20177173 2026-08-20 063126.295Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1001 replayedJournalId: 20177586 2026-08-20 063127.302Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1005 replayedJournalId: 20178008 2026-08-20 063128.308Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1005 replayedJournalId: 20178445 2026-08-20 063128.309Z WARN (replayer|134) [GlobalStateMgr$5.setCanRead():2014] meta out of date. current time: 1787207488309, synchronized time: 1787176117848, has log: true, fe type: FOLLOWER [Thu Aug 20 063129 UTC 2026] Waiting to register as follower, retrying... 2026-08-20 063129.313Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1001 replayedJournalId: 20178847 2026-08-20 063130.316Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20180080 2026-08-20 063131.320Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20180746 2026-08-20 063132.322Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1001 replayedJournalId: 20181366 2026-08-20 063133.325Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1001 replayedJournalId: 20191333 2026-08-20 063133.327Z WARN (replayer|134) [GlobalStateMgr$5.setCanRead():2014] meta out of date. current time: 1787207493326, synchronized time: 1787176524936, has log: true, fe type: FOLLOWER [Thu Aug 20 063134 UTC 2026] Waiting to register as follower, retrying... 2026-08-20 063134.331Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20191780 2026-08-20 063135.334Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20192229 2026-08-20 063136.341Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1005 replayedJournalId: 20192799 2026-08-20 063137.343Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1001 replayedJournalId: 20193349 2026-08-20 063138.346Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20193873 2026-08-20 063138.348Z WARN (replayer|134) [GlobalStateMgr$5.setCanRead():2014] meta out of date. current time: 1787207498348, synchronized time: 1787176544947, has log: true, fe type: FOLLOWER [Thu Aug 20 063139 UTC 2026] Waiting to register as follower, retrying... 2026-08-20 063139.352Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1002 replayedJournalId: 20194343 2026-08-20 063140.355Z WARN (replayer|134) [GlobalStateMgr.replayJournalInner():2146] replay journal cost too much time: 1001 replayedJournalId: 20195171 2026-08-20 063141.200Z WARN (UNKNOWN starrocks-fe-2.starrocks-fe-search.trino.svc.cluster.local_9010_1778607365426(-1)|1) [GlobalStateMgr.waitForReady():1271] It took too much time for FE to transfer to a stable state(LEADER/FOLLOWER), it maybe caused by one of the following reasons: 1. There are too many BDB logs to replay, because of previous failure of checkpoint(you can check the create time of image file under meta/image dir). 2. Majority voting members(LEADER or FOLLOWER) of the FE cluster haven't started completely. 3. FE node has multiple IPs, you should configure the priority_networks in fe.conf to match the ip record in meta/image/ROLE. And we don't support change the ip of FE node. Ignore this reason if you are using FQDN. 4. The time deviation between FE nodes is greater than 5s, please use ntp or other tools to keep clock synchronized. 5. The configuration of edit_log_port has changed, please reset to the original value. 6. The replayer thread may get stuck, please use jstack to find the details. ]

@Rocky how to unload table into s3

@Rocky kushagra@Kushagras-MacBook-Pro ~ % kubectl logs starrocks-cn-1 -n trino -f [Thu Aug 20 130444 UTC 2026] Process conf file cn.conf ... [Thu Aug 20 130444 UTC 2026] Add myself (starrocks-cn-1.starrocks-cn-search.trino.svc.cluster.local:9050) into FE ... ERROR 1064 (HY000) at line 1: Compute node already exists with same host starrocks-cn-1.starrocks-cn-search.trino.svc.cluster.local and port 9050 [Thu Aug 20 130444 UTC 2026] run start_cn.sh

@Rocky ADLINE_EXCEEDED: CallOptions deadline exceeded after 29.999993370s. Name resolution delay 0.000000000 seconds. [closed=[], open=[[remote_addr=127.0.0.1/127.0.0.1:6090]]] 2026-08-20 161216.757Z ERROR (thrift-server-pool-98|2942) [SRTThreadPoolServer$WorkerProcess.run():321] Thrift Error occurred during processing of message. org.apache.thrift.transport.TTransportException: java.net.SocketException: Broken pipe at org.apache.thrift.transport.TIOStreamTransport.flush(TIOStreamTransport.java:206) ~[libthrift-0.20.0.jar:0.20.0] at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:64) ~[libthrift-0.20.0.jar:0.20.0] at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:40) ~[libthrift-0.20.0.jar:0.20.0] at com.starrocks.common.SRTThreadPoolServer$WorkerProcess.run(SRTThreadPoolServer.java:313) ~[starrocks-fe.jar:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?] at java.lang.Thread.run(Thread.java:840) ~[?:?] Caused by: java.net.SocketException: Broken pipe at sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:425) ~[?:?] at sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:445) ~[?:?] at sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:831) ~[?:?] at java.net.Socket$SocketOutputStream.write(Socket.java:1035) ~[?:?] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81) ~[?:?] at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142) ~[?:?] at org.apache.thrift.transport.TIOStreamTransport.flush(TIOStreamTransport.java:201) ~[libthrift-0.20.0.jar:0.20.0] ... 6 more 2026-08-20 161216.757Z WARN (thrift-server-pool-98|2942) [TIOStreamTransport.close():153] Error closing output stream. java.net.SocketException: Socket closed at sun.nio.ch.NioSocketImpl.ensureOpenAndConnected(NioSocketImpl.java:165) ~[?:?] at sun.nio.ch.NioSocketImpl.beginWrite(NioSocketImpl.java:371) ~[?:?] at sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:416) ~[?:?] at sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:445) ~[?:?] at sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:831) ~[?:?] at java.net.Socket$SocketOutputStream.write(Socket.java:1035) ~[?:?] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81) ~[?:?] at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142) ~[?:?] at java.io.FilterOutputStream.close(FilterOutputStream.java:182) ~[?:?] at org.apache.thrift.transport.TIOStreamTransport.close(TIOStreamTransport.java:151) ~[libthrift-0.20.0.jar:0.20.0] at org.apache.thrift.transport.TSocket.close(TSocket.java:238) ~[libthrift-0.20.0.jar:0.20.0] at com.starrocks.common.SRTThreadPoolServer$WorkerProcess.run(SRTThreadPoolServer.java:328) ~[starrocks-fe.jar:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?] at java.lang.Thread.run(Thread.java:840) ~[?:?] 2026-08-20 161216.757Z ERROR (thrift-server-pool-99|2943) [SRTThreadPoolServer$WorkerProcess.run():321] Thrift Error occurred during processing of message. org.apache.thrift.transport.TTransportException: java.net.SocketException: Broken pipe at org.apache.thrift.transport.TIOStreamTransport.flush(TIOStreamTransport.java:206) ~[libthrift-0.20.0.jar:0.20.0] at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:64) ~[libthrift-0.20.0.jar:0.20.0] at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:40) ~[libthrift-0.20.0.jar:0.20.0] at com.starrocks.common.SRTThreadPoolServer$WorkerProcess.run(SRTThreadPoolServer.java:313) ~[starrocks-fe.jar:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?] at java.lang.Thread.run(Thread.java:840) ~[?:?] Caused by: java.net.SocketException: Broken pipe at sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:425) ~[?:?] at sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:445) ~[?:?] at sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:831) ~[?:?] at java.net.Socket$SocketOutputStream.write(Socket.java:1035) ~[?:?] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81) ~[?:?] at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142) ~[?:?] at org.apache.thrift.transport.TIOStreamTransport.flush(TIOStreamTransport.java:201) ~[libthrift-0.20.0.jar:0.20.0] ... 6 more 2026-08-20 161216.758Z WARN (thrift-server-pool-99|2943) [TIOStreamTransport.close():153] Error closing output stream. java.net.SocketException: Socket closed at sun.nio.ch.NioSocketImpl.ensureOpenAndConnected(NioSocketImpl.java:165) ~[?:?] at sun.nio.ch.NioSocketImpl.beginWrite(NioSocketImpl.java:371) ~[?:?] at sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:416) ~[?:?] at sun.nio.ch.NioSocketImpl.write(NioSocketImpl.java:445) ~[?:?] at sun.nio.ch.NioSocketImpl$2.write(NioSocketImpl.java:831) ~[?:?] at java.net.Socket$SocketOutputStream.write(Socket.java:1035) ~[?:?] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81) ~[?:?] at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142) ~[?:?] at java.io.FilterOutputStream.close(FilterOutputStream.java:182) ~[?:?] at org.apache.thrift.transport.TIOStreamTransport.close(TIOStreamTransport.java:151) ~[libthrift-0.20.0.jar:0.20.0] at org.apache.thrift.transport.TSocket.close(TSocket.java:238) ~[libthrift-0.20.0.jar:0.20.0] at com.starrocks.common.SRTThreadPoolServer$WorkerProcess.run(SRTThreadPoolServer.java:328) ~[starrocks-fe.jar:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?] at java.lang.Thread.run(Thread.java:840) ~[?:?] 2026-08-20 161218.325Z WARN (port-connectivity-checker-3|1652) [PortConnectivityChecker.isPortConnectable():113] socket connection to starrocks-fe-1.starrocks-fe-search.trino.svc.cluster.local:9020 failed, reason: Connection refused 2026-08-20 161218.325Z WARN (starrocks-http-pool-4|2719) [HttpServerHandler$RequestHandlingWatch.finish():254] receive slow http request. uri: /api/transaction/commit?, startTime: 1787242286029, latency: 52295 ms 2026-08-20 161218.325Z WARN (PortConnectivityChecker|18) [PortConnectivityChecker.runAfterCatalogReady():90] checking for connectivity of starrocks-fe-1.starrocks-fe-search.trino.svc.cluster.local:9020 failed, not open 2026-08-20 161218.325Z WARN (starrocks-http-pool-2|2706) [TransactionLoadAction.executeWithoutPassword():238] com.starrocks.common.StarRocksException: Can not abort COMMITTED transaction 8361595, label is rw-txn-5a8c7571-cf18-4ff6-a37b-f8dc6239d6e1-1787242280555492 at com.starrocks.http.rest.transaction.TransactionWithoutChannelHandler.handleRollbackTransaction(TransactionWithoutChannelHandler.java:141) at com.starrocks.http.rest.transaction.TransactionWithoutChannelHandler.handle(TransactionWithoutChannelHandler.java:80) at com.starrocks.http.rest.TransactionLoadAction.executeTransaction(TransactionLoadAction.java:254) at com.starrocks.http.rest.TransactionLoadAction.executeWithoutPassword(TransactionLoadAction.java:227) at com.starrocks.http.rest.RestBaseAction.execute(RestBaseAction.java:187) at com.starrocks.http.rest.RestBaseAction.handleRequest(RestBaseAction.java:114) at com.starrocks.http.HttpServerHandler.lambda$handleActionAsync$0(HttpServerHandler.java:140) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:840) 2026-08-20 161218.325Z WARN (starmgr-heartbeatmgr-0|135) [StarletAgent.heartbeat():105] caught GRPC exception when sending heartbeat to worker starrocks-cn-0.starrocks-cn-search.trino.svc.cluster.local:9070, io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: CallOptions deadline exceeded after 1.999990960s. Name resolution delay 0.000000000 seconds. [closed=[], open=[[remote_addr=starrocks-cn-0.starrocks-cn-search.trino.svc.cluster.local/10.4.1.37:9070]]]. 2026-08-20 161218.325Z WARN (starrocks-http-pool-4|2719) [TransactionLoadAction.executeWithoutPassword():238] com.starrocks.common.StarRocksException: Can not abort COMMITTED transaction 8361590, label is rw-txn-8d66caae-093b-42cc-b713-ad98d6f02a17-1787242276271587 at com.starrocks.http.rest.transaction.TransactionWithoutChannelHandler.handleRollbackTransaction(TransactionWithoutChannelHandler.java:141) at com.starrocks.http.rest.transaction.TransactionWithoutChannelHandler.handle(TransactionWithoutChannelHandler.java:80) at com.starrocks.http.rest.TransactionLoadAction.executeTransaction(TransactionLoadAction.java:254) at com.starrocks.http.rest.TransactionLoadAction.executeWithoutPassword(TransactionLoadAction.java:227) at com.starrocks.http.rest.RestBaseAction.execute(RestBaseAction.java:187) at com.starrocks.http.rest.RestBaseAction.handleRequest(RestBaseAction.java:114) at com.starrocks.http.HttpServerHandler.lambda$handleActionAsync$0(HttpServerHandler.java:140) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:840) 2026-08-20 161218.326Z WARN (thrift-server-pool-49|2827) [FrontendServiceImpl.createPartitionProcess():2257] failed to add partitions com.starrocks.common.DdlException: Failed to create shard group. error: GRPCDEADLINE EXCEEDED CallOptions deadline exceeded after 29.999995330s. Name resolution delay 0.000000000 seconds. [closed=[], open=[[remote_addr=127.0.0.1/127.0.0.1:6090]]] at com.starrocks.lake.StarOSAgent.createShardGroup(StarOSAgent.java:479) ~[starrocks-fe.jar:?] at com.starrocks.server.LocalMetastore.createPartition(LocalMetastore.java:1907) ~[starrocks-fe.jar:?] at com.starrocks.server.LocalMetastore.createPartition(LocalMetastore.java:1894) ~[starrocks-fe.jar:?] at com.starrocks.server.LocalMetastore.createPartitionMap(LocalMetastore.java:1089) ~[starrocks-fe.jar:?] at com.starrocks.server.LocalMetastore.addPartitions(LocalMetastore.java:1353) ~[starrocks-fe.jar:?] at com.starrocks.server.LocalMetastore.addPartitions(LocalMetastore.java:971) ~[starrocks-fe.jar:?] at com.starrocks.service.FrontendServiceImpl.createPartitionProcess(FrontendServiceImpl.java:2251) ~[starrocks-fe.jar:?] at com.starrocks.service.FrontendServiceImpl.createPartition(FrontendServiceImpl.java:2086) ~[starrocks-fe.jar:?] at com.starrocks.thrift.FrontendService$Processor$createPartition.getResult(FrontendService.java:6705) ~[starrocks-fe.jar:?] at com.starrocks.thrift.FrontendService$Processor$createPartition.getResult(FrontendService.java:6682) ~[starrocks-fe.jar:?]

@Rocky how to fix 78 inconsistent tablets in my Starrocks cluster?

Firebolt core is open source now, seems a strong competitor to starrocks, especially it seems it is much more light weight. What are the thoughts there ?

@Rocky I have 2 questions 1. When I define a primary key table with live partitions to be 25, and a fake record generates future partitions, ahead of present time, does this evict older partitions? Or is partition expiry calculated from present time. 2. What user permissions exactly are required to create a materialized view?

@Rocky how it comes that in memory management I see: process memory: 54gb jemmaloc: 54gb query memory: 102gb?

@Rocky what is impact of pipeline_dop to half the vcpu instead of default 0 in the cluster in either table scan or join or any query operations?

@Rocky Give me your opinion on this MV definition CREATE MATERIALIZED VIEW requests.mv_pkg_avails_nobids PARTITION BY hour_start DISTRIBUTED BY HASH(package_id) ORDER BY (package_id) REFRESH ASYNC EVERY (INTERVAL 10 MINUTE) PROPERTIES ( "auto_refresh_partitions_limit" = "3", "partition_refresh_number" = "1" ) AS SELECT date_trunc('hour', received) AS hour_start, pid AS package_id, property_id, media_owner_id, country, region, CONCAT(',', array_join(array_sort(array_distinct(formats)), ','), ',') AS format_set, SUM(num_requests) AS n FROM requests.requests, unnest(array_distinct(inventory_package_ids)) AS t(pid) WHERE has_bid = 0 GROUP BY hour_start, package_id, property_id, media_owner_id, country, region, format_set; Base table is distributed by auction_id and ordered by (received, auction_id)

@Rocky I am adding BE node to my shared nothing cluster. How do i know if the tablet rebalancing is done?

@Rocky what are new prom metrics StarRocks got since 4.0.0?

Hi everyone - I filed a new ticket for Apache Iceberg support, specifically for encrypted datasets and supporting Icebergs standard. My company is blocked from adopting Starrocks further (replacing Trino) until this is supported, so I'm hoping that this will be coming to Starrocks soon. github.com/StarRocks/starrocks/issues/78127 iceberg.apache.org/docs/latest/encryption

🧵 rack aware routine load ingestion in starrocks

@Rocky I have installed StarRocks version

4.1.4

via operator helm, is there a way in the helm to auto-scale fe pods, as today I have 3 pods with 8 core, 32 GB per pod, what's the max concurrency I can have for queries. I have external iceberg catalogs also if there is way to auto-scale FE so that it can handle my burst loads during certain times

Throttling Routine Load ingestion rate — options other than a resource group? StarRocks 3.5.x, Routine Load from Kafka into a DUPLICATE KEY table When a backlog builds, the job drains it at full speed — we measured ~15K rows/s average and 68K peak — which spikes BE disk IO exactly when we'd rather it caught up gently. We can't pace it with max_batch_rows: it appears to be floored at 200,000, so setting it lower has no effect. max_batch_interval caps how long a task runs rather than its rate, and desired_concurrent_number is the only other lever we've found. The levers all bound batch size or duration, not the gap between tasks — so on a backlog it just runs back-to-back 200K batches. is there some similar way like we have in kafak via concurrency and other configs as fine control

@Rocky I have metadata mem under mem_tracker 19gb and peak is also 19gb why it can be so? it does not free up that space and allocates it statically ?

@Rocky when can we expect

4.1.5

release? It contains an important fix for a very painful problem and we consider building our own docker images because of it.

@Rocky I have shared data architecture starrocks 4.0.8 running with cache enabled on tables. Lets say If some tablet blocks are cached on the disk, if I query after 1hour, will it get from cache or look at bucket for latest data? how is it controlled the freshness of data when cache is enabled?

Planning to set

lake_autovacuum_grace_period_minutes=43200 # 30 days

for a shared-data cluster (v3.4.10) to support 30-day point in time recovery. Has anyone run with grace period this high long-term? Curious about real-world impact on query performance, compaction behavior, and any surprises we should watch for. Our business requirement is to have a point in time recovery backup of last 15 days and we plan to take cluster_snapshot once a day and move it to separate s3 bucket before it is over-written by the later snapshot. thanks