Lab 18 — Migrar schema em produção sem parar

-- A consulta que transforma "parece travado" em "está esperando ESTE pid".
-- Roda contra a instancia PRINCIPAL, nunca a replica.
SELECT
  blocked.pid       AS bloqueado,
  blocked.query     AS o_que_espera,
  blocking.pid      AS bloqueador,
  blocking.query    AS o_que_segura_o_lock,
  now() - blocking.xact_start AS ha_quanto_tempo_a_transacao_esta_aberta
FROM pg_locks blocked_locks
JOIN pg_stat_activity blocked  ON blocked.pid = blocked_locks.pid
JOIN pg_locks blocking_locks   ON blocking_locks.locktype = blocked_locks.locktype
  AND blocking_locks.relation = blocked_locks.relation
  AND blocking_locks.pid != blocked_locks.pid
JOIN pg_stat_activity blocking ON blocking.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;

{
  "medido_em": "2026-08-07T14:05:00Z",
  "tabela": "pedidos",
  "linhas_totais": 2134982,
  "linhas_divergentes": 0,
  "medicao_anterior_ha_5min": 0,
  "atraso_da_replica_segundos": 1.8,
  "decisao": "AVANCAR"
}

# migration.tf — tempos-limite como padrão da instância, e a task de migração
# como cidadão de primeira classe, fora do servico da API

# lock_timeout e statement_timeout sao parametros DINAMICOS (contexto "user" no
# PostgreSQL): mudam sem reiniciar o RDS, e qualquer sessao pode sobrescreve-los
# com SET LOCAL. Aqui eles viram padrao da INSTANCIA — nao gambiarra ad hoc — e a
# migracao pede um teto ainda mais estrito (3 s) via SET LOCAL na propria migration.
resource "aws_db_parameter_group" "postgres" {
  name   = "${var.projeto}-postgres16"
  family = "postgres16"

  parameter {
    name         = "lock_timeout"
    value        = "5000" # ms; qualquer sessao que nao redefina espera no maximo 5 s por um lock
    apply_method = "immediate"
  }

  parameter {
    name         = "statement_timeout"
    value        = "30000" # ms; protege QUALQUER sessao de rodar para sempre — migration ou nao
    apply_method = "immediate"
  }

  parameter {
    # Registra no log toda espera de lock mais longa que deadlock_timeout (1 s,
    # padrao). E o que torna a fila do diagrama de producao observavel sem
    # precisar reproduzir o incidente para ve-la.
    name         = "log_lock_waits"
    value        = "1"
    apply_method = "immediate"
  }
}

resource "aws_db_instance" "principal" {
  # ... (recursos ja existentes do L01/L07; aqui so o que este laboratorio muda)
  parameter_group_name = aws_db_parameter_group.postgres.name
}

# A task de migracao usa a MESMA imagem da API, com outro entrypoint (ver
# Program.cs). Nao e um servico: nao tem desired_count, nao tem grupo de
# destino, nao recebe trafego. Ela roda com `run-task`, faz UMA coisa e termina.
resource "aws_ecs_task_definition" "migracao" {
  family                   = "${var.projeto}-migracao"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 256
  memory                   = 512
  execution_role_arn       = aws_iam_role.execucao.arn
  task_role_arn            = aws_iam_role.migracao.arn # papel PROPRIO, nao o da API

  container_definitions = jsonencode([{
    name      = "migracao"
    image     = "${aws_ecr_repository.api.repository_url}:${var.sha_da_imagem}"
    essential = true

    # A mesma imagem da API que atende trafego real (L03) — nunca um build
    # "quase igual" compilado a parte. O argumento decide a fase; o pipeline
    # passa um valor por vez.
    command = ["dotnet", "Api.dll", "--migrate", var.fase_da_migracao]

    secrets = [{
      name      = "ConnectionStrings__Migracao"
      valueFrom = aws_secretsmanager_secret.banco_migracao.arn
    }]

    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"         = aws_cloudwatch_log_group.migracao.name
        "awslogs-region"        = var.regiao
        "awslogs-stream-prefix" = "migracao"
      }
    }
  }])
}

