PolarDB:Perguntas frequentes

P: O que é o PolarDB for MySQL?

R: O PolarDB for MySQL é um service de banco de dados relacional baseado em cloud. Ele está implantado em data centers em mais de 10 regiões no mundo todo e oferece services de banco de dados online prontos para uso. O PolarDB suporta três engines independentes: compatibilidade total com MySQL, compatibilidade total com PostgreSQL e alta compatibilidade com a sintaxe Oracle. A capacidade de armazenamento pode chegar a 1 PB. Para obter mais detalhes, consulte O que é o PolarDB for MySQL Enterprise Edition?.

P: Por que o PolarDB é superior aos bancos de dados tradicionais?

R: Em comparação com bancos de dados tradicionais, o PolarDB suporta armazenamento massivo de dados na casa das centenas de PBs e fornece recursos como alta disponibilidade, alta confiabilidade, dimensionamento elástico rápido e backup sem bloqueio. Para obter mais detalhes, consulte O que é o PolarDB for MySQL Enterprise Edition?.

P: Quando o PolarDB foi lançado? Quando ele se tornou comercialmente disponível?

R: O product foi disponibilizado para preview público em setembro de 2017 e entrou em disponibilidade comercial em março de 2018.

P: O que são clusters e nós?

R: O PolarDB for MySQL utiliza uma arquitetura de cluster multi-nó. Cada cluster contém um nó primário e vários nós somente leitura. Um único cluster do PolarDB for MySQL pode abranger várias zonas, mas não pode abranger diferentes regiões. O gerenciamento e o faturamento ocorrem no nível do cluster. Para obter mais detalhes, consulte Glossário.

P: Quais linguagens de programação são suportadas?

R: O PolarDB for MySQL suporta linguagens como Java, Python, PHP, Golang, C, C++, .NET e Node.js. Qualquer linguagem de programação compatível com o MySQL nativo pode usar diretamente o PolarDB for MySQL. Para obter mais detalhes, consulte o site oficial do MySQL.

P: Quais engines de armazenamento são suportadas?

P: Posso criar instâncias secundárias autogerenciadas e qual implementação é recomendada?

R: Sim. Após ativar o binlog, você pode sincronizar o PolarDB for MySQL com outros bancos de dados MySQL para formar uma arquitetura primária-secundária. Para facilitar a manutenção, recomendamos o uso do Data Transmission Service (DTS). Para saber como usar o DTS para sincronização, consulte Sincronizar dados de um cluster PolarDB for MySQL para uma instância ApsaraDB RDS for MySQL.

P: O PolarDB for MySQL é um banco de dados distribuído?

R: Sim. O PolarDB for MySQL é um cluster de armazenamento distribuído baseado no protocolo de consenso Parallel Raft. Sua engine de computação consiste em vários nós de computação distribuídos por diferentes servidores. A capacidade de armazenamento pode chegar a 1 PB, com suporte a até 120 núcleos de CPU e 920 GB de memória. É possível dimensionar dinamicamente os recursos de armazenamento e computação online, sem afetar as cargas de trabalho normais.

P: O PolarDB for MySQL suporta particionamento de tabelas?

R: Sim.

P: Posso alterar a região de um cluster do PolarDB for MySQL após a compra?

R: Não é possível alterar a região de um cluster depois de comprá-lo.

P: O PolarDB for MySQL inclui automaticamente um mecanismo de particionamento?

R: O PolarDB for MySQL realiza o particionamento na camada de armazenamento, de forma transparente e imperceptível para os usuários.

P: Ao executar uma instrução SQL no DMS, ocorre o seguinte erro. O que devo fazer? Durante a execução da instrução SQL, aparece uma mensagem de erro na página: Lock wait timeout exceeded; try restarting transaction.

R: Esse erro é causado por um tempo limite de espera de bloqueio. A causa específica é uma transação não confirmada que bloqueia a sessão atual. Recomendamos que você faça logon novamente no console do DMS, crie uma nova sessão de conexão e execute o comando SQL novamente.

P: Como a série de nó único garante a disponibilidade do service e a confiabilidade dos dados?

R: A série de nó único é um product de banco de dados construído sobre um único nó de computação para finalidades específicas. Embora possua apenas um nó, ela ainda consegue garantir alta disponibilidade de service e alta confiabilidade de dados por meio de tecnologias como agendamento de computação em nível de segundo e armazenamento distribuído com múltiplas réplicas.

