All perguntas(dba)

Suponha que eu tenha ativado o RCSI e meu servidor esteja funcionando bem; Não houve picos no uso de recursos e o aumento da carga no tempdb foi mínimo. Tudo isso é bom, mas como posso saber se a mudança causou problemas aos meus usuários? Por exemplo, com a finalidade de encontrar problemas causados ​​pelo RSCI que o Read Committed não teria causado, existe algum:

• Mensagens de erro que posso rastrear?
• Scripts de diagnóstico que posso executar?
• Métricas a serem observadas?
• Registrando os desenvolvedores de aplicativos podem colocar seu próprio código?
• Reclamações específicas de usuários para as quais devo estar alerta?

Estou muito feliz em usar o RCSI, mas o objetivo desta pergunta é encontrar maneiras práticas de rastrear o impacto de ativá-lo após o fato.

Temos um MySQL primário rodando em 5.7.40. Estamos testando a atualização para 8.0.36 (no AWS RDS). Tínhamos 2 réplicas MySQL-8 e 2 réplicas MySQL-5.7 replicando do primário. Quase ao mesmo tempo, ambas as réplicas do MySQL 8.0 pararam de replicar e reclamaramHA_ERR_FOUND_DUPP_KEY

 Replica SQL for channel '': Worker 2 failed executing transaction '87953f5d-7595-11ed-830d-02f4790d85ab:57805008598' at source log mysql-bin-changelog.676514, end_log_pos 52858646; Could not execute Write_rows event on table ebdb.bike_issues; Duplicate entry '177235118' for key 'bike_issues.PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's source log mysql-bin-changelog.676514, end_log_pos 52858646, Error_code: MY-001062

Estranhamente, embora as réplicas reclamassem de valores de chave diferentes, o carimbo de data e hora era quase o mesmo (alguns ms de diferença). As réplicas do MySQL 5.7 estavam bem, então claramente não houve problemas no lado primário. Nada aparece nos logs primários nesse período também.

A tabela, reclamou, é uma tabela escrita com muita frequência e já tínhamos essas réplicas do MySQL 8 em execução há mais de uma semana, sem nenhum problema de replicação. Fazemos replicação baseada em linhas e GTID (gtid_mode ON,force_gtid_consistency ON)

Consegui retomar a replicação definindo slave_exec_modecomo IDEMPOTENTtemporariamente. Quando verifico os logs de erros depois que a replicação estava sincronizada, não vi erros para a chave da primeira réplica nos logs de erros da segunda réplica e vice-versa, ou seja, ambos falharam em chaves diferentes. Isso poderia ser algum problema na parte do receptor de replicação? Ou possivelmente algum bug devido à incompatibilidade de versão? Ou alguma incompatibilidade de variável mysql?

Como posso depurar isso ainda mais? O que poderia ter causado esse problema?

EDITAR #1

Saída de criação de tabela no primário

Create Table: CREATE TABLE `bike_issues` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `issue_type` varchar(191) COLLATE utf8mb4_bin NOT NULL,
  `bike_id` int(11) NOT NULL,
  `reported_at` datetime NOT NULL,
  `resolved_at` datetime DEFAULT NULL,
  `resolution_type` varchar(191) COLLATE utf8mb4_bin DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  `token` varchar(191) COLLATE utf8mb4_bin DEFAULT NULL,
  `idempotency_key` varchar(191) COLLATE utf8mb4_bin DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `index_bike_issues_on_token` (`token`),
  UNIQUE KEY `index_bike_issues_on_idempotency_key` (`idempotency_key`),
  KEY `by_bike_id_issue_type_resolved_at` (`bike_id`,`issue_type`,`resolved_at`) USING BTREE,
  KEY `index_bike_issues_on_resolved_at` (`resolved_at`)
) ENGINE=InnoDB AUTO_INCREMENT=177614144 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

Na réplica do MySQL 8

