Guia de Treino HST

Copiar Resposta: Então, eu trabalho com banco de dados há uns sete anos já. Comecei lá na Geosiga, mexendo com SQL Server e PostgreSQL, mais focado em manter tudo funcionando e resolver problema quando aparecia. Depois fui pra DivinoBit, onde trabalhei num projeto pra uma instituição financeira. Lá peguei bastante SQL Server e Oracle, e foi onde eu realmente mergulhei em performance tuning. Tinha umas queries que demoravam muito e consegui otimizar bastante, reduzi o tempo em uns quarenta por cento mexendo em índices, reescrevendo queries, essas coisas. Na LC eu era praticamente o único cara de TI, então cuidava de tudo — banco, backup, recovery, otimização, a parada toda. E hoje em dia uso bastante PostgreSQL e MongoDB nos meus projetos pessoais. Tenho quatorze certificações da MongoDB, fui tirando pra me especializar mesmo.

Copiar Resposta: Usei o tempo pra me especializar. Finalizei o projeto da LC em junho — era escopo definido, montei toda infra, site, banco, tudo funcionando. Aí aproveitei pra focar em três coisas: finalizar minha graduação em Banco de Dados (faltam 12 matérias, concluo em 2026/2027), tirar certificações (MongoDB, Cisco) e manter projetos técnicos próprios. Tenho servidor Oracle Cloud com PostgreSQL e MongoDB em produção, homelab com Xeon rodando serviços. Não fiquei parado, foquei em crescimento técnico.

Copiar Resposta: Entendo o requisito. Estou cursando Tecnólogo em Banco de Dados pela Estácio, faltam 12 matérias, conclusão em 2026/2027. Mas tenho 7 anos de experiência prática em produção, incluindo instituição financeira, performance tuning com resultados mensuráveis e certificações que complementam. Posso apresentar declaração de matrícula e histórico. Acredito que experiência + especialização compensam enquanto finalizo a graduação.

Copiar Resposta: Porque vocês trabalham com meios de pagamento, e isso me chama atenção. É sistema crítico, não pode cair. Já trabalhei com instituição financeira na DivinoBit e sei o peso disso. Gosto desse tipo de desafio. Pesquisando sobre vocês, vi que valorizam crescimento técnico e colaboração, não é ambiente engessado. Quero um lugar onde eu possa evoluir tecnicamente e fazer diferença. E o stack de vocês com PostgreSQL e MongoDB casa bem com o que eu já trabalho.

Copiar Resposta: Uso bastante. Tenho vários bancos rodando na minha infra pessoal — site, analytics, projetos. Todos em containers Docker, PostgreSQL 17. Trabalho com dBeaver pra queries e tuning. Na Geosiga usei junto com SQL Server. Gosto porque é robusto e completo. Já mexi com replicação, backup, tuning e uso todo dia.

Copiar Resposta: Produção de grande porte, não. Mas já pratiquei bastante. Tenho quatorze certificações da MongoDB — M201, M312, M103, várias. Domino replica sets, sharding, aggregation, indexes. Já configurei clusters, testei failover e trabalhei com aggregation complexa. Falta ambiente de alto volume, mas tecnicamente tô preparado.

Copiar Resposta: Sim, na DivinoBit trabalhei com instituição financeira. Cuidava dos bancos que processavam transações críticas. Aprendi a importância de disponibilidade, consistência e auditoria. Entendo que em meios de pagamento não pode perder transação, não pode ter inconsistência. É ambiente de alta pressão e responsabilidade.

Copiar Resposta: Uso transações com ACID completo. Isolation level adequado (Serializable em casos críticos), foreign keys pra integridade referencial, constraints, triggers quando necessário. E sempre valido dados antes de commitar. Em pagamento, inconsistência significa prejuízo financeiro, então zero margem pra erro.

Copiar Resposta: Sim. Uso Linux o tempo todo, tanto no trabalho quanto nos meus projetos. Minha infra pessoal roda em Linux com containers Docker e servidor dedicado. Conheço bem terminal, logs, permissões, systemd. Já usei Ubuntu também. Me viro bem em linha de comando.

Copiar Resposta: Primeiro vejo se é problema de recurso — CPU, RAM, disco. Às vezes é só isso. Depois olho as queries ativas, uso pg_stat_activity no Postgres ou DMVs no SQL Server. Checo bloqueio, deadlock, logs de slow queries. Aí analiso execution plan das queries lentas pra achar o gargalo. Dependendo do caso, mato query travada, crio índice ou otimizo a query. Mas sempre comunico antes e documento tudo depois.

