PolarDB:FAQ

O que é o PolarDB?

O PolarDB é um serviço de banco de dados relacional baseado em nuvem, implantado em data centers distribuídos por mais de 10 regiões ao redor do mundo. Ele oferece serviços de banco de dados online prontos para uso. O PolarDB é totalmente compatível com o PostgreSQL. Por padrão, um cluster do PolarDB fornece capacidade de armazenamento de até 500 TB.

Por que o PolarDB supera os bancos de dados tradicionais?

Em comparação aos bancos de dados tradicionais, o PolarDB armazena centenas de terabytes de dados e disponibiliza uma ampla variedade de recursos, como alta disponibilidade, alta confiabilidade, upgrades e downgrades elásticos rápidos e backups sem bloqueio. Para obter mais informações, consulte Benefícios.

Quando o PolarDB foi lançado? Quando ficou disponível para uso comercial?

O PolarDB foi lançado para preview público em setembro de 2017 e tornou-se disponível para uso comercial em março de 2018.

O que são clusters e nós?

A PolarDB Cluster Edition utiliza uma arquitetura de cluster multi-nó. Um cluster possui um nó primário e vários nós somente leitura. Um único cluster do PolarDB pode ser implantado em várias zonas, mas não em várias regiões. O serviço PolarDB é gerenciado e cobrado com base em clusters. Para obter mais informações, consulte o Glossário.

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

O PolarDB suporta linguagens de programação como Java, Python, PHP, Golang, C, C++, .NET e Node.js.

Quais mecanismos de armazenamento são suportados?

Instâncias secundárias autogerenciadas são suportadas? Como implementar uma arquitetura primária/secundária?

Sim, instâncias secundárias autogerenciadas são suportadas. Para implementar uma arquitetura primária/secundária, ative o recurso de binary log para sincronizar dados de um cluster do com uma instância MySQL autogerenciada. Para facilitar a manutenção posterior, recomendamos o uso do Data Transmission Service (DTS) para sincronizar os dados. Para obter mais informações, consulte Sincronizar dados do PolarDB for MySQL para o RDS for MySQL.

O PolarDB é um banco de dados distribuído?

Sim, o PolarDB é um cluster de armazenamento distribuído baseado no protocolo Parallel Raft. O mecanismo de computação consiste em 1 a 16 nós de computação distribuídos em servidores diferentes. Um cluster suporta capacidade máxima de armazenamento de 200 TB, além de até 88 núcleos e 710 GB de memória. É possível dimensionar horizontalmente os recursos de armazenamento e computação dinamicamente e online. Os serviços continuam funcionando normalmente durante o dimensionamento.

Preciso adquirir o middleware de banco de dados PolarDB-X para implementar sharding após comprar o PolarDB?

Sim, é necessário adquirir o middleware de banco de dados PolarDB-X para implementar sharding após a compra do PolarDB.

O PolarDB suporta particionamento de tabelas?

Sim, o PolarDB suporta particionamento de tabelas.

O PolarDB inclui automaticamente um mecanismo de particionamento?

O PolarDB implementa o particionamento na camada de armazenamento. Esse processo é transparente e imperceptível para os usuários.

Qual é o tamanho máximo de dados que uma única tabela pode armazenar no PolarDB em comparação ao MySQL nativo?

O PolarDB não limita o tamanho de tabelas individuais. No entanto, o tamanho das tabelas é limitado pelo espaço do disco onde estão armazenadas. Para obter mais informações, consulte os Limites.

O PolarDB for MySQL é compatível com o MySQL Community Edition?

Sim, o é totalmente compatível com o MySQL Community Edition.

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

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

Os resultados da consulta da instrução SHOW PROCESSLIST no PolarDB for MySQL são iguais aos do MySQL Community Edition?

Se você usar um endpoint primário para executar a instrução SHOW PROCESSLIST, os resultados da consulta serão idênticos. Se utilizar um endpoint de cluster para executar a instrução SHOW PROCESSLIST, os resultados diferem entre o PolarDB for MySQL e o MySQL Community Edition. Nos resultados da consulta dessa instrução no PolarDB for MySQL, é possível encontrar vários registros com o mesmo ID de thread. Cada um desses registros corresponde a um nó no cluster do .

O mecanismo de bloqueio do PolarDB for MySQL é diferente do MySQL Community Edition?