Create Table: CREATE TABLE `bike_issues` (
  `id` int NOT NULL AUTO_INCREMENT,
  `issue_type` varchar(191) COLLATE utf8mb4_bin NOT NULL,
  `bike_id` int NOT NULL,
  `reported_at` datetime NOT NULL,
  `resolved_at` datetime DEFAULT NULL,
  `resolution_type` varchar(191) COLLATE utf8mb4_bin DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  `token` varchar(191) COLLATE utf8mb4_bin DEFAULT NULL,
  `idempotency_key` varchar(191) COLLATE utf8mb4_bin DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `index_bike_issues_on_token` (`token`),
  UNIQUE KEY `index_bike_issues_on_idempotency_key` (`idempotency_key`),
  KEY `by_bike_id_issue_type_resolved_at` (`bike_id`,`issue_type`,`resolved_at`) USING BTREE,
  KEY `index_bike_issues_on_resolved_at` (`resolved_at`)
) ENGINE=InnoDB AUTO_INCREMENT=177614497 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

Na Primária

show variables like '%binlog%';
+--------------------------------------------+----------------------+
| Variable_name                              | Value                |
+--------------------------------------------+----------------------+
| binlog_cache_size                          | 32768                |
| binlog_checksum                            | NONE                 |
| binlog_direct_non_transactional_updates    | OFF                  |
| binlog_error_action                        | IGNORE_ERROR         |
| binlog_format                              | ROW                  |
| binlog_group_commit_sync_delay             | 0                    |
| binlog_group_commit_sync_no_delay_count    | 0                    |
| binlog_gtid_simple_recovery                | ON                   |
| binlog_max_flush_queue_time                | 0                    |
| binlog_order_commits                       | ON                   |
| binlog_row_image                           | FULL                 |
| binlog_rows_query_log_events               | OFF                  |
| binlog_stmt_cache_size                     | 32768                |
| binlog_transaction_dependency_history_size | 25000                |
| binlog_transaction_dependency_tracking     | COMMIT_ORDER         |
| innodb_api_enable_binlog                   | OFF                  |
| innodb_locks_unsafe_for_binlog             | OFF                  |
| log_statements_unsafe_for_binlog           | OFF                  |
| max_binlog_cache_size                      | 18446744073709547520 |
| max_binlog_size                            | 134217728            |
| max_binlog_stmt_cache_size                 | 18446744073709547520 |
| sync_binlog                                | 2000                 |
+--------------------------------------------+----------------------+
mysql> show variables like '%slave%';
+------------------------------+-----------------------+
| Variable_name                | Value                 |
+------------------------------+-----------------------+
| init_slave                   |                       |
| log_slave_updates            | ON                    |
| log_slow_slave_statements    | ON                    |
| pseudo_slave_mode            | OFF                   |
| rpl_stop_slave_timeout       | 31536000              |
| slave_allow_batching         | OFF                   |
| slave_checkpoint_group       | 512                   |
| slave_checkpoint_period      | 300                   |
| slave_compressed_protocol    | OFF                   |
| slave_exec_mode              | STRICT                |
| slave_load_tmpdir            | /rdsdbdata/tmp        |
| slave_max_allowed_packet     | 1073741824            |
| slave_net_timeout            | 60                    |
| slave_parallel_type          | DATABASE              |
| slave_parallel_workers       | 0                     |
| slave_pending_jobs_size_max  | 16777216              |
| slave_preserve_commit_order  | OFF                   |
| slave_rows_search_algorithms | TABLE_SCAN,INDEX_SCAN |
| slave_skip_errors            | OFF                   |
| slave_sql_verify_checksum    | ON                    |
| slave_transaction_retries    | 10                    |
| slave_type_conversions       |                       |
| sql_slave_skip_counter       | 0                     |
+------------------------------+-----------------------+
mysql> show variables where variable_name in  ('gtid_mode', 'enforce_gtid_consistency', 'innodb_flush_log_at_trx_commit');
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| enforce_gtid_consistency       | ON    |
| gtid_mode                      | ON    |
| innodb_flush_log_at_trx_commit | 2     |
+--------------------------------+-------+

Na réplica do MySQL 8.0

