IGGt's questions

Eu tenho a seguinte entrada em um campo JSON no MySQL, como posso acessar os dados wid_1 -> pct_usage?

{ "wid_1": { "cof": 1, "pct_usage": 50.0, "tid": 69285334, "wid": 1 }, "wid_2": { "cof": 1, "pct_usage": 50.0, "tid": 69285335, "wid": 2 } }

Eu tentei várias variações de:

json_unquote(json_extract(s.`col_name`,'$.wid_1'.'pct_usage')) as wid_1_pct,
json_unquote(json_extract(s.`col_name`,'$.wid_1','pct_usage')) as wid_1_pct,
json_unquote(json_extract(s.`col_name`,'$.wid_1'{'pct_usage'})) as wid_1_pct, 
json_unquote(json_extract(s.`col_name`,'$.wid_1','{pct_usage}')) as wid_1_pct,

mas nenhum deles funciona.

Eu tenho alguns campos em uma tabela que contém dados semelhantes aos seguintes:

{"item1":"stuff","item2":"12345","item3":0,"item4":"this field contains some data that has "quotes" in it that need to be removed","item5":"some other stuff","item6":"","item7":"","item8":"a.b.c.d.e.f"}

Preciso atualizar os dados para remover as aspas da item4seção, mantendo o restante dos dados intactos.

por exemplo, isso:

"item4":"this field contains some data that has "quotes" in it that need to be removed"

precisa se tornar:

"item4":"this field contains some data that has quotes in it that need to be removed"

Eu posso remover as aspas sem problemas fazendo:

SET @dataval =('{"item1":"stuff","item2":"12345","item3":0,"item4":"this field contains some data that has "quotes" in it that need to be removed","item5":"some other stuff","item6":"","item7":"","item8":"a.b.c.d.e.f"}');

select REPLACE(SUBSTRING_INDEX(SUBSTRING_INDEX(@dataval,'"item4":"',-1),'","item5"',1),'"','');

Mas é claro que isso perde a redefinição dos dados.

Existe uma maneira de fazer isso em uma consulta ou vou precisar fazer algo como copiar os dados para uma tabela temporária, remover as aspas e fazer um REPLACEcontra os dados originais usando os dados modificados?

Eu tenho o MySQL instalado no meu servidor de teste (Debian 10). Recentemente, atualizei-o para a versão mais recente (8.0.29), mas há alguns problemas com ele, então quero voltar para uma versão mais antiga (8.0.28). Mas eu não posso para a vida de mim descobrir como fazê-lo.

Eu removi o banco de dados existente e tentei reinstalá-lo usando:

apt-get install mysql-server=8.0.28-1debian10

mas isso não funcionou e sugeriu que eu executasse:

apt --fix-broken install

que, claro, o atualizou para a versão mais recente novamente.

Eu tentei inúmeras variações disso, mas todas resultam em mysql-server can't be founderros semelhantes.

Eu estive vasculhando a internet e parece haver muitas pessoas fazendo perguntas semelhantes, mas nenhuma solução real. Até mesmo a documentação oficial do MySQL encobre essa parte.

Isso pode ser feito? E se sim, como? É apenas um banco de dados de teste, então não tenho problemas em descartá-lo e começar de novo.

Existe uma maneira de obter a saída do mysqlshell e usá-la em um script ou similar.

Eu configurei um cluster básico para teste (3 x bancos de dados MySQL 8.0.27, rodando no Debian 11).

Agora estou tentando encontrar uma maneira de capturar a saída da saída do mysqlshell cluster.status().

Como exemplo, de dentro do mysqlshell eu posso executar:

cluster=dba.getCluster()
cluster.status().defaultReplicaSet.topology['test-1:3306'].replicationLag

para obter o atraso de replicação atual. Eu gostaria de capturar isso para que possa ser monitorado automaticamente.

Presumi que a maioria dessas estatísticas também existiria nos bancos de dados performance_schemaou mysql_innodb_cluster_metadataem algum lugar, mas não consigo vê-las.

Existe uma maneira de fazer isso?

Estou montando e testando um Innodb Cluster. Até agora eu tenho três nós rodando 8.0.27 e dois roteadores todos funcionando bem.

