Migração de aplicações

Concluído

Depois de migrar seu banco de dados local para o Azure, você precisa atualizar seus aplicativos existentes para que eles possam acessar o PostgreSQL em seu novo local.

Seu servidor local e banco de dados originais conterão funções que definem os privilégios associados aos usuários, as operações que eles podem fazer e os objetos sobre os quais eles executam essas operações. O Banco de Dados do Azure para PostgreSQL usa os mesmos mecanismos de autenticação e autorização que o PostgreSQL em execução local.

Nesta unidade, você explorará as atualizações que precisa fazer em seus aplicativos para se conectar ao seu Banco de Dados do Azure para PostgreSQL recém-migrado.

Criar as funções de usuário manualmente

Quando você transfere um banco de dados PostgreSQL para o Banco de Dados do Azure para PostgreSQL usando o Serviço de Migração de Banco de Dados do Azure, as funções e atribuições de função não são copiadas. Você deve recriar manualmente as funções e contas de usuário necessárias para o administrador e os usuários das tabelas no banco de dados de destino. Você usa os utilitários psql ou pgAdmin para executar essas tarefas. Execute o comando CREATE ROLE. Use o GRANT comando para atribuir os privilégios necessários a uma função. Por exemplo:

CREATE ROLE myuseraccount WITH LOGIN NOSUPERUSER CREATEDB PASSWORD 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myuseraccount;

Nota

Você também usa o createuser comando do prompt bash para criar funções PostgreSQL.

Para exibir as funções existentes no banco de dados local, execute a seguinte instrução SQL:

SELECT rolname
FROM pg_roles;

Você pode usar o comando \du no utilitário psql para exibir os privilégios atribuídos às funções.

                              List of roles
   Role name   |               Attributes                                   | Member of
---------------+------------------------------------------------------------+-----------
 azureuser     | Superuser, Create DB                                       | {}
 myuseraccount | Create DB                                                  | {}
 postgres      | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

Nota

Observe que o Banco de Dados do Azure para PostgreSQL adiciona algumas funções próprias. Essas funções incluem azure_pg_admin, azure_superusere o usuário administrador que você especificou quando criou o serviço. Você entra usando suas contas administrativas, mas as outras duas funções são reservadas para uso pelo Azure — você não deve tentar usá-las.

Reconfigurar aplicativos

Reconfigurar um aplicativo para se conectar ao Banco de Dados do Azure para PostgreSQL é um processo simples. No entanto, é mais importante determinar uma estratégia para aplicativos de migração.

Considerações ao reconfigurar aplicativos PostgreSQL

Em um ambiente corporativo, você pode ter muitos aplicativos em execução nos mesmos bancos de dados PostgreSQL. Pode haver um grande número de usuários executando esses aplicativos. Você quer ter certeza de que, quando você mudar do sistema existente para o Banco de Dados do Azure para PostgreSQL, seus sistemas ainda funcionarão, os usuários poderão continuar fazendo seus trabalhos e suas operações críticas para os negócios permanecerão operacionais. O Módulo 1, Lição 2, Considerações sobre a migração, discutiu muitas das questões em termos gerais. Quando você migra um banco de dados PostgreSQL para o Azure, há alguns detalhes a serem observados:

  • Se você estiver executando uma migração offline, os dados no banco de dados PostgreSQL original e os novos bancos de dados em execução no Azure podem começar a divergir rapidamente se o banco de dados antigo ainda estiver sendo usado. Uma migração offline é adequada quando você tira um sistema totalmente de operação por um curto período de tempo e, em seguida, alterna todos os aplicativos para o novo sistema antes de iniciar novamente. Essa abordagem pode não ser possível para um sistema crítico para os negócios. Se você estiver migrando para o PostgreSQL em execução em uma máquina virtual do Azure, configure a replicação do PostgreSQL entre seu sistema local e o que está sendo executado no Azure. A replicação nativa do PostgreSQL opera em apenas uma direção, mas estão disponíveis soluções de terceiros que dão suporte à replicação bidirecional entre servidores PostgreSQL (essas soluções não funcionarão com o Banco de Dados do Azure para PostgreSQL).
  • Se você estiver executando uma migração online, o serviço Banco de Dados do Azure para PostgreSQL configurará a replicação do banco de dados local para o banco de dados em execução no Azure. Após a transferência inicial de dados, a replicação garante que todas as alterações feitas no banco de dados local sejam copiadas para o banco de dados no Azure, mas não o contrário.