# Papel PROPRIO da migracao, separado do task role da API (aws_iam_role.task no
# L03). A API nunca precisa de DDL; a migracao nunca precisa das rotas de
# negocio. Separar os dois e o que faz uma credencial vazada da API nao servir
# para alterar schema — e vice-versa.
resource "aws_iam_role" "migracao" {
  name               = "${var.projeto}-migracao"
  assume_role_policy = data.aws_iam_policy_document.ecs_assume.json
}

data "aws_iam_policy_document" "migracao_permite" {
  statement {
    effect  = "Allow"
    actions = ["secretsmanager:GetSecretValue"]
    # Recurso especifico: o secret da migracao, nunca o da API. Nao ha "*" aqui
    # porque a acao aceita ARN, e nao existe motivo para nao restringir.
    resources = [aws_secretsmanager_secret.banco_migracao.arn]
  }
}

resource "aws_iam_role_policy" "migracao" {
  role   = aws_iam_role.migracao.id
  policy = data.aws_iam_policy_document.migracao_permite.json
}

# Metrica CUSTOM, publicada pelo pipeline (ver observabilidade.sh) apos cada
# consulta a pg_locks. Nao existe metrica pronta do AWS/RDS para "sessoes
# esperando bloqueio" — Performance Insights tem o dado, mas via API propria,
# nao como dimensao de alarme do CloudWatch. Publicar a metrica e o que torna
# possivel alarmar sobre ela.
resource "aws_cloudwatch_metric_alarm" "sessoes_bloqueadas" {
  alarm_name          = "${var.projeto}-sessoes-bloqueadas-por-ddl"
  namespace           = "FFV/Migracao"
  metric_name         = "SessoesEsperandoBloqueio"
  statistic           = "Maximum"
  period              = 30
  evaluation_periods  = 2
  threshold           = 5
  comparison_operator = "GreaterThanThreshold"
  treat_missing_data  = "notBreaching"
  alarm_actions       = [aws_sns_topic.alertas.arn]
}

# ReplicaLag e metrica nativa do RDS PostgreSQL, em segundos, medida na
# instancia de REPLICA (L07). E a porta de avanco do backfill: lote demais e
# ela sobe antes de qualquer erro aparecer para o cliente.
resource "aws_cloudwatch_metric_alarm" "atraso_da_replica" {
  alarm_name          = "${var.projeto}-atraso-replica-backfill"
  namespace           = "AWS/RDS"
  metric_name         = "ReplicaLag"
  statistic           = "Maximum"
  period              = 60
  evaluation_periods  = 2
  threshold           = 10 # segundos; acima disso o backfill pausa (ver backfill.sh)
  comparison_operator = "GreaterThanThreshold"

  dimensions = {
    DBInstanceIdentifier = aws_db_instance.replica.id
  }

  alarm_actions = [aws_sns_topic.alertas.arn]
}

// Migrations/20260807120000_Fase1ExpandirTotalCentavos.cs
// Fase 1 — EXPANDIR. So o que e aditivo e barato. A v1 continua no ar sem
// saber que isto rodou: nenhuma coluna virou obrigatoria, nada foi removido.

public partial class Fase1ExpandirTotalCentavos : Migration
{
    protected override void Up(MigrationBuilder mb)
    {
        // SET LOCAL vale so para esta transacao: mais estrito que o padrao de
        // 5 s da instancia (migration.tf), porque aqui preferimos a migration
        // FALHAR rapido e ser repetida a formar fila atras dela.
        mb.Sql("SET LOCAL lock_timeout = '3s';");

        // Sem DEFAULT (ou com DEFAULT nao-volatil) e sem NOT NULL: e catalogo
        // puro, ACCESS EXCLUSIVE por milissegundos. Um DEFAULT volatil aqui
        // reescreveria a tabela inteira — e e exatamente o que este laboratorio
        // ensina a NAO fazer numa tabela de 2,1 milhoes de linhas.
        mb.AddColumn<long>(
            name: "total_centavos",
            table: "pedidos",
            type: "bigint",
            nullable: true);

        // CREATE INDEX CONCURRENTLY nao pode rodar dentro de um bloco de
        // transacao — e as migrations do EF Core sao executadas dentro de uma
        // transacao por padrao. suppressTransaction: true tira ESTA operacao
        // do BEGIN/COMMIT da migration, sem tirar a migration inteira. Custa
        // duas varreduras da tabela em vez de uma, e nao bloqueia escrita.
        mb.Sql(
            "CREATE INDEX CONCURRENTLY IF NOT EXISTS ix_pedidos_total_centavos " +
            "ON pedidos (total_centavos) WHERE total_centavos IS NOT NULL;",
            suppressTransaction: true);
    }