Agora quero testar o que acontece se a conexão de rede desaparecer repentinamente em um.

Eu tenho todos os três nós configurados com:

"autoRejoinTries", "3"
"exitStateAction","OFFLINE_MODE"
"expelTimeout":"5"

Então, quando eu removo a conexão de rede do nó 3 usando:

ifdown eth0

Vejo que ele desaparece do cluster e mostra como:

"status": "UNREACHABLE",

e no próprio servidor diz:

"Cluster has no quorum and cannot process write transactions: Group has no quorum"

Mas eu estava esperando que o banco de dados entrasse em offline_mode. Mas quando eu verifico, ele ainda diz que está desligado:

SELECT @@GLOBAL.offline_mode;
+-----------------------+
| @@GLOBAL.offline_mode |
+-----------------------+
|                     0 |
+-----------------------+

Eu perdi alguma coisa, ou entendi mal o que "exitStateAction","OFFLINE_MODE"significa?

Estou escrevendo um script de backup para um banco de dados e quero usar o util.dumpSchemas()utilitário mysqlshell.

Mas como diabos posso fazê-lo funcionar de dentro de um script de shell?

O processo básico que tenho é este:

filename_1: backup.sh
. . .
mysqlsh --file mysqlshell_backup.js


filename_2: mysqlshell_backup.js
\connect backup_user:<password>@127.0.0.1:3306
util.dumpSchemas(<options........>)
\q

Mas quando executo tudo o que recebo são erros:

SyntaxError: Invalid or unexpected token at mysqlshell_backup.js:2:0
in \connect backup_user:<password>@127.0.0.1:3306

mas se eu executar o código manualmente, por exemplo:

mysqlsh
MySQL  JS > \connect backup_user:<password>@127.0.0.1:3306

Funciona bem.

MySQL  127.0.0.1:3306 ssl  JS > 

Eu tentei tornar o arquivo um executável por si só e executá-lo por conta própria adicionando:

#!/usr/local/mysql-shell/bin/mysqlsh --file
\connect backup_user:<password>@127.0.0.1:3306
util.dumpSchemas(<options........>)
\q

mas então eu recebo:

mysqlshell_backup.js: line 2: connect: command not found
mysqlshell_backup.js: line 3: syntax error near unexpected token `[<options>],'
mysqlshell_backup.js: line 3: `util.dumpSchemas(<options>)

Mas, novamente, se eu executá-lo diretamente de dentro do mysqlshell, o código funciona bem, então eu sei que não há erros de sintaxe.

Existe realmente uma maneira de executar um comando mysqlshell como parte de um script maior ou estou apenas perdendo meu tempo aqui?

Alguém pode ver onde estou errando, pois isso está me levando ao extremo.

Configurei uma instalação limpa do MySQL 8.0.17 no meu laptop Windows 10. Passei por todo o initializeprocesso, entrei e configurei um rootusuário e configurei como um serviço.

O arquivo my.ini contém (entre outros):

port = 3306
server-id = 8306
binlog_format = row
relay-log-info-repository = TABLE
master-info-repository = TABLE
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_checksum = NONE

Até agora tudo bem. Eu log, em tudo funciona.

Em seguida, desligo o MySQL e adiciono o seguinte ao arquivo my.cnf.

#GROUP REPLICATION#
loose-transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="1587d451-feca-11e8-a7b3-c85b768dc0dd"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:33061"
loose-group_replication_group_seeds= "127.0.0.1:33061"
loose-group_replication_bootstrap_group=off
loose-group_replication_member_weight=100
loose-group_replication_ip_whitelist="169.254.243.231"

A última entrada foi adicionada porque as tentativas anteriores reclamaram que não estava na lista de permissões.

Eu reinicio o MySQL novamente.

Agora eu começo a configurar a replicação de grupo.

SET SQL_LOG_BIN=0;
CREATE USER 'GReplication'@'%' IDENTIFIED WITH 'mysql_native_password' BY '@Replication123';
GRANT REPLICATION SLAVE ON *.* TO 'GReplication'@'%';
SET SQL_LOG_BIN=1;

