O Serviço de banco de dados dos clientes Brasil (SmartERP, Smart eSocial e Sistemico Brasil) é de responsabilidade do time CLOUD DBA, ou seja, quaisquer manutenções na infra-estrutura dos bancos de produção, deve-se abrir um ticket para o time atuar.
Para os clientes do SmartERP que possuem ambientes de homologação (development), optamos em utilizar banco em conteiner na versão 12.6, ficando a cargo de todas as manutenções de infra-estrutura do time de SRE Protheus.
Caso haja a necessidade de realizar qualquer processo em dados ou tabelas do banco, deve-se primeiramente alinhar com o time de DBA da Engenharia Protheus.
Temos a possibilidade de acessar o database diretamente via psql, acessando os IPs disponibilizados no ambiente (helm file). Recomendo fazer este processo somente em último caso e que utilize o PSQL de dentro do pod do dbaccess.
Backup dos dados
Processo de backup dos ambiente ocorrerem todos os dias, a partir das 21 horas.
Para clientes do SmartERP, mantemos os dados salvos dentro do volume do cluster e copiamos as 06 horas da manhã para o serviço do rubrick (Job montado no namespace smartbackup). Para Ambientes do Sistêmico e Mercado Internacional, disponibilizamos um bucket na GCP para gravar os backups assim que concluídos. Este processo ocorre devido não existir integração entre o RUBRICK e os clusters do TESP02 e AWS. Para ambientes do Smart eSocial, todo a gestão de backup é efetuada pelo time Cloud DBA Oracle. Além destes dois buckets, mantemos também disponivel o bucket da AWS para tirarmos os backups, porém sem utilização no momento.
O backup dos ambientes POSTGRES é realizado com compactação (Z6), sem a vinculação de owner e no encode que o banco foi criado. Após conclusão do backup por parte do PSQL, fazemos uma nova compactação antes de enviar para o bucket configurado no helmfile do ambiente.
# backup custom com compressão media + gzip ao final do backup
pg_dump postgres://$user:$pass@$DATABASE_ENDPOINT:$DATABASE_PORT/$user -Fc -Z6 --no-owner --no-acl --verbose --encoding $DATABASE_CODEPAGE | gzip > /backup/$BUCKET_NAME/$NAMESPACE/$remote_last |
Restore de dados
O processo de restore de dados dos ambientes do SmartERP e Sistêmico é realizado de forma automática, ou seja, quando o sistema verificar que não existe o banco de dados, ele irá fazer a criação dos usuários, do database, instalar as extensões e restaurar o último backup existente no bucket (database_latest.dump.gz).
Via de regra, o ambiente sempre irá pegar o ultimo backup de produção e restaurar no ambiente que não foi encontrado o banco, não importando se for o ambiente de homologação, os jobs irão pegar o DUMP de produção e restaurar em homologação.
Caso seja necessário o restore da última posição do banco de homologação, deve-se proceder com o processo manual descrito abaixo. |
Para forçar o restore dentro do ambiente, temos duas opções:
Para realizar o restore automático, basta entrar de forma exclusiva no pod do dbaccess e dropar o database produção/homologação. Ao término do drop database, basta reiniciar o pod do dbaccess que o próprio componente irá se certificar de restaurar os dados com o último backup. |
Para realizar o restore manual: - Temos que baixar o backup dentro do pod do dbaccess e descompactar o arquivo baixado (se for o caso);
- Dropar o banco de dados a ser restaurado, lembrando que temos que ter a exclusividade no banco de dados.;
- Criar o banco de dados manualmente, obedecendo o encoding do banco original do cliente;
- Criar a extensão uuid-ossp (Utilizando a senha de SU do postgres para o banco que acabou de criar);
- Executar o pg_restore no banco, solicitando para que ignore o owner e os tablespaces;
Criar a tabela de controle de restore do banco de dados :
Reiniciar o dbaccess.
Para ajudar no processo, desenvolvemos um bash para montar as sentenças a serem executadas:
É necessário ter: - Kubectl instalado com um kubconfig válido
- Ter o JQ instalado
|
#!/bin/bash
set +ef
set +x
ccode=$1
type=$2
if [ "$ccode" = "" ]; then
echo "Required env variable ccode"
exit 0
fi
if [ "$type" = "" ]; then
type="producao"
fi
kubectl -n $ccode scale deploy -l base=true --replicas=1
dbaccess=$(kubectl -n $ccode get pod --no-headers | grep -i dbaccess | awk '{print $1}')
echo "kubectl -n $ccode exec -it $dbaccess -- bash"
endpoint=$(kubectl -n $ccode get configmap protheus-config -o json | jq -r .data.DATABASE_ENDPOINT)
password=$(kubectl -n $ccode get secrets protheus-secrets-db-master -o json | jq -r .data.DATABASE_PASSWORD | base64 -d)
user=$(kubectl -n $ccode get secrets protheus-secrets-db-master -o json | jq -r .data.DATABASE_USER | base64 -d)
echo "PGPASSWORD=$password psql -U $user -h $endpoint -d postgres -c "'"DROP DATABASE '$type';"'
echo "PGPASSWORD=$password psql -U $user -h $endpoint -d postgres -c "'"CREATE DATABASE '$type' WITH LC_COLLATE='"'C'"' LC_CTYPE='"'C'"' ENCODING='"'WIN1252'"' TEMPLATE=template0;"'
echo "PGPASSWORD=$password psql -U $user -h $endpoint -d $type -c 'CREATE EXTENSION IF NOT EXISTS \"uuid-ossp\";'"
echo "PGPASSWORD=$""DATABASE_PASSWORD_$type pg_restore -U $""DATABASE_USER_$type -h $""DATABASE_ENDPOINT -d $type --no-tablespaces --no-owner --no-acl --verbose < /tmp/"
echo "PGPASSWORD=$""DATABASE_PASSWORD_$type psql -U $""DATABASE_USER_$type -h $""DATABASE_ENDPOINT -d $type -c "CREATE TABLE DUMP_OK ();"
|
|
Buckets
Caso seja necessário restaurar o backup de alguma topologia específica é necessário entrar em contato com o pessoal responsável pelo Rubrik e informar o volume que foi gravado o backup (TKS_BKP_01 ou TKS_BKP_HMG_01) e a data que se deseja recuperar os arquivos. Para recuperar qualquer backup do volume TKS_BKP_HIST_GCP é necessário informar a data que o arquivo foi colocado no Rubrik (05/08/2020 ou 06/08/2020). TKS_BKP_01
Backups diários das topologias que estão no cluster de produção. TKS_BKP_HMG_01
Backups diários das topologias que estão no cluster do sistêmico. (Desativado) TKS_BKP_HIST_GCP
Backups antigos que estavam no GCP e que foram gerados antes de migrarmos para o VCP. É possível localizar os arquivos de volume e database de cada topologia gerados entre setembro/2019 e maio/2020. ${topologia}-database-2019-09-30-01-01.tar.gz
${topologia}-database-2019-10-31-04-02.tar.gz
${topologia}-database-2019-11-30-04-00.tar.gz
${topologia}-database-2019-12-31-04-02.tar.gz
${topologia}-database-2020-01-31-04-04.tar.gz
${topologia}-database-2020-02-29-04-04.tar.gz
${topologia}-database-2020-03-31-22-01.tar.gz
${topologia}-database-2020-04-30-03-29.tar.gz
${topologia}-database-2020-05-30-21-14.tar.gz
${topologia}-volume-2019-09-30-01-04.tar.gz
${topologia}-volume-2019-10-31-04-08.tar.gz
${topologia}-volume-2019-11-30-05-03.tar.gz
${topologia}-volume-2019-12-31-05-09.tar.gz
${topologia}-volume-2020-01-31-05-09.tar.gz
${topologia}-volume-2020-02-29-04-08.tar.gz
${topologia}-volume-2020-03-31-22-11.tar.gz
${topologia}-volume-2020-04-30-03-33.tar.gz
${topologia}-volume-2020-05-30-21-17.tar.gz
No dia 5 de agosto de 2020 está o snapshot com todas as topologias do cluster de produção, com exceção da cyuwnr/ e cyuwnr-development/
No dia 6 de agosto de 2020 está o snapshot com todas as topologias do cluster do sistêmico e do cluster de produção entrou a cyuwnr/ e cyuwnr-development/ |
|
Este bucket encontra-se Inativo no momento. |
|
Temos atualmente homologados no ambiente: - Postgres 11 e 12
- Oracle 11 e 19
Estamos terminando de homologar o MSSQL 19 e 22 para conteiner. |