[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 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 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]