Copiar Resposta: Olha, primeira coisa que eu faço é rodar um EXPLAIN ANALYZE pra ver o que tá acontecendo. Aí olho o execution plan pra identificar onde tá o gargalo — se é table scan, falta de índice ou query mal escrita. Depois vejo se as estatísticas estão atualizadas, porque às vezes o otimizador toma decisão errada por causa disso. Também checo se não tem lock ou bloqueio rolando. Dependendo do que eu acho, crio índice, reescrevo a query ou vejo configuração. E sempre documento o que foi feito, porque depois você esquece. Na DivinoBit mesmo, peguei umas queries que levavam dez segundos e deixei em três ou quatro segundos com esse processo.

Copiar Resposta: Primeiro entendo a causa. Normalmente acontece quando duas transações lockam recursos em ordem diferente. Analiso o log do deadlock pra ver as queries e os recursos envolvidos. A solução é reescrever queries pra acessarem as tabelas na mesma ordem ou reduzir o tempo das transações. Às vezes dá pra usar NOLOCK, mas com cuidado. Snapshot Isolation também ajuda. E sempre documento pra evitar repetição.

Copiar Resposta: Primeiro, mantenho calma. Avalio se dá pra fazer rollback imediato ou se precisa restaurar backup. Comunico time e gestão com transparência: "identificamos o problema, estamos trabalhando, tempo estimado X". Restauro do último backup bom, valido integridade, testo antes de subir. Documento tudo durante o processo. Depois, com sistema estável, faço postmortem pra entender causa raiz e evitar repetição. O importante é não entrar em pânico e comunicar constantemente.

Copiar Resposta: Exponho minha visão técnica com dados, não opinião. Mostro riscos e impactos. Se ele mantiver a decisão, documento a discordância e executo. Meu papel é alertar tecnicamente, mas quem decide é quem tem a responsabilidade. Depois, se der problema, uso como aprendizado pra melhorar comunicação técnica na próxima.

Copiar Resposta: Explico tecnicamente por que não é viável no prazo, mas ofereço alternativas. "Isso leva X dias pelo motivo Y, mas posso entregar Z em metade do tempo que resolve 80% do problema". Sempre trago opção, não só o "não dá". E documento tudo pra evitar mal-entendido depois.

Copiar Resposta: Na DivinoBit, time de dev queria criar vários índices em tabela de alto volume pra melhorar SELECT. Eu sabia que ia ferrar com INSERT e UPDATE. Chamei reunião, mostrei dados de custo de escrita, propus alternativa: otimizar queries e criar índices covering estratégicos. Provei com teste de carga. No fim, aceitaram minha solução e ficou melhor pra todo mundo. O importante foi mostrar dados, não só opinião.

Copiar Resposta: Documentação e checklist. Quando algo dá errado, faço postmortem: o que aconteceu, por que, como evitar. Crio checklist se for processo repetitivo. Por exemplo, depois de um erro de deploy, criei checklist: backup feito? testado em homolog? rollback pronto? janela comunicada? Sempre sigo antes de qualquer mudança.

Copiar Resposta: A primeira coisa é manter a calma. Sei que em ambiente crítico isso é essencial. Eu costumo seguir um processo: identificar o impacto, comunicar o time e agir rápido pra mitigar. Analiso logs, vejo o que mudou recentemente e, se for algo que dá pra reverter, faço rollback imediato. Se não, isolo o problema e restabeleço o serviço o quanto antes, mesmo que de forma parcial. Depois, com tudo estável, faço uma análise pós-incidente pra entender a causa raiz e evitar repetição. O importante é não agir no impulso e manter o time informado durante o processo.

Copiar Resposta: Eu priorizo. Paro, respiro e vejo o impacto de cada coisa. Resolvo primeiro o que é mais crítico. E comunico sempre — se vejo que não vai dar prazo, aviso antes e trago alternativas. Na Geosiga já passei por incidentes sérios, então aprendi a manter calma e foco. Pressão faz parte de ambiente crítico, o segredo é focar em resolver.

Copiar Resposta: Primeiro, libero conexões idle antigas (pg_terminate_backend nas longas). Depois ajusto max_connections e shared_buffers se tiver RAM. E investigo por que tá esgotando, se é app segurando conexão ou leak. Configuro pgBouncer pra pooling no meio.

