@Rocky how to set qouta data for a starrock database. example i can create a dababase customer with maximun 100GB

To set a data quota for a StarRocks database, you can use the

ALTER DATABASE

statement. By default, the database storage quota is unlimited. Syntax

sql
ALTER DATABASE <db_name> SET DATA QUOTA <quota>;

You can specify the quota using units such as

B

,

K

,

KB

,

M

,

MB

,

G

,

GB

,

T

,

TB

,

P

, or

PB

. Example To set a maximum limit of 100GB for a database named

customer

, run:

sql
ALTER DATABASE customer SET DATA QUOTA 100GB;

Additional Notes * Replica Quota: You can also limit the number of replicas (tablets) in a database:

sql
    ALTER DATABASE customer SET REPLICA QUOTA 100000;

* Update Interval: StarRocks updates the tracked storage usage periodically. This is controlled by the FE configuration

db_used_data_quota_update_interval_secs

(default is 300 seconds/5 minutes). * Checking Current Data: To see the current storage size of your databases and tables, use:

sql
    SHOW DATA;

References • faq/Others.md • sql-reference/sql-statements/Database/ALTER_DATABASE.md • administration/management/resource_management/Query_management.md • quick_start/shared-data.md • administration/management/FE_configuration.md • faq/Sql_faq.md • knowledge/usage/best-practice.md • administration/management/monitor_manage_big_queries.md

@Rocky i have installed AudiLog, Name |Value -----------+---------- Name |AuditLoade Type |AUDIT Description|Available Version |5.0.0 JavaVersion|11.0.23 ClassName |com.starro SoName | Sources |/home/syss Status |INSTALLED Properties |{} but nothing show in SELECT * FROM starrocks_audit_db__.starrocks_audit_tbl__;

If the

AuditLoader

plugin is installed but no data is showing in your audit table, it is usually due to one of the following reasons. 1. Check Table Partitions The audit table is typically created with Dynamic Partitioning. By default, StarRocks creates the first partition about 10 minutes after the table is created. If there are no partitions, the loader cannot insert data. * Verify: Run

SHOW PARTITIONS FROM starrocks_audit_db*.starrocks_audit_tbl*;

. * Fix: If no partitions exist, wait 10 minutes or manually add a partition for today. 2. Verify

plugin.conf

Configuration The

AuditLoader

reads its configuration (user, password, FE port) from a file called

plugin.conf

inside the zip package you used for installation. If you did not edit this file before zipping and installing, the loader will fail to connect. * Important: You cannot edit

plugin.conf

after the plugin is installed. * Fix: 1. Uninstall:

UNINSTALL PLUGIN AuditLoader;

2. Unzip your

auditloader.zip

. 3. Edit

plugin.conf

to ensure

user

,

password

, and

frontend_host_port

(usually

127.0.0.1:8030

) are correct. 4. Zip it back:

zip -q -m -r auditloader.zip auditloader.jar plugin.conf plugin.properties

5. Re-install:

INSTALL PLUGIN FROM "/path/to/auditloader.zip";

3. Audit Log Format Conflict Recent StarRocks versions (v3.2.7+) introduced an FE configuration

audit_log_json_format

. * The

AuditLoader

plugin expects the text/pipe-separated format. If you set

audit_log_json_format = true

in your

fe.conf

, the plugin will fail to parse the logs. * Fix: Ensure

audit_log_json_format

is

false

(the default). 4. Check

fe.log

for Errors The

AuditLoader

runs as a background thread in the FE. Any errors (like "Access Denied" or "Table not found") are logged in the standard

fe.log

. * Action: Search your

fe.log

for the keyword `audit`:

bash
    grep -i "audit" fe.log

Look for errors related to

Stream Load

or

AuditLoaderPlugin

. 5. Check if

fe.audit.log

exists The plugin works by reading the local

fe.audit.log

file. * Action: Ensure that the file

fe/log/fe.audit.log

exists and is being updated with new queries. If this file is empty, the plugin has nothing to load. 6. Batch Interval The loader does not insert rows instantly. It buffers them based on

max_batch_interval_sec

(default is 60 seconds). Wait at least a minute after running some test queries before checking the table again. References • administration/management/audit_loader.md • administration/management/FE_configuration.md • administration/management/logs.md • sql-reference/sql-statements/cluster-management/plugin/SHOW_PLUGINS.md References • administration/management/FE_configuration.md • administration/management/logs.md • administration/management/audit_loader.md

@Rocky shoud i change a table "replication_num" = "1" to "replication_num" = "2"?

For a production environment, you should avoid

replication_num = 1

because it offers no data redundancy. If the node (BE) storing that data fails, the data becomes unavailable and may be permanently lost. Whether you should choose 2 or 3 depends on your cluster size and reliability needs: 1. The Standard: 3 Replicas StarRocks is designed to work best with 3 replicas (the default). * High Availability: It can tolerate the complete failure of one BE node without any downtime or data loss. * Quorum: By default, StarRocks uses a "Majority" write quorum. With 3 replicas, it only needs 2 to acknowledge a write to succeed, which balances performance and safety. 2. The Middle Ground: 2 Replicas You should only use 2 replicas if you are limited by hardware (e.g., you only have 2 BE nodes). * Risk: While better than 1, if one node is down and the second node experiences a disk failure, your data is gone. * Requirement: You must have at least 2 BE nodes to set this. Summary Comparison Replicas | Data Loss Risk | Availability | Min. BE Nodes 1 | High (Single point of failure) | No HA | 1 2 | Medium | Low HA (Tolerates 1 node failure, but no buffer) | 2 3 | Low | Full HA (Standard production setup) | 3 ────────── How to change the replication number If you decide to increase the replicas, use the following commands. Note that this will trigger a background task to clone data, which consumes disk space and IO. For a non-partitioned table:

sql
ALTER TABLE your_table_name SET ("replication_num" = "3");

For a partitioned table (to update existing and future partitions):

sql
-- 1. Update all existing partitions
ALTER TABLE your_table_name MODIFY PARTITION (*) SET ("replication_num" = "3");

-- 2. Update the default for future partitions
ALTER TABLE your_table_name SET ("default.replication_num" = "3");

-- 3. If using Dynamic Partitioning, update that property too
ALTER TABLE your_table_name SET ("dynamic_partition.replication_num" = "3");

