Todos os produtos
Search
Central de documentação

E-MapReduce:FAQ

Última atualização: Oct 15, 2026

Este tópico responde às perguntas frequentes sobre o EMR Serverless StarRocks.

Como acessar o oss entre contas?

Por padrão, o EMR Serverless StarRocks fornece acesso sem senha aos buckets do oss na mesma conta. Para acessar recursos do oss em outra conta, desative esse padrão, configure o par de AccessKey da conta de destino e aplique a nova configuração.

  1. Desative o acesso sem senha: na aba Parameter Configuration, limpe os valores dos seguintes itens de configuração nos arquivos especificados.

    • core-site.xml

      fs.oss.credentials.provider =
    • jindosdk.cfg

      fs.oss.provider.format =
      fs.oss.provider.endpoint =
  2. Adicione o par de AccessKey da conta de destino: na aba Parameter Configuration, clique em Add Configuration Item e adicione as seguintes configurações aos arquivos especificados.

    • core-site.xml

      fs.oss.accessKeyId = AccessKey ID of the target account
      fs.oss.accessKeySecret = AccessKey Secret of the target account
    • jindosdk.cfg

      fs.oss.accessKeyId = AccessKey ID of the target account
      fs.oss.accessKeySecret = AccessKey Secret of the target account
  3. Aplique a configuração: na aba Parameter Configuration, clique em Submit Parameters.

Uso de drivers de conector UDF e JDBC

Antes de usar drivers UDF e JDBC, obtenha os arquivos JAR necessários de uma source externa.

  1. Faça o upload dos arquivos JAR para o oss. Para mais informações, consulte Upload files.

    Ao fazer o upload dos arquivos, defina o object ACL como Public Read/Write para conceder permissões públicas de leitura e gravação aos arquivos JAR.

  2. Obtenha a URL de cada arquivo JAR.

    No console do oss, localize o link de cada arquivo JAR enviado com sucesso. Use a URL HTTP do endpoint interno, que deve estar em um dos seguintes formatos:

    • Para um driver JDBC: http://<YourBucketName>.oss-cn-xxxx-internal.aliyuncs.com/mysql-connector-java-*.jar.

    • Para uma UDF: http://<YourBucketName>.oss-cn-xxxx-internal.aliyuncs.com/<YourPath>/<jar_package_name>.

  3. Use os arquivos JAR. Para mais informações, consulte Java UDF e JDBC Catalog.

Como redefinir a senha da instância?

Importante
  • Redefinir a senha da instância interrompe as conexões entre cliente e servidor. Para minimizar o impacto na produção, execute esta operação fora dos horários de pico.

  • Apenas usuários com a permissão AliyunEMRStarRocksFullAccess podem redefinir a senha.

  1. acesse a página de detalhes da instância.

    1. Faça login no E-MapReduce console.

    2. No painel de navegação à esquerda, escolha EMR Serverless > StarRocks.

    3. clique em nome da instância de destino.

  2. Na página Instance Details, na seção Basic Information, clique em Reset Password.

  3. Na caixa de diálogo exibida, insira e confirme a nova senha e, em seguida, clique em OK.

Erro ao gravar dados em tabelas Paimon

  • Sintoma: ao usar o StarRocks para gravar dados em uma tabela Paimon, você pode receber a seguinte mensagem de erro:

    (5025, 'Backend node not found. Check if any backend node is down.')
  • Causa: uma verificação de permissão nas tabelas Paimon pode impedir que o StarRocks identifique corretamente os nós BE durante as operações de gravação.

  • Solução:

    • atualize a versão (recomendado): se a versão da sua instância for anterior a uma das seguintes, execute uma minor version update para aplicar a correção.

      • StarRocks 3.2: 3.2.11-1.89 ou posterior

      • StarRocks 3.3: 3.3.8-1.88 ou posterior

    • Solução alternativa: na aba Parameter Configuration da instância do StarRocks, adicione o seguinte item de configuração ao arquivo core-site.xml.

      dlf.permission.clientCheck=false