Em ambos os casos, você deve garantir que não perca dados em tempo real por meio de uma substituição acidental. Por exemplo, no cenário online, um aplicativo conectado ao banco de dados em execução no Banco de Dados do Azure para PostgreSQL pode ter suas alterações substituídas cegamente por um aplicativo que ainda usa o banco de dados local. Com isso em mente, você deve considerar as seguintes abordagens:

  • Migre aplicativos com base em seu tipo de carga de trabalho. Um aplicativo que acessa os dados apenas para leitura pode ser movido com segurança para o banco de dados em execução no Banco de Dados do Azure para PostgreSQL e verá todas as alterações feitas por aplicativos que ainda usam o banco de dados local. Você também pode adotar a estratégia inversa se os aplicativos somente leitura não exigirem dados totalmente atualizados.
  • Migre usuários com base em seu tipo de carga de trabalho. Essa estratégia é semelhante à anterior, exceto que você pode ter usuários que geram apenas relatórios enquanto outros modificam os dados. Você pode ter o mesmo aplicativo configurado para se conectar ao banco de dados apropriado de acordo com os requisitos do usuário.
  • Migre aplicativos com base nos conjuntos de dados que eles usam. Se diferentes aplicativos utilizarem subconjuntos diferentes dos dados, você poderá migrar esses aplicativos independentemente uns dos outros.

Reconfigurando um aplicativo

Para reconfigurar um aplicativo, aponte para o novo banco de dados. A maioria dos aplicativos bem escritos isolará a lógica de conexão, e essa deve ser a única parte do código que requer alteração. Em muitos casos, as informações de conexão podem ser armazenadas como informações de configuração — você só precisa atualizar essas informações.

Você encontrará as informações de conexão do seu serviço Banco de Dados do Azure para PostgreSQL no portal do Azure, na página Cadeias de conexão do seu serviço. O Azure fornece as informações para muitas linguagens de programação e estruturas comuns.

Image showing the Connection strings page for Azure Database for PostgreSQL item in the Azure portal

Abrir portas de rede

Conforme mencionado na Lição 1 deste módulo, o Banco de Dados do Azure para PostgreSQL é um serviço protegido que é executado atrás de um firewall. Os clientes não podem se conectar a menos que seu endereço IP seja reconhecido pelo serviço. Você deve adicionar os endereços IP, ou intervalos de blocos de endereços, para clientes que executam aplicativos que precisam se conectar aos seus bancos de dados.

Testar e verificar aplicativos

Antes de alternar seus aplicativos e usuários para o novo banco de dados, é importante garantir que você configurou tudo corretamente.

Comece por aplicativos de "execução a seco" e conecte cada função para garantir que a funcionalidade correta esteja disponível.

Em seguida, execute "testes de imersão" para imitar o número típico de usuários executando cargas de trabalho representativas simultaneamente por um período de tempo. Monitore o sistema e verifique se você alocou recursos suficientes ao seu serviço Banco de Dados do Azure para PostgreSQL.

Neste ponto, você pode começar a implantar o sistema para os usuários. Pode ser benéfico implementar alguma forma de "teste canário", onde um pequeno subconjunto de usuários é transferido para o sistema desprevenido. Isso lhe dá uma opinião imparcial sobre se os usuários estão tendo a mesma, melhor ou pior experiência com o novo banco de dados.