# Source: https://docs.velodb.io/cloud/4.x/best-practice/data-faq

Version: 4.x

On this page

# Data Operation Error

This document is mainly used to record common problems of data operation
during the use of Doris. It will be updated from time to time.

### Q1. Use Stream Load to access FE's public network address to import data,
but is redirected to the intranet IP?​

When the connection target of stream load is the http port of FE, FE will only
randomly select a BE node to perform the http 307 redirect operation, so the
user's request is actually sent to a BE assigned by FE. The redirect returns
the IP of the BE, that is, the intranet IP. So if you send the request through
the public IP of FE, it is very likely that you cannot connect because it is
redirected to the internal network address.

The usual way is to ensure that you can access the intranet IP address, or to
assume a load balancer for all BE upper layers, and then directly send the
stream load request to the load balancer, and the load balancer will
transparently transmit the request to the BE node .

### Q2. Does Doris support changing column names?​

After version 1.2.0, when the `"light_schema_change"="true"` option is
enabled, column names can be modified.

Before version 1.2.0 or when the `"light_schema_change"="true"` option is not
enabled, modifying column names is not supported. The reasons are as follows:

Doris supports modifying database name, table name, partition name,
materialized view (Rollup) name, as well as column type, comment, default
value, etc. But unfortunately, modifying column names is currently not
supported.

For some historical reasons, the column names are currently written directly
to the data file. When Doris queries, it also finds the corresponding column
through the class name. Therefore, modifying the column name is not only a
simple metadata modification, but also involves data rewriting, which is a
very heavy operation.

We do not rule out some compatible means to support lightweight column name
modification operations in the future.

### Q3. Does the table of the Unique Key model support creating a materialized
view?​

not support.

The table of the Unique Key model is a business-friendly table. Because of its
unique function of deduplication according to the primary key, it can easily
synchronize business databases with frequently changed data. Therefore, many
users will first consider using the Unique Key model when accessing data into
Doris.

But unfortunately, the table of the Unique Key model cannot establish a
materialized view. The reason is that the essence of the materialized view is
to "pre-compute" the data through pre-computation, so that the calculated data
is directly returned during the query to speed up the query. In the
materialized view, the "pre-computed" data is usually some aggregated
indicators, such as sum and count. At this time, if the data changes, such as
update or delete, because the pre-computed data has lost detailed information,
it cannot be updated synchronously. For example, a sum value of 5 may be 1+4
or 2+3. Because of the loss of detailed information, we cannot distinguish how
this summation value is calculated, so we cannot meet the needs of updating.

### Q4. tablet writer write failed, tablet_id=27306172, txn_id=28573520,
err=-235 or -238​

This error usually occurs during data import operations. The error code is
-235. The meaning of this error is that the data version of the corresponding
tablet exceeds the maximum limit (default 500, controlled by the BE parameter
`max_tablet_version_num`), and subsequent writes will be rejected. For
example, the error in the question means that the data version of the tablet
27306172 exceeds the limit.