Recommendation: If you have 3 or more BE nodes, change it to 3. If you only have 2 BE nodes, change it to 2. References • knowledge/usage/best-practice.md • administration/management/resource_management/Replica.md • sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE.md ) References • administration/management/resource_management/Replica.md • knowledge/usage/best-practice.md • administration/management/FE_configuration.md • sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE.md • administration/management/BE_configuration.md

@Rocky what happen to table when i change "replication_num" = "1" --> "replication_num" = "2"? does starrock auto copy all data to second BE

Yes, StarRocks automatically handles the replication process in the background. When you run the

ALTER TABLE

command to increase

replication_num

, you are essentially telling the Frontend (FE) that each tablet in that table now "needs" one more replica. What happens behind the scenes: 1. Detection: The FE's "Tablet Checker" background process (which runs every 20 seconds by default) scans the table and notices that the actual number of replicas (1) is less than your new target (2). It marks these tablets as having a

REPLICA_MISSING

status. 2. Scheduling: The FE's "Tablet Scheduler" generates Clone Tasks. It identifies a healthy source BE (the one that has the existing data) and selects a target BE (the second node) to host the new replica. 3. Data Copy (Cloning): The target BE pulls a copy of the data files from the source BE. This is a physical file copy (cloning). 4. Completion: Once the target BE finishes copying and reports success to the FE, the FE updates its metadata. The table is now considered healthy with 2 replicas. Important details: * Availability: Your table remains online and readable/writable during this process. * Performance: The copying happens in the background. StarRocks limits the number of concurrent clone tasks (default 2 per disk) to prevent the background copy from overwhelming your cluster's I/O and network. * Space: You must ensure the second BE has enough disk space to hold the new copy of the data. How to monitor the progress: You can see the actual background tasks being executed by the Tablet Scheduler using these commands: * Check pending tasks:

sql
    SHOW PROC '/cluster_balance/pending_tablets';

* Check currently running copy tasks:

sql
    SHOW PROC '/cluster_balance/running_tablets';

* Check if the table is healthy (all replicas reached):

sql
    -- Replace 'db_name' and 'table_name' with yours
    SHOW TABLE STATUS FROM db_name LIKE 'table_name';

Alternatively, check the tablet health directly:

sql
    SHOW TABLETS FROM table_name;

In the output of

SHOW TABLETS

, you will see a

ReplicaCount

column. Once the process is finished, it should show

2

for every tablet. References • administration/management/resource_management/Replica.md • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md • knowledge/usage/best-practice.md References • administration/management/resource_management/Replica.md

@Rocky `8060`: BE bRPC port (

brpc_port

) does this need to open in firewall between my 2 BE? what port need open

Yes, the

8060

(bRPC port) must be open between your BE nodes. In StarRocks, the

brpc_port

is used for internal data transmission. Specifically, when you run a query that requires a shuffle (data exchange) or when data needs to be copied between BEs for replication (cloning), the BEs communicate with each other over this port using the bRPC protocol. If this port is blocked, your cluster might start, but queries will fail with "RPC" or "Connection Refused" errors, and data replication between nodes will fail. All Required BE Ports You should ensure the following ports are open between all BEs and between FEs and BEs: Port | Name | Purpose | Communication Type 8060 |

brpc_port

| Data Exchange / RPC | BE $\leftrightarrow$ BE, FE $\to$ BE 9060 |

be_port

| Thrift Server (Requests) | FE $\to$ BE 9050 |

heartbeat_service_port

| Heartbeat & Status | FE $\to$ BE 8040 |

be_http_port

| HTTP Service (Download/Upload) | BE $\leftrightarrow$ BE, FE $\to$ BE 9070 |

starlet_port

| Internal agent service | BE $\leftrightarrow$ BE Summary Recommendation * BE $\leftrightarrow$ BE: Open

8060

,

8040

, and

9070

. * FE $\to$ BE: Open

9060

,

9050

,

8060

, and

8040

. If you are using a security group or firewall (like

iptables

or

firewalld

), it is usually easiest to allow all traffic on all ports between the internal IP addresses of your cluster nodes (FE and BE) to avoid performance issues or unexpected failures. References • deployment/environment_configurations.md • administration/management/BE_configuration.md • deployment/deploy_manually.md References • administration/management/BE_configuration.md • deployment/environment_configurations.md • deployment/deploy_manually.md • administration/management/FE_configuration.md • faq/Deploy_faq.md

@Rocky SQL Error [1064] [42000]: transmit chunk rpc failed [dest_instance_id=019e6245-7b06-7390-a791-1f80d2794775] [dest=10.0.27.71:8060] detail:brpc failed, error=Host is down, error_text=[E112]Not connected to 10.0.27.71:8060 yet, server_id=17179874804 [R1][E112]Not connected to 10.0.27.71:8060 yet, server_id=17179874804 [R2][E112]Not connected to 10.0.27.71:8060 yet, server_id=17179874804 [R3][E112]Not connected to 10.0.27.71:8060 yet, server_id=17179874804, host: unknown transmit chunk rpc failed [dest_instance_id=019e6245-7b06-7390-a791-1f80d2794775] [dest=10.0.27.71:8060] detail:brpc failed, error=Host is down, error_text=[E112]Not connected to 10.0.27.71:8060 yet, server_id=17179874804 [R1][E112]Not connected to 10.0.27.71:8060 yet, server_id=17179874804 [R2][E112]Not connected to 10.0.27.71:8060 yet, server_id=17179874804 [R3][E112]Not connected to 10.0.27.71:8060 yet, server_id=17179874804, host: unknown

The error

[E112] Not connected to 10.0.27.71:8060 yet

(with

Host is down

) means one of your StarRocks BE nodes tried to send data to the node at

10.0.27.71

, but the network connection failed. Since you just changed your replication number, StarRocks is trying to copy data between nodes using this port, and the failure is preventing it from completing. Troubleshooting Steps 1. Check if the BE process is running On the target machine (

10.0.27.71

), check if the StarRocks BE process is actually alive:

bash
ps aux | grep starrocks_be

If it's not running, check the

log/be.INFO

or

log/be.WARNING

files on that machine to see if it crashed or failed to start. 2. Check if port 8060 is listening On

10.0.27.71

, verify the BE has successfully bound to the bRPC port:

bash
# You may need sudo for -p
netstat -tlnp | grep 8060

If nothing shows up, the BE did not start correctly or failed to bind to that port. 3. Test connectivity from the SOURCE node Go to the other BE node (the one that threw the error) and try to connect to the target node manually:

