Conheça o MySQL Fabric

Gerenciamento de Grupos de Bancos de Dados MySQL com MySQL Fabric

O MySQL Fabric torna mais simples o gerenciamento de grupos de bancos de dados MySQL. Você pode e deve utilizar o MySQL Fabric sempre que precisar de uma solução de alta disponibilidade para o seu ambiente produtivo. Além disso, ele provê failover automático e detecção de falhas.
Apesar de o MySQL Fabric prover o “database sharding”, neste artigo iremos abordar apenas a parte da alta disponibilidade do Fabric. Essa parte, basicamente, organiza os servidores MySQL em grupos, ou comumente conhecido como “high-availability groups”, para proporcionar alta disponibilidade. Por exemplo, se você está utilizando uma replicação padrão assíncrona, o Fabric pode ser configurado para monitorar automaticamente o estado dos servidores em um determinado grupo. Nesse caso, se o “Master” atual do grupo falhar, o Fabric elege um novo servidor no grupo para se tornar o “Master”. Mas caso você queira, também é possível realizar o failover de forma manual.

Para utilizar o MySQL Fabric, será necessário utilizar um conector MySQL na aplicação (disponível para download no site do MySQL), que utilize o protocolo XML-RPC. Atualmente, o Python Driver (Connector/Python) e JDBC Driver (Connector/J) são “fabric-aware”, ou seja, estão prontos para o Fabric.

O MySQL Fabric não trabalha sozinho. As informações de todos os servidores e grupos são gerenciadas por uma instância MySQL separada, que é utilizada como uma espécie de “repositório” do Fabric. Essa instância é chamada de “Backing Store” e não pode fazer parte de nenhum grupo de servidores os chamados “high-availability group”. Já as instâncias MySQL gerenciadas pelo Fabric, precisam ter o “Global Transaction Identifiers” (GTID) habilitado. Esse parâmetro é utilizado pelo Fabric para checar e manter a consistência entre os servidores. O MySQL Fabric organiza os servidores em “high-availability groups” para gerenciar diferentes “shards” ou simplesmente proporcionar alta disponibilidade, que é o assunto que iremos abordar aqui.

Quando utilizamos a tecnologia de master/slave, o Fabric pode ser configurado para trabalhar monitorando o estado atual de cada instância para gerenciar quem é o atual “Master”. Por exemplo, se estiver utilizando uma replicação padrão assíncrona, o Fabric monitora o status de cada servidor no grupo. Então, em caso de falha do “Master”, o Fabric elege um novo servidor no grupo para se tornar o “Master”, tudo isso de forma automática.

Para quem está familiarizado com a solução de alta disponibilidade do Oracle Database, o “Oracle Dataguard”, estará mais familiarizado com o MySQL Fabric pois ele tem um papel muito semelhante ao “Broker” do Oracle Dataguard, provendo o failover/switchover de forma manual ou automática.

Assim como no “Broker”, temos a ferramenta DGMGRL para efetuar comandos e administrar a replicação entre os Oracle Databases. No MySQL Fabric utilizamos a ferramenta chamada “mysqlfabric” que segue o mesmo propósito. Com esta ferramenta é possível executar diversas operações, tais como criar e gerenciar grupos, verificar o status da replicação, fazer switchover/failover e várias outras operações.

No exemplo a seguir faremos uma demonstração de como funciona o MySQL Fabric. Para isso iremos utilizar a versão do Linux RHEL x.x, rodando o MySQL 5.7 para ser o repositório (“Backing Store”) do MySQL Fabric.

O MySQL Fabric

No Linux, o MySQL Fabric fica dentro do pacote rpm “MySQL Utilities” disponível para download na página principal (seção Links). Portanto, basta instalar esse pacote que o MySQL Fabric estará instalado, pronto para configuração.

Conceitos Gerais

Para entender o MySQL Fabric, primeiramente precisamos apresentar uma terminologia usada pelo projeto. Começaremos listando definições básicas e, em seguida, entraremos em mais detalhes quando necessário.

• Grupo: Uma coleção de servidores mysqld;
• Nó: Uma instância em execução do MySQL Fabric;
• Primário: Um membro do grupo que foi designado mestre;
• Secundário: Um membro do grupo que é somente leitura.

Grupo

Um servidor aqui é realmente uma instância do mysqld, embora idealmente, todas as instâncias de um grupo devem estar em servidores diferentes. No entanto, durante o teste, você pode criar várias instâncias no mesmo host, uma vez que você realmente não precisa de HA (High Availability Group).

