Migração de aplicativos

Concluído

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

Seu servidor e banco de dados locais originais conterão funções que definem os privilégios associados aos usuários, às operações que eles podem fazer e aos objetos para os quais 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 aos seus aplicativos para se conectar ao Banco de Dados do Azure para PostgreSQL recém-migrado.

Criar as funções de usuário manualmente

Ao transferir 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 as 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. Use os utilitários psql ou pgAdmin para realizar 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;

Observação

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 | {}

Observação

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 ao criar 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ê deseja ter certeza de que, quando você alternar 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 aos negócios permanecerão operacionais. No Módulo 1, Lição 2, Considerações sobre a migração, muitos dos problemas foram abordados 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 poderão 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 da operação por pouco 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 comercialmente crítico. 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 aquele em execução no Azure. A replicação nativa do PostgreSQL opera apenas em uma direção, mas há soluções de terceiros disponíveis 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 dado local sejam copiadas para o banco do dados no Azure, mas não o inverso.

Em ambos os casos, você deve garantir que não perderá dados dinâmicos devido a 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:

  • Migrar os aplicativos com base no tipo de carga de trabalho deles. Um aplicativo que acessa os dados para leitura só pode se mover 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.
  • Migrar os usuários com base no tipo de carga de trabalho deles. 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.
  • Migrar os aplicativos com base nos conjuntos de dados que eles usam. Se aplicativos diferentes utilizarem subconjuntos diferentes dos dados, você poderá migrar esses aplicativos independentemente uns dos outros.

Reconfiguração de um aplicativo

Para reconfigurar um aplicativo, aponte-o 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 para seu serviço do Banco de Dados do Azure para PostgreSQL no portal do Azure, na página Cadeias de conexão do serviço. O Azure fornece as informações para muitas estruturas e linguagens de programação comuns.

Imagem mostrando a página Cadeias de conexão do item Banco de Dados do Azure para PostgreSQL no portal do Azure

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 executado atrás de um firewall. Os clientes não podem se conectar, a menos que o endereço IP deles seja reconhecido pelo serviço. Você deve adicionar os endereços IP ou os intervalos de bloco de endereço para clientes que executam aplicativos que precisam se conectar aos seus bancos de dados.

Testar e verificar aplicativos

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

Comece por aplicativos "em 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 que executam cargas de trabalho representativas simultaneamente por um período de tempo. Monitore o sistema e verifique se você alocou recursos suficientes para seu serviço do Banco de Dados do Azure para PostgreSQL.

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