Copiar Resposta: CPU, RAM, disco (I/O e espaço), conexões ativas, queries lentas (> 5s), locks, deadlocks, replication lag, tamanho de tabelas crescendo rápido, cache hit ratio. Configuro alerta pra CPU > 80%, disco > 90%, lag > 10s.

Copiar Resposta: Monitoramento proativo. Alertas em thresholds, análise de tendências (tabela crescendo rápido, queries ficando lentas gradualmente), revisão semanal de slow query log. E sempre olho métricas depois de cada deploy.

Copiar Resposta: Depende do caso. Read Committed é o padrão, boa pra maioria. Mas pra garantir consistência total em transações críticas, uso Serializable ou Repeatable Read. O trade-off é performance vs consistência. Em pagamento, prefiro Serializable mesmo que mais lento.

Copiar Resposta: Depende do SLA. Normalmente uso replicação — replica sets no MongoDB, streaming replication no PostgreSQL, Always On no SQL Server. Backup automatizado e testado, monitoramento ativo com alertas e runbooks pra incidentes. Na LC eu garantia 99,9% de uptime fazendo isso.

Copiar Resposta: Uso pg_stat_replication pra ver status e lag. Também olho pg_stat_activity. Pra monitoramento contínuo, configuraria alertas de lag. Sempre valido integridade entre primary e replicas. Já brinquei com streaming replication e entendo bem como funciona. Se precisar de algo mais avançado como Patroni, aprendo rápido.

Copiar Resposta: O Primary é o nó principal que recebe todas as escritas e envia os WALs pros Standbys. O Standby é uma réplica em modo de leitura, que aplica continuamente os WALs recebidos. Se o Primary falhar, um Standby pode ser promovido pra assumir como novo Primary.

Copiar Resposta: Dá pra simular desligando o Primary (por exemplo, parando o serviço com systemctl stop postgresql) e promovendo o Standby com o comando pg_ctl promote. Depois verifico se ele virou o novo Primary e se as aplicações conseguem se conectar. Também valido se a replicação volta normal quando o antigo Primary retorna como Standby.

Copiar Resposta: Replica set tem no mínimo três nodes. Um é o Primary, que recebe as escritas, e os outros são Secondaries, que replicam. Ele usa o oplog, que é tipo um transaction log. Se o Primary cai, acontece uma eleição automática e outro assume. Dá pra configurar o Write Concern pra definir quantos nodes confirmam a escrita e o Read Preference pra escolher de onde ler. Já testei failover manual nos meus projetos pra ver o comportamento.

Copiar Resposta: Síncrono espera confirmação do standby antes de commitar. Mais lento mas zero perda de dados. Assíncrono commita direto, standby recebe depois. Mais rápido mas pode perder segundos de dados se primary cair. Escolho baseado em RTO/RPO.

Copiar Resposta: Simulo desastre real. Desligo primary à força, promovo standby, aponto app pro novo primary. Valido se dados bateu, se não perdeu nada. Depois restauro o antigo como standby. Isso tem que ser testado regularmente, não só na teoria.

Copiar Resposta: Depende do RTO e RPO, mas geralmente faço full backup semanal, tipo domingo de madrugada, e durante a semana faço differential diário. Transaction log a cada quinze ou trinta minutos, depende do volume. E o mais importante: testar restore. Backup que não foi testado não é backup. Também mando cópia pra offsite, tipo nuvem ou outro servidor. Na Geosiga eu montei um NAS só pra backup porque tava competindo com produção. E sempre rodo DBCC CHECKDB pra garantir integridade antes.

Copiar Resposta: Pra backup lógico, uso pg_dump -U usuario -d banco -F c -f arquivo.dump. O -F c gera um formato customizado, que permite restore paralelo. Pra restaurar, uso pg_restore -U usuario -d novo_banco -j 4 arquivo.dump. Também dá pra fazer dump de todas as bases com pg_dumpall.

Copiar Resposta: No MongoDB, uso mongodump --uri="mongodb://usuario:senha@host:porta" --out=/backup pra gerar o dump. Pra restaurar, mongorestore --uri="mongodb://usuario:senha@host:porta" /backup. Dá pra usar --gzip pra comprimir e --oplog pra preservar a ordem das operações.

Copiar Resposta: pg_dump é um backup lógico, exporta dados e estrutura pra recriação. Backup físico é feito copiando diretórios de dados e WALs, usado pra restaurar instâncias inteiras, inclusive com point-in-time recovery.

