Tenho três clientes que usam MariaDB para seus aplicativos.
Por questão de segurança, criei uma VM para cada um deles que possui 2vCPU e 4GB de RAM.
Mas eu queria saber se fundir seus servidores seria uma má ideia, já que eles se beneficiariam de um servidor MUITO mais poderoso e isso me custaria um pouco menos em taxas de nuvem.
Quais seriam os benefícios em termos de potência versus segurança?
Estou mexendo no SQL Server 2019 e na replicação transacional há algum tempo e me deparei com um obstáculo. Olhando para o monitor de replicação, estou vendo o erro "A linha não foi encontrada no Assinante ao aplicar o comando UPDATE replicado para a Tabela '[dbo].[MessageQueue]' com Chave(s) Primária(s): [Id] = 6039250" . Este erro ocorre logo no primeiro lote que o distribuidor envia ao assinante.
Eu sei que a linha acima foi adicionada após meu backup do editor, mas eu esperava que o INSERT fosse replicado antes do UPDATE.
Editor/distribuidor: padrão local do SQL Server 2019
Assinante: Instância Gerenciada de SQL
Estou usando o método de backup/restauração para inicializar, pois quando coloco isso em produção, estou lidando com um banco de dados de 2 TB. Meu banco de dados de teste tem apenas 150 GB.
Abaixo está o processo que segui para levantar as coisas:
COPY_ONLY.CREATE CREDENTIAL [credential_name_here]
WITH IDENTITY = '<storage account name>',
SECRET = '<redacted>'
BACKUP DATABASE [myDatabase] TO URL = N'https://<redacted>.blob.core.windows.net/backups/myDatabase_replication.bak'
WITH CREDENTIAL = 'credential_name_here'
,COMPRESSION, COPY_ONLY, STATS = 5
use master
RESTORE DATABASE [myDatabase]
FROM URL = N'https://<redacted>.blob.core.windows.net/backups/myDatabase_replication.bak'
Observe que tenho algumas opções comentadas. Tentei usar @sync_type, @backupdevicetype& @backupdevicenamemas não consegui superar o erro 'Não é possível abrir o dispositivo de backup' https://redacted.blob.core.windows.net/backups/myDatabase_replication.bak '. Erro 86 do sistema operacional (A senha de rede especificada não está correta). '.
Por alguma razão desconhecida, sp_addsubscription não suporta a passagem de uma credencial... bem, pelo que pude encontrar de qualquer maneira.
USE [myDatabase]
GO
EXEC sp_addsubscription
@publication = N'pub_myDatabase',
@subscriber = '<redacted>.<redacted>.database.windows.net',
@destination_db = N'myDatabase',
@sync_type = 'replication support only',
--@sync_type = 'initialize with backup',
--@backupdevicetype ='URL',
--@backupdevicename = 'https://<redacted>.blob.core.windows.net/backups/myDatabase_replication.bak',
@article = N'all',
@update_mode = N'read only',
@subscriber_type = 0
-- Configure the Distribution Agent job
exec [myDatabase]..sp_addpushsubscription_agent
@publication = N'pub_myDatabase',
@subscriber = '<redacted>.<redacted>.database.windows.net',
@subscriber_db = N'myDatabase',
@job_login = NULL, @job_password = NULL,
@subscriber_security_mode = 0,
@subscriber_login = '<redacted>', @subscriber_password = '<redacted>',
@frequency_type = 64, @frequency_interval = 0, @frequency_relative_interval = 0, @frequency_recurrence_factor = 0, @frequency_subday = 0, @frequency_subday_interval = 0 -- Continuous
GO
-- Start Distribution agent
exec [myDatabase]..sp_startpushsubscription_agent
@publication = N'pub_myDatabase',
@subscriber = '<redacted>.<redacted>.database.windows.net',
@subscriber_db = N'myDatabase'
GO
É nesse ponto que verifico o monitor de replicação e vejo o erro citado anteriormente. Qualquer dica e/ou orientação seria muito apreciada!
Dado:
postgres=# create table testing(a int primary key, b int not null);
CREATE TABLE
postgres=# create index on testing (b) where b = 0;
CREATE INDEX
postgres=# \d testing
Table "public.testing"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
a | integer | | not null |
b | integer | | not null |
Indexes:
"testing_pkey" PRIMARY KEY, btree (a)
"testing_b_idx" btree (b) WHERE b = 0
Ao INSERTinserir uma nova linha onde b!= 0, pagarei a penalidade de atualizar o índice?
Idealmente, gostaria de acelerar as consultas com um valor b= 1sem adicionar atraso na inserção de novas linhas onde b!= 0.
Haverá uma maneira de excluir ou incluir apenas índices espaciais da ferramenta IndexOptimize ?
Preciso chamar um procedimento armazenado a cada 10 minutos e estou utilizando um evento recorrente, o problema é que ele não é executado ou não sei como posso ver se há algum erro
Procedimento:
CREATE DEFINER=`root`@`%` PROCEDURE `simertg`.`estados_parqueos`()
BEGIN
set @HORA:= DATE_FORMAT(NOW( ),"%H:%i:00");
set @FECHA:= DATE_FORMAT(NOW( ),"%Y-%m-%d");
set @ID:=0;
select @ID:= estacionamiento_id from Estacionamiento_parqueo where tiempo_salida_t=@HORA and fecha=@FECHA;
UPDATE Estacionamiento_usuario_estacionamiento set estado=0 where estacionamiento_id=@ID;
END
Evento:
CREATE EVENT actualizar
ON SCHEDULE EVERY 10 MINUTE
STARTS '2024-07-17 00:00:00.000'
ON COMPLETION PRESERVE
DISABLE ON SLAVE
DO CALL estados_parqueos()
Quando tento ver o status, fica assim:
+-------------+---------+---------------------+
| EVENT_NAME | STATUS | LAST_EXECUTED |
+-------------+---------+---------------------+
| actualizar | SLAVESIDE_DISABLED| 2024-07-17 11:15:55 |
+-------------+---------+---------------------+
Temos cerca de 100 alterações simples para fazer em nosso esquema de banco de dados, como esta:
alter table transactions alter customer_sport_id type bigint;
Antes era int4. A maioria das colunas alteradas possui um ou mais índices.
Cada um leva cerca de 30 a 45 minutos em uma poderosa instância RDS dedicada (db.r6i.4xlarge) sem outra carga.
Temos que confirmar após cada linha para evitar o uso de todo o armazenamento.
O problema é que é lento, levará dias para fazer as alterações e não podemos ficar inativos por tanto tempo.
Há algo que possamos fazer para acelerar isso? Por exemplo
Aparentemente, colocamos aspirador uma vez por semana.
Aqui estão as estatísticas de desempenho do banco de dados da última hora (você pode ver no lançamento do armazenamento que duas instruções foram concluídas):
Temos um SQL Server 2022 CU13 Enterprise em uma VM Windows 2022 com 8 vCPU. O processo sqlserver.exe mostra uma alta utilização da CPU entre 10-15%, mesmo quando não há carga gerada pelo usuário (o que significa que não há conexão do usuário no momento, até mesmo o SQL Server Agent é interrompido para eliminar toda carga que não seja do sistema) em o servidor. O tipo de espera dominante é SOS_SCHEDULER_YELD nesse tempo ocioso.
Essa atividade do servidor também bloqueia a interrupção do serviço SQL Server. Uma tentativa de interromper o serviço resulta em uma espera interminável e o processo de serviço do Windows precisa ser encerrado para "parar". Após a reinicialização, a utilização funciona perfeitamente por algum tempo (o servidor inativo tem */- 0 utilização de CPU), mas após algum período de tempo (algumas horas ou alguns dias no máximo) com a carga do usuário em execução, o problema volta novamente . Significa que a utilização é maior do que deveria ser com a carga do usuário gerada e, novamente, após a carga ser interrompida (sem conexões do usuário), a utilização permanece alta conforme mencionado acima...
Não há mensagens suspeitas no log de erros, na sessão de integridade do XE, no log de eventos do Windows...
Aqui está a visualização do Activity Monitor no servidor durante o período ocioso descrito acima:
Após alguma investigação, provavelmente identifiquei o SPID, que causa essa utilização. Parece ser um SPID do sistema (SPID 37 no momento da investigação) e consome cerca de 10 segundos de tempo de CPU em um período de 10 segundos (veja a saída da Consulta 4 abaixo). O database_id do SPID parece estar mudando entre o mestre (database_id = 1) e um dos bancos de dados do usuário (database_id = 10). Apenas os IDs de bancos de dados 1 e 10 parecem estar envolvidos nesta atividade SPID. O SPID também está gerando uma alocação cada vez maior no tempdb (veja a saída da Consulta 3 abaixo).
Aqui está a saída do sys.dm_exec_request ao mesmo tempo em que a imagem do Activity Monitor acima foi tirada (o spid problemático é o 37):
Aqui está a saída de sp_WhoIsActive ao mesmo tempo:
Aqui está um cálculo do tempo de CPU consumido para o SPID durante o período de 10 segundos:
Pelo que entendi, parece ser uma atividade do Service Broker. No entanto, não há Service Broker habilitado no banco de dados mestre nem no banco de dados do usuário. Não usamos ativamente o Service Broker em nossos bancos de dados. Não tenho ideia do que possa ser essa atividade do corretor e com que atividade do sistema ela pode estar conectada. Não há nenhum recurso "incomum" usado no servidor ou no banco de dados do usuário, apenas um "conjunto básico de recursos comuns", o único "recurso incomum" é o TDE habilitado.
Alguma idéia de como posso investigar melhor a causa raiz desse problema (do que se trata essa atividade do corretor) e como posso me livrar dele?
Executando o SQL Server 2019 Enterprise. Eu tenho um grupo de arquivos PRIMÁRIO, mas também adicionei quatro arquivos ndf em um grupo de arquivos Data1 que criei. Como esperado, tive que aumentar o espaço disponível no grupo de arquivos Data1 à medida que mais dados eram adicionados, mas o grupo de arquivos PRIMARY mdf permaneceu relativamente estático em tamanho. Nos últimos meses tive que aumentar o espaço no grupo de arquivos PRIMARY. Começou com 5 GB e expandi para 10 GB há algumas semanas. Fiquei sem espaço novamente e acabei de chegar a 15 GB. O grupo de arquivos Data1 é o grupo de arquivos padrão. Por que o grupo de arquivos PRIMARY estaria crescendo repentinamente agora, quando não é o padrão? Cada um dos arquivos Data1 está configurado para 160 GB, então PRIMARY ainda é consideravelmente menor. Gostaria de saber se existe uma maneira de determinar por que ele está crescendo inesperadamente quando estava estagnado no passado.
Tenho lido o manual e os tutoriais do MariaDB e aparentemente isso deve funcionar:
EXPLAIN CREATE TABLE `prefix_database2`.`table1` LIKE `prefix_database1`.`table1`;`
O LIKEoperador deve duplicar as colunas e chaves da tabela. Não sei por que estou recebendo o erro de sintaxe.
Como duplico uma tabela em um segundo banco de dados do primeiro, mantendo exatamente as mesmas colunas, chaves, etc.?
example@ localhostnos servidores locais e ativos.UPDATE information_schema.TABLES ...) em ambos os servidores.Acesso negado ao usuário 'example'@'localhost' ao banco de dados 'information_schema'
SELECT * FROM mysql.global_priv WHERE 'User'='example';.mysql.dbbanco de dados/tabela não há menção ao exampleusuário porque, novamente, ele possui permissões globais .mysql.dbbanco de dados/tabela não há menção ao information_schemabanco de dados em nenhum dos servidores.Como faço para forçar o MariaDB a permitir que o exampleusuário execute minha UPDATE information_schema.TABLES ...consulta no servidor ativo?