MariaDB
 sql >> Base de Dados >  >> RDS >> MariaDB

Como migrar o banco de dados WHMCS para o MariaDB Galera Cluster


WHMCS é uma solução completa de gerenciamento de clientes, cobrança e suporte para empresas de hospedagem na web. É um dos líderes no mundo da automação de hospedagem para ser usado junto com o próprio painel de controle de hospedagem. O WHMCS é executado em uma pilha LAMP, com MySQL/MariaDB como provedor de banco de dados. Comumente, o WHMCS é instalado como uma instância autônoma (aplicativo e banco de dados) de forma independente, seguindo o guia de instalação do WHMCS ou por meio de ferramentas de instalação de software, como cPanel Site Software ou Softaculous. O banco de dados pode ficar altamente disponível migrando para um Galera Cluster de 3 nós.

Nesta postagem do blog, mostraremos como migrar o banco de dados WHMCS de um servidor MySQL autônomo (fornecido pelo próprio servidor WHM/cPanel) para um MariaDB Galera Cluster externo de três nós para melhorar a disponibilidade do banco de dados. O próprio aplicativo WHMCS será mantido em execução no mesmo servidor cPanel. Também daremos algumas dicas de ajuste para otimizar o desempenho.

Implantando o cluster de banco de dados

  1. Instale ClusterControl:
    $ whoami
    root
    $ wget https://severalnines.com/downloads/cmon/install-cc
    $ chmod 755 install-cc
    $ ./install-cc
    Siga as instruções em conformidade até que a instalação seja concluída. Em seguida, acesse o http://192.168.55.50/clustercontrol (192.168.55.50 sendo o endereço IP do host ClusterControl) e registre um usuário superadministrador com senha e outros detalhes necessários.
  2. Configure o SSH sem senha do ClusterControl para todos os nós do banco de dados:
    $ whoami
    root
    $ ssh-keygen -t rsa # Press enter on all prompts
    $ ssh-copy-id 192.168.55.51
    $ ssh-copy-id 192.168.55.52
    $ ssh-copy-id 192.168.55.53
  3. Configure a implantação do banco de dados para nosso cluster MariaDB Galera de 3 nós. Vamos usar a última versão suportada do MariaDB 10.3: Certifique-se de obter todas as verificações verdes após pressionar 'Enter' ao adicionar os detalhes do nó. Aguarde até que o trabalho de implantação seja concluído e você verá que o cluster de banco de dados está listado no ClusterControl.
  4. Implante um nó ProxySQL (nós vamos co-localizá-lo com o nó ClusterControl) acessando Gerenciar -> Balanceador de carga -> ProxySQL -> Implantar ProxySQL . Especifique os seguintes detalhes obrigatórios: Em "Adicionar usuário do banco de dados", você pode pedir ao ClusterControl para criar um novo usuário ProxySQL e MySQL conforme ele configura , assim colocamos o usuário como "portal_whmcs", atribuído com TODOS OS PRIVILÉGIOS no banco de dados "portal_whmcs.*". Em seguida, marque todas as caixas para "Incluir" e, finalmente, escolha "falso" para "Você está usando transações implícitas?".

Depois que a implantação for concluída, você deverá ver algo assim na visualização Topologia:
Recursos relacionados O principal provedor de hospedagem da Austrália aproveita o ClusterControl para oferecer experiência de classe mundial aos usuários Banco de dados de balanceamento de carga para MySQL e MariaDB com ProxySQL - Tutorial Alta disponibilidade MySQL no cPanel com Galera Cluster
Nossa implantação de banco de dados está concluída. Lembre-se de que não abordamos a redundância da camada do balanceador de carga nesta postagem do blog. Você pode conseguir isso adicionando um balanceador de carga secundário e encadeando-o com Keepalived. Para saber mais sobre isso, confira os Tutoriais do ProxySQL no capítulo "4.2. Alta disponibilidade para ProxySQL".

Instalação WHMCS


Se você já tem o WHMCS instalado e em execução, pode pular esta etapa.

