All perguntas(dba)

AFAICT quando você envia uma consulta ao MySQL de qualquer cliente, ele sempre bloqueia e espera que o servidor responda com sucesso ou falha.

Ao executar uma operação lenta, como adicionar um novo índice em uma tabela grande, isso pode ser um problema, pois deixa o cliente em estado ocioso, aguardando muito tempo pela resposta.

No meu caso, especificamente, quero enviar a solicitação da função AWS Lambda.

Encontrei algumas dicas aqui https://stackoverflow.com/a/41371255/202168 sobre como desanexar e colocar o mysqlprocesso do cliente em segundo plano, e também algumas sugestões de que o servidor MySQL provavelmente cancelará a solicitação se o cliente fechar a conexão. Mas o host onde o mysqlcliente foi lançado ainda precisa continuar em execução.

Parece que isso não pode ser tudo o que existe?

O PostgreSQL tem CREATE INDEX CONCURRENTLYpara esse propósito, ou seja, a consulta retorna rapidamente e a construção do índice continua no servidor.

Estou ciente de que o MySQL não suportaCREATE INDEX CONCURRENTLY

Mas é estranho que não exista um método de cliente sem bloqueio? (bem... existem clientes "assíncronos" ou "sem bloqueio", mas eles ainda precisam manter a mesma conexão aberta)

O que eu quero fazer é algo como:

• envie uma ALTER TABLE ... ADD KEYconsulta
• obtenha o ID do processo do lado do servidor para a consulta
• faça logoff do cliente mysql (e encerre minha execução do Lambda)
• o ADD KEYcontinua rodando no servidor
• de um novo processo, pesquise periodicamente o ID do processo da minha consulta DDL e veja se ele foi concluído ou falhou

Existe alguma maneira de conseguir isso?

Pergunta relacionada ou alternativa: se eu simplesmente desconectar o cliente após enviar a consulta, a ADD KEYexecução continuará até a conclusão/falha em vez de ser cancelada?

O servidor é MySQL 8.0.35 em tabelas AWS RDS e InnoDB.

Atualmente usando Postgres 14.

A execução CLUSTER sometable USING someindex;é ótima, mas existe uma consulta para determinar o quão "desclusterizada" a tabela se tornou após muitas atualizações e exclusões?

Pesquisando e lendo https://www.postgresql.org/docs/14/sql-cluster.html apenas diz "configure um script de manutenção periódica ... para que as tabelas desejadas sejam periodicamente reclusteradas", o que é inútil, pois não não dá nenhuma indicação de como determinar quão periódica deve ser a reagrupamento periódico.

O que acontece quando ocorre um tempo limite do cliente durante a execução de um procedimento armazenado que gera XACT_ABORT e envolve seu corpo em blocos TRY/CATCH?

Estou analisando vários procedimentos que geralmente podem ser convertidos em um MWE da seguinte maneira:

create or alter procedure ##ptx
as
begin try
    set xact_abort on
    waitfor delay '10:00'
end try
begin catch
    declare @xsx int = XACT_STATE()
    raiserror('XSX=%d', 16, 10, @xsx) with log, nowait
end catch

Eu criei um equipamento de teste que efetua login no servidor como SA, chama esse procedimento de forma assíncrona e expira a chamada após X segundos, mas antes que o atraso deva acabar. Não há novas entradas no log, então parece que a execução não entra no bloco CATCH quando ocorre um tempo limite. Deveria? Caso contrário, o que acontece quando o tempo limite do cliente é atingido?

Recentemente, configurei um Grupo de Disponibilidade Distribuída (DAG) entre um Grupo de Disponibilidade Always On (AG) local existente e um novo AG na AWS. O AG local atua como primário, enquanto o AG da AWS atua como secundário. Configurei inadvertidamente a propagação automática sem perceber que ela começaria a propagar todos os bancos de dados imediatamente.

Meu problema é que preciso replicar apenas cerca de 10 bancos de dados para o AG secundário e, desses, apenas cinco bancos de dados precisam ser replicados para a réplica secundária do AG secundário. Tentei definir "HADR OFF" para os bancos de dados indesejados, mas só funciona na réplica secundária. O comando é executado com êxito no encaminhador, mas os bancos de dados nunca são realmente removidos.