bash
telnet 10.0.27.71 8060
# OR
nc -zv 10.0.27.71 8060

* If it times out: A firewall (iptables, firewalld) or a Cloud Security Group (AWS/GCP/Azure) is blocking port 8060. * If it says "Connection refused": The target BE is reachable, but it isn't listening on that port (see Step 1 & 2). 4. Verify

priority_networks

If your machines have multiple network interfaces (e.g., a public and a private IP), StarRocks might be trying to connect to the wrong one. Check

conf/be.conf

on all nodes: * Ensure

priority_networks

is set to the correct CIDR (e.g.,

priority_networks = 10.0.27.0/24

). * If you change this, you must restart the BE. Why this happened now? When you changed

replication_num

from 1 to 2, StarRocks immediately triggered a "Clone Task." This task requires the BEs to talk to each other over the

brpc_port

(8060) to transfer the data. If this port was blocked all along, you wouldn't have noticed it until you added a second node or increased the cluster tried to use for replication or distributed queries. References • administration/management/BE_configuration.md • deployment/environment_configurations.md • faq/operation_maintenance_faq.md • faq/loading/Loading_faq.md References • faq/Deploy_faq.md • knowledge/usage/best-practice.md • faq/operation_maintenance_faq.md • administration/Meta_recovery.md • administration/management/BE_configuration.md