Observe que o WHMCS requer uma licença válida que você deve comprar antecipadamente para usar o software. Eles não fornecem uma licença de avaliação gratuita, mas oferecem uma garantia de reembolso de 30 dias sem perguntas, o que significa que você sempre pode cancelar a assinatura antes que a oferta expire sem ser cobrado.

Para simplificar o processo de instalação, usaremos o cPanel Site Software (você pode optar pela instalação manual do WHMCS) em um de nossos subdomínios, selfportal.mytest.io. Após criar a conta no WHM, acesse cPanel> Software> Site Software> WHMCS e instale o aplicativo da web. Faça login como usuário administrador e ative a licença para começar a usar o aplicativo.

Neste ponto, nossa instância WHMCS está sendo executada como uma configuração autônoma, conectando-se ao servidor MySQL local.
ClusterControlSingle Console para toda a sua infraestrutura de banco de dados Descubra o que mais há de novo no ClusterControlInstale o ClusterControl GRATUITAMENTE

Migrando o banco de dados WHMCS para o MariaDB Galera Cluster


A execução do WHMCS em um servidor MySQL autônomo expõe o aplicativo ao ponto único de falha (SPOF) do ponto de vista do banco de dados. O MariaDB Galera Cluster fornece redundância para a camada de dados com recursos de cluster integrados e suporte para arquitetura multimestre. Combine isso com um balanceador de carga de banco de dados, por exemplo, ProxySQL, e podemos melhorar a disponibilidade do banco de dados WHMCS com alterações mínimas no próprio aplicativo.

No entanto, existem várias práticas recomendadas que o WHMCS (ou outros aplicativos) devem seguir para trabalhar com eficiência no Galera Cluster, especialmente:
  • Todas as tabelas devem ser executadas no mecanismo de armazenamento InnoDB/XtraDB.
  • Todas as tabelas devem ter uma chave primária definida (a chave primária de várias colunas é suportada, a chave única não conta).

Dependendo da versão instalada, em nossa instalação do ambiente de teste (cPanel/WHM 11.78.0.23, WHMCS 7.6.0 via Site Software), os dois pontos acima não atenderam ao requisito. A configuração padrão do cPanel/WHM MySQL vem com a seguinte linha dentro de /etc/my.cnf:
default-storage-engine=MyISAM

O acima faria com que tabelas adicionais gerenciadas por Módulos Addon WHMCS fossem criadas no formato de mecanismo de armazenamento MyISAM se esses módulos estivessem habilitados. Aqui está a saída do mecanismo de armazenamento depois de habilitar 2 módulos (Novos TLDs e Quadro de Avisos da Equipe):
MariaDB> SELECT tables.table_schema, tables.table_name, tables.engine FROM information_schema.tables WHERE tables.table_schema='whmcsdata_whmcs' and tables.engine <> 'InnoDB';
+-----------------+----------------------+--------+
| table_schema    | table_name           | engine |
+-----------------+----------------------+--------+
| whmcsdata_whmcs | mod_enomnewtlds      | MyISAM |
| whmcsdata_whmcs | mod_enomnewtlds_cron | MyISAM |
| whmcsdata_whmcs | mod_staffboard       | MyISAM |
+-----------------+----------------------+--------+

O suporte ao MyISAM é experimental no Galera, o que significa que você não deve executá-lo em produção. Em alguns casos piores, pode comprometer a consistência dos dados e causar falhas na replicação do conjunto de gravações devido à sua natureza não transacional.