This error is usually caused by the import frequency being too high, which is
greater than the compaction speed of the backend data, causing versions to
pile up and eventually exceed the limit. At this point, we can first pass the
show tablet 27306172 statement, and then execute the show proc statement in
the result to check the status of each copy of the tablet. The versionCount in
the result represents the number of versions. If you find that a copy has too
many versions, you need to reduce the import frequency or stop importing and
observe whether the number of versions drops. If the number of versions does
not decrease after the import is stopped, you need to go to the corresponding
BE node to view the be.INFO log, search for the tablet id and compaction
keyword, and check whether the compaction is running normally. For compaction
tuning, you can refer to the ApacheDoris official account article: [Doris Best
Practices - Compaction Tuning
(3)](https://mp.weixin.qq.com/s/cZmXEsNPeRMLHp379kc2aA)

The -238 error usually occurs when the same batch of imported data is too
large, resulting in too many Segment files for a tablet (default is 200,
controlled by the BE parameter `max_segment_num_per_rowset`). At this time, it
is recommended to reduce the amount of data imported in one batch, or
appropriately increase the BE configuration parameter value to solve the
problem. Since version 2.0, users can enable segment compaction feature to
reduce segment file number by setting `enable_segcompaction=true` in BE
config.

### Q5. tablet 110309738 has few replicas: 1, alive backends: [10003]​

This error can occur during a query or import operation. Usually means that
the copy of the corresponding tablet has an exception.

At this point, you can first check whether the BE node is down by using the
show backends command. For example, the isAlive field is false, or the
LastStartTime is a recent time (indicating that it has been restarted
recently). If the BE is down, you need to go to the node corresponding to the
BE and check the be.out log. If BE is down for abnormal reasons, the exception
stack is usually printed in be.out to help troubleshoot the problem. If there
is no error stack in be.out. Then you can use the linux command dmesg -T to
check whether the process is killed by the system because of OOM.

If no BE node is down, you need to pass the show tablet 110309738 statement,
and then execute the show proc statement in the result to check the status of
each tablet copy for further investigation.

### Q6. Calling stream load to import data through a Java program may result
in a Broken Pipe error when a batch of data is large.​

Apart from Broken Pipe, some other weird errors may occur.

This situation usually occurs after enabling httpv2. Because httpv2 is an http
service implemented using spring boot, and uses tomcat as the default built-in
container. However, there seems to be some problems with tomcat's handling of
307 forwarding, so the built-in container was modified to jetty later. In
addition, the version of apache http client in the java program needs to use
the version after 4.5.13. In the previous version, there were also some
problems with the processing of forwarding.

So this problem can be solved in two ways:

  1. Disable httpv2

Restart FE after adding enable_http_server_v2=false in fe.conf. However, the
new version of the UI interface can no longer be used, and some new interfaces
based on httpv2 can not be used. (Normal import queries are not affected).

  2. Upgrade

Upgrading to Doris 0.15 and later has fixed this issue.

### Q7. Error -214 is reported when importing and querying​

When performing operations such as import, query, etc., you may encounter the
following errors:

    
    
    failed to initialize storage reader. tablet=63416.1050661139.aa4d304e7a7aff9c-f0fa7579928c85a0, res=-214, backend=192.168.100.10  
    

A -214 error means that the data version for the corresponding tablet is
missing. For example, the above error indicates that the data version of the
copy of tablet 63416 on the BE of 192.168.100.10 is missing. (There may be
other similar error codes, which can be checked and repaired in the following
ways).

Typically, if your data has multiple copies, the system will automatically
repair these problematic copies. You can troubleshoot with the following
steps:

First, check the status of each copy of the corresponding tablet by executing
the `show tablet 63416` statement and executing the `show proc xxx` statement
in the result. Usually we need to care about the data in the `Version` column.

Normally, the Version of multiple copies of a tablet should be the same. And
it is the same as the VisibleVersion version of the corresponding partition.

You can view the corresponding partition version with `show partitions from
tblx` (the partition corresponding to the tablet can be obtained in the `show
tablet` statement.)

At the same time, you can also visit the URL in the CompactionStatus column in
the `show proc` statement (just open it in a browser) to view more specific
version information to check which versions are missing.

If there is no automatic repair for a long time, you need to use the `show
proc "/cluster_balance"` statement to view the tablet repair and scheduling
tasks currently being executed by the system. It may be because there are a
large number of tablets waiting to be scheduled, resulting in a longer repair
time. You can follow records in `pending_tablets` and `running_tablets`.

Further, you can use the `admin repair` statement to specify a table or
partition to be repaired first. For details, please refer to `help admin
repair`;

If it still can't be repaired, then in the case of multiple replicas, we use
the `admin set replica status` command to force the replica in question to go
offline. For details, see the example of setting the replica status to bad in
`help admin set replica status`. (After set to bad, the copy will no longer be
accessed. And it will be automatically repaired later. But before operation,
you should make sure that other copies are normal)

### Q8. Not connected to 192.168.100.1:8060 yet, server_id=384​

We may encounter this error when importing or querying. If you go to the
corresponding BE log, you may also find similar errors.

This is an RPC error, and there are usually two possibilities: 1. The
corresponding BE node is down. 2. rpc congestion or other errors.

If the BE node is down, you need to check the specific downtime reason. Only
the problem of rpc congestion is discussed here.

One case is OVERCROWDED, which means that the rpc source has a large amount of
unsent data that exceeds the threshold. BE has two parameters associated with
it:

  1. `brpc_socket_max_unwritten_bytes`: The default value is 1GB. If the unsent data exceeds this value, an error will be reported. This value can be modified appropriately to avoid OVERCROWDED errors. (But this cures the symptoms but not the root cause, and there is still congestion in essence).
  2. `tablet_writer_ignore_eovercrowded`: Default is false. If set to true, Doris will ignore OVERCROWDED errors during import. This parameter is mainly to avoid import failure and improve the stability of import.

The second is that the packet size of rpc exceeds max_body_size. This problem
may occur if the query has a very large String type, or a bitmap type. It can
be circumvented by modifying the following BE parameters:

    
    
    brpc_max_body_size：default 3GB.  
    

### Q9. [ Broker load ] org.apache.thrift.transport.TTransportException:
java.net.SocketException: Broken pipe​

`org.apache.thrift.transport.TTransportException: java.net.SocketException:
Broken pipe` during import.

The reason for this problem may be that when importing data from external
storage (such as HDFS), because there are too many files in the directory, it
takes too long to list the file directory. Here, the Broker RPC Timeout
defaults to 10 seconds, and the timeout needs to be adjusted appropriately
here. time.

Modify the `fe.conf` configuration file to add the following parameters:

    
    
    broker_timeout_ms = 10000  
    ##The default here is 10 seconds, you need to increase this parameter appropriately  
    

Adding parameters here requires restarting the FE service.

### Q10. [ Routine load ] ReasonOfStateChanged: ErrorReason{code=errCode =
104, msg='be 10004 abort task with reason: fetch failed due to requested
offset not available on the broker: Broker: Offset out of range'}​

The reason for this problem is that Kafka's cleanup policy defaults to 7 days.
When a routine load task is suspended for some reason and the task is not
restored for a long time, when the task is resumed, the routine load records
the consumption offset, and This problem occurs when kafka has cleaned up the
corresponding offset

So this problem can be solved with alter routine load:

View the smallest offset of kafka, use the ALTER ROUTINE LOAD command to
modify the offset, and resume the task

    
    
    ALTER ROUTINE LOAD FOR db.tb  
    FROM kafka  
    (  
     "kafka_partitions" = "0",  
     "kafka_offsets" = "xxx",  
     "property.group.id" = "xxx"  
    );  
    

### Q11. ERROR 1105 (HY000): errCode = 2, detailMessage =
(192.168.90.91)[CANCELLED][INTERNAL_ERROR]error setting certificate verify
locations: CAfile: /etc/ssl/certs/ca-certificates.crt CApath: none​

    
    
    yum install -y ca-certificates  
    ln -s /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt /etc/ssl/certs/ca-certificates.crt  
    

### Q12. create partition failed. partition numbers will exceed limit variable
max_auto_partition_num​

To prevent accidental creation of too many partitions when importing data for
auto-partitioned tables, we use the FE configuration item
`max_auto_partition_num` to control the maximum number of partitions to be
created automatically for such tables. If you really need to create more
partitions, please modify this config item of FE Master node.

On This Page

  * Q1. Use Stream Load to access FE's public network address to import data, but is redirected to the intranet IP?
  * Q2. Does Doris support changing column names?
  * Q3. Does the table of the Unique Key model support creating a materialized view?
  * Q4. tablet writer write failed, tablet_id=27306172, txn_id=28573520, err=-235 or -238
  * Q5. tablet 110309738 has few replicas: 1, alive backends: [10003]
  * Q6. Calling stream load to import data through a Java program may result in a Broken Pipe error when a batch of data is large.
  * Q7. Error -214 is reported when importing and querying
  * Q8. Not connected to 192.168.100.1:8060 yet, server_id=384
  * Q9. [ Broker load ] org.apache.thrift.transport.TTransportException: java.net.SocketException: Broken pipe
  * Q10. [ Routine load ] ReasonOfStateChanged: ErrorReason{code=errCode = 104, msg='be 10004 abort task with reason: fetch failed due to requested offset not available on the broker: Broker: Offset out of range'}
  * Q11. ERROR 1105 (HY000): errCode = 2, detailMessage = (192.168.90.91)[CANCELLED][INTERNAL_ERROR]error setting certificate verify locations: CAfile: /etc/ssl/certs/ca-certificates.crt CApath: none
  * Q12. create partition failed. partition numbers will exceed limit variable max_auto_partition_num