Copiar Resposta: Copio o diretório base e os WALs, configuro recovery.conf ou recovery.signal com restore_command, e inicio o servidor. Ele aplica os WALs até o ponto configurado e volta ao estado desejado.

Copiar Resposta: Consulto pg_stat_database pra ver tempo de execução e contadores gerais, pg_stat_activity pra ver queries em execução e pg_stat_bgwriter pra entender o comportamento de I/O e checkpoints.

Copiar Resposta: Uso SELECT pg_size_pretty(pg_total_relation_size('nome_tabela')); pra ver o tamanho total incluindo índices e TOAST. Se quiser só os dados, uso pg_relation_size('nome_tabela'). Pra ver o tamanho de todo o banco, uso pg_database_size(current_database()).

Copiar Resposta: O clustered define a ordem física dos dados na tabela. É tipo um dicionário, as palavras já estão na ordem. Por isso só pode ter um clustered por tabela. O non-clustered é como o índice no final do livro — ele aponta pra onde os dados estão, mas não muda a ordem física. Você pode ter vários non-clustered numa tabela. No SQL Server, quando cria uma primary key, ela já vira clustered. Eu costumo usar clustered em colunas de range, tipo data, e non-clustered pra buscas diretas.

Copiar Resposta: BRIN significa Block Range Index. Ele guarda metadados sobre blocos de páginas, não valores individuais. É ótimo pra tabelas enormes com dados ordenados naturalmente, tipo logs ou registros por data, porque ocupa pouco espaço e é rápido pra ranges grandes.

Copiar Resposta: GIN significa Generalized Inverted Index. É usado pra tipos de dados complexos como arrays, JSONB e texto. Ideal pra buscas com operadores de contenção (por exemplo, @> ou LIKE). É mais pesado pra gravar, mas ótimo pra leitura.

Copiar Resposta: GiST significa Generalized Search Tree. É um tipo de índice mais genérico, usado pra dados espaciais, ranges e full-text search. É bem flexível e permite tipos de indexação customizados.

Copiar Resposta: BRIN uso em tabelas enormes e ordenadas por campo contínuo, tipo data. GIN uso pra JSONB, arrays e texto com múltiplos termos. GiST uso pra dados geográficos, ranges ou buscas que envolvem proximidade.

Copiar Resposta: Particionamento por data (range partition). Crio partições mensais, índices locais, e boto rotina pra dropar partições antigas ou arquivar. Também otimizo autovacuum pra não travar. Se precisar, uso tablespaces diferentes pra separar I/O.

Copiar Resposta: No PostgreSQL 11+, uso particionamento declarativo. Crio tabela particionada nova, crio partições, copio dados em batches com INSERT SELECT, troco via RENAME. Ou uso pg_partman pra automação. Sempre em janela de baixo uso.

Copiar Resposta: Consulto pg_stat_user_tables e olho n_dead_tup. Se tiver muito dead tuple, vacuum tá atrasado. Também vejo last_autovacuum. Se tabela tá bloated, rodo VACUUM FULL em janela programada, porque bloqueia escrita.

Copiar Resposta: Ainda não em produção, mas conheço bem o conceito. pgBouncer fica entre app e banco, gerenciando pool de conexões. Evita saturar max_connections. Tem modos transaction e session. É essencial em ambientes de alto volume.

Copiar Resposta: Uso pra tudo que é repetitivo. Backup automatizado com cron, validação de integridade, coleta de métricas. Já fiz script pra dump, compactar, enviar pra outro servidor e limpar backups antigos. Também pra restart de serviços e logs. Tenho vários scripts rodando na minha infra.

Copiar Resposta: Costumo orientar sobre boas práticas. Mostro como escrever queries eficientes, quando criar ou não criar índice. Também ajudo em modelagem e explico impacto das decisões. Quando tem problema de performance, analiso junto e explico o motivo, pra dev entender, não só corrigir.

Copiar Resposta: Sim. Na DivinoBit precisei migrar entre ambientes e garantir integridade. O processo é analisar schema, mapear dados, extrair, transformar e carregar. Testar subset antes e validar tudo. Comparo contagens e checksums. Já usei dump/restore e export/import. O importante é ter rollback plan e fazer em janela segura.

Copiar Resposta: Primeiro reviso o código. Vejo se não vai causar lock longo, se tá otimizada, se precisa mesmo ser procedure ou dá pra ser query. Se tiver problema, explico o risco e sugiro alternativa. Mas se tiver ok, libero. O importante é educar, não bloquear.