Sim, o mecanismo de bloqueio do PolarDB for MySQL difere do MySQL Community Edition. O usa redo logs para sincronizar os bloqueios exclusivos de metadados (MDLs) envolvidos em operações de linguagem de definição de dados (DDL) com os nós somente leitura. Os nós somente leitura mantêm os bloqueios até que as operações DDL sejam concluídas. Isso impede que outros threads de usuário nos nós somente leitura acessem os dados armazenados nas tabelas enquanto as operações DDL estão em andamento. O PolarDB for MySQL difere do MySQL Community Edition em termos de armazenamento de dados. No , os nós primários e os nós somente leitura compartilham os dados armazenados. Como resultado, quando os nós primários executam operações DDL, os nós somente leitura podem recuperar os dados intermediários gerados por essas operações, causando um erro.

O formato do binary log do PolarDB for MySQL é igual ao formato nativo do binary log do MySQL?

Sim, o formato do binary log do PolarDB for MySQL é idêntico ao formato nativo do binary log do MySQL.

O performance schema e o sys schema são suportados?

Sim, tanto o performance schema quanto o sys schema são suportados.

As estatísticas de tabela no PolarDB for MySQL são consistentes com as do MySQL Community Edition?

Sim, as estatísticas de tabela no nó primário de um cluster do são consistentes com as do MySQL Community Edition. Cada atualização das estatísticas de tabela no nó primário é sincronizada com os nós somente leitura para garantir que os planos de execução permaneçam consistentes entre o nó primário e os nós somente leitura. Também é possível executar a operação ANALYZE TABLE nos nós somente leitura para carregar proativamente as estatísticas mais recentes dos discos.

O PolarDB suporta transações de arquitetura estendida (XA)? O PolarDB for MySQL suporta transações XA da mesma forma que o sistema MySQL nativo?

Sim, o PolarDB for MySQL suporta transações XA da mesma maneira que o sistema MySQL nativo.

O PolarDB suporta índices de texto completo?

O Percona Toolkit é suportado?

Sim, o Percona Toolkit é suportado. No entanto, recomendamos o uso de DDL online.

O gh-ost é suportado?

Sim, o gh-ost é suportado. Contudo, recomendamos o uso de DDL online.

Quais são os itens faturáveis de um cluster do PolarDB?

Os itens faturáveis incluem espaço de armazenamento, nós de computação, recurso de backup de dados (com cota gratuita) e o recurso SQL Explorer (opcional). Para obter mais informações, consulte Especificações e preços.

Quais arquivos são armazenados no espaço de armazenamento sujeito a cobrança?

O espaço de armazenamento sujeito a cobrança armazena arquivos de tabelas de banco de dados, arquivos de índice, arquivos de undo log, arquivos de redo log, arquivos de slowlog e alguns arquivos de sistema. Para obter mais informações, consulte a Especificações e preços.

Como utilizar os planos de armazenamento do PolarDB?

É possível adquirir planos de armazenamento para deduzir as taxas de armazenamento de clusters que utilizam o método de faturamento por assinatura ou pagamento conforme o uso. Por exemplo, se você tiver três clusters e cada um possuir capacidade de armazenamento de 40 GB, a capacidade total será de 120 GB. Os três clusters podem compartilhar um plano de armazenamento de 100 GB. A cobrança pelos 20 GB excedentes de espaço de armazenamento ocorre com base no pagamento conforme o uso. Para obter mais informações, consulte Adquirir um plano de armazenamento.

Como implementar a divisão de leitura/gravação no PolarDB?

Basta utilizar um endpoint de cluster na sua aplicação para que a divisão de leitura/gravação seja implementada com base no modo de leitura/gravação especificado. Para obter mais informações, consulte Configurar o PolarProxy.

Quantos nós somente leitura são suportados em um cluster do PolarDB?

O PolarDB utiliza uma arquitetura de cluster distribuído. Um cluster consiste em um nó primário e até 15 nós somente leitura. Pelo menos um nó somente leitura é necessário para garantir alta disponibilidade.

Por que as cargas estão desequilibradas entre os nós somente leitura?

Uma possível razão é a existência de poucas conexões com os nós somente leitura. Outro motivo possível é que um dos nós somente leitura não foi especificado como tal durante a criação de um endpoint de cluster personalizado.

Quais são as causas de cargas pesadas ou leves no nó primário?

Cargas pesadas no nó primário podem ocorrer devido aos seguintes motivos: 1. O endpoint primário é usado para conectar suas aplicações ao cluster. 2. O nó primário aceita solicitações de leitura. 3. Existe um grande número de solicitações de transação. 4. As solicitações são roteadas para o nó primário devido a um alto atraso de replicação primário/secundário. 5. Solicitações de leitura são roteadas para o nó primário devido a exceções nos nós somente leitura.

Uma possível causa para cargas leves no nó primário é a ativação do recurso Offload Reads from Primary Node.

Como reduzir as cargas no nó primário?