Encontrei vários artigos explicando como remover um banco de dados de um DAG, mas todos sugerem executar os comandos da réplica primária do AG primário. No entanto, estou preocupado que essa abordagem também possa remover o banco de dados do AG local, o que não é minha intenção. Desejo apenas remover os bancos de dados da réplica secundária do AG de distribuição secundária.

Então, minhas perguntas são:

• Alguém encontrou uma situação semelhante ou sabe como remover bancos de dados específicos do AG secundário em uma configuração do DAG sem afetar o AG primário?
• Se eu remover o DAG e começar de novo, mas optar por propagar manualmente, isso me permitiria selecionar quais bancos de dados serão replicados por meio do DAG?

Eu apreciaria muito quaisquer insights, sugestões ou orientações passo a passo sobre como conseguir isso. Agradeço antecipadamente por sua ajuda!

Tenho um cenário em que desejo criar um Grupo de Disponibilidade Distribuída (DAG) do SQL Server que se estende por dois Grupos de Disponibilidade (AGs) existentes que residem no mesmo conjunto de instâncias do SQL Server. Aqui está a configuração:

• Tenho um Grupo de Disponibilidade chamado "ag1" com duas réplicas: "instance1" e "instance2".
• Também tenho outro Grupo de Disponibilidade chamado "ag2" com as mesmas duas réplicas: "instance1" e "instance2".

Meu objetivo é criar um Grupo de Disponibilidade Distribuída chamado "distag1" que englobe "ag1" e "ag2". Segui a documentação e tentei criar "distag1" no primário global (a réplica primária de "ag1"). Foi criado com sucesso. No entanto, quando tentei ingressar na outra extremidade de "distag1" (a instância para a qual o ouvinte de ag2 aponta), encontrei o seguinte erro:

ALTER AVAILABILITY GROUP distag1
JOIN AVAILABILITY GROUP ON
N'ag1' WITH (
    LISTENER_URL = N'TCP://ag1lsnr:5022',
    FAILOVER_MODE = MANUAL,
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    SEEDING_MODE = MANUAL
),
N'ag2' WITH (
    LISTENER_URL = N'TCP://ag2lsnr:5022',
    FAILOVER_MODE = MANUAL,
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    SEEDING_MODE = MANUAL
);


Msg 19509, Level 16, State 0, Line 38
Cannot create a distributed availability group 'distag1'. An availability group with the same name already exists.

Minha pergunta é:

• Há suporte para criar um Grupo de Disponibilidade Distribuído em dois Grupos de Disponibilidade que residem no mesmo conjunto de instâncias do SQL Server?
• Se for compatível, o que pode estar causando a mensagem de erro que encontrei? Há algum requisito ou consideração específica que preciso levar em consideração ao criar um DAG neste cenário?

Eu apreciaria muito qualquer informação, esclarecimento ou orientação sobre este assunto. Agradeço antecipadamente por sua ajuda!

Tenho uma dúvida sobre a configuração dos Grupos de Disponibilidade Distribuída (DAGs) do SQL Server. Entendo que um DAG é usado para replicar dados de um Grupo de Disponibilidade (AG) para outro. No entanto, estou curioso sobre a possibilidade de ter vários AGs de réplica secundária para um único DAG.

Especificamente, digamos que eu tenha um Grupo de Disponibilidade Distribuída chamado “dag1”. É possível que "dag1" replique dados de um Grupo de Disponibilidade primário "ag1" para vários Grupos de Disponibilidade secundários, como "ag2" e "ag3"?

Em outras palavras, um único DAG pode ter um relacionamento um-para-muitos com AGs de réplica secundária?

Eu apreciaria muito se alguém pudesse esclarecer se esta configuração é suportada e fornecer informações ou considerações adicionais ao configurar um DAG com vários AGs de réplica secundária.

Agradeço antecipadamente por sua ajuda!

O banco de dados em questão: AWS RDS, MySQL 8, InnoDB. Armazenamento GP3.

Estou tentando fazer uma inserção em massa de linhas em várias tabelas no banco de dados.

Omiti todos os índices secundários da tabela de destino, ela possui apenas PK. A tabela de destino não está particionada.

