Restaurar dump do Magento 2 em outro servidor: trocar a base_url no SQL

Importou o dump de produção no servidor de homologação, abriu o endereço novo e o navegador voa para o domínio antigo antes mesmo da página pintar. O Magento guarda a base_url dentro do banco, então o backup traz o domínio de produção junto e o redirect acontece já no primeiro request.

O UPDATE em core_config_data

-- antes de qualquer coisa: mysqldump -u user -p loja > /backup/loja-antes.sql
SELECT config_id, scope, scope_id, path, value
  FROM core_config_data
 WHERE path LIKE 'web/%base_url'
    OR path LIKE 'web/cookie/%';

UPDATE core_config_data
   SET value = 'https://homolog.minhaloja.com.br/'
 WHERE path IN ('web/unsecure/base_url', 'web/secure/base_url');

DELETE FROM core_config_data
 WHERE path = 'web/cookie/cookie_domain';

Tire o dump antes de rodar o UPDATE: core_config_data não tem desfazer e é fácil sobrescrever a linha do escopo errado. O SELECT vem primeiro de propósito, porque é comum existir uma linha de web/secure/base_url no escopo websites além da de default, e mexer só na primeira deixa a loja apontando para o domínio velho de um jeito difícil de rastrear. A barra no fim do valor não é enfeite, o Magento concatena o caminho direto ali. Se o SELECT trouxer base_link_url com URL literal em vez de {{unsecure_base_url}}, troque essa linha também. E o cookie domain com o host antigo é o motivo clássico de logar no admin e cair de volta na tela de login: o navegador descarta o cookie.

Limpar o cache logo depois

cd /var/www/loja
rm -rf var/cache/* var/page_cache/* var/view_preprocessed/*
sudo -u www-data php bin/magento cache:flush
sudo -u www-data php bin/magento config:show web/unsecure/base_url

O config:show é o teste de verdade: ele lê a configuração pela mesma via que o front-end usa. Se voltar o domínio antigo mesmo com o banco corrigido, abra app/etc/env.php e procure a seção system. Um valor gravado ali com config:set --lock-env ganha do banco sempre, e nenhum UPDATE vai derrubar ele.