Um determinado servidor só pode fazer parte de um único grupo. Isso pode parecer confuso no início, mas quando você percebe que o MySQL Fabric depende da replicação (usando GTID) para a maior parte de seu trabalho, fica mais claro. Um determinado servidor MySQL só pode ter um mestre e, portanto, não faz sentido para ele pertencer a vários grupos.

Os grupos têm identificadores, que são apenas nomes simbólicos que precisam cumprir algumas regras básicas

Nó

Note que um nó não é um servidor MySQL que faz parte de um grupo. É um programa python que, entre outras coisas, fornece o servidor XML-RPC que é usado por conectores especiais e pelo cliente de linha de comando "mysqlfabric". No entanto, um nó precisará de uma instância do mysqld. Esta instância é chamada de backend store e será usada pelo MySQL Fabric para salvar todas as informações necessárias para gerenciar os servidores.

Primário

O servidor primário é o único servidor gravável em um grupo. Isso se aplica ao HA, não ao sharding, embora você possa definir um grupo (e, portanto, um Primary) por shard e, portanto, usar o MySQL Fabric tanto para sharding, quanto para fornecer HA para cada shard.

Secundário

Um servidor secundário é um membro de um grupo que está disponível para substituir um servidor primário no failover e que é somente leitura. Também pode ser usado para dimensionar leituras.

Usuários

O MySQL Fabric pode utilizar quatro tipos diferentes de usuários com privilégios específicos para atividades de cada um deles, que são:

• Backing Store User: Armazena informações específicas do Fabric e é criado somente no servidor do MySQL “Backing Store”;
• Server User: Acessa os servidores MySQL que serão gerenciados pelo Fabric, é criado em cada servidor MySQL que será gerenciado pelo Fabric;
• Backup User: Executa operações de backup, assim como mysqldump, é criado em cada servidor MySQL que será gerenciado pelo Fabric;
• Restore User: Executa operações de restore, utiliza normalmente o “client” do mysql, é criado em cada servidor MySQL que será gerenciado pelo Fabric.

Nota. Privilégios e Usuários: É possível utilizar o mesmo usuário MySQL para utilizar como “server user”, “backup user” e “restore user”, porém nesse caso o usuário teria uma soma de privilégios dos três usuários, que o deixaria com muitos privilégios, o que não é recomendado para utilizar em produção.

Nesse exemplo, iremos ver como baixar o pacote de instalação do MySQL Fabric, efetuar a criação dos usuários mencionados acima, que farão parte da configuração. Veremos também a criação do grupo de monitoração da replicação, adição das instâncias a serem gerenciadas pelo Fabric ao group de HA, promover um slave a Master, checar a integridade da replicação.

Baixando o MySQL Fabric

Para fazer o download do MySQL Fabric utilize o link da seção Links. Os downloads estão em pacotes e podem ser baixados para vários tipos de servidores e sistemas operacionais. Baixe o pacote que corresponde à sua plataforma e extraia os arquivos em uma pasta de sua preferência, conforme mostra a Figura 1.

O site acima também fornece os conectores MySQL Fabric-aware. Faça o download do conector que você deseja usar com um aplicativo MySQL Fabric. Para obter mais informações sobre como instalar e começar a usar o MySQL Fabric em seus aplicativos, consulte a seção específica do conector apropriada

Instalando o MySQL Fabric

O MySQL Fabric/Utilities requer o Python 2.6 instalado. Para facilitar o processo você também poderá configurar o YUM (instruções de como configurá-lo na seção Links) para fazer o download e instalar automaticamente as dependências de pacotes, conforme mostra a Figura 2.

Configurando o MySQL Fabric

A primeira coisa que iremos precisar para iniciar a configuração do Fabric é um usuário no servidor (instância) que iremos utilizar como o “Backing Store” ou “Repositorio” do Fabric. As informações dessa conta ficam armazenadas no arquivo de configuração fabric.cfg na sessão de [storage], conforme mostra a Figura 3.

O usuário que criaremos para o backing store, necessita dos seguintes privilégios (Nota do DevMan 1) no database do backing store:

• ALTER- alterar objetos dos databases
• CREATE- criar objetos nos databases
• CREATE VIEW - criar views
• DELETE - deletar linhas
• DROP- deletar objetos no database
• EVENT - gerenciar eventos
• REFERENCES - criar foreign keys
• INDEX - criar indexes
• INSERT - inserir linhas
• SELECT - selecionar linhas
• UPDATE- atualizar linhas