P: Como compro um cluster de nó único do PolarDB for MySQL?

R: A série de product de nó único foi descontinuada. No entanto, ao adquirir um cluster, você pode definir o número de nós somente leitura como 0 para comprar um cluster de nó único do PolarDB for MySQL.

P: Há compatibilidade com o MySQL Community Edition?

R: O PolarDB for MySQL é 100% compatível com o MySQL Community Edition.

P: Quais níveis de isolamento de transação são suportados?

R: O PolarDB for MySQL suporta três níveis de isolamento: READ_UNCOMMITTED, READ_COMMITTED (padrão) e REPEATABLE_READ. O nível de isolamento SERIALIZABLE não é suportado.

P: O SHOW PROCESSLIST difere do MySQL Community Edition?

R: Se você consultar pelo endpoint primário, não há diferença. Caso consulte pelo endpoint do cluster, existe uma pequena diferença: aparecem vários registros com o mesmo Thread ID, um para cada nó no cluster do PolarDB for MySQL.

P: O mecanismo de bloqueio MDL do PolarDB for MySQL difere do MySQL Community Edition?

R: O mecanismo MDL do PolarDB for MySQL é igual ao do MySQL Community Edition. Contudo, como os nós de banco de dados do PolarDB for MySQL usam uma arquitetura de armazenamento compartilhado, um nó somente leitura pode consultar dados intermediários de uma operação DDL enquanto o nó primário executa essa operação, o que causa inconsistência de dados. Por isso, o PolarDB for MySQL sincroniza os bloqueios MDL exclusivos envolvidos na operação DDL com os nós somente leitura por meio de redo logs, impedindo que outras threads de usuário nos nós somente leitura acessem dados da tabela durante a operação DDL. Em certas situações, isso pode bloquear a operação DDL. Execute o comando show processlist para verificar o status de execução da operação DDL. Se o status de execução for Wait for syncing with replicas, a situação descrita ocorreu. Para soluções, consulte Visualizar o status de execução da instrução DDL e o status do MDL.

P: O formato do binlog difere do formato nativo do MySQL?

R: Não há diferença.

P: Os schemas performance e sys são suportados?

R: Sim.

P: A coleta de estatísticas de tabela difere do MySQL Community Edition?

R: As estatísticas de tabela no nó primário do PolarDB for MySQL são iguais às do MySQL Community Edition. Para manter os planos de execução consistentes entre o nó primário e os nós somente leitura, o nó primário sincroniza as estatísticas com os nós somente leitura sempre que as atualiza. Além disso, um nó somente leitura pode executar a operação ANALYZE TABLE para carregar proativamente as estatísticas mais recentes do disco.

P: O PolarDB for MySQL suporta transações XA e há diferenças em relação ao MySQL oficial?

R: Sim, elas são suportadas e não há diferenças.

P: O PolarDB for MySQL suporta índices de texto completo?

P: O Percona Toolkit é suportado?

R: Sim, mas recomendamos o uso de DDL online.

P: O gh-ost é suportado?

R: Sim, mas recomendamos o uso de DDL online.

P: Comentários em índices são suportados?

R: Sim. O PolarDB for MySQL é 100% compatível com o MySQL; portanto, os kernels atuais do MySQL 5.6, MySQL 5.7 e MySQL 8.0 suportam comentários em índices. Use SHOW CREATE TABLE <table_name>; para visualizar as informações específicas do comentário do índice. Se não conseguir consultar essas informações, verifique se um comentário foi adicionado ao índice ou se operações como sincronização ou migração removeram o comentário.

P: Quais taxas estão incluídas no PolarDB for MySQL?

R: As taxas cobrem nós de computação, espaço de armazenamento, backup (com cota gratuita) e SQL Explorer (opcional). Para obter mais detalhes, consulte Itens faturáveis.

P: O que o espaço de armazenamento faturado inclui?