O que fazer ao receber o erro not a RAM user ao criar uma tabela externa no StarRocks?

  • Sintoma: ao criar uma tabela externa no StarRocks, você pode receber a seguinte mensagem de erro:

    current user is not a RAM user
  • Causa: este erro é causado por permissões insuficientes ou por uma versão desatualizada da instância.

  • Solução:

    1. verifique as permissões do usuário RAM: certifique-se de que o usuário do Resource Access Management (RAM) tenha as permissões necessárias para o StarRocks. Para mais informações, consulte Grant permissions to a RAM user.

    2. Se as permissões estiverem corretas, verifique e atualize a versão do kernel na página Instance Details do StarRocks.

      Se a versão da sua instância for anterior a uma das seguintes, execute uma minor version update para aplicar a correção.

      • StarRocks 3.2: 3.2.11-1.89 ou posterior

      • StarRocks 3.3: 3.3.8-1.88 ou posterior

Erro com ponto e vírgula no SQL Editor

  • Sintoma: ao executar uma instrução SQL contendo um ponto e vírgula (;) no SQL Editor, ocorre um erro. A mensagem de erro inclui the most similar input is {a legal identifier}.

    O código do erro é 1064, e os detalhes também incluem Unexpected input '<EOF>', indicando um erro de sintaxe na linha 3, coluna 11.

  • Esse erro ocorre porque o SQL Editor usa o ponto e vírgula (;) como terminador de instrução por padrão. Se a sua instrução SQL contiver um ponto e vírgula (;), ocorrerá um erro de análise de sintaxe.

  • Solução:

    1. defina um delimitador personalizado.

      Antes de executar uma instrução SQL que contenha um ponto e vírgula, defina um delimitador personalizado para evitar erros de análise de sintaxe. Por exemplo, altere o delimitador para $$.

      delimiter $$
    2. execute a instrução SQL que contém um ponto e vírgula. Veja um exemplo abaixo:

      INSERT INTO sr_test VALUES 
      (1, 'asdsd,asdsads'), 
      (2, 'sadsad;asdsads');
    3. Restaure o delimitador padrão.

      Após a execução da instrução SQL, restaure o delimitador padrão (;) para que as operações SQL subsequentes sejam executadas conforme o esperado.

      delimiter ;
    4. verifique o resultado.

      execute uma consulta para verifique se os dados foram inseridos corretamente.

      delimiter ;
      SELECT * FROM sr_test;
      Output
        test_id    test_desc
      0       1    asdsd,asdsads
      1       2    sadsad;asdsads

Falha ao importar dados ou acessar tabelas externas

  • Sintoma: ao usar o EMR Serverless StarRocks para importar dados ou acessar uma tabela externa, a importação ou conexão pode falhar se o destino for um endereço IP público.

  • Causa: por padrão, uma instância do EMR Serverless StarRocks é executada em um ambiente de Virtual Private cloud (vpc), que pode não ter acesso direto à internet. Portanto, as solicitações para recursos públicos, como importações de dados ou consultas a tabelas externas, falham, a menos que o acesso à internet esteja configurado.

  • Solução: implante um gateway nat da Internet na vpc e ative o recurso SNAT. Isso permite que a instância do EMR Serverless StarRocks acesse recursos públicos por meio do gateway. Para mais informações, consulte Use the SNAT feature of an Internet nat gateway to access the Internet.