@Rocky [2026-05-26, 063654 UTC] {extract_helper.py:407} INFO - [dtm_customer_ld_summary] inserted 20000 rows [2026-05-26, 063655 UTC] {extract_dag_creator.py:330} INFO - ✅ Chunk 2: Inserted 20000 rows in 36.19 seconds (Total: 40000) [2026-05-26, 063656 UTC] {retries.py:95} DEBUG - Running Job._fetch_from_db with retries. Try 1 of 3 [2026-05-26, 063656 UTC] {retries.py:95} DEBUG - Running Job._update_heartbeat with retries. Try 1 of 3 [2026-05-26, 063656 UTC] {job.py:234} DEBUG - [heartbeat] [2026-05-26, 063657 UTC] {extract_dag_creator.py:324} INFO - ⬇️ Chunk 3: Fetched 20000 rows in 1.7470 seconds [2026-05-26, 063657 UTC] {extract_helper.py:166} INFO - meta.extra_dejson: {} [2026-05-26, 063657 UTC] {extract_helper.py:167} INFO - meta.extra_dejson.get('sensitive_mode'): None [2026-05-26, 063657 UTC] {extract_helper.py:172} INFO - url: http://10.0.27.71:8030/api/dmapp/dtm_customer_ld_summary/_stream_load [2026-05-26, 063657 UTC] {extract_helper.py:187} INFO - Start streaming loading data to StarRocks table 'dtm_customer_ld_summary' [2026-05-26, 063657 UTC] {extract_helper.py:193} INFO - Executing curl command: curl --location-trusted -X PUT http://10.0.27.71:8030/api/dmapp/dtm_customer_ld_summary/_stream_load -H Authorization: Basic ZG1hcHA6WFBzOWV3SEE= -H format: CSV -H timezone: Asia/Ho_Chi_Minh -H Expect: 100-continue -H column_separator: \t -H columns: SYS_RUN_DATE,LD_NO,LD_DI_KEY,LD_DI_NO,LMS_CIF_NO,LOS_CIF_NO,BRANCH_NO,LMS_PROD_GROUP,LMS_PROD_CODE,INT_RATE,CONTRACT_NO,LOS_APP_CODE,LD_DI_DATE,SIGNED_DATE,MATURITY,PRODUCT_CODE,LOAN_TERM,ACCT_NO,EMI_AMOUNT,COLLECTION_FEE,TOTAL_EMI_AMOUNT,FIRST_PAYMENT_DATE,NEXT_REPAY_DATE,DUE_DATE_OF_MON,DUE_DAY_OF_MON,PAYMENT_FEE,INSURANCE_FEE,INSURANCE_CODE,PARTNER_CODE,LOAN_PURPOSE,LOAN_PURPOSE_LBL,LOAN_PURPOSE_OTHER,DISBURSEMENT_CHANNEL,AGENCY_PAYMENT,SALE_CODE,SALE_NAME,SALE_MOBILE,VERIFY,DRAWDOWN_AMOUNT,DRAWDOWN_AMOUNT_BASE,CURRENCY,LIMIT_AMOUNT,LIMIT_AMOUNT_BASE,REMAINING_LIMIT_AMOUNT,REMAINING_LIMIT_AMOUNT_BASE,DAY_INT_POSTED,DAY_OD_POSTED,CA_ACCT_BALANCE,OUTSTANDING,OUTSTANDING_BASE,OUTSTANDING_MTD,OUTSTANDING_YTD,OUTSTANDING_BASE_MTD,OUTSTANDING_BASE_YTD,OUTSTANDING_BASE_BOM,OS_LESS_PAST_DUE,PRI_PAST_DUE,PRI_PAST_DUE_BOM,INT_POSTED,INT_UNBILL,INT_PAST_DUE,INT_PAST_DUE_BOM,OD_POSTED,OD_PAST_DUE,OD_UNBILL,OD_PAST_DUE_BOM,OD_UNBILL_BOM,INT_RECEIVED,OD_RECEIVED,PRI_RECEIVED,FEE_RECEIVED,TENOR_IN_DAYS,BASE_DAYS,PRI_BILLING_DATE,INT_BILLING_DATE,PAY_OFF_DATE,REVERSED_MATURED,ROLL_DATE,ROLL_DAY,ROLL_FREQ,INTEREST_RATE_BASIS,INTEREST_RATE_SPREAD,INTEREST_TYPE,OVER_DUE_DAYS_DTL,OVER_DUE_DAYS_LD,OVER_DUE_DAYS_CLIENT,OVERDUE_YN,NEXT_INT_REP_DATE,CHALLENGE_START_DATE,CHALLENGE_END_DATE,LD_TRAN_DATE,LD_CHALLENGE_STATUS,LD_INTERNAL_STATUS,LD_ADJUST_STATUS,CUST_CHALLENGE_STATUS,CUST_INTERNAL_STATUS,CUST_ADJUST_STATUS,CUST_CIC_STATUS,CUST_FINAL_STATUS,LOAN_STATUS,NEXT_PAYOFF_AMOUNT,NEXT_PAYOFF_AMOUNT_PAID,NEXT_PRI_OUTSTANDING_PO,NEXT_PENALTY_PO_AMT,MIN_MUST_PAYMENT,TOTAL_MIN_MUST_PAYMENT,MIN_NEXT_PAYMENT,TOTAL_MIN_NEXT_PAYMENT,NEXT_INT_PO_AMT,NEXT_OD_PO_AMT,PRI_REC_BOM_TO_DATE,INT_REC_BOM_TO_DATE,OD_REC_BOM_TO_DATE,LAST_RECEIPT_DATE,LAST_RECEIPT_AMOUNT,LAST_PAYMENT_DATE,LAST_PAYMENT_AMOUNT,LAST_COLLECTION_PARTNER_CODE,LAST_PAYMENT_METHOD,PAYMENT_AMOUNT_MTD,PAYMENT_VOL,PAYMENT_STATUS_BEF_RECEIPT,CHECK_FPD,CHECK_SPD,CHECK_TPD,OVERDUE_AMOUNT_1FST,OVERDUE_AMOUNT_2SND,OVERDUE_AMOUNT_3TRD,MAX_DPD_1FST,MAX_DPD_2SND,MAX_DPD_3TRD,SECOND_PAYMENT_DATE,FIRST_DATE_DPD_1,FIRST_DATE_DPD_31,FIRST_DATE_DPD_61,FIRST_DATE_DPD_91,FIRST_DATE_DPD_181,FIRST_DATE_DPD_361,TOTAL_OVERDUE_PERIOD,DPD_LD,DPD_CUS,DPD_LD_HLD,DPD_CUS_HLD,CURRENT_PAYMENT_PERIOD,OVER_DUE_DATE,APPRAISAL_COMMENT,AMT_MUST_COLLECTED,TOTAL_AMT_MUST_COLLECTED,COLL_METHOD_ID,COLL_METHOD_CODE,LAST_OTHER_COMMENT,LAST_ACTION_ID,LAST_ACTION_CODE,LAST_ACTION_DESC,LAST_ACTION_DATE,LAST_PROMISED_DATE,LAST_PROMISED_AMOUNT,ALLOCATED_GROUP_CODE,ALLOCATED_GROUP_NAME,ALLOCATED_USER_CODE,ALLOCATED_USER_NAME,ALLOCATOR_CODE,ALLOCATOR_NAME,LAST_ALLOCATED_DATE,ALLOCATED_TEAM,ALLOCATED_TEAM_LEADER,ALLOCATED_DEPARMENT,AUTO_ALLOC_GROUP_CODE,AUTO_ALLOC_GROUP_NAME,AUTO_ALLOC_USER_CODE,AUTO_ALLOC_USER_NAME,LAST_AUTO_ALLOC_DATE,RULE_CODE,STAGE_CODE,OUSTANDING_ALLOCATE,PRI_PAST_DUE_ALLOCATE,INT_PAST_DUE_ALLOCATE,OD_PAST_DUE_ALLOCATE,OVERDUE_AMOUNT_ALLOCATE,TOTAL_AMT_MUST_COLL_ALLOCATED,COLLECTED_AMOUNT,DPD_LD_ALLOCATE,DPD_CUS_ALLOCATE,DPD_LD_HLD_ALLOCATE,DPD_CUS_HLD_ALLOCATE,POS_SEGMENT,PAID_TERN,PAID_TERM_USER,TOTAL_AMT_MUST_COLLECTED_BOM,COLLECTION_STATUS,BUCKET_CODE,REDUCE_BUCKET,REDUCE_BUCKET_AND_FEE,ROLL_BACK,MIN_AMOUNT_FOR_ROLL_BACK,MAX_HOLD_OVERDUE_DAY,MAX_HOLD_CUSTOMER_STATUS,MAX_CUSTOMER_STATUS_3_YEAR,MAX_CUSTOMER_STATUS_1_YEAR,TOTAL_OVERDUE_PERIOD_REMAIN,MAX_DPD_HISTORY,MIN_PERIOD_MAX_DPD_HISTORY,MAX_PERIOD_MAX_DPD_HISTORY,COUNT_PERIOD_MAX_DPD_HISTORY,NEXT_END_DATE_OF_GROUP_DCS,PAYMENT_AMOUNT_ACR,PAYMENT_AMOUNT_NET_MTD,PAYMENT_AMOUNT_NET_ACR,PRI_REC_ALLOCATED_TO_DATE,INT_REC_ALLOCATED_TO_DATE,OD_REC_ALLOCATED_TO_DATE,NEXT_REPAY_AMT,NEXT_PRI_AMT,NEXT_INT_AMT,CURRENT_PERIOD_PAYMENT_DATE,MIN_MUST_PAYMENT_DCS,TOTAL_MIN_MUST_PAYMENT_DCS,MIN_NEXT_PAYMENT_DCS,TOTAL_MIN_NEXT_PAYMENT_DCS,CURRENT_PAYMENT_DATE,TOTAL_NEXT_REPAY_AMT,TOTAL_NEXT_INT_AMT,MAX_DPD_4TH,CHECK_4TH,DUE_DATE_3TRD,DUE_DATE_4TH,PRODUCT_NAME,FEE_COLL_RECEIVED,FEE_COLL_RECEIVED_MTD,WRITEOFF_DATE,WO_TRAN_DATE,FEE_PAYOFF_RECEIVED,FEE_PAYOFF_RECEIVED_WAIVE,COLL_FEE_RECEIVED_WAIVE,PRI_RECEIVED_WAIVE,INT_RECEIVED_WAIVE,OD_RECEIVED_WAIVE,MIN_MUST_PAYMENT_BOM,MIN_NEXT_PAYMENT_BOM,LAST_TRAN_RECEIPT_DATE,PRI_PAST_DUE_MIN,INT_PAST_DUE_MIN,OD_PAST_DUE_MIN,FEE_PAST_DUE_MIN,BUCKET_KH,BUCKET_HD_BOM,BUCKET_KH_BOM,BUCKET_HD,COVID_CT1_MUST_PAYMENT,COVID_CT2_MUST_PAYMENT,COVID_CT3_MUST_PAYMENT,COVID_CT1_WAVE_AMOUNT,COVID_CT2_WAVE_AMOUNT,COVID_CT3_WAVE_AMOUNT,FLAG_CODE,MONTH_ON_BOOK,TONG_SO_TIEN_PHAI_THU_DCS,SO_TIEN_ROLL_BACK,SO_TIEN_THOAT_NPL,TOTAL_EMI_AMOUNT_DCS,COVID_CT1_WAVE_PRI,COVID_CT1_WAVE_INT,COVID_CT1_WAVE_ODI,COVID_CT2_WAVE_PRI,COVID_CT2_WAVE_INT,COVID_CT2_WAVE_ODI,COVID_CT3_WAVE_PRI,COVID_CT3_WAVE_INT,COVID_CT3_WAVE_ODI,DU_NO_MAX_OF_CIF,COVID_CT3_WAVE_PENALTY_PO_AMT,PRI_RECEIVED_WAIVE_MTD,INT_RECEIVED_WAIVE_MTD,OD_RECEIVED_WAIVE_MTD,FEE_PAYOFF_RECEIVED_MTD,FEE_PAYOFF_RECEIVED_WAIVE_MTD,COLL_FEE_RECEIVED_WAIVE_MTD,TOLERANCE_AMOUNT,TOLERANCE_AMOUNT_MTD,LAST_PAYMENT_DATE_TIME,PRI_LAST_RECEIPT_DATE,INT_LAST_RECEIPT_DATE,OD_LAST_RECEIPT_DATE,FEE_LAST_RECEIPT_DATE,PRI_OVER_DUE_DATE,INT_OVER_DUE_DATE,OD_OVER_DUE_DATE,FEE_OVER_DUE_DATE,PRI_OVER_DUE_DAYS,INT_OVER_DUE_DAYS,OD_OVER_DUE_DAYS,FEE_OVER_DUE_DAYS,CLASSIFY,CUSTOMER_CLASSIFY,CUSTOMER_MONTH_ON_BOOK,CUSTOMER_MAX_DPD_HISTORY,RESTRUCTURE_TRAN_DATE,RESTRUCTURE_END_DATE,PRI_PO_RECEIVED,PRI_BILLED,INT_BILLED,NEXT_FEE_AMT,LOAN_FEE_RECEIVED,LOAN_FEE_REC_BOM_TO_DATE,FEE_REC_BOM_TO_DATE,RECEIVED_FEE_WAIVE,RECEIVED_LOAN_FEE_WAIVE,RECEIVED_FEE_WAIVE_MTD,RECEIVED_LOAN_FEE_WAIVE_MTD,LOAN_FEE_AMOUNT,LOAN_FEE_BALANCE,FEE_PAST_DUE,COVID_CT4_WAVE_AMOUNT,COVID_CT4_WAVE_PRI,COVID_CT4_WAVE_INT,COVID_CT4_WAVE_ODI,COVID_CT5_MUST_PAYMENT,COVID_CT5_WAVE_AMOUNT,COVID_CT5_WAVE_PRI,COVID_CT5_WAVE_INT,COVID_CT5_WAVE_ODI,COVID_CT6_MUST_PAYMENT,COVID_CT6_WAVE_AMOUNT,COVID_CT6_WAVE_PRI,COVID_CT6_WAVE_INT,COVID_CT6_WAVE_ODI,WO_DATE,COVID_CT4_MUST_PAYMENT,DU_NO_LAI_TK_NOI_BANG,DU_NO_LAI_TK_NGOAI_BANG,DU_NO_LAI_PHAT_TK_NOI_BANG,DU_NO_LAI_PHAT_TK_NGOAI_BANG,DA_TUNG_CCN,DANG_CCN,NHOM_NO_SAU_CO_CAU,NGAY_CCN_DAU_TIEN,CONTRACT_STATUS,PAID_TERM,REMAINING_TERM,CLOSE_DATE,PRI_RECEIVED_NET,INT_RECEIVED_NET,OD_RECEIVED_NET,MAX_DPD_MTD,OVERDUE_AMOUNT_4FTH,LAST_PRI_PAID_DATE,LAST_INT_PAID_DATE,LAST_OD_PAID_DATE,ACCOUNT_NUMBER,LD_KEY,CLIENT_NO,MATURE_DATE,ORIG_LD_AMOUNT,ORIG_LD_AMOUNT_BASE,ODIN_POSTED,ODPR_POSTED,CARD_GROUP,DPD_GROUP,SPECIAL_RESTRUCTURE_GROUP,FINAL_DEBT_GROUP,AUTO_RESTRUCTURE_GROUP,INT_ACCRUED,LOS_PRODUCT_CODE,LOS_PRODUCT_NAME,LAST_PAYMENT_METHOD_NAME,FCC_TERM_PAYMENT,NST90,INT_NOT_DUE,TOTAL_PAID_PERIODS,TOTAL_PAYMENT_COUNT,LAST_PAYMENT_AMOUNT_NO_FEE,OD_TO_EOM_AMT,MIN_AMT_MUST_COLLECTED_BOM -H load_mem_limit: 10737418240 -H enclose: " -H null_value: \N -H row_delimiter: \n --data-binary @- [2026-05-26, 063700 UTC] {extract_helper.py:237} INFO - response: { "TxnId": 2349706, "Label": "50d4f9fe-abb2-47d5-9cb3-cb6acb56415c", "Db": "dmapp", "Table": "dtm_customer_ld_summary", "Status": "Fail", "Message": "Unsupported CSV type DECIMAL256(58, 40)", "NumberTotalRows": 0, "NumberLoadedRows": 0, "NumberFilteredRows": 0, "NumberUnselectedRows": 0, "LoadBytes": 1103420, "LoadTimeMs": 208, "BeginTxnTimeMs": 0, "StreamLoadPlanTimeMs": 20, "ReadDataTimeMs": 0, "WriteDataTimeMs": 127, "CommitAndPublishTimeMs": 0 } [2026-05-26, 063700 UTC] {extract_helper.py:255} ERROR - Failed to insert into dtm_customer_ld_summary: { "TxnId": 2349706, "Label": "50d4f9fe-abb2-47d5-9cb3-cb6acb56415c", "Db": "dmapp", "Table": "dtm_customer_ld_summary", "Status": "Fail", "Message": "Unsupported CSV type DECIMAL256(58, 40)", "NumberTotalRows": 0, "NumberLoadedRows": 0, "NumberFilteredRows": 0, "NumberUnselectedRows": 0, "LoadBytes": 1103420, "LoadTimeMs": 208, "BeginTxnTimeMs": 0, "StreamLoadPlanTimeMs": 20, "ReadDataTimeMs": 0, "WriteDataTimeMs": 127, "CommitAndPublishTimeMs": 0 } [2026-05-26, 063700 UTC] {extract_helper.py:260} ERROR - Failed to insert into dtm_customer_ld_summary: Failed to insert into dtm_customer_ld_summary: { "TxnId": 2349706, "Label": "50d4f9fe-abb2-47d5-9cb3-cb6acb56415c", "Db": "dmapp", "Table": "dtm_customer_ld_summary", "Status": "Fail", "Message": "Unsupported CSV type DECIMAL256(58, 40)", "NumberTotalRows": 0, "NumberLoadedRows": 0, "NumberFilteredRows": 0, "NumberUnselectedRows": 0, "LoadBytes": 1103420, "LoadTimeMs": 208, "BeginTxnTimeMs": 0, "StreamLoadPlanTimeMs": 20, "ReadDataTimeMs": 0, "WriteDataTimeMs": 127, "CommitAndPublishTimeMs": 0 } [2026-05-26, 063700 UTC] {extract_dag_creator.py:291} WARNING - ⚠️ local_steam_load failed (Failed to insert into dtm_customer_ld_summary: { "TxnId": 2349706, "Label": "50d4f9fe-abb2-47d5-9cb3-cb6acb56415c", "Db": "dmapp", "Table": "dtm_customer_ld_summary", "Status": "Fail", "Message": "Unsupported CSV type DECIMAL256(58, 40)", "NumberTotalRows": 0, "NumberLoadedRows": 0, "NumberFilteredRows": 0, "NumberUnselectedRows": 0, "LoadBytes": 1103420, "LoadTimeMs": 208, "BeginTxnTimeMs": 0, "StreamLoadPlanTimeMs": 20, "ReadDataTimeMs": 0, "WriteDataTimeMs": 127, "CommitAndPublishTimeMs": 0 }). Retrying with local_json_stream_load (DECIMAL256-safe)... [2026-05-26, 063700 UTC] {extract_helper.py:315} INFO - url: http://10.0.27.71:8030/api/dmapp/dtm_customer_ld_summary/_stream_load