Por que não consigo recuperar imediatamente os dados recém-inseridos?

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

Posso atribuir endpoints diferentes para serviços diferentes? Posso usar endpoints distintos para isolar meus serviços?

Sim, é possível criar vários endpoints personalizados e atribuí-los a serviços diferentes. Se os nós subjacentes forem diferentes, os endpoints de cluster personalizados poderão isolar os serviços sem que um afete o outro. Para obter mais informações sobre como criar um endpoint personalizado, consulte Configurar o PolarProxy.

Como criar separadamente um endpoint de nó único para um dos nós somente leitura quando existem vários nós?

Qual é o número máximo de endpoints de nó único que posso criar em um cluster?

Se o seu cluster tiver três nós, será possível criar um endpoint de nó único para apenas um dos nós somente leitura. Se o cluster tiver quatro nós, você poderá criar endpoints de nó único para dois dos nós somente leitura, um para cada. Regras semelhantes se aplicam se o cluster tiver cinco ou mais nós.

Os nós somente leitura apresentam carga mesmo quando uso apenas o endpoint primário. O endpoint primário suporta divisão de leitura/gravação?

Não, o endpoint primário não suporta divisão de leitura/gravação. Ele se conecta sempre e exclusivamente ao nó primário. Os nós somente leitura podem apresentar um pequeno número de consultas por segundo (QPS). Isso é normal e não tem relação com o endpoint primário.

Como adicionar campos e índices online?

Ferramentas como o DDL online nativo do MySQL, pt-osc e gh-ost permitem adicionar campos e índices online. Recomendamos o uso do DDL online nativo do MySQL.

O recurso de bulk insert é suportado?

Sim, o recurso de bulk insert é suportado.

Posso fazer bulk insert de dados se escrever apenas em um nó exclusivo de gravação? Qual é o número máximo de valores que posso inserir de uma vez?

Sim, é possível realizar bulk insert de dados escrevendo apenas em um nó exclusivo de gravação. O número máximo de valores que podem ser inseridos de uma vez é determinado pelo valor do parâmetro max_allowed_packet. Para obter mais informações, consulte Replicação e max_allowed_packet.

Posso usar endpoints de cluster para realizar a operação de bulk insert?

Sim, endpoints de cluster podem ser usados para realizar operações de bulk insert.

Ocorre atraso de replicação ao replicar dados do nó primário para os nós somente leitura?

Sim, ocorre um atraso de replicação de alguns milissegundos.

Quando o atraso de replicação aumenta?

Como garantir a consistência dos resultados de consulta se ocorrer atraso de replicação?

Utilize um endpoint de cluster e selecione um nível de consistência apropriado para ele. Os níveis de consistência, listados em ordem decrescente, são: consistência de sessão e consistência eventual. Para obter mais informações, consulte Configurar o PolarProxy.

O objetivo de ponto de recuperação (RPO) pode ser zero se um único nó falhar?

Sim, o RPO pode ser zero caso um único nó falhe.

Se você mantiver os valores padrão dos parâmetros do cluster PolarDB, o RPO não será zero. Modifique o valor do parâmetro sychronous_commit para definir o RPO como zero. Para obter mais informações sobre os valores padrão de parâmetros específicos, consulte Valores padrão de parâmetros do cluster.

Como as especificações dos nós são atualizadas no backend, por exemplo, de 2 núcleos e 8 GB de memória para 4 núcleos e 16 GB de memória? Quais são os impactos dessa atualização nos meus serviços?

Os nós de proxy e de banco de dados do PolarDB devem ser atualizados para as configurações mais recentes. Um método de atualização contínua (rolling upgrade) é utilizado para atualizar vários nós e minimizar os impactos nos seus serviços. Cada atualização leva cerca de 10 a 15 minutos. Os impactos nos serviços duram no máximo 30 segundos. Durante esse período, podem ocorrer de um a três erros transitórios de conexão. Para obter mais informações, consulte Alterar configuração.

Quanto tempo leva para adicionar um nó? Meus serviços são afetados durante a adição do nó?

Quanto tempo leva para atualizar uma versão secundária do kernel para a versão de revisão mais recente? Meus serviços são afetados após a conclusão da atualização?

O PolarDB utiliza um método de atualização contínua para atualizar vários nós, minimizando os impactos nos seus serviços. Na maioria dos casos, uma atualização leva menos de 30 minutos para ser concluída. O PolarProxy ou o mecanismo de banco de dados é reiniciado durante a atualização, o que pode interromper os serviços. Recomendamos realizar a atualização fora dos horários de pico. Certifique-se de que sua aplicação possa se reconectar automaticamente ao banco de dados. Para obter mais informações, consulte Atualizar a versão secundária de um cluster PolarDB.