R: Inclui arquivos de tabelas de banco de dados, arquivos de índice, arquivos de undo log, arquivos de redo log, arquivos de binlog, arquivos de slow log e uma pequena quantidade de arquivos de sistema. Para obter mais detalhes, consulte Espaço de armazenamento P: Como usar o plano de armazenamento do PolarDB for MySQL? R: Clusters com assinatura ou pagamento conforme o uso podem utilizar um plano de armazenamento para compensar as taxas de armazenamento. Por exemplo, se você tiver três clusters, cada um com capacidade de 40 GB (totalizando 120 GB), esses três clusters poderão compartilhar um único plano de armazenamento de 100 GB. Os 20 GB excedentes serão cobrados no modelo de pagamento conforme o uso. Para mais detalhes, consulte Planos de armazenamento. .

P: Se eu adicionar um nó somente leitura, como ele será faturado?

R: Um nó somente leitura tem o mesmo preço do nó primário. Consulte Nós de computação.

P: Se eu adicionar um nó somente leitura, a capacidade de armazenamento dobra?

R: O PolarDB for MySQL usa uma arquitetura que separa computação e armazenamento. O nó somente leitura adquirido é um recurso de computação, portanto a capacidade de armazenamento não aumenta. Os tipos de armazenamento PSL4/PSL5 utilizam uma abordagem serverless. Não é necessário selecionar uma capacidade ao adquirir um cluster. O armazenamento dimensiona automaticamente online conforme seus dados crescem, e você paga apenas pela quantidade real de dados. Cada especificação de cluster possui uma capacidade máxima de armazenamento correspondente. Para aumentar o limite de capacidade de armazenamento, realize uma Alteração manual de especificação.

P: Como libero um cluster do PolarDB for MySQL com assinatura?

R: Um cluster com assinatura não pode ser liberado diretamente. É necessário cancelar a assinatura. Para obter mais detalhes, consulte Regras de cancelamento de assinatura.

P: Como faço para que um cluster de pagamento conforme o uso pare de gerar taxas?

R: Se confirmar que não utiliza mais o cluster, você pode Liberar um cluster. Após a liberação, o cluster deixa de gerar taxas.

P: Ainda posso alterar as especificações de um cluster durante um upgrade temporário?

R: Durante um upgrade temporário (enquanto o cluster estiver em execução), a Alteração manual de especificação é suportada, mas o downgrade manual, a opção de Adicionar ou remover nós, a opção de Adicionar nós temporariamente e o cancelamento da assinatura do cluster não são suportados. Para obter mais detalhes, consulte Auto Scaling.Upgrade temporário.

P: Qual é a largura de banda pública do PolarDB for MySQL? Sou cobrado por ela?

R: O próprio PolarDB for MySQL não possui limite de largura de banda pública. A largura de banda depende principalmente do service SLB utilizado. Conexões públicas ao PolarDB for MySQL são gratuitas.

P: Por que um cluster com assinatura ainda gera taxas todos os dias?

R: Os itens faturáveis do PolarDB for MySQL incluem principalmente nós de computação (nós primários e nós somente leitura), espaço de armazenamento, armazenamento de backup (cobrado apenas quando a cota gratuita é excedida), SQL Explorer (opcional) e arquivamento de dados frios (opcional). Para obter mais detalhes, consulte Itens faturáveis. A assinatura significa que você pré-paga as taxas dos nós de computação ao criar um cluster de banco de dados. No entanto, taxas de espaço de armazenamento (assinatura ou pagamento conforme o uso, dependendo da compra), armazenamento de backup, SQL Explorer e arquivamento de dados frios não estão incluídas. Durante o uso do banco de dados, as taxas de armazenamento são deduzidas da sua conta hourlymente com base no espaço ocupado pelo cluster. Portanto, mesmo sob o método de faturamento por assinatura, contas de pagamento conforme o uso ainda são geradas.

P: Há cobrança extra pela migração com um clique do RDS para o PolarDB for MySQL

?

mysql> kill 33554499;
Query OK, 0 rows affected (0.01 sec)

R: Durante a migração com um clique, há cobrança pelas tarefas de sincronização de dados do DTS, pela instância RDS e pelo próprio cluster PolarDB. Para obter mais detalhes, consulte Faturamento.

P: Por que ainda sou cobrado pelo espaço de armazenamento após excluir dados de tabela do PolarDB for MySQL usando delete?

R: O comando delete apenas marca a tabela como excluída. Ele não libera o tablespace.

P: Como implemento a divisão de leitura/gravação para o PolarDB for MySQL?

R: Utilize o endpoint do cluster na sua aplicação. A divisão de leitura/gravação é então implementada com base no modo de leitura/gravação configurado. Para obter mais detalhes, consulte Configurar o proxy de banco de dados.