    protected override void Down(MigrationBuilder mb)
    {
        mb.Sql("DROP INDEX CONCURRENTLY IF EXISTS ix_pedidos_total_centavos;",
            suppressTransaction: true);
        mb.DropColumn(name: "total_centavos", table: "pedidos");
    }
}

// Migrations/20260814090000_Fase3ContrairValorTotal.cs
// Fase 3 — CONTRAIR. So roda depois de duas portas medidas: divergencia zero
// (backfill.sh) e nenhuma task da v1 no ar nem no plano de rollback do L03.
// A partir daqui, voltar para a v1 exige restauracao (L10), nao redeploy.

public partial class Fase3ContrairValorTotal : Migration
{
    protected override void Up(MigrationBuilder mb)
    {
        mb.Sql("SET LOCAL lock_timeout = '3s';");

        // NOT VALID nao escaneia a tabela: e so catalogo, ACCESS EXCLUSIVE por
        // milissegundos. A validacao (que exige o scan) vira o passo seguinte,
        // com um lock mais fraco.
        mb.Sql(
            "ALTER TABLE pedidos ADD CONSTRAINT total_centavos_not_null " +
            "CHECK (total_centavos IS NOT NULL) NOT VALID;");

        // VALIDATE CONSTRAINT pede SHARE UPDATE EXCLUSIVE, nao ACCESS
        // EXCLUSIVE: escrita concorrente continua liberada enquanto ele varre
        // a tabela inteira para confirmar que nenhuma linha viola a regra.
        // E o motivo de nao ter feito isso com um NOT NULL direto na fase 1.
        mb.Sql("ALTER TABLE pedidos VALIDATE CONSTRAINT total_centavos_not_null;");

        // A operacao irreversivel da sequencia inteira. DROP COLUMN nao
        // reescreve a tabela — e so catalogo — mas o dado fica inacessivel a
        // partir daqui. Sem backup ou PITR (L10), nao ha volta.
        mb.DropColumn(name: "valor_total", table: "pedidos");
    }

    // Sem Down(): contrair nao tem downgrade que devolva o dado. O caminho de
    // volta desta fase e restauracao, nao migration reversa — e e por isso que
    // a porta de avanco (divergencia zero, medida duas vezes) existe.
}

// Program.cs — o mesmo binario, dois caminhos: servir HTTP ou aplicar uma fase

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContextPool<AppDb>(o =>
    o.UseNpgsql(builder.Configuration.GetConnectionString("Padrao")));

// `--migrate <fase>` e o argumento que a task_definition.migracao passa
// (migration.tf). Fora deste caminho, o binario sobe o servidor HTTP normal —
// e essa e a garantia de que a migracao roda o MESMO codigo que atende trafego.
if (args.Contains("--migrate"))
{
    var fase = args[Array.IndexOf(args, "--migrate") + 1];
    using var app = builder.Build();
    using var escopo = app.Services.CreateScope();
    var db = escopo.ServiceProvider.GetRequiredService<AppDb>();

    // Cada fase e uma migration nomeada do EF Core. Rodar `Migrate()` sem alvo
    // aplicaria TODAS as pendentes de uma vez — o oposto do que este
    // laboratorio ensina, que e uma fase por implantacao.
    var migrador = db.GetInfrastructure().GetRequiredService<IMigrator>();
    migrador.Migrate(fase); // ex.: "Fase1ExpandirTotalCentavos"

    Console.WriteLine($"fase {fase} aplicada");
    return; // a task termina aqui; nao ha `app.Run()` neste caminho
}

var app2 = builder.Build();
app2.MapHealthChecks("/health/live");
app2.MapHealthChecks("/health/ready");
app2.Run();

// PedidoService.cs — a v2 escreve nos dois lugares e le com recuo

