Solucionar problemas de bases de dados espelhadas do Fabric de Azure Database para servidor flexível PostgreSQL

Este artigo aborda os passos de resolução de problemas para configurar a replicação do servidor flexível do Base de Dados do Azure para PostgreSQL.

Resolução de problemas de mensagens de erro / aviso durante a seleção de tabela para espelhamento

Quando cria uma nova base de dados espelhada, na página Escolher dados pode receber algum feedback visual sobre tabelas específicas na base de dados de origem. A tabela seguinte apresenta uma lista de potenciais problemas, incluindo a mensagem apresentada e a descrição relacionada sobre como resolver o problema.

¹ Identificadores de objeto com um carácter espaço (' ') não são suportados.

² Este tipo de tabela não é suportado para espelhamento. Atualmente, vistas, vistas materializadas, tabelas estrangeiras e tabelas particionadas não são suportadas. As hipertabelas TimescaleDB também não são suportadas para Fabric Mirroring.

³ Para uma lista de tipos de dados não suportados, veja Limitações. Apenas colunas com os seguintes tipos são suportadas:

• bigint
• bigserial
• boolean
• bytea
• character
• character varying
• date
• double precision
• integer
• numeric
• real
• serial
• oid
• money
• smallint
• smallserial
• text
• time without time zone
• time with time zone (* não como chave primária)
• timestamp without time zone
• timestamp with time zone
• uuid
• xml
• json
• jsonb
• inet
• cidr
• macaddr
• macaddr8
• tsvector
• tsquery
• int4range
• int8range
• numrange
• tsrange
• tstzrange
• daterange
• circle
• line
• lseg
• box
• path
• point
• polygon
• interval

No Postgres, dois valores de 'tempo com fuso horário' que correspondem exatamente ao mesmo momento, mas em fusos horários diferentes, são considerados diferentes. Por exemplo: 06:24:00.59+05 e 05:24:00.59+04 correspondem à mesma época de época, mas o Postgres trata-os de forma diferente.

Colunas numéricas não restritas por defeito nos esquemas de base de dados de origem (sem precisão e escala definidas) são convertidas para Decimal128(38, 0) antes de serem replicadas para tabelas OneLake, alinhando-se com a convenção padrão SQL de que escala não especificada significa precisão inteira.

Operações de linguagem de definição de dados (DDL) suportadas na base de dados de origem

• Renomear coluna: uma coluna com o novo nome é adicionada à tabela espelhada em Fabric e contém dados das linhas recém-inseridas (para as linhas existentes serão NULL). A coluna antiga continua a ser mantida com os valores das linhas existentes (pois as novas linhas são NULL).
• Adicionar coluna: a coluna adicionada é visível na tabela espelhada e contém dados para linhas recém-inseridas (pois as linhas existentes são NULL).
• Remover coluna: a coluna removida permanece visível na tabela espelhada e contém dados para linhas existentes (pois as novas linhas são NULL).
• Alterar chave primária: a sessão de espelhamento continua normalmente.

Qualquer outra operação DDL em tabelas de origem não é atualmente suportada e pode causar falhas de replicação.

Alterações na capacidade do Fabric ou no espaço de trabalho

Consultas SQL para resolução de problemas

Se estiver a ter problemas de espelhamento, ligue-se ao servidor fonte Base de Dados do Azure para PostgreSQL e realize estas verificações usando visualizações e funções do sistema para validar a configuração.

1. Execute a seguinte consulta para validar se todos os pré-requisitos são cumpridos antes de iniciar o espelhamento CDC. Esta função verifica vários requisitos do sistema e de configuração para garantir que o servidor está pronto para operações do CDC.

-- Check if all prerequisites are met
SELECT * FROM azure_cdc.check_prerequisites();

-- Example output when all checks pass (on mock mode with identity configured):
 status |                                                               data
--------+----------------------------------------------------------------------------------------------------------------------------------
 ERROR  | [{"status": "ERROR", "details": {"current_value": "12", "required_value": "13"}, "status_code": "MAX_WORKER_PROCESSES_TOO_LOW"}]

-- Example output on standby replica:
 status |                                               data
--------+---------------------------------------------------------------------------------------------------
 ERROR  | [{"status": "ERROR", "status_code": "SERVER_IN_RECOVERY"}]

-- Example output when identity not configured:
 status |                                data
--------+---------------------------------------------------------------------
 ERROR  | [{"status": "ERROR", "status_code": "IDENTITY_NOT_CONFIGURED"}]

Retornos:(status text, data jsonb)

• status: Estado geral - OK se todos os testes passarem, ERROR se algum teste falhar
• data: array JSONB contendo entradas de estado detalhadas com status, status_code, e details opcional

Códigos de Estado:

2. Execute a seguinte consulta para validar se as tabelas na sua base de dados de origem são elegíveis para replicação. Exclui esquemas de sistema (pg_catalog, information_schema, pg_toast) e tabelas pertencentes à extensão.