Evite o fechamento de conexão pelo tempo limite de ociosidade do slb/CLB

  • Sintoma: ao usar o slb com uma instância do StarRocks, o slb fecha forçadamente a conexão do cliente se uma consulta SQL for executada por mais de 900 segundos, impedindo que a consulta retorne um resultado. Para mais informações sobre como ativar o slb, consulte gerencie gateways.

  • Causa: o slb fecha qualquer conexão tcp que fique ociosa por mais de 900 segundos. Isso pode acontecer durante uma consulta SQL de longa duração, interrompendo a conexão antes que o StarRocks retorne um resultado.

  • Solução: configure os parâmetros tcp Keepalive no lado do cliente para evitar que o slb feche conexões ociosas.

    • Configurações globais de parâmetros do kernel (nível do sistema)

      modifique os parâmetros do kernel do sistema operacional para ative e defina as configurações adequadas de tcp Keepalive para todas as conexões tcp. Isso ajuda a monitorar o status das conexões de rede. A tabela a seguir descreve os parâmetros a serem configurados.

      Parâmetro

      Descrição

      Valor recomendado

      • Linux: net.ipv4.tcp_keepalive_time

      • FreeBSD/macOS: net.inet.tcp.keepidle

      O período de inatividade, em segundos, após o qual a primeira sondagem Keepalive é enviada.

      600 segundos

      • Linux: net.ipv4.tcp_keepalive_intvl

      • FreeBSD/macOS: net.inet.tcp.keepintvl

      O intervalo, em segundos, entre as retransmissões da sondagem Keepalive.

      60 segundos

      • Linux: net.ipv4.tcp_keepalive_probes

      • FreeBSD/macOS: net.inet.tcp.keepcnt

      O número de sondagens consecutivas com falha após as quais a conexão é descartada.

      5

      Linux

      • Aplicar configurações temporariamente

        # Set global Keepalive parameters (root permissions required)
        sudo sysctl -w net.ipv4.tcp_keepalive_time=600   # Corresponds to keepidle (600 seconds)
        sudo sysctl -w net.ipv4.tcp_keepalive_intvl=60   # Corresponds to keepintvl (60 seconds)
        sudo sysctl -w net.ipv4.tcp_keepalive_probes=5   # Corresponds to keepcount (5)
      • Aplicar configurações permanentemente

        Adicione o seguinte conteúdo a /etc/sysctl.conf e execute sysctl -p para aplicar as configurações.

        echo "net.ipv4.tcp_keepalive_time = 600" >> /etc/sysctl.conf
        echo "net.ipv4.tcp_keepalive_intvl = 60" >> /etc/sysctl.conf
        echo "net.ipv4.tcp_keepalive_probes = 5" >> /etc/sysctl.conf

      FreeBSD/macOS

      • Aplicar configurações temporariamente

        # Set global Keepalive parameters (root permissions required)
        sudo sysctl -w net.inet.tcp.keepidle=600
        sudo sysctl -w net.inet.tcp.keepintvl=60
        sudo sysctl -w net.inet.tcp.keepcnt=5
      • Aplicar configurações permanentemente

        Adicione o seguinte conteúdo a /etc/sysctl.conf.

        echo "net.inet.tcp.keepidle = 600" >> /etc/sysctl.conf
        echo "net.inet.tcp.keepintvl = 60" >> /etc/sysctl.conf
        echo "net.inet.tcp.keepcnt = 5" >> /etc/sysctl.conf
    • Configurações no nível da aplicação

      Use APIs específicas da linguagem para defina os parâmetros tcp Keepalive para uma única conexão.

      Java

      A biblioteca padrão do Java tem suporte limitado para tcp Keepalive. No entanto, você pode implementá-lo usando reflection ou opções de socket de baixo nível.

      Nota

      O código a seguir requer suporte do sistema para opções como tcp_keepidle no Linux ou FreeBSD. Além disso, alguns métodos, como reflection, podem não funcionar devido a diferenças nas versões da JVM. Recomendamos testar a compatibilidade antes de usar em um ambiente de produção.

      import java.io.IOException;
      import java.net.InetSocketAddress;
      import java.net.Socket;
      import java.net.SocketOption;
      import java.nio.channels.SocketChannel;
      public class TcpKeepaliveExample {
          public static void main(String[ ] args) {
              try (Socket socket = new Socket()) {
                  // 1. Enable Keepalive
                  socket.setKeepAlive(true);
                  // 2. Set Keepalive parameters (requires low-level socket options)
                  SocketChannel channel = socket.getChannel();
                  if (channel != null) {
                      // Set Keepidle (idle time)
                      channel.setOption(StandardSocketOptions.SO_KEEPALIVE, true); // Keepalive must be enabled first
                      setSocketOptionInt(socket, "tcp_keepidle", 600); // Requires system support
                      // Set Keepintvl (retransmission interval)
                      setSocketOptionInt(socket, "tcp_keepintvl", 60);
                      // Set Keepcount (number of failures)
                      setSocketOptionInt(socket, "tcp_keepcnt", 5); // Note: The parameter name may vary by system
                  }
                  // Connect to the server
                  socket.connect(new InetSocketAddress("example.com", 80));
                  // ... Other operations ...
              } catch (IOException e) {
                  e.printStackTrace();
              }
          }
          // Use reflection to set system-specific socket options (such as on Linux/FreeBSD)
          private static void setSocketOptionInt(Socket socket, String optionName, int value) {
              try {
                  Class<?> clazz = Class.forName("java.net.Socket$SocketOptions");
                  Object options = clazz.getDeclaredMethod("options").invoke(socket);
                  Class<?> optionsClass = options.getClass();
                  optionsClass.getDeclaredMethod("setOption", String.class, int.class)
                          .invoke(options, optionName, value);
              } catch (Exception e) {
                  throw new RuntimeException("Failed to set socket option " + optionName, e);
              }
          }
      }

      Python

      O módulo socket do Python suporta a configuração direta dos parâmetros tcp Keepalive.

      Nota

      Diferentes sistemas operacionais podem usar nomes de parâmetros diferentes. Por exemplo, o macOS pode exigir TCP_KEEPALIVE em vez de TCP_KEEPIDLE. Alguns parâmetros podem exigir permissões de root para serem definidos.

      import socket
      def create_keepalive_socket():
          sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
          # 1. Enable Keepalive
          sock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
          # 2. Set Keepalive parameters (Linux/FreeBSD)
          # Keepidle: 600 seconds
          sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 600)
          # Keepintvl: 60 seconds
          sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 60)
          # Keepcount: 5
          sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 5)
          return sock
      # Example
      sock = create_keepalive_socket()
      sock.connect(("example.com", 80))
      # ... Other operations ...
      sock.close()

      Golang

      O pacote net do Golang fornece uma configuração básica de Keepalive. No entanto, é necessário usar o pacote syscall de baixo nível para defina parâmetros detalhados.

      Nota

      Diferentes sistemas operacionais podem usar nomes de parâmetros diferentes. Alguns parâmetros podem exigir permissões de root para serem definidos.

      package main
      import (
          "fmt"
          "net"
          "syscall"
      )
      func main() {
          // Create a TCP connection
          conn, err := net.Dial("tcp", "example.com:80")
          if err != nil {
              panic(err)
          }
          defer conn.Close()
          // Get the underlying file descriptor
          file, err := conn.(*net.TCPConn).File()
          if err != nil {
              panic(err)
          }
          defer file.Close()
          fd := int(file.Fd())
      
          // Enable Keepalive
          err = syscall.SetsockoptInt(fd, syscall.SOL_SOCKET, syscall.SO_KEEPALIVE, 1)
          if err != nil {
              panic(fmt.Errorf("set SO_KEEPALIVE: %v", err))
          }
          // Set Keepidle (idle time)
          err = syscall.SetsockoptInt(fd, syscall.IPPROTO_TCP, syscall.TCP_KEEPIDLE, 600)
          if err != nil {
              panic(fmt.Errorf("set TCP_KEEPIDLE: %v", err))
          }
          // Set Keepintvl (retransmission interval)
          err = syscall.SetsockoptInt(fd, syscall.IPPROTO_TCP, syscall.TCP_KEEPINTVL, 60)
          if err != nil {
              panic(fmt.Errorf("set TCP_KEEPINTVL: %v", err))
          }
          // Set Keepcount (number of failures)
          err = syscall.SetsockoptInt(fd, syscall.IPPROTO_TCP, syscall.TCP_KEEPCNT, 5)
          if err != nil {
              panic(fmt.Errorf("set TCP_KEEPCNT: %v", err))
          }
          // ... Other operations ...
      }