Outro ponto importante é que toda tabela deve ter uma chave primária definida. Dependendo do procedimento de instalação do WHMCS que você executou (como para nós, usamos o cPanel Site Software para instalar o WHMCS), algumas das tabelas criadas pelo instalador não vêm com chave primária definida, conforme mostrado na saída a seguir:
MariaDB [information_schema]> SELECT TABLES.table_schema, TABLES.table_name FROM TABLES LEFT JOIN KEY_COLUMN_USAGE AS c ON (TABLES.TABLE_NAME = c.TABLE_NAME AND c.CONSTRAINT_SCHEMA = TABLES.TABLE_SCHEMA AND c.constraint_name = 'PRIMARY' ) WHERE TABLES.table_schema <> 'information_schema' AND TABLES.table_schema <> 'performance_schema' AND TABLES.table_schema <> 'mysql' and TABLES.table_schema <> 'sys' AND c.constraint_name IS NULL;
+-----------------+------------------------------------+
| table_schema    | table_name                         |
+-----------------+------------------------------------+
| whmcsdata_whmcs | mod_invoicedata                    |
| whmcsdata_whmcs | tbladminperms                      |
| whmcsdata_whmcs | tblaffiliates                      |
| whmcsdata_whmcs | tblconfiguration                   |
| whmcsdata_whmcs | tblknowledgebaselinks              |
| whmcsdata_whmcs | tbloauthserver_access_token_scopes |
| whmcsdata_whmcs | tbloauthserver_authcode_scopes     |
| whmcsdata_whmcs | tbloauthserver_client_scopes       |
| whmcsdata_whmcs | tbloauthserver_user_authz_scopes   |
| whmcsdata_whmcs | tblpaymentgateways                 |
| whmcsdata_whmcs | tblproductconfiglinks              |
| whmcsdata_whmcs | tblservergroupsrel                 |
+-----------------+------------------------------------+

Como uma nota lateral, o Galera ainda permitiria a existência de tabelas sem chave primária. No entanto, as operações DELETE não são suportadas nessas tabelas, além de expor você a problemas muito maiores, como falha do nó, degradação do desempenho da certificação do conjunto de gravação ou linhas podem aparecer em uma ordem diferente em nós diferentes.

Para superar isso, nosso plano de migração deve incluir a etapa adicional para corrigir o mecanismo de armazenamento e a estrutura do esquema, conforme mostrado na próxima seção.

Plano de migração


Devido às restrições explicadas no capítulo anterior, nosso plano de migração deve ser algo assim:
  1. Ativar o modo de manutenção WHMCS
  2. Faça backups do banco de dados whmcs usando o backup lógico
  3. Modifique os arquivos de despejo para atender aos requisitos do Galera (mecanismo de armazenamento de conversão)
  4. Chame um dos nós do Galera e deixe os nós restantes serem desligados
  5. Restaurar no nó Galera escolhido
  6. Corrija a estrutura do esquema para atender aos requisitos do Galera (chaves primárias ausentes)
  7. Inicialize o cluster a partir do nó Galera escolhido
  8. Inicie o segundo nó e deixe-o sincronizar
  9. Inicie o terceiro nó e deixe-o sincronizar
  10. Altere o banco de dados apontando para o endpoint apropriado
  11. Desativar o modo de manutenção WHMCS

A nova arquitetura pode ser ilustrada como abaixo:

Nosso nome de banco de dados WHMCS no servidor cPanel é "whmcsdata_whmcs" e vamos migrar esse banco de dados para um cluster MariaDB Galera externo de três nós implantado pelo ClusterControl. No topo do servidor de banco de dados, temos um ProxySQL (co-locate with ClusterControl) em execução para atuar como o balanceador de carga MariaDB, fornecendo o endpoint único para nossa instância WHMCS. O nome do banco de dados no cluster será alterado para "portal_whmcs", para que possamos distingui-lo facilmente.

Em primeiro lugar, habilite o modo de manutenção em todo o site acessando WHMCS> Configuração> Configurações gerais> Geral> Modo de manutenção> Marque para habilitar - impede o acesso à área do cliente quando habilitado . Isso garantirá que não haverá atividade do usuário final durante a operação de backup do banco de dados.

