Os jobs BUILD são usados para reconstruir partições que receberam novos dados. Isso ajuda a melhorar o desempenho de leitura. Durante o processo de reconstrução, o sistema cria índices, limpa dados redundantes e executa instruções DDL de forma assíncrona.
Visão geral
Durante um job BUILD, o sistema mescla os dados gravados em tempo real com as partições históricas que contêm esses dados, cria índices e executa instruções DDL de forma assíncrona. Após a execução de instruções INSERT, UPDATE ou DELETE nos dados de uma partição, você pode executar um job BUILD para reconstruir a partição. Os jobs BUILD não reconstruem partições que não sofreram alterações nos dados.
O agendamento dos jobs BUILD ocorre no nível da tabela. Jobs BUILD de tabelas diferentes podem ser executados em paralelo. Quando um job BUILD é iniciado em uma tabela, ele é dividido em tarefas no nível do shard. Cada uma das três réplicas de um shard executa uma tarefa. O job BUILD é concluído quando todas as tarefas terminam.
Ao executar instruções DELETE ou REPLACE, os dados são marcados para exclusão e limpos de forma assíncrona pelos jobs BUILD em segundo plano. Se um grande número de instruções DELETE ou REPLACE for executado e os jobs BUILD ainda não estiverem concluídos, o número de linhas da tabela exibido no Storage Overview será maior que o resultado retornado por SELECT COUNT(*). O número de linhas exibido no Storage Overview vem do campo row_count em information_schema.kepler_partitions, que conta as linhas físicas e inclui as linhas marcadas para exclusão, mas ainda não limpas. Já o SELECT COUNT(*) retorna o número de linhas lógicas válidas e exclui as linhas marcadas para exclusão. Execute manualmente BUILD TABLE para que o sistema exclua os dados marcados para exclusão e iguale os dois valores.
Notas de uso
Durante um job BUILD, não é possível executar a instrução
INSERT OVERWRITE SELECTpara inserir dados nas tabelas até que o job BUILD seja concluído. Para inserir dados nesse período, execute a instruçãoINSERT INTO.Envie o job BUILD com atenção, pois após o envio, não é possível que você o cancele.
-
Por padrão, o número de jobs BUILD simultâneos é o resultado arredondado para cima de
Number of cores/3e não pode ser modificado.Por exemplo, se as especificações do nó de um cluster AnalyticDB for MySQL forem de 32 núcleos e 128 GB de memória, o número de jobs BUILD simultâneos será 11 (resultado arredondado para cima de
32/3). Os jobs BUILD consomem recursos de cpu, memória e I/O. Como resultado, métricas relacionadas ao disco, como utilização de cpu e uso de I/O de disco, podem aumentar. Após a conclusão dos jobs BUILD, as métricas retornam aos valores normais. Recomendamos a execução dos jobs BUILD em horários de menor movimento.
Acionamento automático de jobs BUILD
Um job BUILD é acionado automaticamente quando uma das seguintes condições é atendida:
-
O tempo decorrido desde o job BUILD mais recente atinge o intervalo de tempo mínimo entre jobs BUILD e pelo menos 50.000 linhas de dados são adicionadas a um shard de uma tabela.
Intervalo de tempo para a Enterprise Edition, Basic Edition ou Data Lakehouse Edition: 1,5 horas.
Intervalo de tempo para a Data Warehouse Edition in elastic mode: 1,5 horas.
Intervalo de tempo para a Data Warehouse Edition in reserved mode: 0,5 horas.
Vinte e quatro horas se passaram desde o job BUILD mais recente e pelo menos uma linha de dados foi modificada.
-
Quando a quantidade de dados recém-adicionados em um shard de uma tabela atinge 1 milhão de linhas, o intervalo de tempo entre jobs BUILD é ignorado e um job BUILD é executado imediatamente no próximo agendamento.
NotaEssa regra é suportada apenas por clusters cujas versões de kernel sejam v3.1.8.7, v3.1.9.4, v3.1.10.1 ou v3.2.0 e posteriores. Visualize a versão do kernel de um cluster consultando 如何查看实例版本信息. O limiar para acionar essa regra pode ser ajustado usando o parâmetro de controle
RC_BUILD_IGNORE_INTERVAL_TIME_ROW_COUNT. O valor padrão é1000000(1 milhão de linhas). O ajuste entra em vigor imediatamente, sem necessidade de reinicialização. -
Quando a tabela possui tarefas assíncronas DDL no estado Waiting, um job BUILD é executado imediatamente no próximo agendamento.
NotaEssa regra é suportada apenas por clusters cujas versões de kernel sejam v3.2.0 e posteriores. As tarefas assíncronas DDL (como alteração de tipos de coluna e modificação de políticas de armazenamento) entram em vigor somente após a conclusão de um job BUILD. Essa regra evita que tarefas DDL assíncronas permaneçam no estado Waiting por muito tempo devido à espera pelo intervalo de tempo entre jobs BUILD. O controle dessa regra é feito pelo parâmetro
RC_AUTO_BUILD_WHEN_HAS_DATA_MODIFY_TASKSe ela está ativada por padrão. Para desativá-la, executeSET ADB_CONFIG RC_AUTO_BUILD_WHEN_HAS_DATA_MODIFY_TASKS = false;.
Acionar manualmente um job BUILD
Executar uma instrução BUILD nas partições que sofreram alterações nos dados
-
Tabela XUANWU
BUILD TABLE <table_name>;Este método aciona um job BUILD apenas nas partições cujos dados foram modificados.
-
-
Tabela XUANWU_V2
BUILD TABLE <table_name> [BUILD_OPTION];BUILD_OPTION: suporta apenas o valorttl, que é um parâmetro opcional. Se você deixar esse parâmetro vazio, este método aciona um job BUILD apenas nas partições cujos dados foram modificados. Se você especificar esse parâmetro, este método exclui imediatamente as partições expiradas após a conclusão do job BUILD. Certifique-se de que você especifique o mecanismo de tabela corretamente.
NotaPara obter informações sobre como determinar o mecanismo de tabela, e para que você especifique um mecanismo de tabela, consulte a seção "Especifique um mecanismo de tabela" do tópico XUANWU_V2 engine.
-
Executar uma instrução BUILD em partições específicas
BUILD TABLE test force partitions='partition1,partition2';
Você pode executar uma instrução BUILD em partições específicas apenas para clusters AnalyticDB for MySQL V3.1.6.0 ou posteriores. Visualize a versão secundária de um cluster AnalyticDB for MySQL consultando 如何查看实例版本信息. Para atualizar a versão secundária de um cluster, entre em contato com o suporte técnico.
Se uma tabela contiver grandes volumes de dados, a execução da instrução BUILD TABLE <table_name> force = true; pode levar muito tempo. O AnalyticDB for MySQL permite que você selecione e especifique as partitions nas quais deseja executar um job BUILD. Isso ajuda a reduzir o uso de recursos e melhora o desempenho dos jobs BUILD.
Executar uma instrução BUILD em uma tabela inteira
BUILD TABLE <table_name> force = true;
Este método aciona um job BUILD e recria um índice para todas as partições de uma tabela. Por padrão, esse recurso está desabilitado.
Este método recria um índice para todos os dados existentes de uma tabela, o que consome um longo período de tempo. Recomendamos que você execute uma instrução BUILD em partições específicas. Antes de executar uma instrução BUILD em uma tabela inteira, avalie os efeitos e riscos. Ative esse recurso abrindo um ticket.
Configurar o agendamento automático para jobs BUILD
-
Método de configuração
SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD=`<start>,<end>`;Os parâmetros
starteendespecificam um intervalo de tempo no qual você deseja agendar jobs BUILD. É recomendado que você defina os parâmetros no intervalo de 0 a 24 e coloque o intervalo de tempo entre crases (). Você pode configurar vários intervalos de tempo. Separe vários intervalos de tempo com ponto e vírgula (;).Por exemplo, você pode definir o parâmetro
startcomo 0 e o parâmetroendcomo 6 para agendar jobs BUILD entre 0:00 e 6:59.ImportanteOs intervalos de tempo especificados são usados para agendar jobs, e não para executá-los. Portanto, após o agendamento dos jobs, o sistema pode não concluir a execução quando os intervalos de tempo terminarem.
-
Exemplo
Para agendar jobs BUILD, configure os seguintes intervalos de tempo: 00:00 às 06:59 e 18:00 às 22:59.
SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD=`0,6;18,22`;Após a execução da instrução anterior, o sistema agenda jobs BUILD entre 00:00 e 06:59 e entre 18:00 e 22:59.
Configurar prioridades de agendamento para jobs BUILD
A ordem em que os jobs BUILD são agendados baseia-se na quantidade de dados adicionada a shards individuais das tabelas. Quanto maior a quantidade de dados adicionada a um shard de uma tabela, mais cedo o job é agendado e executado. Você também pode usar uma hint ou executar a instrução SET ADB_CONFIG para configurar as prioridades de agendamento de jobs BUILD para as tabelas.
-
Você pode configurar as prioridades de agendamento de jobs BUILD apenas para clusters AnalyticDB for MySQL V3.1.5.0 ou posteriores.
Para visualize e atualize a versão secundária, acesse a seção Configuration Information na página Cluster Information no console do AnalyticDB for MySQL.
Uma hint suporta apenas uma tabela. A prioridade configurada entra em vigor apenas no job BUILD atual.
A instrução
SET ADB_CONFIGsuporta uma ou mais tabelas. As prioridades configuradas permanecem válidas até que você configure novas prioridades de agendamento de jobs BUILD para as tabelas.Se você usar uma hint e a instrução
SET ADB_CONFIGpara configurar prioridades de agendamento diferentes para jobs BUILD de uma mesma tabela, a prioridade baseada na hint terá precedência no job atual.
O parâmetro task_priority especifica a prioridade de agendamento dos jobs BUILD. O valor deve ser um número inteiro. O valor padrão é 0. Um valor maior especifica uma prioridade de agendamento mais alta. Após configurar as prioridades para os jobs BUILD, os nós de frontend agendam os jobs BUILD com base nessas prioridades. Se você definir o parâmetro task_priority com um valor menor que 0 para uma tabela, o agendamento automático de jobs BUILD será desabilitado para essa tabela e os nós de frontend não agendarão jobs BUILD para ela.
Métodos de configuração:
-
Usar uma hint
/*build_task_priority = <task_priority> */ BUILD TABLE <db_name>.<table_name>;Por exemplo, defina a prioridade de agendamento de jobs BUILD como 30 para a tabela
testno banco de dadosadb_demo./*build_task_priority = 30 */ Build TABLE adb_demo.test; -
Usar a instrução SET ADB_CONFIG
-
Configure as prioridades de agendamento de jobs BUILD para várias tabelas em bancos de dados diferentes.
SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.<table1_name>.<task_priority>;<db2_name>.<table2_name>.<task_priority>`;NotaSepare várias tabelas com ponto e vírgula (;).
Por exemplo, defina a prioridade de agendamento de jobs BUILD como 30 para a tabela
test1no banco de dadosadb_demo1e como 10 para a tabelatest2no banco de dadosadb_demo2.SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.test1.30;adb_demo2.test2.10`; -
Configure a mesma prioridade de agendamento de jobs BUILD para todas as tabelas em um banco de dados.
SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.*.<task_priority>`;Por exemplo, defina a prioridade de agendamento de jobs BUILD como 30 para todas as tabelas no banco de dados
adb_demo1.SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.*.30`; -
Configure prioridades de agendamento diferentes para jobs BUILD entre uma tabela e outras tabelas no mesmo banco de dados.
SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.*.<task_priority>;<db1_name>.<table_name>.<task_priority>`;Por exemplo, defina a prioridade de agendamento de jobs BUILD como 30 para a tabela
test1no banco de dadosadb_demo1e como 10 para todas as outras tabelas no banco de dados.SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.*.10;adb_demo1.test1.30`;
-
Você pode executar a instrução SHOW ADB_CONFIG para consultar a prioridade de agendamento atual dos jobs BUILD.
Consultar o status de um job BUILD
Após o acionamento automático ou manual de um job BUILD, você pode executar a seguinte instrução SQL para consultar o status do job BUILD nos últimos três dias:
SELECT table_name, schema_name, status FROM INFORMATION_SCHEMA.KEPLER_META_BUILD_TASK ORDER BY create_time DESC LIMIT 10;
A tabela a seguir descreve o status dos jobs BUILD com base nos valores do parâmetro status.
|
Valor de status |
Descrição |
|
INIT |
O job está sendo inicializado. |
|
RUNNING |
O job está em execução. |
|
FINISH |
O job foi concluído. |
Perguntas frequentes
Por que o agendamento automático de jobs BUILD não entra em vigor?
Causa: Os parâmetros relacionados ao tempo não estão entre crases ( ). Como resultado, ocorre uma falha na análise dos parâmetros.
Solução: Ao executar a instrução SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD para configurar o agendamento automático, coloque os parâmetros start e end entre crases ( ). Por exemplo, SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD= especifica que o sistema agenda jobs BUILD entre 0:00 to 6:59.