Alta disponibilidade no MySQL 5.7 GUOB 2016

Copyright © 2016 Oracle and/or its affiliates. All rights reserved. |

30 de Julho de 2016 no Hotel Blue Tree Morumbi, São Paulo - SP

ALTA DISPONIBILIDADE NO MySQL 5.7 Airton Lastori


DBA Dev Gerencial, Usuário

ou Professor

Quem?


Não usa MySQL Usa MySQL sem

HA Usa MySQL com

HA

Quem?


Agenda

1. Alta disponibilidade (HA) – conceitos básicos

2. Arquiteturas e topologias de HA para MySQL

3. Monitoramento e gerenciamento


Agenda




Copyright © 2016 Oracle and/or its affiliates. All rights reserved. | 7

O chefe


O Desenvolvedor


O DBA


“Precisamos garantir que a nossa aplicação não pare nunca! Nosso cliente não pode esperar. Perderemos dinheiro e nossa marca ficará prejudicada.”

10


“Vamos comprar um NoBreak para o Servidor e está tudo certo!”

11


...

12


“Quanto % do tempo o sistema deve ficar no ar?”

13


“100%, é claro!”

14


“Desculpe desapontá-lo, mas disponibilidade infinita não existe. Pense em serviços como abastecimento de água ou energia elétrica... Há necessidade de ter redundância e contingência dos equipamentos e processos+ferramentas para a operação”

15


“Chefe, na verdade precisamos de mais 1 servidor para aplicação. É só instalar

uma cópia da aplicação nele e estamos bem. Teremos nosso Cluster!”

16


“Na camada de banco não é tão simples assim...”

17


Xiii... Lá vem esse cara complicar...


Standalone

Clusterizado

19

Problemas diferentes


mysql.com/why-mysql/white-papers/mysql_wp_ha_strategy_guide.php

Escolhendo a melhor solução para sua necessidade

http://www.mysql.com/why-mysql/white-papers/mysql_wp_ha_strategy_guide.php







Etapas típicas de um projeto de HA

1. Definir qual o tempo máximo de indisponibilidade e perdas aceitáveis

2. Revisar todos intens da infra-estrutura atual que terão contingência (mapear SPoF)

3. Definir a melhor arquitetura e topologia de HA para este contexto

4. Implantar a redundância dos componentes

5. Implantar monitoramento (instrumentação)

6. Implantar procedimentos operacionais para contingência

21


Etapas típicas de um projeto de HA

1. Definir qual o tempo máximo aceitável de uma indisponibilidade

2. Revisar todos intens da infra-estrutura atual que terão contingência (mapear SPoF)

3. Definir a melhor arquitetura e topologia de HA para este contexto

4. Implantar a redundância dos componentes

5. Implantar monitoramento (instrumentação)

6. Implantar procedimentos operacionais para contingência

22


Agenda





Sem alta disponibilidade

“Topologia” Stand-Alone

24

MySQL

Importante! Backup No-Break Duplicidade disco Duplicidade rede Etc.


Sem alta disponibilidade

“Topologia” Stand-Alone

Data Access (mysqld)

Data (Storage/HD/SDD)

App Servers

Database connection

25


Sem alta disponibilidade no Banco de Dados

Topologia com redundância apenas na Aplicação



App Servers

Database connections

26


Alta disponibilidade no modo Ativo-Passivo

Topologia com redundância via Shared Storage


Data (Shared Storage/SAN)

App Servers


27

Ativo

Passivo


• Oracle Clusterware é o core do Oracle RAC

– Para MySQL, funciona no modo Ativo/Passivo

• Oracle Cluster 12c inclui o MySQL Server 5.6 agent

• Paradas programadas ou failover automático

– Transparente para a aplicação

30/07/2016

MySQL Enterprise Edition + Oracle Clusterware

28


Alta disponibilidade com possibilidade do uso do Slave para outras atividades

Topologia com Replicação Simples (Master-Slave)

29

Master Read-write

Slave Read-only

Replicação nativa do MySQL Escrita

Leitura


Alta disponibilidade com possibilidade do uso do Slave para outras atividades

Topologia com redundância via Replicação Master-Slave

Slave read-only (mysqld)


App Servers


30

Read-write

Read-only

Replicação nativa

Master read-write (mysqld)


Replicação em 5 minutos Monte seu lab e comece a brincar

• [blog post] http://www.alastori.com.br/2015/02/tutorial-replicacao-mysql-em-5-minutos.html

http://www.alastori.com.br/2015/02/tutorial-replicacao-mysql-em-5-minutos.html













MySQL Enterprise Backup

1. Sem parar o Master, faça um hot backup

2. Restaure no Slave

3. No Slave execute CHANGE MASTER TO ...

4. Inicie o Slave

32

Crie novos Slaves online

https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/advanced.slave.html







Replicação Semi-síncrona para evitar perda de dados

Topologias resilientes

33

