admin 
[ad_1]
O MySQL Operator for Kubernetes da Oracle é uma maneira conveniente de automatizar o provisionamento de banco de dados MySQL em seu cluster. Um dos principais recursos do operador é o suporte de backup integrado que aumenta sua resiliência. Os backups copiam seu banco de dados para armazenamento externo em uma programação recorrente.
Este artigo orientará você na configuração de backups em 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 dentro de seu cluster.
Preparando 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: "P@$$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 agendamento de backup que define quando o backup será executado.
- UMA perfil de backup que configura o local de armazenamento e as opções de exportação do MySQL.
Agendas e perfis são criados independentemente um do outro. Isso permite que você execute vários backups em agendamentos diferentes usando o mesmo perfil.
Cada agendamento e perfil está associado a um cluster de banco de dados específico. Eles são criados como recursos aninhados em seu 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
o backupProfileName campo referencia o perfil de backup a ser usado. Você criará isso na próxima etapa.
Criando 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 carregar 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 em seu próprio acesso S3 e chaves secretas 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 bucket do S3 para o qual carregar seus backups.prefix– Defina isso para aplicar um prefixo aos seus arquivos carregados, como/my-app/mysql. O prefixo permite criar árvores de pastas em seu bucket.endpoint– Defina isso para o URL do seu provedor de serviços quando estiver usando armazenamento compatível com S3 de terceiros. Você pode omitir esse campo se estiver usando 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 definido paradefaultno 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 ativará backups de banco de dados de hora em hora para sua conta do S3.
Armazenamento OCI
O operador oferece suporte ao armazenamento de objetos Oracle Cloud Infrastructure (OCI) como uma alternativa ao S3. Está configurado de forma 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 estrofe:
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 e prefix campos para definir o local de upload em sua conta OCI. o credentials O campo deve fazer referência 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 dentro de seu cluster Kubernetes. No entanto, pode ser útil para backups pontuais e fins de teste.
Primeiro, crie um volume persistente e a declaração que o acompanha:
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 exemplo 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 declaração de volume persistente criada anteriormente é 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’s dumpInstance Utilitário. Esse padrão é exportar um dump completo do seu servidor. O formato grava a estrutura e os arquivos de dados em partes para cada tabela. A saída é compactada com zstd.
Você pode passar as opções para dumpInstance através do 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, criando 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.
Restaurando 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 em seu cluster 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 estrofe, use o dump.storage objeto para fazer referência 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 desse arquivo YAML criará um novo cluster de banco de dados inicializado com o dumpInstance saída no bucket S3 especificado. o prefix O campo deve conter o caminho completo para os arquivos de despejo no bucket. Os backups criados pelo operador serão armazenados automaticamente em pastas com carimbo de data/hora; você precisará indicar qual 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 do operador para armazenar dumps de banco de dados completos em um volume persistente ou bucket de armazenamento de objetos.
Usar o Kubernetes para dimensionar horizontalmente o MySQL adiciona resiliência, mas os backups externos ainda são vitais caso o 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]
Source link