P: Qual é o número máximo de nós somente leitura suportado por um cluster do PolarDB for MySQL?

R: O PolarDB for MySQL utiliza uma arquitetura de cluster distribuído. Clusters Enterprise Edition suportam até 15 nós somente leitura, e clusters Standard Edition suportam até 7 nós somente leitura. Recomendamos pelo menos um nó somente leitura para garantir alta disponibilidade.

P: Por que a carga está desequilibrada entre vários nós somente leitura?

R: A carga pode ficar desequilibrada entre os nós somente leitura por vários motivos, como um nó somente leitura tendo poucas conexões ou um nó somente leitura não ter sido incluído quando o endpoint personalizado do cluster foi configurado.

P: O que causa uma carga alta ou baixa no nó primário?

R: As causas de uma carga alta no nó primário incluem conexões diretas ao endpoint primário, o banco de dados primário aceitando solicitações de leitura, um grande número de solicitações de transação, alta latência de replicação fazendo com que solicitações sejam roteadas para o banco de dados primário e nós somente leitura anormais causando o roteamento de solicitações de leitura para o banco de dados primário.

Por outro lado, uma carga baixa no nó primário pode resultar da ativação da opção que impede o banco de dados primário de aceitar solicitações de leitura.

P: Como reduzo a carga no nó primário?

P: Por que não consigo ler os dados que foram recém-inseridos?

P: Como forço a execução de uma instrução SQL no nó primário?

P: Posso atribuir endpoints diferentes para cargas de trabalho diferentes? É possível alcançar isolamento entre endpoints distintos?

R: Você pode criar vários endpoints personalizados para diferentes cargas de trabalho. Se os nós subjacentes forem diferentes, os endpoints personalizados ficam isolados entre si e não se afetam mutuamente. Para saber como criar um endpoint personalizado, consulte Gerenciar endpoints.

P: Se houver vários nós somente leitura, como crio um endpoint de nó único para um nó somente leitura específico?

P: Uso apenas o endpoint primário, mas notei que os nós somente leitura também têm carga. O endpoint primário suporta divisão de leitura/gravação?

R: O endpoint primário não suporta divisão de leitura/gravação e conecta-se sempre apenas ao nó primário. Uma pequena quantidade de QPS nos nós somente leitura é normal e não tem relação com o endpoint primário.

P: Como adicionar colunas e índices online?

R: Utilize o recurso de DDL online integrado ou ferramentas como pt-osc e gh-ost. Recomendamos o uso do recurso de DDL online nativo.

P: O recurso de inserção em massa é suportado?

R: Sim.

P: Se os dados forem gravados apenas no nó somente de gravação, a inserção em massa é suportada? Qual é o número máximo de valores que podem ser inseridos por vez?

R: Sim. O número máximo de valores suportados por vez depende do valor do parâmetro max_allowed_packet. Para mais detalhes, consulte Replication and max_allowed_packet.

P: É possível realizar operações de inserção em massa usando o endpoint do cluster?

R: Sim.

P: Existe latência de replicação entre o nó primário (primary) e os nós somente de leitura (secondary)?

R: Sim. Há uma latência na ordem de milissegundos entre eles.

P: Em quais situações a latência de replicação aumenta?

P: Como garantir a consistência das consultas quando há latência de replicação?

R: Use o endpoint do cluster e selecione um nível de consistência apropriado. Atualmente, os níveis de consistência, do maior para o menor, são: consistência global (consistência forte), consistência de sessão e consistência eventual. Para mais detalhes, consulte Consistency levels.

P: Um RPO de 0 pode ser garantido se um único nó falhar?

R: Sim.

P: Como o backend implementa uma atualização de especificação (por exemplo, de 2 núcleos e 8 GB para 4 núcleos e 16 GB)? Qual é o impacto da atualização nas minhas cargas de trabalho?

R: Alterações de especificação em um cluster PolarDB for MySQL acionam reinicializações de nó, causando interrupções transitórias de conexão e breves flutuações de desempenho. O impacto depende da capacidade de hot standby switchover do cluster e do status do binlog. Para mais detalhes, consulte Impact assessment.

P: Quanto tempo leva para adicionar um nó? Isso afetará minhas cargas de trabalho?

P: Quanto tempo leva uma atualização para a versão secundária mais recente? Isso afeta as cargas de trabalho?