A Listagem 1 mostra um exemplo de criação do usuário.

CREATE USER "fabric"@"localhost"
     IDENTIFIED BY "secret";
   
  GRANT ALTER, CREATE, CREATE VIEW, DELETE, DROP, EVENT,
     INDEX, INSERT, REFERENCES, SELECT, UPDATE ON fabric.*
     TO "fabric"@"localhost";

Privilégios: A permissão “REFERENCES” não é necessária nas versões anteriores ao MySQL 5.6. Somente será necessário se estiver utilizando o MySQL 5.7 ou superior.

O usuário do Servidor

O Fabric utiliza o usuário do servidor (instância mysql) para acessar todos os servidores MySQL que serão gerenciados pelo Fabric, portanto é necessário criá-lo em cada servidor individualmente. As informações dessa conta ficam armazenadas no arquivo de configuração do fabric.cfg na sessão de [servers], conforme mostra a Figura 4.

Nota. Senhas: As senhas dos usuários ficam em aberto no arquivo de exemplo, porém isso não é recomendado para ambientes produtivos, devendo então criptografar essas senhas.

O usuário do server (fabric) nesse exemplo, necessita dos seguintes privilégios no escopo GLOBAL: DELETE, PROCESS, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE.

No escopo do database, que no exemplo se chama “fabric”, o usuário do servidor necessita das seguintes permissões: ALTER, CREATE, DELETE, DROP, INSERT, SELECT, UPDATE. Na Listagem 2 temos o exemplo para criação do usuário.

CREATE USER "fabric"@"localhost"
    IDENTIFIED BY "secret";
   
  GRANT DELETE, PROCESS, RELOAD, REPLICATION CLIENT,
    REPLICATION SLAVE, SELECT, SUPER, TRIGGER ON *.*
    TO "fabric"@"localhost";
   
  GRANT ALTER, CREATE, DELETE, DROP, INSERT, SELECT, UPDATE
     ON fabric.* TO "fabric"@"localhost";

Usuário de Backup

Se você quiser clonar uma instância do MySQL e adicionar em um HA “High-Availability Group”, então você irá precisar criar os usuários de backup e restore (Nota do DevMan 2), assim como foi feito com o usuário do servidor. As informações dessa conta também ficam armazenadas no arquivo de configuração do fabric.cfg na sessão de [servers].

Nota do DevMan 2. Backup e Restore: Não iremos considerar o backup e restore da instância MySQL nesse exemplo. Iremos apenas tratar da configuração do MySQL Fabric, levando em consideração que você já tenha uma replicação padrão Master/Slave.

Arquivo de Configuração

O arquivo de configuração possui o nome de fabric.cfg e dependendo do sistema operacional, fica armazenado em um caminho diferente (Figura 5). O arquivo pode ser encontrado na documentação do pacote que será feito o download. Nesse arquivo configuramos os usuários e senhas que foram criados no passo anterior.

O arquivo de configuração do Fabric possui todas as informações necessárias para rodar o MySQL Fabric. Cada sessão possui vários parâmetros configurados que definem informações chaves das bibliotecas do MySQL Fabric, você não precisará alterar nenhum desses parâmetros além dos usuários e senhas da Listagem 2.

Apesar de não ser necessário na maioria das vezes fazer nenhuma alteração no arquivo de configuração além da alteração dos usuários e senhas, iremos descrever algumas dessas sessões que temos disponíveis no arquivo (fabric.cfg) e fazer uma breve explicação de para que server cada uma delas.

[DEFAULT]
A sessão DEFAULT contém as informações dos caminhos de instalação do MySQL Fabric. Essa sessão é criada como uma parte da instalação e normalmente não deveria ser modificada.

[STORAGE]
Essa sessão contém informações que o nó do MySQL Fabric usa para se conectar ao backing store.

[SERVERS]
Essa sessão contém informações que o MySQL Fabric utiliza para se conectar aos servidores que são gerenciados.

[PROTOCOL.XMLRPC]
Essa sessão contém informações sobre como o client se conecta ao nó do MySQL Fabric e parâmetros de configuração do protocolo XML-RPC no servidor.

[PROTOCOL.MYSQL]
Essa sessão contém informações sobre como o client se conecta ao nó do MySQL Fabric utilizando o protocolo MySQL Client/Server.