Master Slave

ACK = Confirmação de recebimento dos pacotes

Importante! Há configurações adicionais para tornar a replicação crash-safe


Analogia

34

Carta Simples

Carta AR

Intimação Judicial

Assíncrona sem confirmação do recebimento

Semi-síncrona confirmado recebimento, mas ainda não “processada”

Síncrona confirmado recebimento e processamento (commit)


Sem perda de dados e failover facilitado com replicação Semi-síncrona

Topologias resilientes com Múltiplos Slaves

35

Master Slave 1 (local) Primeira opção de failover (sempre mais atualizado)

Slave 2 (remoto) Segunda opção de failover


Grandes usuários MySQL usam a replicação

36

Web, Cloud, Distribuído e Embarcado…


Exemplos de uso da Replicação

• Redundância simples dos dados (Contingência)

• Backup

• Geo-redundância (DR)

• Dado mais próximo do cliente

• Escalabilidade de Leituras

– Dividir cargas OLTP e OLAP

– Read-write split




• Backup







Contingência em caso de falhas ou manutenção programada

Topologia Replicação Simples



App Servers


39

Read-write

Read-only



Contingência em caso de falhas do Master


Novo Master read-write (mysqld)


App Servers

Database connections Failover

novas rotas para as conexões com o MySQL

manual ou automático


Contingência em caso de falhas ou manutenção programada




App Servers


41

Read-write

Read-only



Contingência em caso de manutenção programada do Master


Temporary Master read-write (mysqld)


App Servers


42

Read-write

Inativo

Em Manutenção replicação parada

Switchover conexões roteadas para

outro servidor durante manutenção programada


Componentes para Roteamento de conexões

MySQL Connectors

• Funcionalidades nativas de Failover ou Load Balancing

MySQL Router (novo )

• Middleware leve

• Roteamento baseado nas conexões

• Failover para o primeiro disponível ou Load Balancing

MySQL Utilities

• mysqlfailover – monitora a replicação, promove novo master e redireciona slaves

• MySQL Fabric – provê mapeamento da topologia para connector ou router



MySQL Connectors



• Middleware leve



MySQL Utilities




Não recomendado uso como Master-Master: sem resolução de conflitos

Topologia de Replicação Cruzada + MySQL Router

45

Master “read-write” (hot stand-by)


App Servers

MySQL Router

Read-write

Read-only

Master read-write (ativo)

Heartbeat


Cuidado com Replicação Cruzada ou bi-direcional

• Este setup é bastante controverso, na maioria das vezes evitado

– Porém, tem seus usos

• Nesse caso anterior, a replicação cruzada é usada por praticidade

– permite simplificar o failover

– facilita resincronização dos dados em casos de falsos positivos, como falhas temporárias na rede

– use GTID, ROW BASED REPLICATION auto_increment_offset e auto_increment_increment para evitar problemas

• É importante monitorar e se ambos servidores estão recebendo escritas, deve-se agir rapidamente para diminuir chances de inconsistências.

46



MySQL Connectors



• Middleware leve



MySQL Utilities




Failover automático ou manual e automatizado para o primeiro disponível

MySQL Utilities para HA – mysqlfailover ou MySQL Fabric



App Servers


48

Read-write

Read-only


MySQL Utilities


MySQL Utilities

shell> mysqlfailover --master=root@localhost:3331 --discover-slaves-login=root --

log=log.txt

MySQL Replication Monitor and Failover Utility

Failover Mode = auto Next Interval = Mon Mar 19 15:56:03 2012

...

Master Information

Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB

mysql-bin.000001 571

GTID Executed Set

2A67DE00-2DA1-11E2-A711-00764F2BE90F:1-7 [...]

49

mysqlfailover

dev.mysql.com/doc/mysql-utilities/1.6/en/mysqlfailover.html

http://dev.mysql.com/doc/mysql-utilities/1.6/en/mysqlfailover.html





MySQL Utilities

Replication Health Status

+------------+-------+---------+--------+------------+---------+

| host | port | role | state | gtid_mode | health |

+------------+-------+---------+--------+------------+---------+

| localhost | 3331 | MASTER | UP | ON | OK |

| localhost | 3332 | SLAVE | UP | ON | OK |



+------------+-------+---------+--------+------------+---------+

Q-quit R-refresh H-health G-GTID Lists U-UUIDs L-log entries

50

mysqlfailover

dev.mysql.com/doc/mysql-utilities/1.6/en/mysqlfailover.html








• Backup







Menor tempo em backups e restores, menos downtime

MySQL Enterprise Backup


Backup no Slave


Slave parado (mysqld)


App Servers


53

Read-write

Inativo


Backup STOP SLAVE Cópia dos dados START SLAVE


Usada como solução de Backup

Topologia com Replicação Atrasada

54

Master Slave para failover/switchover

Slave com Atraso Caso típico = falha humana