mysql> show variables like '%binlog%';
+------------------------------------------------+----------------------+
| Variable_name                                  | Value                |
+------------------------------------------------+----------------------+
| binlog_cache_size                              | 32768                |
| binlog_checksum                                | NONE                 |
| binlog_direct_non_transactional_updates        | OFF                  |
| binlog_encryption                              | OFF                  |
| binlog_error_action                            | ABORT_SERVER         |
| binlog_expire_logs_auto_purge                  | ON                   |
| binlog_expire_logs_seconds                     | 2592000              |
| binlog_format                                  | ROW                  |
| binlog_group_commit_sync_delay                 | 0                    |
| binlog_group_commit_sync_no_delay_count        | 0                    |
| binlog_gtid_simple_recovery                    | ON                   |
| binlog_max_flush_queue_time                    | 0                    |
| binlog_order_commits                           | ON                   |
| binlog_rotate_encryption_master_key_at_startup | OFF                  |
| binlog_row_event_max_size                      | 8192                 |
| binlog_row_image                               | FULL                 |
| binlog_row_metadata                            | MINIMAL              |
| binlog_row_value_options                       |                      |
| binlog_rows_query_log_events                   | OFF                  |
| binlog_stmt_cache_size                         | 32768                |
| binlog_transaction_compression                 | OFF                  |
| binlog_transaction_compression_level_zstd      | 3                    |
| binlog_transaction_dependency_history_size     | 25000                |
| binlog_transaction_dependency_tracking         | COMMIT_ORDER         |
| innodb_api_enable_binlog                       | OFF                  |
| log_statements_unsafe_for_binlog               | OFF                  |
| max_binlog_cache_size                          | 18446744073709547520 |
| max_binlog_size                                | 134217728            |
| max_binlog_stmt_cache_size                     | 18446744073709547520 |
| sync_binlog                                    | 1000                 |
+------------------------------------------------+----------------------+
mysql> show variables where variable_name in  ('gtid_mode', 'enforce_gtid_consistency', 'innodb_flush_log_at_trx_commit');
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| enforce_gtid_consistency       | ON    |
| gtid_mode                      | ON    |
| innodb_flush_log_at_trx_commit | 2     |
+--------------------------------+-------+
mysql> show variables like '%replica%';
+-----------------------------------------------+----------------+
| Variable_name                                 | Value          |
+-----------------------------------------------+----------------+
| group_replication_consistency                 | EVENTUAL       |
| init_replica                                  |                |
| innodb_replication_delay                      | 0              |
| log_replica_updates                           | ON             |
| log_slow_replica_statements                   | OFF            |
| pseudo_replica_mode                           | OFF            |
| replica_allow_batching                        | ON             |
| replica_checkpoint_group                      | 512            |
| replica_checkpoint_period                     | 300            |
| replica_compressed_protocol                   | OFF            |
| replica_exec_mode                             | STRICT         |
| replica_load_tmpdir                           | /rdsdbdata/tmp |
| replica_max_allowed_packet                    | 1073741824     |
| replica_net_timeout                           | 60             |
| replica_parallel_type                         | LOGICAL_CLOCK  |
| replica_parallel_workers                      | 32             |
| replica_pending_jobs_size_max                 | 134217728      |
| replica_preserve_commit_order                 | ON             |
| replica_skip_errors                           | OFF            |
| replica_sql_verify_checksum                   | ON             |
| replica_transaction_retries                   | 10             |
| replica_type_conversions                      |                |
| replication_optimize_for_static_plugin_config | OFF            |
| replication_sender_observe_commit_only        | OFF            |
| rpl_stop_replica_timeout                      | 31536000       |
| skip_replica_start                            | ON             |
| sql_replica_skip_counter                      | 0              |
+-----------------------------------------------+----------------+

Estamos usando o PgAdmin conectando-se a uma instância do PostgreSQL.

Com o PgAdmin, no contexto de Servers > [the_server_login] > Databases > Create > Database, inserimos os parâmetros necessários, esperando permitir que o assistente gere o seguinte exemplo de SQL a partir de um documento.

CREATE DATABASE "Metabase_VM"
    WITH
    OWNER = metabase
    ENCODING = 'UTF8'
    LC_COLLATE = 'en_US.UTF-8'
    LC_CTYPE = 'en_US.UTF-8'
    TABLESPACE = pg_default
    CONNECTION LIMIT = -1
    IS_TEMPLATE = False;

No entanto, até agora, obtivemos apenas o seguinte SQL gerado:

CREATE DATABASE "Metabase_VM"
    WITH 
    OWNER = metabase
    ENCODING = 'UTF8'
    LC_COLLATE = 'en_US.UTF-8'
    LC_CTYPE = 'en_US.UTF-8'
    TABLESPACE = pg_default
    CONNECTION LIMIT = -1;