Copiar Resposta: Sempre testo em homologação primeiro, exatamente igual prod. Faço backup antes, tenho rollback script pronto, executo em janela de manutenção ou baixo uso. Comunico todo mundo antes. E monitoro depois pra garantir que não quebrou nada.

Copiar Resposta: Sim. Na DivinoBit, devs queriam criar vários índices que iam ferrar com INSERT. Expliquei o impacto, mostrei números de performance, propus alternativa (reescrever queries). No fim, aceitaram minha solução. O importante foi mostrar dados, não só falar não.

Copiar Resposta: Primeiro, manter tudo atualizado — patches, service packs. Depois, autenticação forte, nada de senha padrão. Princípio de menor privilégio, auditoria habilitada, criptografia em repouso e trânsito. E monitorar logs pra detectar anomalias. Na DivinoBit tinha padrão de segurança bem rígido, então aprendi a seguir processo.

Copiar Resposta: Sim, na DivinoBit. Não conduzia, mas tinha que fornecer evidências — logs, relatórios de backup, controles de segurança. Aprendi a importância de documentar tudo. PA DSS e PCI ainda não fiz, mas entendo o conceito de compliance em sistemas críticos.

Copiar Resposta: Ainda não trabalhei diretamente com eles, mas sei que 3D Secure é aquele protocolo de autenticação extra em compras online. DSS é ligado à segurança dos dados de pagamento. Na DivinoBit trabalhei com dados financeiros críticos, então o contexto é parecido. Aprendo rápido e tenho base sólida de segurança.

Copiar Resposta: Tranquilo. Sei que sistema de pagamento precisa disso. Já lidei com problemas fora de horário e resolvi. Tenho toda estrutura aqui — internet boa, backup, servidor próprio. Me adapto bem a escala de sobreaviso. Prefiro ter clareza de quando é minha responsabilidade do que ficar naquela incerteza.

Copiar Resposta: Diria que são três. Primeiro, autonomia — já fui o único de TI, então aprendi a me virar. Segundo, troubleshooting — gosto de resolver problema complexo, não desisto fácil. E terceiro, estudo. Mantenho servidor em casa, tiro certificações, contribuo com tradução pra comunidade. Tecnologia pra mim é prazer, não só trabalho.

Copiar Resposta: Às vezes fico muito focado e perco noção do tempo. Já fiquei até tarde tentando resolver algo. Aprendi que tem hora de parar e pedir opinião. Outra é que ainda não tenho experiência com PA DSS e PCI, mas aprendo rápido. Já tenho base de segurança de dados de ambiente financeiro, então é mais questão de prática.

Copiar Resposta: No começo da carreira, fiz uma mudança em produção sem testar adequadamente. Causou indisponibilidade de uns 20 minutos até reverter. Impactou usuários e aprendi na prática a importância de processo. Desde então, nunca mais pulei etapa de homologação. Criei checklist próprio que sigo religiosamente. Foi uma lição cara, mas me tornou mais criterioso.

Copiar Resposta: Escuto, processo e implemento. Feedback é dado de graça, seria burrice ignorar. Pode doer na hora, mas depois vejo que sempre tem algo válido. Já recebi feedback de que eu ficava muito tempo tentando resolver sozinho ao invés de pedir ajuda. Era verdade. Mudei isso, aprendi a pedir segunda opinião mais cedo.

Copiar Resposta: Três coisas me diferenciam. Primeiro, experiência real em ambiente crítico financeiro - sei o peso de sistema que não pode cair. Segundo, autonomia comprovada - já fui o único de TI, não preciso de micro-gerenciamento. Terceiro, paixão genuína por tecnologia - mantenho homelab, tiro certificações, contribuo com open source. Pra mim não é só trabalho, é o que eu gosto de fazer.

Copiar Resposta: Intermediário avançado, tipo B2. Leio documentação técnica tranquilo, assisto curso e vídeo em inglês. Falo e escrevo bem o suficiente pra trabalho. Tenho certificação de English for IT 2 da Cisco, nível B2.

Copiar Resposta: No começo da carreira fiz mudança em prod sem testar direito em homolog. Causou bug que só apareceu depois. Aprendi duas coisas: sempre testar em ambiente idêntico e ter plano de rollback pronto. Desde então, uso checklist antes de qualquer deploy.