Delay CHANGE MASTER TO MASTER_DELAY = N;


Usada em conjunto com backup para Point-In-Time-Recovery

Live Backup com mysqlbinlog

55

Master Slave para failover/switchover

mysqlbinlog --read-from-remote-server --host=host_name –raw --stop-never

https://dev.mysql.com/doc/refman/5.7/en/mysqlbinlog-backup.html







• Backup







Geo-redundância para Disaster Recovery

Topologias com múltiplos slaves

57

Site 1 Master

Site 2 Slave

Ativo Passivo




• Backup







Dado mais próximo do cliente para Leituras

Topologias com múltiplos slaves

59

Master read-write

Slave 1 read-only

Réplica do Master

Slave 2 read-only Réplica do Master

Slave 3 read-only Réplica do Slave 1


Consolidação de Múltiplos Masters em um Slave

Replicação Multi-Source: mais flexibilidade nas topologias

60

Slave

Master 3 read-write

Master 2 read-write

Master 1 read-write


Restrições e recomendações para Replicação

• A replicação convencional ocorre na camada de acesso aos dados (SQL), portanto funciona com qualquer storage engine, mas recomenda-se InnoDB

• InnoDB é recomendado por ser crash-safe, facilitando operações de crash-recovery e provisionamento via MEB

• Failover automático requer GTID e Row Format

• A replicação do NDB Cluster é diferente da replicação convencional e ocorre na camada de dados


Group Replication: multi-master Ativo-Ativo

Router

App

Virtually Synchronous Replication

App App

labs.mysql.com


Exemplos de uso da Replicação do NDB Cluster

• Redundância dos dados

– Ativo-Ativo


– Consistência forte, load balancing

• Escalabilidade de Escritas – Auto-sharding

• Geo-replicação


MySQL Cluster: Escalabilidade de Escritas


Resumo das opções

Replication Shared Disk

Virtualization Group Replication

Cluster Carrier Grade Edition

Failover Speed Config. Medium High High

Geo-Redundancy High None Config. High

Scaling Read None Read R/W

Ease of Migration From Stand-alone InnoDB to HA

Medium High High Low

Zero-Loss During Failure Config. Yes Config. Yes


Agenda











MySQL Utilities

• Binary Log Operations

• Database Operations

• General Operations

• Server Operations

• Specialized Operations

• High Availability Operations

– How Can I Use Replication?

– How Do I Add New Servers to My Topology and Change Master Role

– Setup Automatic Failover

– Restore the Previous Master After Failover

– How Can I Find All of the Slaves Attached to My Master Server?

– How To Check If Data Is Correctly Replicated?

– How To Fix Errant Transactions on the Replication Topology?

73

dev.mysql.com/doc/mysql-utilities/1.6/en/mysql-utils-ha.html

https://dev.mysql.com/doc/mysql-utilities/1.6/en/mysql-utils-ha.html









MySQL Utilities – Exemplo switchover

shell> mysqlrpladmin --master=root@server2:3312 \

--slaves=root@server2:3313,root@server4:3314,root@server5:3315 \

--rpl-user=rpl:rpl --new-master=root@server1:3311 --demote-master

switchover

# Checking privileges.

# Performing switchover from master at server2:3312 to slave at server1:3311.

# Checking candidate slave prerequisites.

# Checking slaves configuration to master.

# Waiting for slaves to catch up to old master.

# Stopping slaves.

# Performing STOP on all slaves.

...

74

dev.mysql.com/doc/mysql-utilities/1.6/en/mysql-utils-ha.html










MySQL Utilities – Exemplo switchover

...

# Switchover complete.

# Replication Topology Health:

+----------+-------+---------+--------+------------+---------+

| host | port | role | state | gtid_mode | health |

+----------+-------+---------+--------+------------+---------+

| server1 | 3311 | MASTER | UP | ON | OK |

| server2 | 3312 | SLAVE | UP | ON | OK |




+----------+-------+---------+--------+------------+---------+

75


MySQL Enterprise Edition Suporte + Base de Conhecimento + Hot Backup + Monitor + Oracle EM + Workbench + Plug-ins

Escalabilidade Autenticação

Firewall Auditoria novo TDE

Criptografia

MySQL Enterprise Monitor Oracle EM for MySQL

Plug-ins

Suporte

Hot Backup

Monitor & Workbench


Sumário

1. HA não é simples nem de graça

2. O MySQL possui diversas opções para HA

3. Entenda os requisitos, compare as possíveis arquiteturas e topologias, faça a melhor escolha!


@MySQLBR meetup.com/MySQL-BR facebook.com/MySQLBR

pt.planet.mysql.com

http://pt.planet.mysql.com/


Obrigado!


Perguntas?

Alta Disponibilidade no MySQL 5.7 Contato: [email protected] twitter.com/mysqlbr facebook.com/mysqlbr

Alta disponibilidade no MySQL 5.7 GUOB 2016

Technology