Based on the error logs you provided, it appears you are using StarRocks v4.0 (where

DECIMAL256

was introduced) and hitting a known limitation in the CSV parsing logic for this high-precision data type. What is happening? The StarRocks Backend (BE) has a dedicated parser for CSV data. For

DECIMAL256

(precision > 38), the current CSV scanner in your version does not yet support direct mapping to this specific internal 256-bit type, resulting in the

Unsupported CSV type DECIMAL256(58, 40)

error. How to fix it There are two primary ways to resolve this: 1. Switch to JSON format (Recommended) As indicated by your own pipeline's retry logic (

Retrying with local_json_stream_load (DECIMAL256-safe)

), the JSON format uses a different parsing path that correctly handles

DECIMAL256

. * Change your header to

-H "format: json"

. * Ensure your data is formatted as a JSON array of objects or line-delimited JSON. 2. Use the

CAST

Workaround in CSV If you must stick with CSV format, you can load the high-precision numbers as strings (temporarily) and then cast them to the target type within the Stream Load command. This bypasses the direct CSV-to-Decimal256 mapping. Modify your

curl

command's

columns

header like this: 1. Identify the column name in the CSV (e.g.,

MY_DEC_COL

). 2. Map it to a temporary name (e.g.,

MY_DEC_COL_TEMP

). 3. Assign the actual column using a