public class PedidoService(AppDb db)
{
    public async Task<Guid> CriarPedidoAsync(NovoPedidoDto dto, CancellationToken ct)
    {
        var centavos = (long)Math.Round(dto.ValorTotal * 100m, MidpointRounding.AwayFromZero);

        var pedido = new Pedido
        {
            Id = Guid.NewGuid(),
            // Escreve nos DOIS lugares. Enquanto a v1 conviver com a v2
            // durante o rollout do L03, o dado tem de estar correto nos dois
            // esquemas ao mesmo tempo — e sao consultas DIFERENTES que leem
            // cada um.
            ValorTotal = dto.ValorTotal,
            TotalCentavos = centavos,
        };

        db.Pedidos.Add(pedido);
        await db.SaveChangesAsync(ct);
        return pedido.Id;
    }

    public async Task<decimal> ObterValorTotalAsync(Guid id, CancellationToken ct)
    {
        // Projecao explicita das DUAS colunas — nunca `SELECT *` / `FindAsync`
        // sem projecao aqui. Se a v1 (que nao conhece total_centavos) ainda
        // estiver mapeando a mesma entidade sem a coluna nova, um `SELECT *`
        // corre o risco de o EF Core tentar materializar um campo que a
        // versao antiga do modelo nao declara — e e exatamente esse acoplamento
        // implicito que expand/contract existe para evitar.
        var pedido = await db.Pedidos
            .Where(x => x.Id == id)
            .Select(x => new { x.TotalCentavos, x.ValorTotal })
            .SingleAsync(ct);

        // Le da coluna NOVA; recua para a antiga so enquanto o backfill nao
        // convergiu. Depois da fase 3 (contrair), TotalCentavos nunca sera
        // nulo, e este recuo vira codigo morto que a fase 3 seguinte remove.
        return pedido.TotalCentavos.HasValue
            ? pedido.TotalCentavos.Value / 100m
            : pedido.ValorTotal;
    }
}

// Backfill.cs — task avulsa, mesma imagem, entrypoint `--backfill`. Roda uma
// vez, fora de horario de pico por escolha (nao por necessidade: e
// interrompivel e retomavel pelo cursor).

const int TamanhoDoLote = 5_000;
const int PausaEntreLotesMs = 200;
const double AtrasoMaximoDaReplicaSegundos = 10;

var cursor = Guid.Empty;
while (true)
{
    // Checa a replica ANTES de cada lote, nao so no inicio: um lote grande
    // alonga o atraso, e o PROXIMO lote precisa saber disso antes de rodar.
    var atraso = await MedirAtrasoDaReplicaAsync(conexao);
    if (atraso > TimeSpan.FromSeconds(AtrasoMaximoDaReplicaSegundos))
    {
        log.LogWarning("atraso de replica em {Atraso}s, acima do limite; pausando 10s", atraso.TotalSeconds);
        await Task.Delay(TimeSpan.FromSeconds(10));
        continue;
    }

    // UPDATE por LOTE, nunca na tabela toda: um lote de 5 mil linhas e uma
    // transacao curta, gera bloat proporcional ao lote (nao ao total) e
    // escreve WAL em pedacos que a replica absorve entre um lote e outro.
    var afetadas = await conexao.ExecuteAsync(
        """
        UPDATE pedidos SET total_centavos = ROUND(valor_total * 100)
        WHERE id IN (
            SELECT id FROM pedidos
            WHERE total_centavos IS NULL AND id > @cursor
            ORDER BY id
            LIMIT @tamanho
        )
        RETURNING id
        """,
        new { cursor, tamanho = TamanhoDoLote });

    if (afetadas == 0)
        break; // convergiu: nenhuma linha com total_centavos nula acima do cursor

    cursor = await ObterMaiorIdDoLoteAsync(conexao, cursor, TamanhoDoLote);
    log.LogInformation("lote aplicado: {Linhas} linhas, cursor em {Cursor}", afetadas, cursor);

    // A pausa da tempo ao autovacuum de processar as versoes mortas do lote
    // anterior antes do proximo UPDATE gerar mais. Sem pausa, o bloat cresce
    // mais rapido do que o autovacuum consegue reciclar.
    await Task.Delay(PausaEntreLotesMs);
}

// pg_stat_replication e visao do lado do PRIMARIO: mostra, por replica
// conectada, o atraso de reproducao em tempo real. Roda na conexao com a
// instancia principal, nunca na replica.
static async Task<TimeSpan> MedirAtrasoDaReplicaAsync(NpgsqlConnection conexao) =>
    TimeSpan.FromSeconds(await conexao.ExecuteScalarAsync<double>(
        "SELECT EXTRACT(EPOCH FROM replay_lag) FROM pg_stat_replication LIMIT 1;"));

