Atualmente, temos um único servidor MySQL 8 rodando em Oracle Linux. Ele roda em uma VM em um data center gerenciado no Texas.

Cerca de 95% do seu tempo é gasto em operações SELECT e cerca de 5% em INSERT e UPDATE.

Estamos trabalhando para adicionar outro servidor MySQL em um local separado (MO), principalmente para fins de redundância e recuperação de desastres.

Minha ideia é criar um túnel entre os dois locais e configurar a replicação do MySQL usando o local principal como mestre. Dessa forma, se ocorrer um desastre, eu poderia alternar as coisas para apontar para o servidor escravo. Uma desvantagem é que esse servidor escravo dedicado ficará parado, potencialmente sem trazer nenhum benefício, a menos que algo ruim aconteça.

Eu estava pensando em maneiras de utilizá-lo e talvez atualizar meu aplicativo para usar o servidor escravo para algumas das consultas/relatórios pesados.

Achei que era um ótimo plano até começar a ler sobre clustering MySQL. Na verdade, não temos condições de ter um terceiro servidor MySQL dedicado para configurar um cluster.

Minhas perguntas são:

Supondo que você tivesse 2 nós MySQL, em 2 locais, como você os utilizaria melhor?

Nossos servidores de aplicação executam tudo em contêineres Docker. Seria uma ideia maluca adicionar uma instância do MySQL (em um contêiner Docker) aos servidores de aplicação para construir um cluster MySQL em vez da replicação?

Se um cluster fosse realmente uma possibilidade (por meio de instâncias MySQL nos servidores de aplicação), meu entendimento é que as gravações podem ser potencialmente mais lentas, já que a gravação não é concluída até que todos os nós do cluster tenham escrito. Isso significa que ter os nós do cluster em vários locais pode realmente tornar as gravações significativamente mais lentas, já que haverá um pouco de latência entre os dois sites?

Qualquer conselho aqui é bem-vindo.

Na edição comunitária do servidor MySQL 8, aqui estão exemplos de uma consulta e comando SQL em :MySQL Shell

SELECT * FROM planet;
DESC planet;
SHOW DATABASES;
SHOW tables;

Como você pode ver, é obrigatório declarar o ;caractere (ou ambos \g, \Gconforme o caso) no final da frase.

Mas percebi por engano que é possível executar o usecomando para alterar o banco de dados sem ; .

Portanto, os dois comandos a seguir funcionam em paz:

use <datababase>
use <datababase>;

Só por curiosidade:

Pergunta

• usePor que o comando não precisa ;ser executado?

Para ser honesto, não tenho certeza se esse é o comando exclusivo dessa situação, mas por que ele é diferente dos outros?

Na comunidade do servidor MySQL 8 para exportar a saída de uma consulta SQL é possível executar o MySQL Shellseguinte comando (o mais básico):

SELECT * FROM cientifico INTO OUTFILE '/var/lib/mysql-files/cientifico-data.txt';

E funciona como esperado

Mas para uma consulta não SQL como a seguir:

SHOW PROCESSLIST INTO OUTFILE '/var/lib/mysql-files/processlist.txt';

Lança o seguinte erro

ERRO 1064 (42000): Há um erro na sintaxe SQL; verifique o manual correspondente à versão do seu servidor MySQL para obter a sintaxe correta a ser usada perto de 'INTO OUTFILE '/var/lib/mysql-files/processlist.txt'' na linha 1

O mesmo que:

SHOW DATABASES INTO OUTFILE '/var/lib/mysql-files/databases.txt';

Dando

ERRO 1064 (42000): Há um erro na sintaxe SQL; verifique o manual correspondente à versão do seu servidor MySQL para obter a sintaxe correta a ser usada perto de 'INTO OUTFILE '/var/lib/mysql-files/databases.txt'' na linha 1

Portanto se for possível

Pergunta

• Como exportar a saída de uma frase de consulta não SQL?

Estou assumindo que a INTO OUTFILEsintaxe é apenas para sentenças SQL, mas e para sentenças não SQL?

Na comunidade do servidor MySQL 8, os dois comandos a seguir mostram a mesma estrutura:

SHOW PROCESSLIST;
SELECT * FROM information_schema.PROCESSLIST;

Pergunta

• Quando usar o comando SHOW PROCESSLISTvs SELECT * FROM information_schema.PROCESSLIST?

Cada comando existe por um motivo específico, certo?

Sobre suas saídas, encontrei apenas duas diferenças para as colunas Statee Infopara cada comando, respectivamente:

State     | Info
----------------------------
init      | SHOW PROCESSLIST
executing | SELECT * FROM information_schema.PROCESSLIST