[EXECUTOR]
Essa sessão contém parâmetros para configurar o executor. O executor é responsável por executar procedimentos em uma ordem sequencial, que garante que as solicitações não conflitem entre si. As solicitações recebidas são mapeadas e envidadas como procedimentos que podem ser executados imediatamente ou serem agendados através do executor. Procedimentos agendados através do executor são processados dentro do contexto de “threads” chamados pelo executor. Normalmente, operações de leitura são imediatamente executadas pela sessão XML-RPC e operações de escrita são agendadas e executadas através do executor.

[LOGGING]
MySQL Fabric registra informações sobre suas atividades para a saída padrão quando iniciado como um processo regular. No entanto, quando iniciado como um daemon, ele grava informações em um arquivo configurado pela opção Fabric URL usado para log.

Preparando o MySQL para o Fabric

Agora vamos configurar as instâncias do MySQL que serão gerenciadas pelo Fabric. Basicamente todas as instâncias de MySQL que serão gerenciados pelo Fabric requerem os parâmetros gtid_mode (GTID), bin_log (binary logging) e o log_slave_updates habilitados. Além disso, cada servidor deverá ter o seu próprio server_id configurado, conforme mostra a Figura 6.

As configurações a seguir devem constar no arquivo de configuração do MySQL (my.cnf) de cada instância que será gerenciada pelo Fabric.

Server-id=1 é a identificação de cada servidor, gtid-mode=on parâmetro que é utilizado pelo Fabric para checar e manter a consistência entre os servidores, log-bin que são os logs binários do mysql como pode ser visto na Listagem 3.

#Server_id 
  server-id=1 
  #Global Transacional
  gtid-mode=on
  log-bin = /etc/mysql/binlog/mysql-bin
  log-slave-updates = 1

Existe um parâmetro opcional --config que aceita o caminho do arquivo de configuração do Fabric como parâmetro (Nota do DevMan 3). Assim ele irá utilizar o arquivo passado no parâmetro ao invés do arquivo de configuração no caminho padrão.

Parâmetros: Existe uma opção –param que permite que você sobrescreva as configurações em tempo de execução, como utilizar outro usuário e senha para o fabric, por exemplo:

No servidor onde será instalado o Fabric, iremos executar os comandos para configurar o Fabric. Aqui iremos fazer o setup inicial do Fabric:

mysqlfabric manage setup

Com esse comando o database é criado assim como as devidas tabelas e usuários. Essas informações são carregadas do arquivo de configuração, conforme mostra a Figura 7.

Após a execução do setup, podemos ver que o database configurado no fabric.cfg (fabric) foi criado com sucesso utilizando o seguinte código, assim como as tabelas:

mysql -hlocalhost -P3306 -ufabric -psecret -e"SHOW DATABASES; USE fabric; SHOW TABLES;"

Veja a execução na Figura 8.

Depois de configurado iniciamos o MySQL Fabric com o comando a seguir (o comando em específico não retorna nenhuma saída):

mysqlfabric manage start --daemonize

Com o serviço do Fabric iniciado, agora podemos listar os grupos existentes (note que aqui ainda não aparece nenhum grupo criado) com o código a seguir:

mysqlfabric group lookup_groups

Veja o resultado na Figura 9.

Agora criaremos o HA (High Availability Group) para depois adicionarmos os servidores a esse grupo utilizando o código a seguir e o resultado apresentado na Figura 10:

mysqlfabric group create my_group

Na Figura 11 listamos os grupos novamente. Repare que agora o novo grupo irá aparecer usando o seguinte código:

mysqlfabric group lookup_groups

O comando abaixo é utilizado para listar os servidores que fazem parte do grupo:

mysqlfabric group lookup_servers my_group

Nesse momento só criamos o grupo, por isso ainda não aparece nenhum servidor, como mostra a Figura 12.

Verificando a “saúde” do grupo, com o comando a seguir é apontado qualquer anormalidade na replicação, e o erro irá aparecer na sessão “issue”, conforme mostra a Figura 13:

mysqlfabric group health my_group

Agora sim com o código a seguir iremos adicionar os servidores ao HA grupo my_group criado anteriormente, conforme mostra a Figura 14.

mysqlfabric group add my_group localhost:3307

Em seguida, adicionamos a segunda instância (Figura 15) e a terceira instância (Figura 16) com os seus respectivos comandos:

mysqlfabric group add my_group localhost:3308
mysqlfabric group add my_group localhost:3309