R: O PolarDB for MySQL usa atualizações contínuas em vários nós para minimizar o impacto nas cargas de trabalho. Uma atualização de versão geralmente não leva mais de 30 minutos. O proxy de banco de dados ou o mecanismo de banco de dados é reiniciado durante a atualização, o que pode causar interrupções transitórias na conexão. Execute a atualização fora dos horários de pico e certifique-se de que sua aplicação possua um mecanismo de reconexão automática. Para mais detalhes, consulte Minor version management.

P: Como funciona o failover automático?

R: O PolarDB for MySQL utiliza uma arquitetura de cluster de alta disponibilidade ativo-ativo. O failover ocorre automaticamente entre o nó primário de leitura/gravação e os nós somente de leitura, e o sistema elege um novo nó primário. PolarDB Cada nó possui uma prioridade de failover que determina a probabilidade de ser eleito como primário durante um failover. Quando múltiplos nós têm a mesma prioridade, eles possuem igual probabilidade de eleição. Para mais detalhes, consulte Automatic failover and manual failover.

P: Quais permissões são necessárias para encerrar uma conexão no PolarDB for MySQL?

R: No MySQL, encerrar uma conexão (usando o comando KILL) requer permissões adequadas. Especificamente, encerrar a conexão de outro usuário comum exige a permissão PROCESS.

P: O erro de log de execução [ERROR] InnoDB: fil_space_extend space_name:xxx afeta as cargas de trabalho existentes?

R: Não. Suas cargas de trabalho existentes não são afetadas. Este log indica que, após a extensão do tamanho de um arquivo no nó de leitura/gravação do cluster PolarDB, os nós somente de leitura sincronizam as informações de tamanho do arquivo na memória. Clusters MySQL 5.7 não alteram o nível ERROR do log, portanto, nos nós somente de leitura, ele pode ser tratado como nível INFO. Isso não afeta suas cargas de trabalho.

P: Qual é a arquitetura do proxy de banco de dados? Ele possui um mecanismo de failover? Como sua alta disponibilidade é garantida?

R: O proxy de banco de dados usa uma arquitetura de alta disponibilidade com dois nós e distribui o tráfego uniformemente entre eles na proporção de 1:1. O sistema verifica continuamente a integridade dos nós de proxy. Se um nó falhar, o sistema desconecta proativamente as conexões nesse nó. O nó saudável restante assume automaticamente todo o tráfego para que o serviço não seja interrompido. O sistema também reconstrói e restaura automaticamente o nó de proxy com falha. Todo o processo geralmente leva cerca de 2 minutos, e o cluster de banco de dados permanece acessível durante esse período.

Em casos raros, as conexões em um nó com falha não são desconectadas a tempo, mas o nó já não consegue responder às solicitações. Para lidar com isso, configure políticas de timeout apropriadas no cliente, como os parâmetros JDBC socketTimeout e connectTimeout, permitindo que a camada de aplicação detecte e encerre prontamente conexões suspensas. Isso melhora ainda mais a tolerância a falhas e a eficiência de resposta do sistema.

P: Como visualizar os logs de erro de um cluster PolarDB for MySQL?

R: Acesse o PolarDB console. No painel de navegação à esquerda da página de detalhes do cluster alvo, escolha Diagnostics and Optimization > Log Management. Na aba Running Logs, visualize os logs de erro correspondentes.

P: O PolarDB for MySQL cria automaticamente uma chave primária implícita para uma tabela sem chave primária?

R: Por padrão, o PolarDB for MySQL cria uma chave primária implícita para tabelas sem chaves primárias.

Faça login no cluster e execute SET show_ipk_info = 1. Em seguida, visualize-a executando SHOW CREATE TABLE.

mysql> kill 33554499;
Query OK, 0 rows affected (0.01 sec)

Visualize o esquema da tabela, onde a coluna __#alibaba_rds_row_id#__ é a chave primária implícita.

mysql> kill 33554499;
Query OK, 0 rows affected (0.01 sec)

P: Por que minha aplicação recebe o erro Lock wait timeout exceeded e a solução de problemas encontra uma transação cujo trx_mysql_thread_id é 0?

mysql> kill 33554499;
Query OK, 0 rows affected (0.01 sec)

Por que diferentes clusters PolarDB for MySQL 8.0 lidam com erros de forma inconsistente ao comparar tipos inválidos de data e hora?