Como temos que fazer pequenas modificações na estrutura do esquema para encaixar bem no Galera, é uma boa ideia criar dois arquivos de despejo separados. Um apenas com o esquema e outro apenas para dados. No servidor WHM, execute o seguinte comando como root:
$ mysqldump --no-data -uroot whmcsdata_whmcs > whmcsdata_whmcs_schema.sql
$ mysqldump --no-create-info -uroot whmcsdata_whmcs > whmcsdata_whmcs_data.sql

Então, temos que substituir todas as ocorrências MyISAM no arquivo de despejo de esquema por 'InnoDB':
$ sed -i 's/MyISAM/InnoDB/g' whmcsdata_whmcs_schema.sql

Verifique se não temos mais linhas MyISAM no arquivo de despejo (não deve retornar nada):
$ grep -i 'myisam' whmcsdata_whmcs_schema.sql

Transfira os arquivos de despejo do servidor WHM para mariadb1 (192.168.55.51):
$ scp whmcsdata_whmcs_* 192.168.55.51:~

Crie o banco de dados MySQL. No ClusterControl, vá para Gerenciar -> Esquemas e usuários -> Criar banco de dados e especifique o nome do banco de dados. Aqui usamos um nome de banco de dados diferente chamado "portal_whmcs". Caso contrário, você pode criar manualmente o banco de dados com o seguinte comando:
$ mysql -uroot -p 
MariaDB> CREATE DATABASE 'portal_whmcs';

Crie um usuário MySQL para este banco de dados com seus privilégios. No ClusterControl, vá para Gerenciar -> Esquemas e usuários -> Usuários -> Criar novo usuário e especifique o seguinte:

Caso você opte por criar o usuário MySQL manualmente, execute as seguintes instruções:
$ mysql -uroot -p 
MariaDB> CREATE USER 'portal_whmcs'@'%' IDENTIFIED BY 'ghU51CnPzI9z';
MariaDB> GRANT ALL PRIVILEGES ON portal_whmcs.* TO [email protected]'%';

Observe que o usuário do banco de dados criado deve ser importado para o ProxySQL, para permitir que o aplicativo WHMCS seja autenticado no balanceador de carga. Vá para Nós -> escolha o nó ProxySQL -> Usuários -> Importar usuários e selecione "portal_whmcs"@"%", conforme mostrado na captura de tela a seguir:

Na próxima janela (Configurações do usuário), especifique Hostgroup 10 como o hostgroup padrão:

Agora a etapa de preparação da restauração está completa.

No Galera, restaurar um grande banco de dados via mysqldump em um cluster de nó único é mais eficiente e isso melhora significativamente o tempo de restauração. Caso contrário, cada nó no cluster teria que certificar cada instrução da entrada mysqldump, o que levaria mais tempo para ser concluído.

Como já temos um MariaDB Galera Cluster de três nós em execução, vamos interromper o serviço MySQL em mariadb2 e mariadb3, um nó por vez para uma redução gradual. Para encerrar os nós do banco de dados, do ClusterControl, basta ir para Nodes -> Node Actions -> Stop Node -> Proceed . Aqui está o que você veria no painel do ClusterControl, onde o tamanho do cluster é 1 e o status do db1 é Sincronizado e Primário:

Em seguida, em mariadb1 (192.168.55.51), restaure o esquema e os dados de acordo:
$ mysql -uportal_whmcs -p portal_whmcs < whmcsdata_whmcs_schema.sql
$ mysql -uportal_whmcs -p portal_whmcs < whmcsdata_whmcs_data.sql

Uma vez importado, temos que corrigir a estrutura da tabela para adicionar a coluna "id" necessária (exceto para a tabela "tblaffiliates"), bem como adicionar a chave primária em todas as tabelas que estão faltando:
$ mysql -uportal_whmcs -p
MariaDB> USE portal_whmcs;
MariaDB [portal_whmcs]> ALTER TABLE `tblaffiliates` ADD PRIMARY KEY (id);
MariaDB [portal_whmcs]> ALTER TABLE `mod_invoicedata` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbladminperms` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblconfiguration` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblknowledgebaselinks` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_access_token_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_authcode_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_client_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_user_authz_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblpaymentgateways` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblproductconfiglinks` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblservergroupsrel` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;