Listando os servidores contidos no grupo novamente com o comando a seguir, conforme mostra a Figura 17.

mysqlfabric group lookup_servers my_group

Agora podemos checar novamente a “saúde” do cluster utilizando o comando a seguir:

mysqlfabric group health my_group

Podemos notar que os três servidores aparecem adicionados ao grupo my_group, porém estes servidores estão com o status “SECONDARY”, conforme mostra a Figura 18.

Com os servidores devidamente adicionados ao grupo HA podemos agora promover com o código a seguir um dos servidores como o primário (master), conforme mostra a Figura 19:

mysqlfabric group promote my_group --slave_id=9964e6a3-a925-11e6-85f8-5254009fbdfd

Listando novamente os servidores e status, podemos verificar que agora um dos servidores foi promovido a “PRIMARY”, ou seja, agora esse servidor será o master, conforme mostra a Figura 20.

Mostrando novamente a “saúde” do cluster podemos notar que o servidor que escolhemos para promover já aparece como “PRIMARY”, conforme mostra a Figura 21.

Ative o failover automático com o comando a seguir para que, em caso de falha do servidor que promovemos ou algum problema acontecer, um novo servidor que aparece como “SECONDARY” no grupo seja promovido para master, conforme mostra a Figura 22.

mysqlfabric group activate my_group

Agora com o Fabric configurado iremos criar um database para teste e verificar se a replicação está funcionando corretamente, conforme mostra a Figura 23.

Na segunda instância que está rodando na porta 3308 podemos verificar que o database teste_fabric foi criado com sucesso, conforme mostra a Figura 24.

O MySQL Fabric tem seus pontos positivos e negativos. Felizmente, a maior parte dos pontos negativos que identificamos são devido ao projeto estar ainda no início de seu ciclo de vida. Considerando que a versão mais recente é um RC, temos certeza de que aqueles vão desaparecer no futuro. Quanto aos pontos positivos, temos:

• Ele é desenvolvido pela Oracle: é um ponto importante porque o MySQL não tinha uma ferramenta padrão para gerenciar farms de servidores;
• É extensível: O MySQL Fabric parece mais um framework do que um produto fechado. Como um framework, ele é roda em Python, uma linguagem amplamente disponível e amigável. Acreditamos que isso significa que o MySQL Fabric deve ser adaptável a necessidades específicas com pouco aborrecimento;
• Ele é focado no MySQL nas versões 5.6.10 e mais recentes: Por não se preocupar com compatibilidade com versões anteriores, a implementação deve ser mais simples. Contudo, a desvantagem óbvia é que você não pode considerar o uso do MySQL Fabric se você estiver em uma versão anterior do MySQL.

Em configurações de HA, MySQL Fabric em si, pode se tornar um único ponto de falha. O MySQL Fabric e seu armazenamento de dados (a instância mysqld que armazena os dados do MySQL Fabric) são um único ponto de falha que precisa ser resolvido. Em termos práticos, o impacto do MySQL Fabric caindo irá variar com o seu caso de uso. Se você estiver usando apenas o utilitário mysqlfabric para gerenciar servidores, nada acontecerá enquanto todos os servidores em um grupo continuarem a funcionar. Se, no entanto, estiver utilizando um dos conectores especiais para acessar o grupo, a aplicação ficará indisponível. O MySQL Fabric poderia permitir que você configurasse vários Nodes Fabric e fazer com que eles monitorem uns aos outros e promovam um novo ativo se necessário.

Seguindo esses passos, podemos criar facilmente um grupo para uma solução de replicação do MySQL (master/slave). Dessa forma, o Fabric nos auxilia no gerenciamento do cluster e nos permite uma facilidade enorme para administrar e gerenciar problemas. Isso é muito recomendado para ambientes produtivos onde não queremos ter indisponibilidade nem perda de dados.

O MySQL Fabric é uma feature que já está embutida no preço de licenciamento, caso você utilize o MySQL Enterprise. Então esse é mais um motivo para não deixar de usar e testar suas funcionalidades, lembrando que neste artigo, abordamos apenas a parte de alta disponibilidade do MySQL Fabric.

O Lab montado nesse exemplo está disponível para download. O arquivo Readme possui todas as instruções de como configurar o ambiente virtual para testar o MySQL Fabric. Para isso você precisará apenas de uma conexão com a internet e praticamente um comando irá fazer o download de todos os componentes necessários pra a instalação, inclusive a instalação do sistema operacional, dependências, pacotes e configurações.