Como um failover automático é implementado?

O PolarDB utiliza uma arquitetura de cluster de alta disponibilidade ativo-ativo. Essa arquitetura suporta failovers automáticos entre o nó primário (que suporta leituras e gravações) e os nós somente leitura. O sistema elege automaticamente um novo nó primário. Cada nó em um cluster do PolarDB possui uma prioridade de failover. Essa prioridade determina a probabilidade de um nó ser eleito como primário durante um failover. Se vários nós tiverem a mesma prioridade de failover, todos terão a mesma probabilidade de serem eleitos como primários. Para obter mais informações, consulte Failover automático e switchover manual.

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 utiliza uma arquitetura de alta disponibilidade com dois nós, distribuindo o tráfego uniformemente entre eles. O sistema verifica continuamente o status de integridade dos nós de proxy. Se uma falha for detectada, o sistema desconecta proativamente as conexões desse nó, e o nó saudável restante assume automaticamente todo o tráfego para garantir a continuidade do serviço. Simultaneamente, o sistema reconstrói e restaura automaticamente o nó de proxy com falha. Esse processo geralmente é concluído em cerca de 2 minutos. Durante esse período, o cluster de banco de dados permanece acessível.

Em casos raros, as conexões com um nó com falha podem não ser desconectadas rapidamente e ficarem sem resposta. Para lidar com essas situações, configure políticas de timeout adequadas no lado do cliente, como socketTimeout e connectTimeout do JDBC. Isso permite que a camada de aplicação detecte e encerre prontamente conexões suspensas, melhorando ainda mais a tolerância a falhas e a eficiência de resposta do sistema.

Como o PolarDB faz backup dos dados?

O PolarDB utiliza snapshots para fazer backup dos dados. Para obter mais informações, consulte Método 2: Backup manual.

Qual é a velocidade de restauração de um banco de dados?

Leva 40 minutos para restaurar ou clonar 1 TB de dados em um banco de dados com base em conjuntos de backup ou snapshots. Para restaurar dados até um ponto específico no tempo, é necessário incluir o tempo necessário para reproduzir os redo logs. A reprodução de 1 GB de dados de redo log leva cerca de 20 a 70 segundos. O tempo total de restauração é a soma do tempo necessário para restaurar os dados com base nos conjuntos de backup e o tempo necessário para reproduzir os redo logs.

Por que o não apresenta melhorias significativas de desempenho quando comparado ao ApsaraDB RDS for MySQL?

Para obter mais informações sobre os resultados da comparação de desempenho entre o e o ApsaraDB RDS for MySQL, consulte Comparação de desempenho: PolarDB for MySQL vs. ApsaraDB RDS for MySQL.

Por que um banco de dados excluído ocupa muito espaço de armazenamento?

Isso ocorre porque os arquivos de redo log do banco de dados excluído ocupam espaço de armazenamento. Na maioria dos casos, os arquivos de redo log ocupam de 2 GB a 11 GB de espaço. Se um total de 11 GB estiver ocupado, 8 GB correspondem aos oito arquivos de redo log no buffer pool. Os 3 GB restantes são divididos igualmente entre o arquivo de redo log que está sendo gravado, o arquivo de redo log pré-criado e o arquivo de redo log mais recente.

O parâmetro loose_innodb_polar_log_file_max_reuse especifica o número de arquivos de redo log no buffer pool. O valor padrão desse parâmetro é 8. Altere esse valor para reduzir o espaço de armazenamento ocupado pelos arquivos de log. Nesse caso, podem ocorrer flutuações periódicas de desempenho durante o processamento de cargas pesadas.

Qual é o número máximo de tabelas? Qual é o limite superior para o número de tabelas se eu quiser garantir que o desempenho não seja comprometido?

O número máximo de tabelas depende do número de arquivos. Para obter mais informações, consulte os Limites.

O particionamento de tabelas pode melhorar o desempenho de consulta do PolarDB?

Na maioria dos casos, se a instrução de consulta SQL incidir sobre uma partição específica, o desempenho será melhorado.

Posso criar 10.000 bancos de dados no PolarDB? Qual é o limite superior para o número de bancos de dados?

Sim, é possível criar 10.000 bancos de dados no PolarDB. O número máximo de bancos de dados que podem ser criados depende do número de arquivos. Para obter mais informações, consulte os Limites.

O número máximo de conexões depende do número de nós somente leitura? Posso aumentar o número máximo de conexões adicionando nós somente leitura?