SELECT * FROM azure_cdc.get_all_tables_mirror_status();
 table_schema | table_name | mirroring_status |                      mirroring_data
--------------+------------+------------------+------------------------------------------------------
 public       | customers  | OK               | [{"status": "OK", "status_code": "HAS_PRIMARY_KEY"}]
 public       | orders     | OK               | [{"status": "OK", "status_code": "HAS_UNIQUE_INDEX"}]
 public       | logs       | WARNING          | [{"status": "WARNING", "status_code": "NO_INDEX_FULL_IDENTITY"}]

Retornos: Conjunto de (table_schema text, table_name text, mirroring_status text, mirroring_data jsonb)

• table_schema: Nome do esquema da tabela
• table_name: Nome da tabela
• mirroring_status: Estado geral - OK, WARNING, ou ERROR
• mirroring_data: array JSONB contendo entradas de estado detalhadas com status, status_code e opcionais details

Códigos de Estado:

3. Execute a consulta seguinte para devolver erros e problemas detetados durante operações de replicação, incluindo erros a nível de sistema, erros específicos de publicação e erros por tabela.

-- Get only system-wide errors
SELECT * FROM azure_cdc.get_health_status('', '');

-- Get system-wide errors and publication-specific errors
SELECT * FROM azure_cdc.get_health_status('my_database', 'my_publication');

Parâmetros:

• db_name (texto): Nome da base de dados
• pub_name (texto): Nome da publicação

Comportamento:

• Quando chamado com cadeias vazias para ambos os parâmetros (azure_cdc.get_health_status('', '')): Retorna apenas erros a nível de sistema (tipo de erro 'S').
• Quando invocada com nomes válidos de base de dados e publicação: Retorna tanto erros a nível de sistema como erros específicos de publicação/tabela para a publicação especificada.

Retornos: Conjunto de (error_time timestamptz, schema_name text, table_name text, error_type char(1), error_code text, params jsonb)

Tipos de Erro:

Códigos de Erro:

4. Execute a seguinte consulta para verificar se a publicação foi criada corretamente e se as alterações de replicação fluem corretamente:

   select * from azure_cdc.tracked_publications;
   

   Verifique se a publicação está ativa e se o snapshot foi gerado. Também pode verificar se foram gerados lotes de alterações subsequentes através de consultas:

   select * from azure_cdc.tracked_batches;
   

5. Se a azure_cdc.tracked_publications visualização não mostrar qualquer progresso no processamento de alterações incrementais, execute a seguinte consulta SQL para verificar se há problemas reportados:

   SELECT * FROM pg_stat_activity WHERE state = 'idle in transaction';
   

6. Se não forem reportados problemas, execute o seguinte comando para rever a configuração atual da base de dados PostgreSQL espelhada. Confirme se ele foi ativado corretamente.

   SELECT * FROM pg_replication_slots;
   

   As principais colunas a procurar aqui são as slot_name e active. Qualquer valor diferente de t (true) indica um problema potencial.

7. Entre em contato com o suporte se a solução de problemas for necessária.

Identidade gerenciada

A Identidade Gerida Atribuída ao Sistema (SAMI) do servidor flexível Base de Dados do Azure para PostgreSQL precisa de estar ativada e deve ser a identidade principal. Para mais informações, consulte Identidade gerida atribuída pelo sistema para o servidor flexível PostgreSQL.

Após a ativação, se o estado da configuração SAMI for posteriormente desativado e novamente ativado, o espelhamento do servidor flexível "Base de Dados do Azure para PostgreSQL" para o Fabric OneLake falha.

Verifique se o SAMI está ativado com a seguinte consulta: show azure.service_principal_id;

Permissões SAMI

Não remova as permissões do contributo do Base de Dados do Azure para PostgreSQL para servidor flexível System Assigned Managed Identity (SAMI) no item espelhado da base de dados Fabric.

Se remover acidentalmente permissões SAMI, o Mirroring Base de Dados do Azure para PostgreSQL flexible server não funciona como esperado. Nenhum novo dado pode ser espelhado do banco de dados de origem.

Se remover as permissões SAMI do servidor flexível do Base de Dados do Azure para PostgreSQL ou se as permissões não estiverem configuradas corretamente, use os seguintes passos.

1. Adicione o servidor flexível SAMI como utilizador selecionando a ... opção de elipses no item espelhado da base de dados.
2. Selecione a opção Gerenciar permissões .
3. Insira o nome do Base de Dados do Azure para PostgreSQL flexible server. Forneça permissões de Leitura e Gravação.

Conteúdo relacionado

• Limitações do Microsoft Fabric Data Warehouse
• Perguntas frequentes sobre a replicação da Base de Dados do Azure para PostgreSQL em servidor flexível no Microsoft Fabric