#!/usr/bin/env bash
# implantar-fases.sh — quatro implantacoes, cada uma so avanca com a anterior confirmada
set -euo pipefail

PROJETO="${PROJETO:?defina PROJETO}"
REGIAO="${REGIAO:-us-east-1}"
SHA="$(git describe --always --dirty --match='' --abbrev=12)"

rodar_fase() {
  local fase="$1"
  echo "== fase ${fase}: run-task =="
  TASK_ARN=$(aws ecs run-task --cluster "$PROJETO" \
    --task-definition "${PROJETO}-migracao" \
    --launch-type FARGATE \
    --overrides "{\"containerOverrides\":[{\"name\":\"migracao\",\"command\":[\"dotnet\",\"Api.dll\",\"--migrate\",\"${fase}\"]}]}" \
    --network-configuration "awsvpcConfiguration={subnets=[$PRIVADA_A],securityGroups=[$SG_MIGRACAO]}" \
    --query 'tasks[0].taskArn' --output text)

  aws ecs wait tasks-stopped --cluster "$PROJETO" --tasks "$TASK_ARN"

  # Exit code != 0 e falha silenciosa de DDL se ninguem checar. O `wait` acima
  # so espera a task PARAR — nao diz se ela terminou bem.
  EXIT_CODE=$(aws ecs describe-tasks --cluster "$PROJETO" --tasks "$TASK_ARN" \
    --query 'tasks[0].containers[0].exitCode' --output text)
  [[ "$EXIT_CODE" == "0" ]] || { echo "fase ${fase} falhou (exit ${EXIT_CODE})" >&2; exit 1; }
}

# ── Fase 1: expandir ──────────────────────────────────────────────────────────
rodar_fase "Fase1ExpandirTotalCentavos"

# ── Implantação 2: a v2 sobe com escrita dupla, sem parar a v1 (rolling do L03) ─
terraform apply -var="sha_da_imagem=${SHA}" -auto-approve
aws ecs wait services-stable --cluster "$PROJETO" --services "${PROJETO}-api"

# ── Backfill, fora do pipeline de deploy — roda uma vez, pode ser retomado ────
aws ecs run-task --cluster "$PROJETO" --task-definition "${PROJETO}-backfill" \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[$PRIVADA_A],securityGroups=[$SG_MIGRACAO]}"

# ── Porta de avanço: divergência zero, medida DUAS vezes com 5 min de intervalo ─
medir_divergencia() {
  psql "$DATABASE_URL_SOMENTE_LEITURA" -tAc \
    "SELECT count(*) FROM pedidos WHERE total_centavos IS NULL OR total_centavos <> ROUND(valor_total * 100);"
}
D1=$(medir_divergencia); sleep 300; D2=$(medir_divergencia)
if [[ "$D1" != "0" || "$D2" != "0" ]]; then
  echo "divergência não convergiu (D1=${D1} D2=${D2}); NÃO prossiga para a implantação 3" >&2
  exit 1
fi

# ── Implantação 3: a v3 para de escrever no antigo ────────────────────────────
terraform apply -var="sha_da_imagem=${SHA}-v3" -auto-approve
aws ecs wait services-stable --cluster "$PROJETO" --services "${PROJETO}-api"

# ── Confirma que a v1 já não é mais alvo de rollback antes de contrair ────────
REVISAO_ATIVA=$(aws ecs describe-services --cluster "$PROJETO" --services "${PROJETO}-api" \
  --query 'services[0].taskDefinition' --output text)
echo "revisão ativa: ${REVISAO_ATIVA} — confirme manualmente que não é mais a v1 antes de continuar"
read -r -p "prosseguir para a fase 3 (contrair)? [s/N] " CONFIRMA
[[ "$CONFIRMA" == "s" ]] || { echo "abortado antes da operação irreversível"; exit 1; }

# ── Fase 3: contrair — irreversível a partir daqui ────────────────────────────
rodar_fase "Fase3ContrairValorTotal"
echo "as quatro implantações concluíram"

# provas.sh — cinco medições; nenhuma conclusão vem de "parece que funcionou"

PROJETO=ffv-lab; REGIAO=us-east-1