CHANGE MASTER TO MASTER_USER='GReplication', MASTER_PASSWORD='@Replication123' FOR CHANNEL 'group_replication_recovery';

INSTALL PLUGIN group_replication SONAME 'group_replication.dll';
SHOW PLUGINS;

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

SELECT * FROM performance_schema.replication_group_members;

Isso mostra um membro ativo.

MySQL  localhost:3306 ssl  SQL > SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 454b0127-b204-11e9-a032-c85b768dc0db | pc12345     |        3306 | ONLINE       | PRIMARY     | 8.0.17         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
1 row in set (0.0005 sec)

Agora altero a seguinte linha no arquivo my.ini para "on"

loose-group_replication_start_on_boot=on

E reinicie o MySQL.

No entanto, quando eu verifico, agora recebo:

MySQL  localhost:3306 ssl  SQL > SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 454b0127-b204-11e9-a032-c85b768dc0db | pc12345     |        3306 | OFFLINE      |             |                |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
1 row in set (0.0005 sec)

Olhando no log de erros, tudo parece estar funcionando bem até:

2019-07-29T15:26:17.651950Z 0 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Error connecting to all peers. Member join failed. Local port: 33061'
2019-07-29T15:26:17.791783Z 0 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] The member was unable to join the group. Local port: 33061'
2019-07-29T15:27:17.469988Z 2 [ERROR] [MY-011640] [Repl] Plugin group_replication reported: 'Timeout on wait for view after joining group'
2019-07-29T15:27:17.473776Z 2 [Note] [MY-011649] [Repl] Plugin group_replication reported: 'Requesting to leave the group despite of not being a member'
2019-07-29T15:27:17.476534Z 2 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] The member is leaving a group without being on one.'
2019-07-29T15:27:17.492689Z 12 [Note] [MY-010596] [Repl] Error reading relay log event for channel 'group_replication_applier': slave SQL thread was killed
2019-07-29T15:27:17.495987Z 12 [Note] [MY-010587] [Repl] Slave SQL thread for channel 'group_replication_applier' exiting, replication stopped in log 'FIRST' at position 0
2019-07-29T15:27:17.498976Z 9 [Note] [MY-011444] [Repl] Plugin group_replication reported: 'The group replication applier thread was killed.'

Presumo que estou faltando um passo em algum lugar, mas o que é isso? Passei por toda a documentação que posso encontrar e não consigo ver nada de diferente?

Eu também tentei configurá-lo no Linux, com o mesmo resultado.

Como posso desabilitar o log binário no MySQL 8.0?

Estou precisando importar um arquivo MySQLDump grande e não quero preencher os logs binários com muitos GB de dados. No passado eu teria definido log_bin=0no my.cnfe reiniciado o banco de dados.

Mas com o MySQL 8.0 eu tentei várias configurações, mas toda vez que entro no banco de dados e executo:

SELECT @@global.log_bin;

e continua voltando1

Eu tentei:

log_bin = 0
log_bin = OFF
#log_bin = 1

É possível desabilitar os logs binários?

Eu tenho dois bancos de dados configurados para teste (portanto, não há dados ou conexões ao vivo).

O primeiro é um banco de dados MySQL 5.5.57atuando como mestre. O segundo é um banco de dados MySQL 5.7.23atuando como escravo. Ele está sendo executado Statement Based Replicationno MySQL 5.5 e Row Based Replicationno MySQL 5.7.

Por alguma razão, consultas maiores parecem levar muito mais tempo no MySQL 5.7. Por exemplo, tenho a seguinte tabela:

CREATE TABLE `test1` (
  `col0` int(11) DEFAULT NULL,
  `col1` int(11) DEFAULT NULL,
  `col2` datetime DEFAULT NULL,
  `col3 datetime DEFAULT NULL,
  `col4` int(11) DEFAULT NULL,
  `col5` int(11) DEFAULT NULL,
  `col6` int(11) DEFAULT NULL,
  `col7` int(4) DEFAULT NULL,
  `col8` int(11) DEFAULT NULL,
  `col9` datetime DEFAULT NULL,
  `col10` datetime DEFAULT NULL,
  `UniqRef` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `col11` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `col12` tinyint(1) unsigned zerofill DEFAULT NULL,
  `col13` tinyint(1) unsigned DEFAULT NULL,
  PRIMARY KEY (`UniqRef`),
  KEY `col0` (`col0`),
  KEY `col3` (`col3`),
  KEY `col4` (`col4`),
  KEY `col8` (`col8`),
  KEY `col5` (`col5`),
  KEY `col10` (`Deleted`),
  KEY `col2` (`col2`),
  KEY `col12` (`col12`) USING BTREE,
  KEY `col13` (`col13`)
) ENGINE=InnoDB AUTO_INCREMENT=400046649 DEFAULT CHARSET=latin1;

A tabela tem 21 GB de tamanho e contém 83261829 linhas (usando count(*)).

Se eu executar a consulta: UPDATE test.test1 SET col9 = NOW() WHERE UniqRef IN ('397958600','397940686','397940704','397940678','397. . . . .

A consulta contém 6945 entradas uniqref. Ele é executado quase instantaneamente no MySQL 5.5, mas depois é replicado no MySQL 5.7 e leva 90 segundos para ser executado.

Alterei várias configurações, mas até agora não fizeram diferença:

SET @@global.slave_compressed_protocol = 0;

SET @@global.sync_binlog = 0;

set @@global.range_optimizer_max_mem_size = 0;

Também tentei alterar read_io_threadse write_io_threadspara vários valores, além de alterar o número de buffer pool instancese desabilitar os logs binários.

Existem outras variáveis ​​que podem fazer a diferença para tentar acelerar isso que eu perdi?

ATUALIZAÇÃO 2018-10-17

Consegui acelerar as consultas quando executadas localmente (diretamente no MySQL 5.7) configurando SET @@global.range_optimizer_max_mem_size = 16777216;. Após isso, as consultas passaram de 90+ segundos para 0 segundos.

No entanto, quando a mesma consulta foi executada no MySQL 5.5 e replicada no MySQL 5.7, ela ainda leva mais de 90 segundos para ser executada.

Comecei a testar alguns bancos de dados MySQL 5.7 para substituir nossos bancos de dados 5.5 antigos e parece haver uma mudança significativa na maneira como a information_schema.tablestabela registra o tamanho dos dados.

Eu executo a seguinte consulta:

SELECT  
    table_schema AS table_schema,   
    table_name AS table_name,   
    (data_length + index_length + data_free) AS table_size, 
    ROUND((data_length + index_length + data_free)/POWER(1024,3),2) AS table_sizeGB,    
    t.data_length,  
    t.index_length, 
    t.data_free
FROM information_schema.TABLES t
WHERE table_schema = 'myDb' 
ORDER BY table_size DESC, table_name
LIMIT 10;

Isso me dá as 10 maiores tabelas. Eu corro isso diariamente para registrar o crescimento ao longo do tempo. No MySQL 5.5 leva apx 5 segundos, no MySQL 5.7 é instantâneo.

No MySQL 5.5 recebo o seguinte resultado para a maior tabela:

myDb | myTable | 319383535616 | 297.45 | 319116279808 | 262012928 | 5242880

No MySQL 5.7 eu recebo:

myDB | myTable | 270051115008 | 251.50 | 269824819200 | 226295808 | 0

Ambos os bancos de dados foram criados com poucos dias de intervalo. O banco de dados 5.7 é um escravo do banco de dados 5.5. Nenhum deles está ativo ainda (apenas sentado como escravo do Sistema Ativo).

Se eu olhar no servidor, o arquivo .ibd das tabelas tem 302 GB no banco de dados 5.5 e 292 GB no banco de dados 5.7.

Eu esperava uma pequena discrepância (um está usando o Antelope, o formato Barracuda File - ambos são innodb). Os dados estão sendo constantemente adicionados ao banco de dados e muito pouco (se houver) está sendo removido.

No banco de dados MySQL 5.5, posso ver os números aumentarem cada vez que executo a consulta, mesmo com apenas alguns segundos de intervalo. Mas no MySQL 5.7, os números não mudaram desde que comecei a olhar para ele, há uma semana.

Este é um comportamento correto? Existe uma maneira melhor de monitorar isso no MySQL 5.7 que eu perdi?

-- ATUALIZADO 2018-10-16

Após três semanas, o resultado da consulta ainda é praticamente o mesmo no MySQL 5.7:

5.5 -- myDb | myTable | 327890632704 | 305.37 | 327616036864 | 268304384 |6291456
5.7 -- myDb | myTable | 270055309312 | 251.51 | 269824819200 | 226295808 | 4194304

O tamanho físico no servidor é 310 GB no MySQL 5.5 e 300 GB no MySQL 5.7.

Ambas as tabelas são criadas de forma idêntica.

Nenhum banco de dados está ativo ainda, portanto, as únicas consultas em execução (além do meu teste) são da replicação.

Ambos os bancos de dados usam innodb_file_per_table.

O MySQL 5.5 foi copiado de um slave ativo usando mysqldump.

O banco de dados 5.7 foi copiado do banco de dados MySQL 5.5 usando mysqldump + mysql_upgrade.

A tabela de otimização nunca foi executada nessas tabelas.

Eu tenho um problema de replicação estranho. Para referência, estou usando o MySQL 5.5 com replicação baseada em instruções. Temos um Master com Slaves no site A/rede A, e slaves no site B/rede B.

Tudo na rede A está bem. O problema ocorre com os bancos de dados no site B/rede B que estão se conectando ao mestre no site A.

Em algumas ocasiões agora eu vi a replicação parar nos bancos de dados no site B. Se eu olhar para o SLAVE_IO_RUNNINGe SLAVE_SQL_RUNNINGem SHOW SLAVE STATUSambos dizem yes. Para todas as extensões e propósitos, tudo parece bem para mim. No entanto, meu monitoramento está relatando que o evento de pulsação que executamos está ficando para trás. É como se o escravo estivesse conectado ao mestre, mas não recebendo nenhum dado.

Os vários posvalores ( read_master_log_pos, relay_log_pos, exec_master_log_pos) são todos estáticos e não se movem. Eu também verifiquei o log de retransmissão em um, e os dados de entrada param naquele momento.

Se eu olhar para os bancos de dados mestre e escravo, não há consultas de longa duração que causem isso. Tudo parece correr conforme o esperado e, como mencionado, os escravos no site A estão bem e mantêm-se atualizados.

Os bancos de dados em questão estão todos executando consultas diferentes, portanto, não é uma consulta específica perturbando as coisas.

Não há nada nos logs de erro do MySQL.

Simulamos uma pequena falha de rede (embora de nosso monitoramento não possamos ver nenhuma interrupção de rede nesses horários) e os bancos de dados funcionam conforme o esperado. Assim que a rede é reconectada, eles retomam a replicação.

Isso é corrigido executando stop slave; start slave;em que ponto tudo continua como se nada tivesse acontecido.

Alguém mais teve um problema semelhante? ou poderia lançar alguma luz sobre o que pode estar acontecendo. Minha intuição é que há uma interrupção de rede muito breve, muito curta para o monitoramento pegar, mas por que isso perturbaria o MySQL eu não sei.

Estamos usando o MySQL 5.7.22. Cada vez que reinicio o MySQL, ele cria um conjunto de arquivos SSL ( ca-key.pemetc) no arquivo datadir.
O problema é que já tenho esses arquivos no servidor, em /etc/mysql/ssl.

A execução show global variables like '%ssl%'me mostra que está procurando os arquivos corretos no /etc/mysql/ssl, mas ainda cria os novos no datadir.

Eu posso ver que existe uma opção,auto_generate_certs=off mas quando eu adiciono isso ao my.cnfarquivo, ele aparece como unknown variablee o MySQL não inicia

Existe uma maneira de impedir que ele crie esses certificados toda vez que eu reinicio o banco de dados?

Eu tenho a seguinte tabela (há mais colunas na real).

CREATE TABLE `test`.`j_data` (
`j_id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
`j_name` VARCHAR(80) NULL DEFAULT NULL
PRIMARY KEY (`j_id`));

