No cenário de sistemas que demandam altíssima confiabilidade, como nos setores financeiro, governamental e de telecomunicações, o banco de dados KingbaseES, desenvolvido pela CEC Kingbase, oferece soluções robustas. A necessidade central é garantir alta disponibilidade, consistência forte e capacidade de processamento concorrente, superando as limitações de bancos de dados monolíticos ou de arquiteturas primário-standby simples, que podem apresentar pontos únicos de falha, tempos de failover elevados ou risco de perda de dados.
O KingbaseES atende a esses requisitos com diferentes estratégias. Este artigo concentra-se em duas soluções chave: o cluster de escrita múltipla com armazenamento compartilhado, RAC, introduzido a partir da versão V9R1, e o cluster de alta disponibilidade primário-standby oferecido na versão V8R6. A escolha entre eles depende criticamente do cenário de aplicação e da versão do produto, sendo crucial entender as distinções.
- Cluster RAC V9R1+: Arquitetura de Escrita Múltipla para Cenários Críticos
O KingbaseES RAC (Real Application Cluster) é uma solução de cluster com armazenamento compartilhado projetada para operações transacionais de missão crítica. É fundamental notar que este recurso é uma inovação da versão V9R1. A versão V8R6 e anteriores não oferecem suporte oficial a RAC. Qualquer implementação não oficial nessa versão apresenta riscos significativos e não é recomendada para ambientes de produção.
O princípio fundamental do RAC é permitir que múltiplas instâncias de banco de dados acessem simultaneamente o mesmo conjunto de armazenamento compartilhado, podendo cada nó realizar operações de leitura e escrita. Isso difere da arquitetura primário-standby, onde a carga de escrita é centralizada no nó primário. No RAC, a carga é distribuída horizontalmente entre os nós ativos.
Componentes Essenciais da Arquitetura
O funcionamento do RAC depende da sinergia entre vários componentes:
- Armazenamento Compartilhado: A base do sistema. Todos os nós acessam os mesmos arquivos de dados, controle e logs de redo através de SAN ou NAS, garantindo consistência inerente dos dados no nível de armazenamento.
- Clusterware: Construído sobre Pacemaker e Corosync, é responsável pelo monitoramento de saúde dos nós, detecção de falhas e agendamento de recursso. A troca e recuperação automáticas do cluster dependem dele.
- Cache Fusion: Um componenet crítico para o desempenho. Cada nó mantém seu próprio buffer pool de memória. A sincronização entre os buffers é realizada via uma rede privada de alta velocidade (como InfiniBand ou RDMA), garantindo que qualquer leitura reflita os dados mais recentes.
- Gerenciador de Lock Global (GLM): Coordena as escritas concorrentes dos múltiplos nós no nível superior, prevenindo conflitos como a modificação simultânea da mesma linha de dados por dois nós.
- QDevice: Um nó de votação arbitral que, em caso de particionamento de rede, decide qual parte do cluster tem o direito de continuar atendendo, evitando o fenômeno de "cérebro dividido".
Uma topologia típica de dois nós compreende duas instâncias de banco de dados (em Node A e Node B) montando o mesmo armazenamento compartilhado. A rede privada é dedicada à comunicação de Cache Fusion, e o QDevice, independente dos nós de bannco, fornece a arbitragem.
Desempenho
Em cenários típicos de OLTP, o KES RAC pode oferecer um ganho de desempenho em escrita de mais de 3x comparado ao modo primário-standby tradicional. Como os dados existem em uma única cópia no armazenamento compartilhado, a troca de nó não requer sincronização de dados, resultando em um Tempo de Recuperação (RTO) próximo de zero e Ponto de Recuperação (RPO) zero, atendendo ao nível de disponibilidade "five nines" (99,999%) exigido no setor financeiro.
Passos Críticos de Implantação
A implantação de um cluster RAC V9R1+ envolve múltiplas etapas. A seguir, destacam-se os pontos-chave.
Preparação do Ambiente: A configuração recomendada para um cluster de dois nós inclui CPU com 16 núcleos, 64 GB de RAM, armazenamento local SSD de 500 GB, armazenamento compartilhado de 2 TB e duas placas de rede (uma para tráfego de aplicação, outra para a rede privada do cluster). No nível do sistema, é necessário criar usuários, configurar resolução de nomes, desativar firewall e SELinux, e ajustar parâmetros do kernel:
# Criação do usuário do banco de dados
useradd -u 2000 kingbase
# Configuração de resolução de nomes de host
echo -e "10.0.1.10 node1\n10.0.1.20 node2\n10.0.2.10 qdevice" >> /etc/hosts
# Otimização de parâmetros do kernel
cat >> /etc/sysctl.conf << 'EOF'
kernel.shmmax = 68719476736
kernel.shmall = 16777216
kernel.sem = 250 32000 100 128
vm.swappiness = 10
EOF
sysctl --system
Configuração do Armazenamento Compartilhado: O foco é garantir acesso estável por todos os nós através de software de múltiplos caminhos:
pvcreate /dev/mapper/mpatha1
vgcreate kb_shared_vg /dev/mapper/mpatha1
lvcreate -L 1.8T -n kb_data_lv kb_shared_vg
mkfs.xfs /dev/kb_shared_vg/kb_data_lv
mkdir -p /mnt/kingbase_shared
mount /dev/kb_shared_vg/kb_data_lv /mnt/kingbase_shared
Registro de Recursos no Clusterware: O armazenamento compartilhado, o IP virtual e as instâncias do banco são gerenciados centralmente. Grupos de recursos garantem a ordem correta de inicialização, e a propriedade de "aderência" evita migrações desnecessárias:
crm configure primitive VIP_KINGBASE ocf:heartbeat:IPaddr2 \
params ip="10.0.1.100" cidr_netmask="24" nic="eth0" \
op monitor interval="10s" timeout="20"
crm configure group KINGBASE_RESOURCE_GROUP VIP_KINGBASE STG_KINGBASE DB_KINGBASE_INST
crm configure rsc_defaults resource-stickiness=500
Configuração Final do Banco: No arquivo kingbase.conf, o modo RAC é habilitado, com um ID de nó único e um IP privado para a comunicação de Cache Fusion:
enable_rac_mode = on
rac_node_id = 1
rac_node_name = 'primary_node'
rac_private_ip = '192.168.100.10'
Otimização do Desempenho do Cache Fusion
O desempenho máximo do RAC é amplamente determinado pela eficiência do Cache Fusion. Parâmetros como tamanho do pool de conexões, buffers de rede e estratégias adaptativas devem ser ajustados com base na carga de trabalho real:
ALTER SYSTEM SET rac_cache_fusion_pool_size = '2GB';
ALTER SYSTEM SET rac_cache_fusion_buffer_size = '8MB';
ALTER SYSTEM SET rac_cache_fusion_adaptive = on;
- Cluster Primário-Standby V8R6: Uma Solução Leve de Alta Disponibilidade
Nem todos os cenários requerem a complexidade de um RAC. Adicionalmente, a versão V8R6 não o suporta. Para a maioria dos sistemas de negócios de médio porte, a solução primário-standby do V8R6 oferece um excelente equilíbrio entre funcionalidade e custo. Ela utiliza replicação de log (streaming replication) para sincronizar os dados: o nó primário grava, e o nó standby acompanha. Com ferramentas de implantação gráfica, um cluster pronto para produção pode ser configurado em poucas horas.
Planejamento da Implantação
O planejamento de IP é simples: um IP para o nó primário, um para o nó standby, e um IP flutuante (VIP) como ponto de entrada da aplicação. As aplicações sempre se conectam ao VIP. Em caso de failover, o VIP migra para o novo nó primário, tornando a operação transparente para a aplicação. Exemplo: primário (192.168.225.128), standby (192.168.225.129), VIP (192.168.225.200).
Pré-requisitos
Antes da implantação, algumas verificações são essenciais: comandos como cron, arping e ip devem estar disponíveis; todos os nós devem alcançar o gateway; a comunicação SSH entre os nós deve estar configurada, permitindo login como root; SELinux e firewall devem estar desativados; os relógios de todos os nós devem estar sincronizados; o processo do banco deve ser executado por um usuário não-root (geralmente kingbase).
Processo de Implantação Gráfica
A ferramenta gráfica do V8R6 simplifica o processo. Você cria um projeto e um cluster, seleciona o pacote de instalação (db.zip) adequado à sua arquitetura (suporte para Lin64, Mips64, Aarch64), preenche os parâmetros do banco e os parâmetros de alta disponibilidade (incluindo VIP, máscara de sub-rede, gateway de confiança, e se o failover automático é permitido), e então adiciona os nós primário e standby sequencialmente. A ferramenta realiza verificações de ambiente e a instalação automaticamente.
Parâmetros de Configuração Importantes
Após a implantação, alguns parâmetros no kingbase.conf merecem atenção. Para memória, shared\_buffers deve ser cerca de 25% da RAM física, e effective\_cache\_size cerca de 50%. Para checkpoints, checkpoint\_timeout em 20 minutos e checkpoint\_completion\_target em 0.9 suavizam a gravação dos checkpoints. Para logs, ativar o registro de consultas lentas (acima de 1s) e de DDL é vital para diagnósticos futuros.
listen_addresses = '*'
port = 54321
max_connections = 1000
shared_buffers = '16GB' # Exemplo para 64GB de RAM
effective_cache_size = '32GB'
checkpoint_timeout = 20min
checkpoint_completion_target = 0.9
max_wal_size = 64GB
logging_collector = on
log_directory = 'pg_log'
log_filename = 'kingbase-%Y-%m-%d.log'
log_min_duration_statement = 1000 # ms
log_statement = 'ddl'
Operações Básicas do Cluster
Para iniciar ou parar o cluster diariamente, utilize o script sys\_monitor.sh no diretório bin com o usuário kingbase:
./sys_monitor.sh start
./sys_monitor.sh stop
Para verificar o papel de um nó, conecte-se e execute SELECT pg\_is\_in\_recovery();. Retornar f indica que é o nó primário; t indica que é o standby. Para visualizar o estado completo do cluster, incluindo atraso de replicação, use ./repmgr cluster show.
Configuração de Leitura/Escrita Separada
O V8R6 suporta separação de leitura e escrita diretamente via driver JDBC. Ao configurar o endereço do nó standby e ativar USEDISPATCH no arquivo de configuração do driver, as requisições de leitura são roteadas automaticamente para o standby, e as de escrita para o primário, sem necessidade de alterar o código da aplicação.
# /opt/app/jdbc_conn.conf
HOST=192.168.225.128
PORT=54321
DBNAME=mydatabase
user=dbuser
password=secure_password
USEDISPATCH=true
SLAVE_HOST=192.168.225.129
SLAVE_PORT=54321
A string de conexão JDBC usa o VIP. Após um failover, não é necessário alterar a configuração:
jdbc:kingbase8://192.168.225.200:54321/mydatabase?ConfigurePath=/opt/app/jdbc_conn.conf
- Como Escolher Entre as Duas Soluções?
A diferença entre RAC e o cluster primário-standby reside em duas dimensões: versão e cenário.
Versão: O RAC é uma capacidade exclusiva do V9R1; o V8R6 não o suporta. Esta é uma restrição técnica incontornável. Se você utiliza o V8R6 e deseja empregar RAC, será necessário um upgrade de versão, um projeto significativo que requer avaliação separada.
Cenário:
- RAC: Indicado para operações de missão crítica onde o tempo de inatividade é inaceitável e a carga de escrita concorrente é massiva (ex.: transações bancárias em tempo real, faturamento de telecomunicações). O custo é um hardware mais caro (armazenamento compartilhado e rede privada de alta velocidade) e maior complexidade de implantação e operação.
- Cluster Primário-Standby: Ideal para a maioria dos cenários de negócios que requerem eliminação de ponto único de falha, podem tolerar segundos de failover, têm sensibilidade a custos de hardware e desejam simplicidade de implantação e manutenção. Esta solução é suficiente e mais prática para esses casos.
Aviso Importante: Não tente simular um comportamento de RAC na versão V8R6 através de métodos não oficiais. Tais abordagens não têm garantia de estabilidade e os fornecedores não oferecerão suporte em caso de falhas, representando um risco grande em ambientes de produção.
Recomenda-se realizar uma validação extensiva em um ambiente de teste com uma carga que se aproxime da realidade de produção antes da decisão final, garantindo que a solução escolhida cumpra os requisitos de nível de serviço (SLA) definidos.