• Descrição do problema: Os clusters PolarDB for MySQL 8.0 estão disponíveis em duas revisões: MySQL 8.0.1 e MySQL 8.0.2. As duas revisões são totalmente compatíveis com MySQL 8.0.13 e MySQL 8.0.18, respectivamente. No entanto, elas se comportam de maneira inconsistente ao lidar com tipos inválidos de data e hora.

  Especificamente, quando uma constante de string é comparada com um tipo de tempo, a string é convertida para esse tipo de tempo. Se a string for uma data inválida, a conversão falha. As duas revisões também se comportam de maneira diferente quando a conversão falha. A revisão 8.0.13 retorna apenas WARNING, enquanto a revisão 8.0.18 retorna diretamente o código de erro ER_WRONG_VALUE. Como resultado, quando campos inválidos de data e hora são comparados, as duas revisões dos clusters PolarDB for MySQL relatam erros de forma inconsistente.

• Solução: Para manter os resultados da mesma instrução SQL consistentes (todos com sucesso ou todos com falha), múltiplos clusters PolarDB for MySQL devem usar a mesma versão principal do kernel. Ou seja, todos devem ser MySQL 8.0.1 ou MySQL 8.0.2.

P: Qual método de backup o PolarDB for MySQL utiliza?

R: O PolarDB for MySQL usa snapshots para backup. Para mais detalhes, consulte ESSD cloud disk.

P: Qual é a velocidade da restauração do banco de dados?

R: Seja para restaurar até um ponto no tempo ou a partir de um conjunto de backup (snapshot), o processo principal é o mesmo: primeiro, um nó temporário é criado e os dados de um ponto específico no tempo são restaurados para esse nó; em seguida, os dados restaurados são recuperados para o cluster original. Para estimativas detalhadas de tempo, consulte Overall process and estimated time.

P: Por que a melhoria de desempenho do PolarDB for MySQL em relação ao RDS MySQL não é óbvia?

Para os resultados da comparação de desempenho com o RDS MySQL, consulte PolarDB for MySQLPerformance comparison: PolarDB for MySQL vs. ApsaraDB RDS for MySQL.

P: Qual é o número máximo de tabelas? Com qual quantidade de tabelas o desempenho pode começar a degradar?

R: O número máximo de tabelas é limitado pelo número de arquivos. Para mais detalhes, consulte Limits.

P: O particionamento de tabelas pode melhorar o desempenho de consulta do PolarDB for MySQL?

R: Em geral, se uma instrução SQL de consulta puder ser limitada a uma única partição, o desempenho melhora.

P: O PolarDB for MySQL suporta a criação de 10.000 bancos de dados? Qual é o número máximo de bancos de dados?

R: O PolarDB for MySQL suporta a criação de 10.000 bancos de dados. O número máximo de bancos de dados é limitado pelo número de arquivos. Para mais detalhes, consulte Limits.

P: O número de nós somente de leitura está relacionado ao número máximo de conexões? Posso aumentar o número máximo de conexões adicionando nós somente de leitura?

R: O número de nós somente de leitura não está relacionado ao número máximo de conexões. O número máximo de conexões para o PolarDB for MySQL é determinado pelas especificações do nó. Para mais detalhes, consulte Limits. Se precisar de mais conexões, upgrade specifications.

P: Como o IOPS é limitado e isolado? Pode ocorrer contenção de I/O entre múltiplos nós de cluster PolarDB for MySQL?

R: Cada nó de um cluster PolarDB for MySQL tem seu IOPS configurado com base em suas especificações. O IOPS é isolado independentemente entre os nós, de modo que eles não se afetam mutuamente.

P: Um desempenho mais lento em um nó somente de leitura afeta o nó primário?

R: Quando a carga em um nó somente de leitura está muito alta ou a latência de replicação aumenta, o consumo de memória no nó primário pode aumentar ligeiramente.

P: Qual é o impacto no desempenho após a ativação do binlog?

R: A ativação do binlog não afeta o desempenho de consultas (SELECT). Ela afeta apenas o desempenho de operações de gravação e atualização (INSERT, UPDATE e DELETE). Em geral, para um banco de dados com carga de trabalho equilibrada de leitura/gravação, a ativação do binlog afeta o desempenho em no máximo 10%.