Executamos consultas regularmente em que a coluna principal usada é o PK, por exemplo

SELECT * FROM j_data WHERE j_id = 123;

Mas agora estamos procurando executar muitas consultas como:

SELECT j_id FROM j_data WHERE j_name = xxx; 

Isso se beneficiaria de um índice de cobertura em j_namee j_id.

ADD INDEX `j_name_id` (`j_name` ASC, `j_id` ASC);

Ou um índice em j_nameapenas seria suficiente? É uma tabela bastante grande, então não quero perder tempo adicionando o índice se for improvável que ajude.

Estou tentando instalar um plug-in no meu banco de dados MySQL, mas toda vez que tento recebo um erro de entrada duplicada:

INSTALL PLUGIN audit_log SONAME 'audit_log.so';
Error Code: 1062. Duplicate entry 'audit_log' for key 'PRIMARY'

Mas se eu executar:

SHOW PLUGINS;
SELECT * FROM `information_schema`.`plugins`;

Não há sinal disso.

Se eu executar SELECT * FROM mysql.plugin;, há uma entrada para ele.

Mas se eu correr UNINSTALL PLUGIN audit_log;, então ele me diz que não existe.Error Code: 1305. PLUGIN audit_log does not exist

Eu sei que o arquivo está lá, porque existem dois bancos de dados neste servidor em execução mysqld_multie ele foi instalado bem no outro.