Nossas perguntas:

O SQL gerado atualmente está faltando IS_TEMPLATE = False, então onde na GUI podemos definir esse parâmetro?

Somos novos no PostgreSQL e no PgAdmin, por isso agradecemos muito quaisquer dicas e sugestões.

Quero mostrar os 10 melhores jogadores de ataque e minha consulta é assim:

SELECT
player_id as id,
player_name as name,
count(attack_id) as attacks, 
sum(result) as victory,
( count(attack_id) - sum(result) ) as defeat,
( sum(result) - ( count(attack_id) - sum(result) ) ) as difference
FROM `my_table_name` 
GROUP BY player_id 
ORDER BY difference DESC
LIMIT 10

A consulta calcula as vitórias, derrotas dos jogadores e a diferença entre vitórias e derrotas. O problema aqui está relacionado ao nome do jogador. O jogador pode alterar um nome após alguns ataques, mas esta consulta retorna o primeiro player_name (relacionado ao player_id), não o último (atual).

Resultado desta consulta (de acordo com meu exemplo, em vez de gato, deveria ser panda, pois foi o nome do ataque do último jogador):

Como posso resolver esse problema?

Configurando MONGO_FDW no Postgres pela primeira vez.

A primeira etapa é adicionar a extensão após conectar-se como postgresusuário padrão:

CREATE EXTENSION mongo_fdw;

O usuário do aplicativo é app_user, então concedo isso:

GRANT CREATE SERVER TO app_user;

Eu então conecto como app_usere emito:

CREATE  SERVER "app_rem_db"
    FOREIGN DATA WRAPPER mongo_fdw
    OPTIONS (
        address 'localhost',
        port '27017'
    );

Mas recebo o erro:

ERROR: foreign-data wrapper "mongo_fdw" does not exist

Se, no entanto, eu executar CREATE SERVERcomo postgresfunciona.

Como posso permitir que outros usuários criem o servidor?

Continuando com o postgresusuário, em seguida crio o MAPEAMENTO DE USUÁRIO:

CREATE USER MAPPING FOR app_user
    SERVER "app_rem_db"
    OPTIONS (username 'app_user_pg', password 'hello123');

Se eu me conectar novamente app_usere tentar criar uma tabela estrangeira, recebo (o mongoDB possui um banco de dados mongo_teste uma coleção testcol):

CREATE FOREIGN TABLE mongo_testtab
(
    data JSON
)
SERVER "app_rem_db"
OPTIONS (database 'mongo_test', collection 'testcol');

Novamente recebo um erro:

ERROR: server "app_rem_db" does not exist

Se eu voltar para postgreso usuário, posso criar a tabela externa.

Mas então, quando tento consultar a tabela, recebo:

select * from mongo_testtab;
ERROR:  relation "mongo_testtab" does not exist
LINE 1: select * from mongo_testtab;

Operamos uma instância do MS SQL Server 2022 (padrão 16.0.4095.4) no Windows Server 2022 (máquina virtual com 32GB de RAM) e tendo problema com a “Memória Modificada” consumida pelo processo sqlservr.exe.

A configuração de memória do SQL Server é a seguinte:

O consumo geral de memória é assim:

Quando olho o que consome essa memória modificada, vejo que é o SQL Server:

Essa parte "modificada" da memória está em constante crescimento e parece nunca diminuir (ela tem se mantido cada vez mais alta há dias). As estatísticas de desempenho do SQL Server não indicam nenhum problema de desempenho no momento.

Além disso, a saída do DBCC MEMORYSTATUS não me dá nenhuma pista sobre o que poderia ser essa parte de "memória modificada". Pelo que entendi a saída (veja abaixo) o consumo de memória relatado pelo DBCC MEMORYSTATUS se enquadra no limite definido em "Memória máxima do servidor".

Você tem alguma ideia do que poderia causar o tipo de consumo de memória muito acima do valor definido em "Memória máxima do servidor" ou como posso investigar mais detalhadamente?

O problema não ocorre em nenhuma outra instância que temos - a "memória modificada" é uma pequena parte do consumo de memória. A única diferença entre esta e outras instâncias é que há vários grupos básicos de disponibilidade configurados nesta caixa. Não são permitidos quaisquer outros "recursos suspeitos" (sem índices columnstore, sem OLPT na memória ...).

