Como fazer backup de clusters de operador MySQL do Kubernetes

November 11, 2022

278

[ad_1]

O MySQL Operator for Kubernetes da Oracle é uma maneira conveniente de automatizar o provisionamento de bancos de dados MySQL em seu cluster. Uma das principais características do operador é o suporte integrado de backup sem toque que aumenta sua capacidade de recuperação. Os backups copiam seu banco de dados para armazenamento externo em uma programação recorrente.

Este artigo orientará você na configuração de backups para um serviço de armazenamento de objetos compatível com o Amazon S3. Você também verá como armazenar backups no armazenamento Oracle Cloud Infrastructure (OCI) ou em volumes persistentes locais em seu cluster.

Preparar um cluster de banco de dados

Instale o operador MySQL em seu cluster Kubernetes e crie uma instância de banco de dados simples para fins de teste. Copie o YAML abaixo e salve-o em mysql.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: mysql-root-user
stringData:
  rootHost: "%"
  rootUser: "root"
  rootPassword: "[email protected]$$w0rd"
 
---

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1

Use Kubectl para aplicar o manifesto:

$ kubectl apply -f mysql.yaml

Aguarde alguns minutos enquanto o operador MySQL provisiona seus pods. Use Kubectl’s get pods Comando para verificar o progresso. Você deverá ver quatro pods em execução: uma instância do roteador MySQL e três réplicas do servidor MySQL.

$ kubectl get pods
NAME                                    READY   STATUS    RESTARTS   AGE
mysql-cluster-0                         2/2     Running   0          2m
mysql-cluster-1                         2/2     Running   0          2m
mysql-cluster-2                         2/2     Running   0          2m
mysql-cluster-router-6b68f9b5cb-wbqm5   1/1     Running   0          2m

Definindo um agendamento de backup

O operador MySQL requer dois componentes para criar um backup com sucesso:

UMA programa de backup que define quando o backup será executado.
UMA perfil de backup que configura o local de armazenamento do MySQL e as opções de exportação.

Agendas e perfis são criados independentemente um do outro. Isso permite que você execute vários backups em momentos diferentes usando o mesmo perfil.

Cada programa e perfil está associado a um cluster de banco de dados específico. Eles são criados como recursos aninhados dentro de seus InnoDBCluster objetos. Cada banco de dados que você cria com o operador MySQL precisa de sua própria configuração de backup.

Os agendamentos de backup são definidos pelo seu banco de dados. spec.backupSchedules campo. Cada item requer um schedule campo que especifica quando executar o backup usando uma expressão cron. Aqui está um exemplo que inicia um backup a cada hora:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
   backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup

a backupProfileName O campo refere-se ao perfil de backup a ser usado. Você irá criá-lo na próxima etapa.

Criar perfis de backup

Os perfis são definidos no spec.backupProfiles campo. Cada perfil deve ter um name e um dumpInstance propriedade que configura a operação de backup.

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          # ...

O armazenamento de backup é configurado por perfil no dumpInstance.storage campo. As propriedades que você precisa fornecer dependem do tipo de armazenamento que você está usando.

Armazenamento S3

O operador MySQL pode fazer upload de seus backups diretamente para provedores de armazenamento de objetos compatíveis com S3. Para usar esse método, você deve criar um segredo do Kubernetes que contenha um aws Arquivo de configuração CLI com suas credenciais.

Adicione o seguinte conteúdo a s3-secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: s3-secret
stringData:
  credentials: |
    [default]
    aws_access_key_id = YOUR_S3_ACCESS_KEY
    aws_secret_access_key = YOUR_S3_SECRET_KEY

Substitua seu próprio segredo e as chaves de acesso do S3 e use o Kubectl para criar o segredo:

$ kubectl apply -f s3-secret.yaml
secret/s3-secret created

Em seguida, adicione os seguintes campos ao seu perfil de backup storage.s3 seção:

bucketName – O nome do repositório S3 para carregar seus backups.
prefix – Defina isso para aplicar um prefixo aos seus arquivos enviados, como /my-app/mysql. O prefixo permite que você crie árvores de pastas em seu repositório.
endpoint – Defina o URL do seu provedor de serviços ao usar armazenamento compatível com S3 de terceiros. Você pode omitir esse campo se usar o Amazon S3.
config – O nome do segredo que contém seu arquivo de credenciais.
profile – O nome do perfil de configuração a ser usado no arquivo de credenciais. Isso foi configurado para default no exemplo acima.

Aqui está um exemplo completo:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          s3:
            bucketName: backups
            prefix: /mysql
            config: s3-secret
            profile: default

A aplicação desse manifesto acionará backups de banco de dados de hora em hora para sua conta do S3.

Armazenamento ICO