O servidor é 5.5.54, o servidor é Debian 8 (jessie).

Há algo mais que eu possa fazer? Posso simplesmente excluí-lo da mysql.plugintabela sem causar problemas? Reiniciar o servidor não é viável, pois é meu banco de dados mestre.

Acabei de instalar uma cópia Percona xtrabackupno meu servidor Debian (jessie), mas quando o executo, diz que é:

innobackupex version 2.3.5 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 45cda89)

Mas estou usando o MySQL 5.5. Esta é a versão correta do innobackupex para usar com meus bancos de dados e, se não, qual versão devo usar? A documentação não é muito clara.

Eu instalei usando o seguinte processo:

apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A

sudo pico /etc/apt/sources.list

then add the following two lines
    deb http://repo.percona.com/apt jessie main
    deb-src http://repo.percona.com/apt jessie main

apt-get update

apt-get install percona-xtrabackup

Tenho certeza de que há uma resposta realmente óbvia, mas:

Por que o length(comprimento do byte) de uma string em um varcharcampo é menor que a string real?

por exemplo

CREATE TABLE `test1` (
  `testdata` varchar(4) DEFAULT NULL
) CHARSET=latin1;

insert into test1 (`testdata`) VALUES('ÂÂÂÂ');

select 
    testdata,
    length(testdata),
    char_length(testdata),
    length('ÂÂÂÂ'),
    char_length('ÂÂÂÂ')
from test1

**result:**
testdata: ÂÂÂÂ
length: 4
char_length: 4
length: 8
char_length: 4

Eu tenho um banco de dados que é um escravo e um mestre. por exemplo, ele replica dados de nosso site principal e, em seguida, para um conjunto de bancos de dados escravos. (esta é principalmente uma instalação de teste, portanto não é monitorada fora do horário).

No domingo de manhã, às 7h55, ele começou a executar uma INSERTconsulta. Esta é uma consulta padrão executada milhares de vezes por dia. É uma consulta única, não faz parte de uma transação. Não há gatilhos nessa tabela. Esta tabela (e todas as outras) são arquivos INNODB.

Mas, nesta ocasião, travou. Quando cheguei ao escritório hoje, ele estava funcionando há 24 horas (aparentemente). E a replicação estava um dia atrasada.

No entanto, quando olhei nos logs binários, apareceu como COMMITed.

#160814  7:55:25 server id 21  end_log_pos 103319397    Query   thread_id=635785334 exec_time=4294967294    error_code=0
SET TIMESTAMP=1471157725/*!*/;
INSERT INTO tablename . . . 
/*!*/;
# at 103319397
#160814  7:55:25 server id 21  end_log_pos 103319424    Xid = 284047583
COMMIT/*!*/;
# at 103319424