O que tentei só por curiosidade é diminuir o valor de "Memória máxima do servidor". O único efeito foi que a “memória em uso” liberada por isso foi lenta mas seguramente trocada para a “memória modificada” em algum tempo. Estou pensando em aumentar a memória da VM, mas temo que isso resulte apenas em um consumo maior de "memória modificada"...

Tenho algumas dúvidas sobre a execução de nós de armazenamento Cassandra 4.1 com nós Cassandra 4.0 exclusivos para coordenadores dedicados. Entendo que alguns recursos específicos do 4.1 não estarão disponíveis com esta topologia.

1. Posso ver diferentes hash de versão do esquema entre os nós Coordenador e Armazenamento, o que é esperado. Até agora, em meus testes, não vi nenhum problema ao fazer alterações no esquema e os nós conseguiram chegar a um acordo de esquema. Pelo que entendi, as restrições de alteração de esquema ocorrem apenas entre as versões principais. Há alguma coisa que estou faltando aqui?
2. Posso verificar se as operações de streaming estão funcionando bem com esta topologia, como reparos e dimensionamento de cluster (adicionando mais nós). Há algum outro problema potencial que não estou pensando?

Obrigado

Olá pessoas mais espertas que eu! Eu criei uma espécie de sistema de tabela de fila, mas parece simples demais para estar protegido contra condições de corrida. Estou faltando alguma coisa ou a seguinte condição de corrida é segura?

O Esquema

Eu tenho uma mesa, vamos chamá-la ProductQueue:

CREATE TABLE dbo.ProductQueue
(
    SerialId BIGINT PRIMARY KEY,
    QueuedDateTime DATETIME NOT NULL -- Only using this for reference, no functionality is tied to it
);

Eu tenho um procedimento para adicionar à fila chamado AddToProductQueue:

CREATE PROCEDURE dbo.AddToProductQueue (@SerialId BIGINT)
AS
BEGIN
    INSERT INTO dbo.ProductQueue (SerialId, QueuedDateTime)
    OUTPUT Inserted.SerialId
    SELECT @SerialId, GETDATE();
END

Também tenho um procedimento para remover da fila chamado RemoveFromProductQueue:

CREATE PROCEDURE dbo.RemoveFromProductQueue (@SerialId BIGINT)
AS
BEGIN
    DELETE FROM dbo.ProductQueue
    OUTPUT Deleted.SerialId
    WHERE SerialId = @SerialId;
END

Observe SerialIdque é globalmente exclusivo para um Productbanco de dados/sistema de origem. Ou seja, duas instâncias de a Productnunca podem ter o mesmo SerialId. Essa é a extensão do lado do banco de dados.

O fluxo de trabalho

• Eu tenho um processo de inscrição que é executado de hora em hora.
• Esse processo obtém uma lista de variáveis SerialIds​​do sistema de origem.
• Ele chama iterativamente o AddToProductQueueprocedimento em cada um SerialIdde sua lista.
• Se o procedimento tentar inserir um SerialIdque já existe na ProductQueuetabela, ele gerará um erro de violação de chave primária e o processo do aplicativo capturará esse erro e o ignorará SerialId.
• Caso contrário, o procedimento adiciona isso SerialIdà ProductQueuetabela com êxito e o retorna ao processo de aplicativo.
• O processo de inscrição então adiciona o que foi enfileirado com sucesso SerialIdem uma lista separada.
• Depois que o processo de aplicativo termina de iterar sua lista de todos os candidatos SerialIdsa serem enfileirados, ele itera sua nova lista de enfileirados com sucesso SerialIdse realiza trabalho externo neles, em um thread separado por SerialId. (Este trabalho não está relacionado ao banco de dados.)
• Finalmente, à medida que cada thread termina seu trabalho externo, a última etapa desse thread assíncrono é removê-lo SerialIdda ProductQueuetabela chamando o RemoveFromProductQueueprocedimento. (Observe que um novo objeto de contexto de banco de dados é instanciado e uma nova conexão é criada para cada chamada assíncrona para esse procedimento, para que ele seja thread-safe no lado do aplicativo.)

Informações adicionais