P: Qual é o impacto no desempenho quando o SQL Explorer (auditoria completa de logs SQL) está ativado?

R: Nenhum impacto.

P: Qual protocolo de rede de alta velocidade o PolarDB for MySQL utiliza?

R: RDMA duplo de 25 Gbps é usado entre os nós de computação de banco de dados e os nós de armazenamento do PolarDB for MySQL, e entre as múltiplas réplicas de dados armazenados. Isso proporciona desempenho de I/O de baixa latência e alto throughput.

P: Qual é a largura de banda máxima da conexão com a Internet para o PolarDB for MySQL?

R: A largura de banda máxima da conexão com a Internet para o PolarDB for MySQL é de 10 Gbit/s.

P: Comparado a um banco de dados tradicional que usa discos locais, quais são as vantagens de armazenar tabelas grandes no PolarDB for MySQL?

R: Uma tabela no PolarDB for MySQL é dividida fisicamente em N servidores de armazenamento. O I/O de uma única tabela é, portanto, distribuído por vários discos de armazenamento. O throughput geral de leitura de I/O (não a latência de I/O) é muito superior ao de um banco de dados centralizado em discos locais.

P: Como otimizar uma tabela grande?

R: Use tabelas particionadas.

P: Em quais situações as tabelas particionadas são adequadas?

R: Tabelas particionadas são adequadas quando você precisa podar uma tabela grande para controlar a quantidade de dados acessados por uma consulta e deseja que a poda seja transparente para o código da sua aplicação (nenhuma alteração no código da aplicação é necessária). Por exemplo, use uma tabela particionada para limpar dados históricos de negócios em uma programação regular, como descartar a partição mensal mais antiga e criar a partição para o próximo mês, mantendo apenas os dados dos últimos seis meses.

P: Dentro do mesmo banco de dados PolarDB for MySQL, qual é a melhor maneira de copiar uma tabela que contém uma grande quantidade de dados (por exemplo, copiar toda a tabela A para a tabela B)?

mysql> kill 33554499;
Query OK, 0 rows affected (0.01 sec)

P: Conexões PHP de curta duração podem ser otimizadas sob alta concorrência?

R: Sim. Ative um pool de conexões no nível de sessão no endpoint do cluster para otimizar essas conexões. Para mais detalhes, consulte Configure the database proxy.

P: Como evitar que algumas instruções SQL ineficientes derrubem todo o banco de dados?

R: Utilize o recurso de controle de concorrência de instruções Concurrency control para limitar instruções específicas.

P: O PolarDB for MySQL suporta timeout de sessão ociosa?

R: Sim. Modifique o parâmetro wait_timeout para personalizar o período de timeout de sessões ociosas. Para obter instruções, consulte Set cluster parameters and node parameters.

P: Como encontrar instruções SQL lentas?

P: Como encerrar uma instrução SQL lenta?

mysql> kill 33554499;
Query OK, 0 rows affected (0.01 sec)

Por que o banco de dados reiniciou o cluster? Vejo uma tarefa de reinicialização de cluster no centro de tarefas.

Acesse a página Performance Monitoring do cluster alvo e verifique a aba Cluster para ver se o CPU Usage ou Memory Usage dos nós do seu cluster atingiu 100%, o que acionou um failover primário/secundário e reiniciou o cluster.

P: Como o PolarDB for MySQL arquiva dados quentes e mornos para armazenamento frio?

R: O PolarDB for MySQL suporta o arquivamento dos dados quentes do mecanismo InnoDB no PolarStore, dos dados mornos do X-Engine e dos dados frios no OSS (nos formatos CSV, ORC, IBD e outros) para mídias de armazenamento frio do OSS usando uma política DDL especificada. Após o arquivamento dos dados, o espaço de armazenamento no PolarStore é liberado e o custo geral de armazenamento do banco de dados é reduzido. Para mais informações, consulte Cold data archiving.

P: O PolarDB for MySQL suporta armazenamento separado automático de dados quentes, mornos e frios? Como isso é implementado?

R: O PolarDB for MySQL suporta a separação e o arquivamento automáticos de dados quentes, mornos e frios. Ao especificar uma política DLM, arquive automaticamente os dados no PolarStore para mídias de armazenamento OSS de baixo custo, o que reduz os custos de armazenamento do banco de dados. Para mais informações, consulte Cold data archiving.