O operador oferece suporte ao armazenamento de objetos Oracle Cloud Infrastructure (OCI) como uma alternativa ao S3. Ele é configurado de maneira semelhante. Primeiro, crie um segredo para suas credenciais OCI:

apiVersion: v1
kind: Secret
metadata:
  name: oci-secret
stringData:
  fingerprint: YOUR_OCI_FINGERPRINT
  passphrase: YOUR_OCI_PASSPHRASE
  privatekey: YOUR_OCI_RSA_PRIVATE_KEY
  region: us-ashburn-1
  tenancy: YOUR_OCI_TENANCY
  user: YOUR_OCI_USER

Em seguida, configure o perfil de backup com um storage.ociObjectStorage quarto:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          ociObjectStorage:
            bucketName: backups
            prefix: /mysql
            credentials: oci-secret

Modifique o bucketName S prefix campos para definir o local de upload em sua conta OCI. a credentials O campo deve se referir ao segredo que contém suas credenciais OCI.

Armazenamento de volume do Kubernetes

Os volumes persistentes locais são uma terceira opção de armazenamento. Isso é menos robusto, pois seus dados de backup ainda residirão em seu cluster Kubernetes. No entanto, pode ser útil para backups únicos e fins de teste.

Primeiro, crie um volume persistente e seu texto explicativo:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: backup-pv
spec:
  storageClassName: standard
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /tmp
 
---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: backup-pvc
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Este manifesto de amostra não é adequado para uso em produção. Você deve selecionar uma classe de armazenamento e um modo de montagem de volume apropriados para sua distribuição do Kubernetes.

Em seguida, configure seu perfil de backup para usar seu volume persistente adicionando um storage.persistentVolumeClaim campo:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          persistentVolumeClaim:
            claimName: backup-pvc

A reivindicação de volume persistente criada acima é referenciada pelo claimName campo. O operador MySQL agora depositará dados de backup no volume.

Configurando opções de backup

Os backups são criados usando o MySQL Shell dumpInstance Utilitário. Por padrão, ele exporta um dump completo do seu servidor. O formato grava a estrutura e os arquivos de dados fragmentados para cada tabela. A saída é compactada com zstd.

Você pode passar as opções dumpInstance Através de dumpOptions campo em um perfil de backup do operador MySQL:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  # ...
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        dumpOptions:
          chunking: false
          compression: gzip
        storage:
          # ...

Este exemplo desativa a saída em partes, cria um arquivo de dados por tabela e alterna para compactação gzip em vez de zstd. Você pode encontrar uma referência completa para as opções disponíveis na documentação do MySQL.

Restaurar um backup

O operador MySQL pode inicializar novos clusters de banco de dados usando arquivos criados anteriormente de dumpInstance. Isso permite que você restaure seus backups diretamente no cluster do Kubernetes. É útil em situações de recuperação ou quando você está migrando um banco de dados existente para o Kubernetes.

A inicialização do banco de dados é controlada pelo spec.initDB campo em seu InnoDBCluster objetos. Dentro desta sala, use o dump.storage objeto para se referir ao local de backup que você usou anteriormente. O formato corresponde ao equivalente dumpInstance.storage campo em objetos de perfil de backup.

apiVersion: v1
kind: Secret
metadata:
  name: s3-secret
stringData:
  credentials: |
    [default]
    aws_access_key_id = YOUR_S3_ACCESS_KEY
    aws_secret_access_key = YOUR_S3_SECRET_KEY

---

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster-recovered
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  initDB:
    dump:
      storage:
        s3:
          bucketName: backups
          prefix: /mysql/mysql20221031220000
          config: s3-secret
          profile: default

A aplicação deste arquivo YAML criará um novo cluster de banco de dados que é inicializado com o dumpInstance saída para o bucket S3 especificado. a prefix O campo deve conter o caminho completo para os arquivos de despejo no repositório. Os backups criados pelo operador serão armazenados automaticamente em pastas com carimbo de data/hora; você precisará indicar qual deles recuperar definindo o prefixo. Se você estiver restaurando de um volume persistente, use o path campo em vez de prefix.

Resumo

O operador MySQL da Oracle automatiza o gerenciamento de banco de dados MySQL nos clusters Kubernetes. Neste artigo, você aprendeu como configurar o sistema de backup da operadora para armazenar dumps de banco de dados completos em um volume persistente ou bucket de armazenamento de objetos.

Usar o Kubernetes para expandir o MySQL adiciona resiliência, mas os backups externos ainda são vitais caso seu cluster seja comprometido ou os dados sejam excluídos acidentalmente. O operador MySQL pode restaurar uma nova instância de banco de dados de seu backup, se necessário, simplificando o procedimento de recuperação pós-desastre.

[ad_2]

ssazglobe