Os backups são uma parte muito importante de suas operações de banco de dados, pois sua empresa deve estar protegida quando ocorrer uma catástrofe. Quando esse momento chegar (e chegará), seu Objetivo de Ponto de Recuperação (RPO) e Objetivo de Tempo de Recuperação (RTO) devem ser predefinidos, pois é a rapidez com que você pode se recuperar do incidente que ocorreu.
A maioria das organizações varia sua abordagem de backups, tentando ter uma combinação de backups de imagem de servidor (snapshots), backups lógicos e físicos. Esses backups são armazenados em vários locais, para evitar desastres locais ou regionais. Isso também significa que os dados podem ser restaurados no menor tempo possível, evitando grandes paralisações que podem impactar os negócios da sua empresa.
Hospedar seu banco de dados com um provedor de nuvem, como o Microsoft Azure (que discutiremos neste blog), não é exceção, você ainda precisa preparar e definir sua política de recuperação de desastres.
Como outras ofertas de nuvem pública, o Microsoft Azure (Azure) oferece uma abordagem para backups que é prática, econômica e projetada para fornecer opções de recuperação. As soluções de backup do Microsoft Azure permitem configurar e operar e são facilmente manipuladas usando o Backup do Azure ou por meio do Restore Services Vault (se você estiver operando seu banco de dados usando máquinas virtuais).
Se você deseja um banco de dados gerenciado na nuvem, o Azure oferece o Banco de Dados do Azure para MySQL. Isso deve ser usado apenas se você não quiser operar e gerenciar o banco de dados MySQL por conta própria. Este serviço oferece uma solução rica para backup que permite criar um backup de sua instância de banco de dados, seja de uma região local ou por meio de uma localização georredundante. Isso pode ser útil para recuperação de dados. Você pode até conseguir restaurar um nó a partir de um período de tempo específico, o que é útil para obter uma recuperação pontual. Isso pode ser feito com apenas um clique.
Neste blog, abordaremos todos esses cenários de backup e restauração usando um banco de dados MySQL na nuvem do Microsoft Azure.
Realizando backups em uma máquina virtual no Azure
Infelizmente, o Microsoft Azure não oferece uma solução de tipo de backup específica do MySQL (por exemplo, MySQL Enterprise Backup, Percona XtraBackup ou MariaDB's Mariabackup).
Ao criar sua Máquina Virtual (usando o portal), você pode configurar um processo para fazer backup de sua VM usando o cofre dos Serviços de Restauração. Isso irá protegê-lo de qualquer incidente, desastre ou catástrofe e os dados armazenados são criptografados por padrão. Adicionar criptografia é opcional e, embora recomendado pelo Azure, tem um preço. Você pode dar uma olhada na página de preços de backup do Azure para obter mais detalhes.
Para criar e configurar um backup, vá para o painel esquerdo e clique em Todos os Recursos → Computação → Máquina Virtual. Agora defina os parâmetros necessários nos campos de texto. Quando estiver nessa página, vá para a guia Gerenciamento e role para baixo abaixo. Você poderá ver como configurar ou criar o backup. Veja a imagem abaixo:
Em seguida, configure sua política de backup com base em seus requisitos de backup. Basta clicar no link Criar novo no campo de texto Política de backup para criar uma nova política. Ver abaixo:
Você pode configurar sua política de backup com retenção semanal, mensal e anual .
Depois de configurar seu backup, você pode verificar se tem um backup ativado nessa máquina virtual específica que acabou de criar. Veja a imagem abaixo:
Restaure e recupere sua máquina virtual no Azure
Projetar sua recuperação no Azure depende de que tipo de política e requisitos seu aplicativo exige. Também depende se o RTO e o RPO devem ser baixos ou invisíveis para o usuário em caso de incidente ou durante a manutenção. Você pode configurar sua máquina virtual com um conjunto de disponibilidade ou em uma zona de disponibilidade diferente para obter uma taxa de recuperação mais alta.
Você também pode configurar uma recuperação de desastres para sua VM replicar suas máquinas virtuais para outra região do Azure para necessidades de continuidade de negócios e recuperação de desastres. No entanto, isso pode não ser uma boa ideia para sua organização, pois tem um custo alto. Se estiver em vigor, o Azure oferece a opção de restaurar ou criar uma máquina virtual a partir do backup criado.
Por exemplo, durante a criação de sua máquina virtual, você pode ir para a guia Discos e depois para Discos de Dados. Você pode criar ou anexar um disco existente onde você pode anexar o instantâneo disponível. Veja a captura de tela abaixo para a qual você poderá escolher entre instantâneo ou blob de armazenamento:
Você também pode restaurar em um momento específico, como na captura de tela abaixo de:
A restauração no Azure pode ser feita de maneiras diferentes, mas usa a mesma recursos que você já criou.
Por exemplo, se você criou um instantâneo ou uma imagem de disco armazenada no blob de armazenamento do Azure, se você criar uma nova VM, poderá usar esse recurso desde que seja compatível e esteja disponível para uso. Além disso, você pode até fazer alguma recuperação de arquivos, além de restaurar uma VM, como na captura de tela abaixo:
Durante a recuperação de arquivos, você pode escolher um ponto de recuperação específico , além de baixar um script para navegar e recuperar arquivos. Isso é muito útil quando você precisa apenas de um arquivo específico, mas não de todo o sistema ou volume de disco.
A restauração do backup em uma VM existente leva cerca de três minutos. No entanto, a restauração do backup para gerar uma nova VM leva doze minutos. Isso, no entanto, pode depender do tamanho de sua VM e da largura de banda de rede disponível no Azure. O bom é que, ao restaurar, ele fornecerá detalhes do que foi concluído e quanto tempo resta. Por exemplo, veja a captura de tela abaixo:
Backups do Banco de Dados do Azure para MySQL
O Banco de Dados do Azure para MySQL é um serviço de banco de dados totalmente gerenciado pelo Microsoft Azure. Este serviço oferece uma maneira muito flexível e conveniente de configurar seus recursos de backup e restauração.
Ao criar sua instância do servidor MySQL, você pode configurar a retenção de backup e criar suas opções de redundância de backup; seja localmente redundante (região local) ou georredundante (em uma região diferente). O Azure fornecerá a você o custo estimado que seria cobrado por um mês. Veja uma captura de tela de exemplo abaixo:
Lembre-se de que as opções de backup com redundância geográfica só estão disponíveis para uso geral e tipos de nós de computação com otimização de memória. Ele não está disponível em um nó de computação básico, mas você pode ter sua redundância na região local (ou seja, dentro das zonas de disponibilidade disponíveis).
Depois de ter uma configuração mestre, é fácil criar uma réplica acessando o Banco de Dados do Azure para servidores MySQL → Selecione sua instância MyQL → Replicação → e clique em Adicionar Réplica. Sua réplica pode ser usada como origem ou destino de restauração quando necessário.
Lembre-se de que, no Azure, quando você interrompe a replicação entre o mestre e uma réplica, isso será para sempre e irreversível, pois torna a réplica um servidor autônomo. Uma réplica criada usando o Microsoft Azure é idealmente uma instância gerenciada e você pode parar e iniciar os threads de replicação exatamente como faz em uma replicação mestre-escravo normal. Você pode fazer uma reinicialização e isso é tudo. Se você criou a réplica manualmente, restaurando a partir do mestre ou de um backup (por exemplo, por meio de uma recuperação pontual), poderá parar/iniciar os threads de replicação ou configurar um atraso escravo, se necessário.
Restaurando seu banco de dados do Azure para MySQL a partir de um backup
A restauração é muito fácil e rápida usando o portal do Azure. Você pode simplesmente pressionar o botão de restauração com o nó da instância do MySQL e seguir a interface do usuário, conforme mostrado na captura de tela abaixo:
Então você pode selecionar um período de tempo e criar/gerar uma nova instância com base neste backup capturado:
Depois de ter o nó disponível, este nó não será uma réplica de o mestre ainda. Você precisa configurar isso manualmente com etapas fáceis usando os procedimentos armazenados disponíveis:
CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', 3306, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');onde,
master_host:nome do host do servidor mestre
master_user:nome de usuário para o servidor mestre
master_password:senha para o servidor mestre
master_log_file:nome do arquivo de log binário da execução show master status
master_log_pos:posição do log binário da execução show master status
master_ssl_ca:contexto do certificado CA. Se não estiver usando SSL, passe uma string vazia.
Então, iniciar os threads do MySQL é o seguinte,
CALL mysql.az_replication_start;ou você pode interromper os threads de replicação da seguinte maneira,
CALL mysql.az_replication_stop;ou você pode remover o mestre como,
CALL mysql.az_replication_remove_master;ou ignore os erros de thread SQL como,
CALL mysql.az_replication_skip_counter;Como mencionado anteriormente, quando uma réplica é criada usando o Microsoft Azure no recurso Adicionar réplica em uma instância do MySQL, esses procedimentos armazenados específicos não estão disponíveis. No entanto, o procedimento mysql.az_replication_restart estará disponível, pois você não tem permissão para parar nem iniciar os threads de replicação de uma réplica gerenciada pelo Azure. Portanto, o exemplo que temos acima foi restaurado de um mestre que obtém a cópia completa do mestre, mas atua como um único nó e precisa de uma configuração manual para ser uma réplica de um mestre existente.
Além disso, quando você tiver uma réplica manual configurada, não poderá vê-la no Banco de Dados do Azure para servidores MySQL → Selecione sua instância MyQL → Replicação desde que você criou ou configurou a replicação manualmente .
Soluções alternativas de backup em nuvem e restauração
Existem certos cenários em que você deseja ter acesso total ao fazer um backup completo do seu banco de dados MySQL na nuvem. Para fazer isso, você pode criar seu próprio script ou usar tecnologias de código aberto. Com eles, você pode controlar como os dados em seu banco de dados MySQL devem ser copiados e precisamente como devem ser armazenados.
Você também pode aproveitar a Interface de Linha de Comando (CLI) do Azure para criar sua automação personalizada. Por exemplo, você pode criar um instantâneo usando o seguinte comando com a CLI do Azure:
az snapshot create -g myResourceGroup -source "$osDiskId" --name osDisk-backupou crie sua réplica do servidor MySQL com o seguinte comando:
az mysql server replica create --name mydemoreplicaserver --source-server mydemoserver --resource-group myresourcegroupComo alternativa, você também pode aproveitar uma ferramenta corporativa que apresenta maneiras de fazer backup com opções de restauração. O uso de tecnologias de código aberto ou ferramentas de terceiros requer conhecimento e habilidades para alavancar e criar sua própria implementação. Aqui está a lista que você pode aproveitar:
- Controle de cluster - Embora possamos ser um pouco tendenciosos, o ClusterControl oferece a capacidade de gerenciar backups físicos e lógicos de seu banco de dados MySQL usando tecnologias de código aberto testadas em batalha (PXB, Mariabackup e mydumper). Suporta bancos de dados MySQL, Percona, MariaDB, Galera. Você pode criar facilmente nossa política de backup e armazenar seus backups de banco de dados em qualquer nuvem (AWS, GCP ou Azure). Observe que a versão gratuita do ClusterControl não inclui os recursos de backup.
- Instantâneos de LVM - Você pode usar o LVM para tirar um instantâneo do seu volume lógico. Isso só se aplica à sua VM, pois requer acesso ao armazenamento em nível de bloco. O uso dessa ferramenta requer ressalvas, pois pode fazer com que o nó do banco de dados pare de responder enquanto o backup estiver em execução.
- Percona XtraBackup (PXB) - Uma tecnologia de código aberto da Percona. Com o PXB, você pode criar uma cópia de backup física do seu banco de dados MySQL. Você também pode fazer um hot-backup com PXB para o mecanismo de armazenamento InnoDB, mas é recomendável executá-lo em um servidor de banco de dados MySQL escravo ou não ocupado. Isso só se aplica à sua instância de VM, pois requer acesso binário ou de arquivo ao próprio servidor de banco de dados.
- Mariabackup - O mesmo com o PXB, é uma tecnologia de código aberto bifurcada do PXB, mas é mantida pelo MariaDB. Especificamente, se seu banco de dados estiver usando MariaDB, você deve usar Mariabackup para evitar problemas de incompatibilidade com tablespaces.
- mydumper/myloader - Essas ferramentas de backup criam cópias de backup lógicas do seu banco de dados MySQL. Você pode usar isso com seu banco de dados do Azure para MySQL, embora eu não tenha tentado o sucesso disso para seu procedimento de backup e restauração.
- mysqldump - é uma ferramenta de backup lógico que é muito útil quando você precisa fazer backup e despejar (ou restaurar) uma tabela ou banco de dados específico para outra instância. Isso é comumente usado por DBAs, mas você precisa prestar atenção ao espaço em seus discos, pois as cópias de backup lógicas são enormes em comparação com os backups físicos.
- Backup do MySQL Enterprise - Ele oferece backups on-line, quentes e sem bloqueio em várias plataformas, incluindo Linux, Windows, Mac e Solaris. Não é uma ferramenta de backup gratuita, mas oferece muitos recursos.
- rsync - É uma ferramenta de cópia de arquivos rápida e extraordinariamente versátil. Ele pode copiar localmente, de/para outro host em qualquer shell remoto ou de/para um daemon rsync remoto. Oferece um grande número de opções que controlam cada aspecto de seu comportamento e permitem uma especificação muito flexível do conjunto de arquivos a serem copiados. Principalmente em sistemas Linux, o rsync é instalado como parte do pacote do SO.