Erro "Unexpected exception: Table '' is not a OLAP table" ao fazer backup de dados do StarRocks

  • Sintoma: a seguinte mensagem de erro é relatada ao usar o StarRocks para criar um backup de snapshot de dados.

    Unexpected exception: Table '<table_name>' is not a OLAP table
  • Análise da causa:

    • A instância usa o modo de separação de armazenamento e computação.

      As instâncias do StarRocks que usam a separação de armazenamento e computação não suportam backup e restauração de dados. Apenas instâncias com armazenamento e computação integrados suportam este recurso.

    • O tipo de mecanismo da tabela é incompatível.

      O recurso de backup do StarRocks suporta apenas tabelas que usam o mecanismo OLAP. Se o tipo de mecanismo de uma tabela não for OLAP, esse erro será relatado.

  • Solução:

    • verifique o tipo de instância.

      Na página Instance List do StarRocks, verifique o Instance Type. Se o tipo de instância for Storage-Compute Separation, o backup e a restauração de dados não são suportados. Recomendamos o uso de uma instância com armazenamento e computação integrados para ative o backup e a restauração. Para mais informações, consulte Backup and restoration.

    • verifique o tipo de mecanismo da tabela.

      verifique a definição DDL da tabela de destino para confirme se ENGINE=OLAP está definido.

      SHOW CREATE TABLE <table_name>;

      Se o mecanismo da tabela não for OLAP, recrie a tabela com base nos seus requisitos de negócios e certifique-se de que ENGINE=OLAP esteja especificado.