O número de nós somente leitura não tem relação com o número máximo de conexões. O limite máximo de conexões do PolarDB é determinado pelas especificações do nó. Para obter mais informações, consulte os . Atualize as especificações se precisar de mais conexões. Para obter mais informações, consulte Alteração manual de especificação.

Como as operações de entrada/saída por segundo (IOPS) são limitadas e isoladas? Os múltiplos nós de um cluster do PolarDB competem por recursos de I/O?

O IOPS é definido para cada nó de um cluster do PolarDB com base nas especificações do nó. O IOPS de cada nó é isolado dos demais e não há interferência mútua.

O nó primário é afetado se o desempenho dos nós somente leitura for comprometido?

Sim, o consumo de memória do nó primário aumenta ligeiramente se as cargas nos nós somente leitura forem excessivamente pesadas e o atraso de replicação aumentar.

Qual é o impacto no desempenho do banco de dados se eu ativar o recurso de binary log?

Após ativar o recurso de binary log, apenas o desempenho de gravação e atualização (INSERT, UPDATE e DELETE) é afetado. O desempenho de consulta (SELECT) não sofre alterações. Na maioria dos casos, se você ativar o binary log em um banco de dados com equilíbrio entre solicitações de leitura e gravação, o desempenho do banco de dados diminuirá em no máximo 10%.

Qual é o impacto no desempenho do banco de dados se eu ativar o recurso SQL Explorer (auditoria completa de logs SQL)?

O desempenho do banco de dados não é afetado ao ativar o recurso SQL Explorer.

Qual protocolo de rede de alta velocidade o PolarDB utiliza?

O PolarDB utiliza Remote Direct Memory Access (RDMA) de porta dupla para garantir alto throughput de I/O entre nós de computação e nós de armazenamento, bem como entre réplicas de dados. Cada porta fornece uma taxa de dados de até 25 Gbit/s com baixa latência.

Qual é a largura de banda máxima que posso usar ao acessar o PolarDB pela Internet?

Ao acessar o PolarDB pela Internet, a largura de banda máxima é de 10 Gbit/s.

O que posso fazer se a reinicialização dos nós demorar muito?

Um maior número de arquivos no cluster resulta em maior tempo de reinicialização dos nós. Nesse caso, defina o parâmetro innodb_fast_startup como ON para acelerar o processo de reinicialização. Para obter mais informações sobre como modificar o parâmetro, consulte Definir parâmetros de cluster e de nó.

Quais são as vantagens das tabelas grandes no em relação aos discos locais de bancos de dados tradicionais?

Uma tabela grande em um banco de dados do é dividida e armazenada em N servidores de armazenamento físico. Portanto, as operações de I/O dessa tabela são distribuídas por vários discos. O throughput geral (e não a latência de I/O) das operações de leitura de I/O no banco de dados PolarDB for MySQL é superior ao de um banco de dados onde todas as operações de I/O são agendadas para discos locais.

Como otimizar tabelas grandes?

Recomendamos o uso de tabelas particionadas para otimizar tabelas grandes.

Quais são os cenários de uso de tabelas particionadas?

Tabelas particionadas são úteis quando você deseja podar tabelas grandes para controlar a quantidade de dados verificados nas consultas, sem modificar o código da aplicação. Por exemplo, use tabelas particionadas para limpar dados históricos dos seus serviços em intervalos regulares. Exclua as partições criadas no mês mais antigo e crie partições para o próximo mês, retendo apenas os dados dos últimos seis meses.

Qual método é adequado para copiar uma tabela com grande volume de dados no mesmo banco de dados do , por exemplo, copiar todos os dados da tabela A para a tabela B?

create table B as select * from A

Posso otimizar conexões de curta duração do PHP em cenários de alta concorrência?

Sim, é possível otimizar conexões de curta duração do PHP em cenários de alta concorrência. Para isso, ative o pool de conexões no nível de sessão nas configurações dos endpoints de cluster. Para obter mais informações, consulte Configurar o PolarProxy.

Como evitar que consultas SQL lentas reduzam o desempenho de todo o banco de dados?

Se você utilizar clusters do 5.6 ou 8.0, utilize o recurso de controle de concorrência de instruções para implementar limitação de taxa e throttling em instruções SQL específicas. Para obter mais informações sobre esse recurso, consulte Controle de concorrência.

O PolarDB suporta o recurso de timeout de sessão ociosa?

Sim, o PolarDB suporta o recurso de timeout de sessão ociosa. Altere o valor do parâmetro wait_timeout para especificar um período de timeout para sessões ociosas. Para obter mais informações, consulte Definir parâmetros de cluster e de nó.

Como identificar consultas SQL lentas?

Como encerrar consultas SQL lentas?