Solucionar problemas de bancos de dados espelhados da solução Fabric no servidor flexível do Banco de Dados do Azure para PostgreSQL

Este artigo aborda as etapas de solução de problemas para replicar servidores flexíveis do Azure Database para PostgreSQL.

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

Ao criar um novo banco de dados espelhado, na página Escolher dados , você poderá receber alguns comentários visuais sobre tabelas específicas no banco de dados de origem. A tabela a seguir fornece uma lista de possíveis problemas, incluindo a mensagem exibida e a descrição relacionada sobre como resolver o problema.

¹ Não há suporte para identificadores de objeto com um caractere de espaço (' ').

² Este tipo de tabela não tem suporte para espelhamento. Atualmente, não há suporte para exibições, exibições materializadas, tabelas estrangeiras e tabelas particionadas. Hipertabelas do TimescaleDB também não têm suporte para o espelhamento de Fabric.

³ Para obter uma lista de tipos de dados sem suporte, consulte Limitações. Há suporte apenas para colunas com os seguintes tipos:

• 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 uma 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 "hora com fuso horário" que correspondem exatamente ao mesmo momento, mas em fusos horários diferentes, são tratados como distintos. Por exemplo: 06:24:00.59+05 e 05:24:00.59+04 correspondem ao mesmo tempo de época, mas o Postgres os trata de forma diferente.

Colunas numéricas sem restrições em esquemas de bancos de dados de origem (sem precisão e escala definidas) são convertidas em Decimal128(38, 0) antes de serem replicadas em tabelas OneLake, alinhando-se à convenção padrão do SQL, onde a escala não especificada significa precisão de número inteiro.

Operações de DDL (linguagem de definição de dados) com suporte no banco de dados de origem

• Renomear coluna: uma coluna com o novo nome é adicionada à tabela espelhada no Fabric e contém dados para linhas recém-inseridas (para linhas existentes é NULL). A coluna antiga ainda é mantida com valores para as linhas existentes (para 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 (para linhas existentes são NULL).
• Remover coluna: a coluna removida permanece visível na tabela espelhada e contém dados para linhas existentes (nas novas linhas, os dados são NULL).
• Alterar chave primária: a sessão de espelhamento continua regularmente.

No momento, não há suporte para qualquer outra operação DDL em tabelas de origem e pode causar falhas de replicação.

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

Consultas SQL para solução de problemas

Se você estiver enfrentando problemas de espelhamento, conecte-se ao servidor de Banco de Dados do Azure para PostgreSQL de origem e execute essas verificações usando exibições e funções do sistema para validar a configuração.

1. Execute a consulta seguinte para verificar se todos os pré-requisitos são atendidos antes de iniciar o espelhamento CDC. Essa função verifica vários requisitos de sistema e configuração para garantir que o servidor esteja pronto para operações 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"}]

Retorna:(status text, data jsonb)

• status: status geral - OK se todas as verificações forem aprovadas, ERROR se alguma verificação falhar
• data: matriz JSONB que contém entradas de status detalhadas com status, status_codee opcional details

Códigos de status:

2. Execute a consulta a seguir para validar se as tabelas no banco de dados de origem estão qualificadas para replicação. Exclui esquemas do sistema (pg_catalog, information_schema, pg_toast) e tabelas pertencentes a extensões.

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"}]

Retorna: 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: status geral - OK, WARNING, ou ERROR
• mirroring_data: matriz JSONB que contém entradas de status detalhadas com status, status_codee opcional details

Códigos de status:

3. Execute a consulta a seguir para retornar erros e problemas detectados durante operações de replicação, incluindo erros em todo o 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 do banco de dados
• pub_name (texto): nome da publicação

Comportamento:

• Quando chamado com cadeias de caracteres vazias para ambos os parâmetros (azure_cdc.get_health_status('', '')): retorna somente erros em todo o sistema (tipo de erro 'S').
• Quando chamado com nomes válidos de banco de dados e publicação: retorna erros em todo o sistema e erros específicos de publicação/tabela para a publicação especificada.

Retorna: 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 consulta a seguir para verificar se a publicação foi criada corretamente e as alterações de replicação fluem corretamente:

   select * from azure_cdc.tracked_publications;
   

   Verifique se a publicação está ativa e se o instantâneo foi gerado. Você também pode verificar se os lotes de alteração subsequentes foram gerados consultando:

   select * from azure_cdc.tracked_batches;
   

5. Se a exibição azure_cdc.tracked_publications não mostrar nenhum progresso no processamento de alterações incrementais, execute a seguinte consulta SQL para verificar se há algum problema relatado:

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

6. Se não houver nenhum problema relatado, execute o comando a seguir para examinar a configuração atual do banco de dados PostgreSQL espelhado. Confirme se ele foi habilitado corretamente.

   SELECT * FROM pg_replication_slots;
   

   As colunas de chave a serem procuradas aqui são slot_name e active. Qualquer valor além t (true) indica um possível problema.

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

Identidade gerenciada

A SAMI (Identidade Gerenciada Atribuída pelo Sistema) do servidor flexível do Banco de Dados do Azure para PostgreSQL precisa ser habilitada e deve ser a identidade primária. Para obter mais informações, consulte a identidade gerenciada atribuída pelo sistema para o servidor flexível postgreSQL.

Após a habilitação, se o status de configuração do SAMI for posteriormente desabilitado e depois habilitado novamente, o espelhamento do servidor flexível do Banco de Dados do Azure para PostgreSQL no Fabric OneLake falhará.

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

Permissões SAMI

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

Se você remover permissões SAMI, o Espelhamento do Banco de Dados do Azure para o servidor flexível PostgreSQL não funcionará conforme o esperado, acidentalmente. Nenhum dado novo pode ser espelhado do banco de dados de origem.

Se você remover permissões SAMI do Azure Database para servidor flexível PostgreSQL ou as permissões não estiverem configuradas corretamente, use os passos a seguir.

1. Adicione o servidor flexível SAMI como um usuário selecionando a opção de reticências ... no item de banco de dados espelhado.
2. Selecione a opção Gerenciar Permissões .
3. Insira o nome do servidor flexível do PostgreSQL no Banco de Dados do Azure. 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 do servidor flexível do Azure Database para PostgreSQL no Microsoft Fabric