Falha na carga de dados em uma tabela Primary Key com o erro: Cancelled, msg: Primary-key index exceeds the limit

  • Problema:

    A carga de dados em uma tabela Primary Key falha com a mensagem de erro: msg: Cancelled, msg: Primary-key index exceeds the limit. tablet_id: 2506733, consumption: 33176971421, limit: 32116807950. Memory stats of top five tablets: 3656508(4465M) 3656496(4464M) 3656544(4464M) 3656520(4462M) 3656532(4461M): be: backend-0.backend.xxx.svc.cluster.local.xxx

  • Abordagem para solução de problemas:

    • Analise o uso atual de memória do nó BE para determinar se existe um gargalo de recursos.

    • Determine se o cluster usa uma arquitetura shared-nothing ou shared-data e verifique os itens de configuração correspondentes.

  • Etapas detalhadas de solução de problemas:

    • Analisar o uso de memória

      • O erro ocorre porque a memória consumida pelo índice de chave primária excede o limite de memória do nó BE.

      • verifique a configuração mem_limit do nó BE, que pode ser obtida executando SHOW FRONTENDS ou SHOW BACKENDS, e avalie sua capacidade de memória disponível.

    • Soluções

      • Solução 1: ative índices persistentes (recomendado)

        • Cluster shared-nothing: defina enable_persistent_index como true.

        • Cluster shared-data: defina persistent_index_type como cloud_native.

      • Solução 2: Projetar partições adequadamente

        • Particione a tabela Primary Key com base em dimensões apropriadas, como tempo ou região, para evitar gravações na tabela inteira.

        • Após o particionamento da tabela, cada gravação afeta apenas um subconjunto das partições. O índice de chave primária precisa carregar dados apenas das partições afetadas, o que reduz a pressão de memória de cada gravação.

    • Falha no job de carga com o erro "[E1008]Reached timeout=xxx ms"

      • Problema:

        • Quando um job do Flink carrega dados no StarRocks, ocorre o seguinte erro: Message: [E1008] Reached timeout=7500ms @x.x.x.x:8060.

        • Quando os dados são carregados usando INSERT INTO, ocorre o seguinte erro: java.sql.SQLException: [E1008] Reached timeout=7500ms @10.106.7.182:8060.

      • Solução de problemas:

        • Se o valor de tempo limite no erro não for 30000 ms, que é o valor padrão de rpc_connect_timeout_ms, verifique se o parâmetro rpc_connect_timeout_ms do nó BE foi alterado manualmente.

        • Para jobs de carga que usam INSERT INTO, verifique se o parâmetro query_timeout está configurado, como query_timeout = 15. O StarRocks define o tempo limite do RPC como metade do valor de query_timeout e converte o resultado para milissegundos. Portanto, se query_timeout=15, o tempo limite correspondente é de 7500 ms.

      • Etapas detalhadas de solução de problemas:

        • Se você confirme que o parâmetro rpc_connect_timeout_ms do nó BE foi alterado: restaure o parâmetro para seu valor padrão de 30000 ms para evitar erros de tempo limite falsos causados por um tempo limite de conexão excessivamente curto.

        • O erro Reached timeout=7500ms geralmente indica uma alta carga de threads brpc no nó BE. Isso atrasa o processamento de solicitações RPC e, eventualmente, aciona um tempo limite.

        • execute SHOW TABLET FROM &lt;destination_database&gt;.&lt;destination_table&gt; ORDER BY RowCount DESC; para analisar a distribuição de dados da tabela de destino e determinar se os dados estão distribuídos adequadamente entre os tablets. Por exemplo, se a quantidade de dados em um único tablet exceder significativamente o intervalo recomendado de 1 GB a 10 GB, alguns nós BE podem ficar sobrecarregados, o que degrada o desempenho de gravação.

        • Soluções:

          • Solução 1 (recomendada): otimize a estratégia de bucketing da tabela. selecione um campo apropriado de alta cardinalidade como chave de bucketing em DISTRIBUTED BY HASH(...) para distribuir os dados uniformemente entre os tablets.

          • Solução 2 (mitigação temporária): se o uso de cpu e I/O nos nós BE não tiver atingido seus limites, ajuste os seguintes parâmetros conforme apropriado:

            • Aumente brpc_num_threads. O valor padrão é o número de núcleos de cpu no nó BE. Tente defina o parâmetro para duas ou quatro vezes o seu valor padrão. Não exceda quatro vezes o valor padrão, pois isso pode aumentar a contenção de threads.

            • Aumente flush_thread_num_per_store. O valor padrão é 2. defina o parâmetro como 4 para aumentar a concorrência quando os dados são gravados nos discos.

        • Falha no job de carga com o erro "Error:NULL value in non-nullable column 'xxx'"

          • Problema: ao carregar dados em uma tabela do StarRocks, ocorre o seguinte erro: Error: NULL value in non-nullable column 'xxx'.

          • Causa: um valor NULL é gravado em uma coluna definida como NOT NULL. Isso viola a restrição do schema da tabela e faz com que o job de carga falhe.

          • Soluções:

            • Solução 1: Corrija os dados upstream

              Antes que os dados sejam gravados no StarRocks, filtre ou substitua os valores NULL para garantir que os dados estejam em conformidade com as restrições da tabela de destino.

            • Solução 2: modifique o schema da tabela

              Se a lógica de negócios permitir que o campo contenha valores NULL, modifique o schema da tabela e remova a restrição NOT NULL.

          O erro "because of too many versions, current/limit: 1009/1000" ocorre ao importar dados usando o Flink Connector

          • Problema:

            Ao gravar dados continuamente em uma tabela do StarRocks usando o Flink Connector, ocorre o seguinte erro: because of too many versions, current/limit: 1009/1000.

          • Causa: no modelo Primary Key do StarRocks ou no modelo Unique Key que usa Merge-on-Write, cada importação de dados gera uma nova versão. Para evitar o inchaço de metadados e garantir o desempenho da consulta, o sistema permite que cada partição retenha até 1.000 versões por padrão.

          • Solução:

            • verifique o Compaction Score das partições

              execute a seguinte instrução SQL para verifique a carga de compactação de cada partição na tabela de destino:

              SELECT 
                  TABLE_NAME,
                  PARTITION_NAME,
                  AvgCS AS avg_compaction_score,
                  MaxCS AS max_compaction_score
              FROM information_schema.partitions_meta 
              WHERE TABLE_NAME = 'your_table_name';

              Se o valor MaxCS — o Compaction Score máximo — da partição afetada for significativamente maior que 100, a partição conterá um grande número de versões pequenas aguardando para serem mescladas. Isso indica que a compactação não foi concluída a tempo.

            • Acione a compactação manualmente

              execute a seguinte instrução: ALTER TABLE your_db.your_table COMPACT PARTITION your_partition_name;

            • Otimize os parâmetros do sink do Flink

              Aumente os valores dos seguintes parâmetros do sink do Flink: sink.buffer-flush.max-bytes, sink.buffer-flush.max-rows, sink.buffer-flush.interval-ms. Isso reduz a frequência de importação de dados e evita a geração excessiva de versões pequenas.

          Erro "Failed to get status for file xxx" ao consultar dados usando um External Catalog

          • Problema:

            Ao consultar uma tabela em um data lake externo, como Paimon ou Iceberg, ocorre o seguinte erro: (1064, 'Failed to get status for file: oss://data-lakehouse-oss-normal/dataware.db/dwd_annotation2_user/metadata/00097-10647858-814a-499e-b300-51c570ee7ee0.metadata.json') A API do oss retorna o seguinte erro:

            <Error>
              <Code>AccessDenied</Code>
              <Message>You have no right to access this object because of bucket acl.</Message>
              <RequestId>68EC744EB6CD8C3539FAB32A</RequestId>
              <HostId>data-lakehouse-oss-normal.oss-cn-shenzhen-internal.aliyuncs.com</HostId>
              <EC>0003-00000001</EC>
              <RecommendDoc>https://api.alibabacloud.com/troubleshoot?q=0003-00000001</RecommendDoc>
            </Error>
          • Causa: o StarRocks depende do acesso a um Object Storage Service, como o Alibaba Cloud oss, ao consultar tabelas em um data lake externo, como Hive, Iceberg ou Hudi, usando um External Catalog. Permissões ou configurações incorretas podem impedir que o StarRocks leia metadados ou arquivos de dados.

          • Solução:

            • Primeiro, verifique se o AccessKey é válido. confirme se o accessKeyId e o accessKeySecret configurados podem acessar o bucket do oss de destino.

            • Se o accessKeyId e o accessKeySecret estiverem configurados corretamente, verifique se o bucket do oss é acessado entre contas da Alibaba Cloud. Para acesso entre contas a um bucket do oss, modifique as configurações relevantes. Para mais informações, consulte How do I access oss across accounts? .

          Como visualize o espaço em disco ocupado por índices persistentes nos nós CN e BE?

          Após a ativação de índices persistentes definindo enable_persistent_index = true ou persistent_index_type = 'cloud_native', os índices de chave primária são armazenados em discos. Consulte a tabela information_schema.be_tablets para obter o uso de disco deles.

          -- Query the index size of each table and sort the results, by index size in descending order.
          SELECT 
              tables_config.TABLE_NAME,
              t1.TABLE_ID,
              t1.index_sum_mb
          FROM (
              -- Calculate the total index size of each table in MB.
              SELECT 
                  TABLE_ID,
                  SUM(INDEX_DISK)/1024/1024 AS index_sum_mb
              FROM information_schema.be_tablets 
              GROUP BY TABLE_ID
          ) t1 
          JOIN tables_config ON tables_config.TABLE_ID = t1.TABLE_ID 
          ORDER BY index_sum_mb DESC
          -- Optional: Add a LIMIT clause to limit the number of returned rows when the result set is excessively large.
          -- LIMIT 100
          ;

          Como visualize transações de gravação em andamento e os tablets associados a diferentes lotes de transação?

          Rastreie jobs de carga em andamento ou concluídos recentemente para identificar os tablets nos quais os dados são gravados.

          SELECT 
              txn_table.*,
              tc.table_name
          FROM (
              SELECT 
                  bt.TABLET_ID,
                  bt.COMMIT_TIME,
                  bt.PUBLISH_TIME,
                  bt.TABLE_ID
              FROM information_schema.be_txns bt
              JOIN information_schema.be_tablets btt 
                  ON bt.TABLET_ID = btt.TABLET_ID
          ) AS txn_table
          JOIN information_schema.tables_config tc 
              ON txn_table.TABLE_ID = tc.TABLE_ID;

          Como analisar um aumento repentino na carga de cpu ou memória durante um período específico?

          Use logs de auditoria para identificar consultas que consomem grandes quantidades de recursos.

          SELECT 
              queryId,
              timestamp,
              ROUND(memCostBytes / 1024 / 1024 / 1024, 2) AS memCostGB,
              cpuCostNs
          FROM _starrocks_audit_db_.starrocks_audit_tbl
          WHERE timestamp BETWEEN '2025-xx-xx hh:mm:ss' AND '2025-xx-xx hh:mm:ss'
          ORDER BY cpuCostNs DESC, memCostGB DESC
          LIMIT 20;

          Como analisar um aumento repentino na carga de I/O durante um período específico?

          Os picos de I/O são geralmente causados por varreduras em grande escala, como varreduras de tabela completa ou consultas que não podem usar poda de partição ou índices.

          SELECT 
              queryId,
              timestamp,
              ROUND(scanBytes / 1024 / 1024 / 1024, 2) AS scanTotalGB
          FROM _starrocks_audit_db_.starrocks_audit_tbl
          WHERE timestamp BETWEEN '2025-xx-xx hh:mm:ss' AND '2025-xx-xx hh:mm:ss'
          ORDER BY scanTotalGB DESC
          LIMIT 20;

          Erro de armazenamento insuficiente ao reduzir a escala dos nós BE em um cluster StarRocks totalmente gerenciado

          • Problema:

            Ao reduzir a escala dos nós BE a partir do console de um cluster StarRocks totalmente gerenciado, o seguinte erro é exibido: invalid status: [insufficient storage].

          • Causa: os requisitos de validação de armazenamento para a operação de redução de escala não são atendidos. O sistema permite a operação apenas se a capacidade total de armazenamento após a redução de escala atender ao seguinte requisito:

            Armazenamento usado < Capacidade total após a redução de escala × 0,7

            Os valores são calculados da seguinte forma:

            • Capacidade total após a redução de escala = Capacidade combinada dos nós restantes após a remoção dos nós especificados

            • Armazenamento usado = Soma de (capacidade total − capacidade disponível) em todos os nós

            • execute SHOW BACKENDS para obter totalCapacity e availCapacity.

          • Solução:

            • verifique a capacidade atual do cluster.

              execute a seguinte instrução SQL para obter as capacidades total e disponível de cada nó BE:

              SHOW BACKENDS\G

              verifique os campos TotalCapacity e AvailCapacity. Determine se o armazenamento usado excede 70% da capacidade total após a redução de escala.

            • Expanda os discos e tente novamente.

              Se a capacidade do disco for insuficiente, expanda os discos dos nós BE no console do EMR. Certifique-se de que Used storage &lt; Total capacity after scale-in × 0.7 e, em seguida, tente novamente a operação de redução de escala.

          O erro RAM.Permission.NotAllow é relatado ao fazer login no StarRocks Manager

          • Problema:

            Ao usar um usuário RAM para fazer login no StarRocks Manager, a mensagem "You are not authorized to perform the operation" é exibida. O código do erro é RAM.Permission.NotAllow.

          • Causa: o usuário RAM não tem as permissões necessárias para executar operações no EMR Serverless StarRocks e, portanto, não pode acessar o StarRocks Manager. Para mais informações, consulte Authorize a RAM user.

          • Solução:

            • Método 1: Conceda uma política do sistema.

              Faça login no console do RAM e conceda a política do sistema AliyunEMRStarRocksFullAccess ao usuário RAM. O usuário RAM terá então permissões totais para executar operações no EMR Serverless StarRocks.

            • Método 2: Conceda permissões refinadas.

              Se você não quiser conceder permissões totais, use o RequestId na mensagem de erro para identificar as permissões ausentes e conceda-as ao usuário RAM no console do RAM. Por exemplo, se a permissão emr-serverless-starrocks:ListInstances estiver ausente, crie uma política personalizada que conceda apenas essa permissão.

            Na página Policies do console do RAM, pesquise por AliyunEMRStarRocksFullAccess para visualize todas as permissões incluídas na política do sistema.

          Como resolver o erro "must be an aggregate expression or appear in GROUP BY clause" no StarRocks?

          • Sintoma: ao executar uma consulta SQL que contém uma cláusula GROUP BY no StarRocks, o seguinte erro ocorre se a lista SELECT contiver uma coluna não agregada que não esteja incluída na cláusula GROUP BY.

            Getting analyzing error: ... must be an aggregate expression or appear in GROUP BY clause
          • Causa: a regra ONLY_FULL_GROUP_BY no sql_mode aciona esse erro. Quando esta regra está ativada, cada coluna não agregada na lista SELECT também deve aparecer na cláusula GROUP BY.

          • Solução:

            1. Conecte-se à instância do StarRocks usando o SQL Editor no StarRocks Manager ou um cliente MySQL.

            2. execute o seguinte comando para limpar o sql_mode e remover a regra ONLY_FULL_GROUP_BY.

              SET GLOBAL sql_mode='';
            3. verifique se o sql_mode está vazio.

              SELECT @@GLOBAL.sql_mode;

            A configuração SET GLOBAL sql_mode entra em vigor imediatamente sem a reinicialização do service. Desativar ONLY_FULL_GROUP_BY pode produzir valores imprecisos para colunas não agregadas em consultas GROUP BY. Teste essa alteração em um ambiente de teste antes de aplicá-la à produção. Esta operação altera a configuração global.