cast()

function. Example snippet for the header:

bash
-H "columns: col1, col2, MY_DEC_COL_TEMP, MY_DEC_COL=cast(MY_DEC_COL_TEMP as decimal(58,40))"

Summary of

DECIMAL256

in v4.0 * Precision: Supports up to 76 digits (your

58, 40

fits perfectly). * Availability: Only available in StarRocks v4.0 and later. * Workload: Best for financial calculations where

DECIMAL128

(max 38 digits) might overflow. If you are seeing this on a version older than 4.0, it means the table was created with an unsupported precision, and you should reduce the precision to

DECIMAL(38, S)

or less than 38)` or upgrade to v4.0. References • sql-reference/data-types/numeric/DECIMAL.md • release_notes/release-4.0.md • loading/StreamLoad.md References • sql-reference/data-types/numeric/DECIMAL.md • release_notes/release-4.0.md • sql-reference/data-types/string-type/BINARY.md

@Rocky current version is starrock 4.0.10 alread, got this error [2026-05-26, 063918 UTC] {taskinstance.py:3313} ERROR - Task failed with exception Traceback (most recent call last): File "/opt/airflow/dags/bags/dwh-dmapp-starrocks/airflow_dags/extract_framework/extract_dag_creator.py", line 289, in do_insert dest_hook.local_steam_load(dest_table, dest_schema, rows, target_fields) File "/opt/airflow/dags/bags/dwh-dmapp-starrocks/airflow_dags/extract_framework/extract_helper.py", line 261, in local_steam_load raise e File "/opt/airflow/dags/bags/dwh-dmapp-starrocks/airflow_dags/extract_framework/extract_helper.py", line 256, in local_steam_load raise Exception("Failed to insert into %s: %s" % (table, response_text)) Exception: Failed to insert into dtm_customer_ld_summary: { "TxnId": 2349706, "Label": "50d4f9fe-abb2-47d5-9cb3-cb6acb56415c", "Db": "dmapp", "Table": "dtm_customer_ld_summary", "Status": "Fail", "Message": "Unsupported CSV type DECIMAL256(58, 40)", "NumberTotalRows": 0, "NumberLoadedRows": 0, "NumberFilteredRows": 0, "NumberUnselectedRows": 0, "LoadBytes": 1103420, "LoadTimeMs": 208, "BeginTxnTimeMs": 0, "StreamLoadPlanTimeMs": 20, "ReadDataTimeMs": 0, "WriteDataTimeMs": 127, "CommitAndPublishTimeMs": 0 } During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/airflow/.local/lib/python3.12/site-packages/airflow/models/taskinstance.py", line 768, in _execute_task *result = _execute_callable(context=context, *execute_callable_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/airflow/.local/lib/python3.12/site-packages/airflow/models/taskinstance.py", line 734, in _execute_callable return ExecutionCallableRunner( ^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/airflow/.local/lib/python3.12/site-packages/airflow/utils/operator_helpers.py", line 252, in run *return self.func(*args, *kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/airflow/.local/lib/python3.12/site-packages/airflow/models/baseoperator.py", line 424, in wrapper *return func(self, *args, *kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/airflow/.local/lib/python3.12/site-packages/airflow/operators/python.py", line 238, in execute return_value = self.execute_callable() ^^^^^^^^^^^^^^^^^^^^^^^ File "/home/airflow/.local/lib/python3.12/site-packages/airflow/operators/python.py", line 256, in execute_callable *return runner.run(*self.op_args, *self.op_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/airflow/.local/lib/python3.12/site-packages/airflow/utils/operator_helpers.py", line 252, in run *return self.func(*args, *kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/airflow/dags/bags/dwh-dmapp-starrocks/airflow_dags/extract_framework/extract_dag_creator.py", line 326, in _extract_table_to_target do_insert(rows) File "/opt/airflow/dags/bags/dwh-dmapp-starrocks/airflow_dags/extract_framework/extract_dag_creator.py", line 295, in do_insert dest_hook.local_json_stream_load(dest_table, dest_schema, rows, target_fields) File "/opt/airflow/dags/bags/dwh-dmapp-starrocks/airflow_dags/extract_framework/extract_helper.py", line 410, in local_json_stream_load raise e File "/opt/airflow/dags/bags/dwh-dmapp-starrocks/airflow_dags/extract_framework/extract_helper.py", line 383, in local_json_stream_load raise Exception(f"Curl failed: {error_msg}") Exception: Curl failed: % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 -- -- -- -- -- -- 0 0 203M 0 0 0 0 0 0 -- -- -- -- -- -- 0 0 0 0 0 0 0 0 0 -- -- -- -- -- -- 0 0 0 0 0 0 0 0 0 -- -- 00002 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00003 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00004 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00005 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00006 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00007 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00008 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00009 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00010 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00011 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00012 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00013 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00014 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00015 -- -- 0 0 0 0 0 0 0 0 0 -- -- 00016 -- -- 0 curl: (28) Failed to connect to 10.0.27.72 port 8040 after 131191 ms: Couldn't connect to server [2026-05-26, 063918 UTC] {job.py:234} DEBUG - [heartbeat]

Even on StarRocks v4.0.10, you are seeing these errors because of two separate issues: a data type limitation in the CSV parser and a network configuration issue (port 8040). 1. The DECIMAL256 Error Although StarRocks v4.0 supports the

DECIMAL256

type, the CSV scanner in current v4.0.x releases has a known limitation where it cannot directly parse CSV strings into 256-bit decimals. This is why you get:

Message: Unsupported CSV type DECIMAL256(58, 40)

Solution (CSV): You must map the column as a temporary string and then use

CAST

in the

columns

header. Modify your

columns

parameter in the Stream Load:

bash
# Change: ...COL_NAME... 
# To: ...COL_NAME_TEMP, COL_NAME = CAST(COL_NAME_TEMP AS DECIMAL(58,40))...

Solution (JSON): The JSON parser does support

DECIMAL256

directly. Your Airflow script noticed the failure and tried to switch to JSON automatically, but then hit the second error below. ────────── 2. The Connection Error (Port 8040) The error

curl: (28) Failed to connect to 10.0.27.72 port 8040

confirms that your BE HTTP port (8040) is not accessible from your Airflow worker. In your previous question, we discussed port 8060. However, for Stream Load: 1. You send the request to the FE (port 8030). 2. The FE redirects (HTTP 307) your

curl

command to a BE (port 8040). 3. Your

curl

(via

--location-trusted

) tries to connect to

10.0.27.72:8040

to upload the actual data. Why it failed: Your firewall or security group likely allows port 8030 (FE) but is blocking port 8040 on the BEs. Summary Checklist to Fix: 1. Open Port 8040: Ensure the Airflow worker can reach all BE nodes on port

8040

. 2. Verify BE Status: Check if the BE on

10.0.27.72

is running (

ps aux | grep starrocks_be

). 3. Check `be_http_port`: Confirm in

be.conf

that

be_http_port

is indeed

8040

(the default). 4. Priority Networks: Ensure

priority_networks

in

be.conf

is set so the BE reports the correct IP (

10.0.27.72

) to the FE. If the BE reports an IP that the Airflow worker can't "see," the redirect will fail. Quick fix for the Airflow Job: If you fix the network for port 8040, the script's automatic retry using JSON will likely succeed, as JSON doesn't suffer from the

DECIMAL256

CSV parsing bug. References • sql-reference/data-types/numeric/DECIMAL.md • loading/StreamLoad.md • administration/management/BE_configuration.md • deployment/environment_configurations.md References • sql-reference/data-types/numeric/DECIMAL.md • loading/StreamLoad.md • administration/management/BE_configuration.md • deployment/environment_configurations.md • faq/loading/Stream_load_faq.md • faq/Deploy_faq.md • release_notes/release-4.0.md References • faq/loading/Stream_load_faq.md • quick_start/helm.md • loading/StreamLoad.md • loading/Stream_Load_transaction_interface.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md

@Rocky with table abc like below, let update from replication_num = 1 --> 2 ENGINE=OLAP PRIMARY KEY(

app_code

) COMMENT "Thông tin danh mục hồ sơ khách hàng Master" DISTRIBUTED BY HASH(

app_code

) BUCKETS 16 PROPERTIES ( "compression" = "LZ4", "enable_persistent_index" = "true", "fast_schema_evolution" = "true", "replicated_storage" = "true", "replication_num" = "1" );

To update the replication number from 1 to 2 for your table

abc

, run the following SQL command:

sql
ALTER TABLE abc SET ("replication_num" = "2");

Important Considerations 1. Verification of progress After running the command, StarRocks does not immediately create the second replica. It starts background Clone Tasks. You can monitor the health and replication status of the tablets using:

sql
SHOW TABLETS FROM abc;

Look at the

ReplicaCount

column. It should eventually reach

2

for all tablets. 2. Network requirement (Crucial for your cluster) In your previous messages, you reported

transmit chunk rpc failed

and

Not connected to yet

errors. * The Problem: When you change

replication_num

to 2, the current BE must send a copy of the data to another BE. * The Port: This transfer happens over the bRPC port (8060). * The Risk: If your BEs still cannot communicate with each other on port 8060, the replication will fail. The table will remain with only 1 replica, and you will see "Unhealthy Tablets" in your FE logs. 3. If you have partitions If your table actually has partitions (though not shown in your snippet), you must also update the historical partitions and the default for future ones:

sql
-- For existing partitions
ALTER TABLE abc MODIFY PARTITION (*) SET ("replication_num" = "2");

-- For future partitions
ALTER TABLE abc SET ("default.replication_num" = "2");

4. Check for errors If the replicas do not increase after a few minutes, check the FE master logs (

fe.log

) for "Tablet Scheduler" errors or "Clone Task" failures. These will tell you if the network connection is still blocking the process. References • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md • knowledge/usage/best-practice.md • sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE.md • faq/operation_maintenance_faq.md • administration/management/resource_management/Replica.md

@Rocky what does this mean? Load: Summary: - Query ID: 9244b7f1-63ce-1b31-f5f4-87df8c4049a4 - Start Time: 2026-05-26 150447 (+07:00) - End Time: 2026-05-26 150448 (+07:00) - Total: 283ms - Query Type: Load - Load Type: STREAM_LOAD - Query State: Aborted - StarRocks Version: 4.0.10-5b36164 - Sql Statement - Default Db: dmapp - Warehouse Execution: Fragment 0: Instance 9244b7f1-63ce-1b31-f5f4-87df8c4049a5 (host=TNetworkAddress(hostname:10.0.27.71, port:36036)):(Active: 1.918ms[1918612ns], % non-child: 0.00%) - Address: 10.0.27.71:36036 - InstanceId: 9244b7f1-63ce-1b31-f5f4-87df8c4049a5 - InstanceAllocatedMemoryUsage: 1.773 MB - InstanceDeallocatedMemoryUsage: 73.945 KB - InstancePeakMemoryUsage: 1.700 MB - MemoryLimit: -1.000 B - RowsProduced: 0 OlapTableSink:(Active: 44.102ms[44102645ns], % non-child: 0.00%) - TxnID: 2357323 - IndexNum: 1 - ReplicatedStorage: true - AutomaticPartition: false - AutomaticBucketSize: 0 - DynamicOverwrite: false - AllocAutoIncrementTime: 0ns - CloseWaitTime: 0ns - OpenTime: 39.692ms - PrepareDataTime: 0ns - ConvertChunkTime: 0ns - ValidateDataTime: 0ns - RowsFiltered: 0 - RowsRead: 0 - RowsReturned: 0 - RpcClientSideTime: 0ns - RpcServerSideTime: 0ns - RpcServerWaitFlushTime: 0ns - SendDataTime: 0ns - PackChunkTime: 0ns - SendRpcTime: 0ns - CompressTime: 0ns - SerializeChunkTime: 0ns - WaitResponseTime: 0ns - UpdateLoadChannelProfileTime: 0ns FILE_SCAN_NODE (id=0):(Active: 1.911ms[1911568ns], % non-child: 0.00%) - BytesRead: 0.000 B - IOTaskExecTime: 0ns - IOTaskWaitTime: 0ns - NumDiskAccess: 0 - PeakMemoryUsage: 0.000 B - RowsRead: 0 - RowsReturned: 0 - RowsReturnedRate: 0 /sec - ScanTime: 738.711us - ScannerQueueCounter: 1 - ScannerQueueTime: 4.056us - ScannerThreadsInvoluntaryContextSwitches: 0 - ScannerThreadsTotalWallClockTime: 0ns - MaterializeTupleTime(*): 0ns - ScannerThreadsSysTime: 0ns - ScannerThreadsUserTime: 0ns - ScannerThreadsVoluntaryContextSwitches: 0 - TotalRawReadTime(*): 0ns - TotalReadThroughput: 0.000 B/sec DataSource: - DataSourceType: FileDataSource - FileScanner: - CastChunkTime: 0ns - CreateChunkTime: 0ns - FileReadCount: 0 - FileReadTime: 0ns - FillTime: 0ns - MaterializeTime: 0ns - ReadTime: 0ns - ScannerTotalTime: 0ns

This profile indicates that your Stream Load was terminated before it even started processing data. Here is a breakdown of what the specific sections mean in the context of your recent errors: 1. "Query State: Aborted" The load did not finish successfully. "Aborted" means the system stopped the execution. Since the Total time was only 283ms, the failure happened during the "setup" phase of the load, not during the data transmission. 2. "RowsRead: 0" and "BytesRead: 0.000 B" The

FILE_SCAN_NODE

(which is responsible for reading your CSV/JSON data) shows 0 bytes and 0 rows. * This confirms that the error you saw earlier (Unsupported CSV type DECIMAL256) happened during the Plan Initialization. * StarRocks looked at the table schema (which has a

DECIMAL256

column) and the load request (which is

format: CSV

), realized it cannot map those two together, and "Aborted" the task immediately without reading a single line of your file. 3. "OlapTableSink: OpenTime: 39.692ms" The sink is the part that writes data to the disks. * The

OpenTime

is very low, but notice that

SendDataTime

,

PackChunkTime

, and

WaitResponseTime

are all 0ns. * This means the load failed so early that it never even tried to send data to the replicas. Why did this happen? Based on your previous logs, this profile is the "behind-the-scenes" look at the

Unsupported CSV type DECIMAL256(58, 40)

error. The sequence was: 1. Airflow sent the

curl

request. 2. StarRocks FE created a plan and sent it to the BE (

10.0.27.71

). 3. The BE checked the plan, saw it was supposed to scan CSV data into a

DECIMAL256

column, and realized it doesn't have the internal code to do that specific conversion for CSVs. 4. The BE immediately Aborted the fragment. 5. The BE sent the error message back to your Airflow task. How to fix it (Recap) Since you are on v4.0.10, you must bypass the CSV parser's limitation for `DECIMAL256`: 1. Switch to JSON: Your Airflow log showed a retry with JSON. Fix the Port 8040 network issue so that retry can succeed. 2. Use CAST in CSV: If you must use CSV, change your

columns

header to read the decimal column as a string first: _ _Instead of:*

..., MY_COL, ...

_ _Use:*

..., MY_COL_TEMP, MY_COL = CAST(MY_COL_TEMP AS DECIMAL(58,40)), ...

Once you do one of these, you will see

RowsRead

and

BytesRead

increase in the profile.