# ── Prova 1: zero erro do cliente durante as quatro implantações ─────────────
URL="https://$(terraform output -raw dominio)/api/pedidos/health"
( while true; do curl -s -o /dev/null -w '%{http_code} ' "$URL"; sleep 0.2; done ) & LACO=$!
./implantar-fases.sh
kill $LACO
# Medido na Cadência: 14.208 requisições, 0 diferente de 200, ao longo das
# quatro implantações e do backfill. Qualquer não-200 aqui reprova o rollout.

# ── Prova 2: a fila de bloqueio, observada — não decorada ────────────────────
# Abra uma transação de relatório de propósito, dispare um ALTER concorrente, e
# consulte quem espera quem. É a prova do mecanismo central deste módulo.
psql "$DATABASE_URL" -c "BEGIN; SELECT * FROM pedidos LIMIT 1;" &  # segura ACCESS SHARE, sem COMMIT
psql "$DATABASE_URL" -c "ALTER TABLE pedidos ADD COLUMN teste_prova int;" &
psql "$DATABASE_URL" -c "
  SELECT blocked.pid AS bloqueado, blocking.pid AS bloqueador, blocked.query AS espera
  FROM pg_locks blocked_locks
  JOIN pg_stat_activity blocked ON blocked.pid = blocked_locks.pid
  JOIN pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktype
    AND blocking_locks.relation = blocked_locks.relation AND blocking_locks.pid != blocked_locks.pid
  JOIN pg_stat_activity blocking ON blocking.pid = blocking_locks.pid
  WHERE NOT blocked_locks.granted;"
# Esperado: uma linha mostrando o ALTER como bloqueado pela transação de
# relatório — a prova de que a fila, não o comando, é a causa da espera.

# ── Prova 3: lock_timeout defende da fila, e o erro é o esperado ─────────────
psql "$DATABASE_URL" -c "SET lock_timeout = '3s'; ALTER TABLE pedidos ADD COLUMN teste_prova2 int;"
# Com a transação de relatório ainda aberta: falha em ~3s com SQLSTATE 55P03
# ("lock_not_available"), não trava indefinidamente. Reverta a transação de
# relatório com ROLLBACK antes de seguir.

# ── Prova 4: um CREATE INDEX CONCURRENTLY interrompido vira índice INVALID ───
psql "$DATABASE_URL" -c "SELECT indexrelid::regclass, indisvalid FROM pg_index WHERE NOT indisvalid;"
# Esperado em operação normal: zero linhas. Uma linha aqui é índice que falhou
# no meio — consome espaço e overhead de escrita sem servir consulta nenhuma;
# a correção é DROP INDEX e repetir o CONCURRENTLY.

# ── Prova 5: o tamanho do lote muda o pico de atraso da réplica ──────────────
# Repita o backfill em ambiente de teste com TamanhoDoLote = 50000 (sem pausa) e
# depois com 5000 + 200 ms de pausa, medindo o pico de ReplicaLag em cada corrida.
# Medido na Cadência: pico de 41 s de atraso com lote de 50 mil sem pausa,
# contra pico de 2 s com lote de 5 mil e pausa — quase 20× de diferença para o
# mesmo total de linhas processadas.
aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value="${PROJETO}-replica" \
  --start-time "$(date -u -d '-1 hour' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 60 --statistics Maximum --region "$REGIAO"

#!/usr/bin/env bash
# limpar.sh — ordem exata; o que o destroy NAO leva está na tabela ao lado
set -euo pipefail
PROJETO="${PROJETO:?defina PROJETO}"

# 1. Nenhuma task avulsa deve estar rodando (migração ou backfill).
aws ecs list-tasks --cluster "$PROJETO" --family "${PROJETO}-migracao" --query 'taskArns' --output text
aws ecs list-tasks --cluster "$PROJETO" --family "${PROJETO}-backfill" --query 'taskArns' --output text

# 2. O parameter group só pode ser removido depois da instância RDS.
terraform destroy -target=aws_db_parameter_group.postgres -target=aws_db_instance.principal \
  -target=aws_db_instance.replica 2>/dev/null || true

# 3. O restante do Terraform, na ordem inversa de dependência.
terraform destroy -auto-approve

# 4. O que sobrevive ao destroy e cobra parado — confira manualmente.
aws logs describe-log-groups --log-group-name-prefix "/ecs/${PROJETO}-migracao" \
  --query 'logGroups[].logGroupName' --output text