Eu verifiquei os bancos de dados do Slave, e estava presente lá como seria de esperar.

Eu tenho um sistema de monitoramento que registra (entre outras coisas) a lista de processos e mostra que, para essa INSERTconsulta, ela estava permanentemente presa em STATE = UPDATE.

Eu também verifiquei slow query logpara ver se estava lá, e não estava.

Meu entendimento era que uma consulta não poderia ser gravada binary logaté que estivesse commmitedno mestre, então alguém pode explicar o que aconteceu aqui?

Houve um efeito negativo no sistema de teste, uma vez fora, que tentou se conectar às 8h38 desta manhã, a primeira SELECTconsulta também travou e recusou todas as conexões. Então fui forçado a reiniciar o banco de dados. Nesse ponto, ele executou a recuperação de falhas e continuou como se nada tivesse acontecido.

É MySQL 5.5.47 e usando Replicação Baseada em Instrução.

Esta pode ser uma pergunta estúpida, mas nas notas de versão do MySQL, muitas delas são seguidas por números de referência de BUG. Mas a maioria desses BUGS não existe quando você os procura em bugs.mysql.com .

exemplo: InnoDB: A full-text query raised an assertion. Under certain circumstances, DDL operations such as ALTER TABLE ... RENAME caused full-text auxiliary tables to be removed on server restart. (Bug #13651665)

Apesar dos meus melhores esforços, não consigo descobrir onde encontrar esses BUGS. Alguém pode me indicar o local certo?

Durante um recente problema/desaceleração com um de nossos bancos de dados escravos, notei isso quando executei o arquivo SHOW ENGINE INNODB STATUS. Estou recebendo o seguinte:

----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 822986039, signal count 17045541908
--Thread 140562108442368 has waited at row0sel.c line 2930 for 0.00 seconds the semaphore:
S-lock on RW-latch at 0x7fd752e55c40 created in file buf0buf.c line 938
a writer (thread id 140562088974080) has reserved it in mode  exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file row0sel.c line 2930
Last time write locked in file /tmp/buildd/mysql-5.5-5.5.44/storage/innobase/buf/buf0buf.c line 3168

Na verdade, existem cerca de 15 instâncias disso.

Olhando para as transações, há apx 200 transações listadas, das quais apx metade aparece como waiting in InnoDB queue, e a outra metade é fetching data.

Todas as transações são SELECTconsultas e nenhuma delas mostra nenhum arquivo locks.

Alguém pode me dizer o que o SEMAPHORES(acima) se relaciona?

Tenho a seguinte tabela:

CREATE TABLE `tab1` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `DEFAULT` VARCHAR(25) DEFAULT NULL,
  `ITEM` varchar(25) DEFAULT NULL,
  `TIMESTAMP` TIMESTAMP DEFAULT NULL,
  `NAME` varchar(25) DEFAULT NULL,
  `SURNAME` varchar(45) DEFAULT NULL,
  `LOADED` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
);

Em seguida, tenho um arquivo XML contendo várias entradas, como:

<RECORD
  ITEM="item1"
  TIMESTAMP="2015-08-26 10:04:40"
  NAME="Bob"
  SURNAME="SMITH"
/>

Eu uso o MySQL para importar os dados com:

LOAD XML LOCAL INFILE 'c:/myFile.xml'
INTO TABLE `test`.`tab1`
ROWS IDENTIFIED BY '<RECORD>';

Isso funciona bem. No entanto, preciso especificar um valor padrão para o DEFAULTcampo. Mas ela precisa ser especificada na hora que carrego o arquivo, e será diferente para cada arquivo. (por uma questão de argumento, vamos usar o nome do arquivo, myfile.xml)

Como posso adicionar um valor padrão para esta linha durante a importação do XML?

Eu olhei para usar algo como:

LOAD XML LOCAL INFILE 'c:/myFile.xml'
INTO TABLE `test`.`tab1` (@default="myfile.xml")
ROWS IDENTIFIED BY '<RECORD>'; 
SET DEFAULT=@default;

Mas não gostou disso. Existe uma maneira de contornar isso?