Copiar Resposta: Gosto. Vi no Glassdoor que vocês estão crescendo e revisando processos. Isso significa ambiente dinâmico, onde dá pra ter impacto real. Já trabalhei em contextos onde eu era o único de TI, então me adapto bem a ambientes onde precisa ter autonomia e iniciativa. Prefiro isso a empresa engessada.

Copiar Resposta: Gosto de documentar e compartilhar conhecimento. Se resolvo problema interessante, documento pra virar referência pro time. Também ajudo colegas com dúvidas técnicas. Contribuo com traduções pra comunidade open source. Acredito que DBA não é só apagar incêndio, é melhorar o ambiente como um todo.

Copiar Resposta: O projeto foi concluído. Era um contrato específico pra instituição financeira, com escopo definido. Quando finalizamos as entregas principais, o contrato encerrou naturalmente. Foi uma experiência muito boa, aprendi bastante sobre ambiente crítico.

Copiar Resposta: Porque o que vocês pedem é exatamente o que eu faço. PostgreSQL eu uso todo dia, MongoDB tenho quatorze certificações, SQL Server e Oracle trabalhei em produção, Linux é meu ambiente. Gosto de troubleshooting e performance, e tenho experiência com sistemas críticos. Acho que posso contribuir bastante e crescer junto com a empresa.

Copiar Resposta: Depende do tipo de dado. MongoDB faz mais sentido pra dados semi-estruturados ou quando o schema muda muito, porque é schema-less. Também quando precisa escalar horizontal de forma massiva ou ler documentos inteiros. Já o PostgreSQL é melhor pra dados bem estruturados, com relacionamentos e necessidade de ACID completo. Muitas vezes dá pra usar os dois — PostgreSQL pro transacional e MongoDB pra logs ou dados menos críticos.

Copiar Resposta: Li as avaliações. Vi que tem gente falando bem da cultura técnica e colaboração, mas também críticas sobre processos em mudança e comunicação. Isso é normal em empresa crescendo. O que me chamou atenção positivo foi o investimento em desenvolvimento (subsídio pra curso, Whiteboard pra aprender). E negativo, alguns falam de decisões centralizadas. Mas avalio isso presencialmente, Glassdoor é só uma visão. Prefiro formar minha própria opinião.

Copiar Resposta: Porque vocês atuam em meios de pagamento há mais de 30 anos, não são startup experimentando. Têm base sólida mas continuam inovando. Stack moderno (PostgreSQL, MongoDB), presença internacional, clientes grandes. E pela descrição da vaga, vejo que DBA aqui não é só operacional, tem espaço pra performance, automação, melhorias. É o tipo de desafio que me motiva.

Copiar Resposta: Me vejo como DBA Sênior ou Especialista, sendo referência técnica em banco de dados dentro da HST. Quero me aprofundar em arquitetura de alta disponibilidade, disaster recovery e otimização de databases de larga escala. Também tenho interesse em mentoria técnica, ajudar DBAs mais juniores. Não vejo meu futuro em gestão, prefiro me manter técnico mas num nível de especialização alto.

Copiar Resposta: Minha expectativa pra DBA Pleno está na faixa de R$ 7.000 a R$ 8.500 CLT, considerando minha experiência de 7 anos, certificações e o pacote de benefícios que vocês oferecem. Mas estou aberto a conversar sobre a proposta de vocês, levando em conta o todo.

Copiar Resposta: Sim! Como é o time de dados hoje? Quantos DBAs vocês têm e como o trabalho é dividido? Qual o maior desafio técnico que o time tá enfrentando agora? E como vocês fazem deploy de mudanças em banco — tem CI/CD, janela de manutenção? Como é o processo de onboarding pro DBA novo? E qual o próximo passo do processo seletivo?

Copiar Resposta: Primeiro, eu avalio impacto e urgência real de cada coisa. O que afeta mais usuários ou o negócio vem primeiro. Em seguida, vejo dependências. Na maioria das vezes resolver uma tarefa destrava as outras. Também costumo comunicar claramente o que vou priorizar, pra todo mundo ter visibilidade. Se tem algo que não vai dar pra entregar no prazo, aviso antes e proponho alternativas. Aprendi que priorizar não é só escolher o que fazer primeiro, mas também deixar claro o porquê. Em ambiente crítico, priorização e comunicação andam juntas.

Copiar Resposta: Paro o PostgreSQL no Standby, limpo o diretório data, e executo pg_basebackup -h primary -U replicador -D /var/lib/postgresql/data -Fp -Xs -P -R. Isso copia todos os dados e já cria o recovery.conf com os parâmetros de replicação.