• Não há índices na ProductQueuetabela e ela nunca terá mais de 1.000 linhas ao mesmo tempo. (Na verdade, na maioria das vezes terá literalmente apenas algumas linhas.)
• O mesmo SerialIdpode se tornar candidato novamente para ser adicionado novamente à tabela de filas em uma futura execução do processo de aplicação.
• Não há proteções que impeçam a execução simultânea de uma segunda instância do processo de aplicativo, seja por acidente ou se a primeira instância demorou mais de 1 hora para ser executada, etc. (Esta é a parte simultânea com a qual estou mais preocupado.)
• O nível de isolamento da transação do banco de dados (e da conexão que está sendo feita) onde residem a tabela de filas e os procedimentos é o nível de isolamento padrão de Read Committed.

Problemas potenciais

• A instância em execução do processo do aplicativo trava de forma não tratada, deixando- SerialIdsa presa na tabela de filas. Isso é aceitável para as necessidades do negócio e planejamos ter relatórios de exceção para nos ajudar a remediar manualmente esse caso.
• O processo do aplicativo é executado várias vezes simultaneamente e captura algumas das mesmas SerialIdsentre as instâncias em suas listas de origem iniciais. Ainda não consigo pensar em nenhuma ramificação negativa deste caso, uma vez que o procedimento de enfileiramento é atômico, e a lista real em SerialIdsque o processo de aplicação funcionará deve ser independente devido a esse procedimento de enfileiramento atômico. Não nos importamos qual instância do processo de aplicativo realmente processa cada uma SerialId, desde que a mesma SerialIdnão seja processada simultaneamente por ambas as instâncias do processo.

Estou encontrando um problema com uma função PL/pgSQL em que ela retorna diferentes tipos de dados com base em uma condição e resulta em um erro de incompatibilidade de tipo. Aqui está uma versão simplificada da função:

CREATE OR REPLACE FUNCTION public.test(lever int)
    RETURNS VARCHAR
    LANGUAGE plpgsql
AS $function$
DECLARE
    _new_record RECORD;
BEGIN
    -- Evaluating the random condition and returning different strings
    IF (lever = 0) THEN
        SELECT * FROM
        (VALUES(uuid_generate_anura()))x(id)
        INTO _new_record;
    ELSE
        SELECT * FROM
        (VALUES(10))x(id)
        INTO _new_record;
    END IF;
    RETURN pg_typeof(_new_record.id)::varchar;
END;
$function$;

Observe que esta é uma versão muito simplificada da minha função completa. Estou interessado em entender por que e como posso contornar isso.

Ao chamar esta função com lever = 0, ela retorna corretamente o texto uuid. No entanto, ao chamá-lo lever = 1para forçar a ELSEexecução da instrução, ocorre um erro:

postgres=# select test(0);
 test 
------
 uuid
(1 row)

postgres=# select test(1);
ERROR:  type of parameter 4 (integer) does not match that when preparing the plan (uuid)
CONTEXT:  PL/pgSQL function test(integer) line 15 at RETURN

Não importa o tipo de dados, o ELSEbloco sempre falhará.

Estou olhando para o servidor IIS que hospeda dezenas de aplicativos. Alguns deles são bem antigos. Todos eles usam cadeias de conexão armazenadas em machine.config em C:\Windows\Microsoft.NET\Framework64.

Todas as cadeias de conexão apontam para o SQL Server 2016 e usam System.Data.SqlClient para conexões:

providerName="System.Data.SqlClient" 

O objetivo é migrar dados para a nova Instância Gerenciada de SQL do Azure e substituir cadeias de conexão para que apontem para o novo servidor.

Na Instância Gerenciada de SQL do Azure, a criptografia para conexões é obrigatória, não é possível desligá-la. Você só pode selecionar a versão mínima do TLS (1.0, 1.1 ou 1.2).

As cadeias de conexão MI contêm arquivos Encrypt=True;TrustServerCertificate=False. Tentei configurar Encrypt=Falseo SSMS para teste, mas a consulta sys.dm_exec_connectionsencrypt_option ainda estava aparecendo TRUE.

Todas as versões do System.Data.SqlClient oferecem suporte à criptografia para conexões ou existem algumas versões antigas que não oferecem suporte?

Perguntando isso porque quero evitar situações em que, após a migração, algum aplicativo possa parar de funcionar porque seu driver cliente não suporta criptografia.