Os dados de origem para a importação (que não estão no MySQL) são particionados por intervalo de datas. Para cada partição eu tenho um script que seleciona um lote de dados e os insere no MySQL. Os scripts de loop em lote por partição estão sendo executados simultaneamente em paralelo.

Cada lote é carregado como um dataframe do pandas por tabela, várias transformações são feitas e, em seguida, os dataframes do lote são inseridos no MySQL (em uma transação de banco de dados) usando o to_sqlmétodo de inserção "multi" do pandas.

Posso pensar em várias maneiras de melhorar isso. Duas sugestões que aparecem em todos os conselhos de inserção em massa do MySQL são: a) inserir na ordem PK eb) usar LOAD DATA IN FILE. Atualmente não estou fazendo nenhum dos dois. Mas antes de reescrever radicalmente todo o código, gostaria de entender o sintoma que vejo quando executo o código atual:

Podemos ver a importação em execução por aproximadamente 1 hora. O número de scripts em lote paralelos é totalmente consistente. O tamanho do lote é consistente por toda parte. Cada lote leva cerca de 60 segundos para ser processado e inserido. No gráfico acima, cerca de 200 lotes (vários milhões de linhas) são processados ​​com sucesso. Mas o IOPS aumenta aproximadamente linearmente por 30 minutos até atingir o limite provisionado e ser limitado.

Minha pergunta é: se minha taxa de inserção é constante, por que o IOPS continua aumentando linearmente?

Estou importando cerca de 50 milhões de linhas para MySQL 8, InnoDB. Está no AWS RDS com armazenamento GP3.

A chave exclusiva das linhas é uma string semelhante a uuid.

Ao consultar, nunca nos importaremos com essa chave exclusiva, exceto ao atualizar linhas novas/modificadas da fonte primária.

Normalmente, o ID exclusivo seria o PK. Mas eu li que o índice PK no MySQL é especial porque visa 'agrupar' os dados para valores semelhantes, para melhorar o desempenho.

Parece que ao usar uma string semelhante a uuid como PK, o clustering não ajudará em nossas consultas.

Se eu particionasse a tabela, faria isso por intervalo de datas.

Eu poderia imaginar definir uma PK sintética, ou uma PK composta, que combine o campo de data e o uuid para obter um cluster com maior probabilidade de suportar as consultas que realmente fazemos.

Minha pergunta é a seguinte: quão importante é ter um cluster PK que suporte as consultas típicas (ou seja, os resultados obtidos provavelmente estarão 'próximos' no índice)?

Presumivelmente, o caso típico de um ID de incremento automático para PK também resulta em clustering que tem pouca relação com consultas típicas (muitas vezes não há razão para selecionar IDs adjacentes).

Estou pensando especificamente se o armazenamento SSD moderno torna esse tipo de otimização menos importante, obsoleto... ou ainda mais importante?

Mais contexto

https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html

Como o índice clusterizado acelera as consultas

Acessar uma linha por meio do índice clusterizado é rápido porque a pesquisa do índice leva diretamente à página que contém os dados da linha. Se uma tabela for grande, a arquitetura de índice clusterizado geralmente salva uma operação de E/S de disco quando comparada a organizações de armazenamento que armazenam dados de linha usando uma página diferente do registro do índice.

Parece que o "agrupamento" do índice PK só tem valor para consultas selecionadas por PK.

Trata-se de co-localizar os dados da linha com o índice (?)

Então, se todas as consultas de aplicativos que me interessam usam índices secundários, acho que realmente não importa quais são as propriedades do PK? por exemplo, incluir uma coluna de partição de data no PK não vai acelerar magicamente as consultas usando um índice diferente.

Isso está certo?

Realizei uma redução manual do banco de dados no SQL Server Management Studio e preciso verificar quanto tempo demorou para ser concluído (duração da execução). Existe um log específico, tabelas/visualizações do sistema que eu possa verificar para encontrar esse tipo de informação, por favor?

Eu tenho uma coluna com valor como este.

Declare @Table TABLE (ID int, Val varchar(100))

Insert into @Table
Select 1, 'happy_Summer_Holiday_by_Jan_2024.xlsx'

Quero extrair dinamicamente janeiro como mês e 2024 como ano.