Ou podemos traduzir as instruções repetidas acima usando um loop em um script bash:
#!/bin/bash

db_user='portal_whmcs'
db_pass='ghU51CnPzI9z'
db_whmcs='portal_whmcs'
tables=$(mysql -u${db_user} "-p${db_pass}"  information_schema -A -Bse "SELECT TABLES.table_name FROM TABLES LEFT JOIN KEY_COLUMN_USAGE AS c ON (TABLES.TABLE_NAME = c.TABLE_NAME AND c.CONSTRAINT_SCHEMA = TABLES.TABLE_SCHEMA AND c.constraint_name = 'PRIMARY' ) WHERE TABLES.table_schema <> 'information_schema' AND TABLES.table_schema <> 'performance_schema' AND TABLES.table_schema <> 'mysql' and TABLES.table_schema <> 'sys' AND c.constraint_name IS NULL;")
mysql_exec="mysql -u${db_user} -p${db_pass} $db_whmcs -e"

for table in $tables
do
        if [ "${table}" = "tblaffiliates" ]
        then
                $mysql_exec "ALTER TABLE ${table} ADD PRIMARY KEY (id)";
        else
                $mysql_exec "ALTER TABLE ${table} ADD id INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST";
        fi
done

Neste ponto, é seguro iniciar os nós restantes para sincronizar com mariadb1. Comece com mariadb2 acessando Nodes -> pick db2 -> Node Actions -> Start Node . Monitore o andamento da tarefa e certifique-se de que o mariadb2 esteja no estado Sincronizado e Primário (monitorize a página Visão geral para obter detalhes) antes de iniciar o mariadb3.

Por fim, altere o banco de dados apontando para o host ProxySQL na porta 6033 dentro do arquivo de configuração WHMCS, pois no nosso caso está localizado em /home/whmcsdata/public_html/configuration.php:
$ vim configuration.php
<?php
$license = 'WHMCS-XXXXXXXXXXXXXXXXXXXX';
$templates_compiledir = 'templates_c';
$mysql_charset = 'utf8';
$cc_encryption_hash = 'gLg4oxuOWsp4bMleNGJ--------30IGPnsCS49jzfrKjQpwaN';
$db_host = 192.168.55.50;
$db_port = '6033';
$db_username = 'portal_whmcs';
$db_password = 'ghU51CnPzI9z';
$db_name = 'portal_whmcs';

$customadminpath = 'admin2d27';

Não se esqueça de desabilitar o modo de manutenção WHMCS acessando WHMCS> Configuração> Configurações gerais> Geral> Modo de manutenção> desmarque "Marcar para habilitar - impede o acesso à área do cliente quando habilitado" . Nosso exercício de migração de banco de dados está concluído.

Teste e ajuste


Você pode verificar isso observando as entradas de consulta do ProxySQL em Nós -> ProxySQL -> Principais consultas :

Para as consultas somente leitura mais repetidas (você pode classificá-las por Contagem de estrelas), você pode armazená-las em cache para melhorar o tempo de resposta e reduzir o número de acessos aos servidores de back-end. Basta rolar para qualquer consulta e clicar em Consulta de cache e o seguinte pop-up aparecerá:

O que você precisa fazer é escolher apenas o hostgroup de destino e clicar em "Add Rule". Você pode então verificar se a consulta em cache foi atingida na guia "Regras":

A partir da própria regra de consulta, podemos dizer que as leituras (todos SELECT exceto SELECT .. FOR UPDATE) são encaminhados para o hostgroup 20 onde as conexões são distribuídas para todos os nós enquanto as gravações (exceto SELECT) são encaminhadas para o hostgroup 10, onde as conexões são encaminhados para apenas um nó Galera. Essa configuração minimiza o risco de deadlocks que podem ser causados ​​por uma configuração de vários mestres, o que melhora o desempenho da replicação como um todo.

Por enquanto é isso. Boa aglomeração!