PGDay Campinas 2013 - Postgres XC @ Cloud

Postgres-XC em Cloud IaaSPGDay Campinas 2013

Postgres-XC emCloud IaaS

A Experiência - PGDay Campinas 2013

Matheus de Oliveirae

Vinícius Schmidt




PostgreSQLStreamming Replication


Streamming Replication

Replicação master/slave:

Um único servidor primário/master – escrita/leitura

Diversos secundários/slaves – somente leitura





Características:

Replicação por stream de dados (WAL)

Replicação síncrona (9.1) ou assíncrona

Muito rápida (se comparado à log shipping)

Servidores réplicas disponíveis para consulta

Rápida promoção de um slave para master

Replicação em cascata (9.2)



Aplicações:

Alta disponibilidade

Escalabilidade de leitura – balanceamento de carga

Servidores distribuídos geograficamente



Limitações:

Apenas um servidor síncrono

Atraso na replicação assíncrona

Sem escalabilidade de escrita

Balanceamento de carga (leitura) feita pela aplicação ou middleware (como PGPool-II)

Alta disponibilidade feita com ferramentas a parte (ou manualmente)


Postgres-XC


Postgres-XC – Visão Geral

Cluster de banco de dados para alta performance:

Cluster multi-master

Operações de escrita síncronas

Escalabilidade horizontal de leitura e escrita

Tabelas replicadas ou distribuídas

Banco de dados relacional

100% ACID (transacional)

Interface de acesso via SQL

...


Postgres-XC

O Projeto:

Fork do código-fonte do PostgreSQL

Re-implementa funcionalidades e correções de novas versões

Pretendem “juntar” novamente um dia...

Mesma licença do PostgreSQL


Postgres-XC

Desenvolvimento:

Todos podem enviar patches pela lista de desenvolvimento.

Patches são revisados pelos desenvolvedores. Eles tem a chance de avaliar, atualizar os fontes, ou pedir por novas features.

Se um commiter se sentir pronto para commitar, deve anunciar na lista e deixar 24 horas para aguardar uma melhoria de alguém.


Postgres-XC – Commiters

Em Set. 1st, 2013, haviam:

Ashutosh Bapat

Abbas Butt

Amit Khandekar

Satoshi Nagayasu

Michael Paquier

Masataka Saito

Koichi Suzuki

Política para novos Committers:

Não há um processo definido para como novos commiters são selecionados.

Tipicamente, candidatos devem enviar bons patches por um “longo” período. Então, os commiters existentes ou o “core team” irá propor para que essa pessoa seja aprovada como commiter.


Postgres-XC – Development Flow


Postgres-XC – Escalabilidade

DBT-1 throughput scalability

Postgres-XC em Cloud IaaSPGDay Campinas 2013Postgres-XC – Arquitetura


Postgres-XC – Arquitetura

Coordinators

Recebem as conexões/comandos dos usuários e redireciona aos datanodes

Análise/Planejamento/Execução de SQL

Enviam comandos para os datanodes, processam o resultado e retornam ao usuário

Datanodes

Armazenam os dados

Execução de SQL local

Basicamente o “bom e velho” PostgreSQL


Postgres-XC – Arquitetura

GTM (Global Transaction Manager)

Gerencia o controle de transações e visibilidade

Gerencia as sequências (sequences)

Tem-se sempre um único GTM para o cluster

GTM-Standby

Alta disponibilidade/backup para o GTM

GTM-Proxy

Se responsabiliza pela conexão ao GTM

Diminui o overhead de comunicação ao GTM agrupando requisições/respostas

Em geral, tem-se um em cada nó


Postgres-XCTopologias e Casos de Uso


Postgres-XC – Distribuição dos dados

Distribuição:

Os dados de uma tabela pode estar presente em um ou mais datanode

Grupo de datanodes:

Pode-se selecionar em qual(is) datanode(s) distribuir cada tabela

Tabelas replicadas:

Todos eles terão todos os dados dessa tabela

Tabelas distribuídas:

Cada um terá uma parte dos dados

Distribuição via: hash, roundrobin ou módulo


Postgres-XC – Tabelas replicadas


Postgres-XC – Tabelas distribuídas


Postgres-XC – DN/DC juntos


Postgres-XC – DN/DC juntos

Vantagens:

Arquitetura mais simples e de fácil manuntenção

Bom para aplicações OLTP

Muito bom para tabelas replicadas (tudo executado localmente, sem latência de rede)

Desvantagens:

Concorrência de CPU (nem sempre)

Pontos de falha


Postgres-XC – DN/DC separados


Postgres-XC – DN/DC separados

Mais DNs e menos DCs:

Bom para aplicações com muita escrita e pouca leitura

E tabelas distribuídas

Mais DCs e menos DNs:

Algumas tabelas distribuídas outras replicadas

Muita escrita e muita leitura

Processamento maior nos coordenadores

Equilíbrio:

Facilidade de balanceamento de carga

Adição de nós:

Adicionar DC é fácil

Adicionar DN não


Postgres-XCAlta Disponibilidade/Backup


Postgres-XC – Alta disponibilidade

GTM:

Usar GTM Standby

DN/DC:

Replicação síncrona

Failover/Failback:

Utilizar ferramenta de HA (Corosync+Pacemaker, Heartbeat, etc.)

Manualmente


Postgres-XC – Alta disponibilidade


Postgres-XC – Backup

pg_dump:

Executar em qualquer coordenador

Backup físico offline:

Parar todo o cluster e copiar

Backup físico online:

Criar barreira:

CREATE BARRIER meu_backup;

Realizar um backup-base em cada nó


ConsideraçõesFinais


Postgres-XC na Nuvem (AWS)

Escalabilidade:

Possibilidade de adicionar nós para aumentar escalabilidade tanto de escrita quanto de leitura

Apesar disso, adicionar nós automaticamente não é viável (como no Autoscaling)

Balanceamento de carga:

Simplesmente adicionar um ELB sobre os nós coordenadores e porta 5432


Postgres-XC na Nuvem (AWS)

Tentativa e erro:

Encontrar a melhor topologia não é fácil

Na nuvem, podemos testar diversos modelos

Comprar hardware pra “testar” cluster é inviável

Ambiente virtualizado:

Devido a distribuição, o I/O deixa de ser o gargalo

Muitas tabelas distribuídas:

Priorizar memória e CPU para os coordenadores


Dificuldades

Alta disponibilidade:

Muitos SPOFs

Distribuição de tabelas:

Encontrar a melhor chave e as tabelas que devem ser particionadas ou replicadas, não é fácil e depende (e muito) das consultas feitas pela aplicação

Topologia ideal:

Também depende do padrão de acesso

As possibilidades são muitas


Matheus de Oliveira<[email protected]>

Vinícius Schmidt<[email protected]>


Perguntas???


Software

PGDay Campinas 2013 - Postgres XC @ Cloud