A diferença da Infocoluna é clara porque ela representa o próprio comando que foi executado , mas :

• StatePor que a coluna é diferente ?

Está claro o executingvalor, mas:

• O que significa o initvalor?

eu tenho uma transação simples com nível de isolamento READ COMMITTED A configuração da tabela é simples

create table example.parent_tbl(
id int auto_increment primary key
);

create table example.child_tbl(
id int auto_increment primary key,
parent_id int not null,
update_dt timestamp default current_timestamp ON UPDATE current_timestamp,

foreign key (parent_id) references parent_tbl(id),
unique (parent_id)
);

select 
p.*
from example.parent_tbl p
where p.id not in (select parent_id from example.child_tbl)
limit 1
for update
skip locked; 

depois disso, inserirei um novo registro com parent_tbl.idinto child_tbl.

A coluna ID child_tblé única. Tenho vários processos em execução em paralelo e, ocasionalmente, um deles gera uma exceção de integridade, pois o mesmo ID child_tbljá existe.

PERGUNTA

por que uma transação pode selecionar um ID que aparece em child_tbl?

A lógica parece trivial.

Ou a transação A mantém o bloqueio de linha parent_tblantes da confirmação, então a transação B irá ignorá-lo.

OU

A transação A foi confirmada e a cláusula where da transação B filtrará a linha e a ignorará.

Mas a verdade é que não é bem assim!!!

O log de consulta geral mostra o comportamento contraintuitivo deste mecanismo de bloqueio

log do lado do servidor

Há dois processos em execução em paralelo, fazendo a mesma coisa. Neste caso, eles são os threads 60 e 61, respectivamente.

Dois resultados são observados.

1. A thread 61 inseriu o ID 113 na tabela filha e liberou o bloqueio de linha. A thread 60 executa a consulta, mas não consegue detectar a linha com o ID 113 recém-inserida pela thread 61.

2. o thread 61 inseriu o id 113 na child_tbl e logo antes de confirmar e liberar o bloqueio de linha, outro thread 60 executa a consulta e adquire o mesmo bloqueio de linha da parent_tbl .

Adicional

Fiz os mesmos testes com o PostgreSQL e também encontrei uma exceção.

A máquina que serve o MySQL está funcionando bem. Duas outras máquinas se conectam usando o cliente MySQL sem problemas. Uma máquina na rede parou de se conectar espontaneamente.

Eu tentei strace mysql -h servere a tentativa foi rejeitada imediatamente

Não sei como solucionar o que está causando a falha repentina.

EDIT: Desculpe. Esqueci de incluir o erro:

ERROR 2003 (HY000): Can't connect to MySQL server on 'server1:3308' (111)

Isso é interessante. O outro servidor que acessa o banco de dados não tem problemas:

mysql -h server2 -P3308 -u root -p

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 16591
Server version: 5.5.62 MySQL Community Server (GPL)

Copyright (c) 2000, 2025, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Então, o servidor onde o banco de dados está rodando está funcionando corretamente. Por algum motivo, server1a conexão foi recusada.

A autenticação permite conexões remotas de dentro da intranet.

Qualquer pesquisa no Google assume que o problema está no servidor e não no cliente, então não encontrei nada relevante sobre falha de conexão do cliente ser um problema do cliente.

Alguém que está lendo isso teve esse problema e o resolveu?

Todas as tabelas e colunas do meu banco de dados usam o conjunto de caracteres utf8mb4 e a ordenação utf8mb4_unicode_ci. Gostaria de migrar para a ordenação utf8mb4_0900_ai_ci, mas usá-la convert toé inviável em minhas tabelas grandes, a menos que eu use gh-ost ou pt-osc.

Parece-me que isso convert tonão deveria ser necessário, visto que o conjunto de caracteres não muda, mas não consigo encontrar nenhuma documentação que confirme ou negue isso. Preciso usar convert toneste caso ou é alter table ... modify col ... collate ...suficiente?

Dei uma olhada em "Usando CONVERTER EM CONJUNTO DE CARACTERES para alterar apenas a ordenação?", que faz uma pergunta muito semelhante, mas a idade dessa pergunta torna as respostas um tanto obsoletas. Mesmo assim, uma resposta parece sugerir que isso convert toé desnecessário. A outra resposta se aprofunda na conversão de conjuntos de caracteres e no uso de pt-osc, o que eu gostaria de evitar.

O MySQL se recusa a iniciar e eu só consegui iniciar em modo somente leitura usando innodb_force_recovery = 6. Todas as respostas que encontrei sobre esse tópico sugerem fazer um backup, deletar ibdata e ib_logfiles e então deixá-los serem recriados:

• https://serverfault.com/questions/592793/mysql-crashed-and-wont-start-up
• innodb_force_recovery quando corrupção do InnoDB
• https://stackoverflow.com/questions/41997197/mysql-data-recovery-with-innodb

No meu caso, como innodb-file-per-table está habilitado, estou pensando se também preciso excluir arquivos como /var/lib/mysql/MY_DATABASE/table.ibd?este. Além disso, como o registro de refazer está desabilitado, não há nenhum arquivo de log para remover.

O erro específico que recebi foi este:

[InnoDB] O servidor foi encerrado quando o redo logging do InnoDB foi desabilitado. Os arquivos de dados podem estar corrompidos. Você pode tentar reiniciar o banco de dados com innodb_force_recovery=6

Neste ponto, consegui iniciar no modo somente leitura e fiz um backup de todas as tabelas que preciso. O que especificamente devo excluir? Ou há uma abordagem melhor para reconstruir completamente essas tabelas?

Estou pensando em simplesmente desinstalar o MySQL completamente e limpar o diretório inteiro, mas estou esperando feedback aqui se houver uma abordagem mais simples.

Acabei de tentar atualizar uma instância do MySQL executando o MySQL 5.7.30 (no Docker) para o MySQL 8.4.3 (no Docker) e agora a instância não inicia, reclamando de um mysql.ibdarquivo ausente.

Verifiquei a pasta de dados do MySQL e esse arquivo não existe (a pasta mysql existe com todos os arquivos de tabela nela), mas verifiquei outros sistemas ainda no MySQL 5.7.x e o arquivo não está lá. Acho que talvez a atualização do MySQL 8.x deva criá-lo, pois entendi que o banco de dados do sistema mysql era um MyISAM antes da v8.x?

Pesquisei e não consegui encontrar nenhum relato do mesmo problema. Alguém sabe por que isso ocorreu e como resolver esse problema e colocar a nova instância em funcionamento?

Este foi um teste de atualização no local antes de tentar em sistemas ativos, então eu gostaria de entender como evitá-lo ao fazer atualizações reais.

2025-03-07 19:50:44+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.3-1.el9 started.
'/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock'
2025-03-07T19:50:45.450364Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2025-03-07T19:50:45.794562Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.4.3) starting as process 1
2025-03-07T19:50:45.870761Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2025-03-07T19:50:51.814984Z 1 [ERROR] [MY-012592] [InnoDB] Operating system error number 2 in a file operation.
2025-03-07T19:50:51.815073Z 1 [ERROR] [MY-012593] [InnoDB] The error means the system cannot find the path specified.
2025-03-07T19:50:51.815110Z 1 [ERROR] [MY-012216] [InnoDB] Cannot open datafile for read-only: 'mysql.ibd' OS error: 71
mysqld: Can't open file: 'mysql.ibd' (errno: 0 - )
2025-03-07T19:50:52.210315Z 1 [ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
2025-03-07T19:50:52.210893Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2025-03-07T19:50:52.210968Z 0 [ERROR] [MY-010119] [Server] Aborting
2025-03-07T19:50:52.214916Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.4.3)  MySQL Community Server - GPL.
2025-03-07T19:50:52.214957Z 0 [System] [MY-015016] [Server] MySQL Server - end.

Preciso de ajuda com isso...

Dentro de uma tabela "posts", tenho duas colunas onde preciso extrair/mover um valor de um campo para outro e mesclá-lo com o valor existente.

Table name: posts
-------------------
post_title       | post_name
-------------------------------
Title            | ashgt-36548
Some title       | ahrgz-46587
Some other title | kkahe-55486

Os valores de post_name estão todos no mesmo formato: 5 letras com um traço "-" e cerca de 5 dígitos (-DIGITS).

Então o que preciso ganhar é:

Remova "-DIGITS" de post_name e injete isso no campo post_title (mesclar valores) no início (primeira posição), remova o "-" e coloque o número de 5 dígitos entre colchetes [DIGITS]+SPACE

Então o resultado deve ser parecido com:

Table name: posts
--------------------------------------
post_title               | post_name
--------------------------------------
[36548] Title            | ashgt
[46587] Some title       | ahrgz
[55486] Some other title | kkahe

A sintaxe SQL que tenho até agora para remover o traço e os dígitos de post_name é (eu seleciono por meio de outra coluna "maschinen"):

UPDATE posts
SET `post_name`= mid(`post_name`, 1,length(`post_name`)-6)
WHERE `post_name` LIKE '%-%' AND `post_type` LIKE 'maschinen';

Qualquer ajuda sobre isso seria ótima. Obrigado.