atxdba's questions

Eu tenho experimentado as opções de alta disponibilidade do GCPs SQL. Existe uma maneira de melhorar a velocidade de failover?

A tentativa de failover manual por meio da interface do usuário leva literalmente mais de 5 minutos, onde o mysql está completamente indisponível.

Estou usando as menores instâncias 5.7 de segunda geração possíveis atualmente sem tráfego atingindo-a.

Parece que está realmente parando e iniciando instâncias. Estou tendo problemas para ver como isso é uma opção para "HA" significando tempo de inatividade mínimo.

Estou tentando definir meu arquivo de log geral para um pipe nomeado fifo e estou recebendo um erro

$ sudo mkfifo -m 0666 general.fifo

mysql> set global general_log_file='/var/log/mysql/dradis/general.fifo';
ERROR 1231 (42000): Variable 'general_log_file' can't be set to the value of '/var/log/mysql/dradis/general.fifo'

mysql> \! ls -l /var/log/mysql/dradis/general.fifo
prw-rw-rw- 1 root root 0 Nov 27 14:27 /var/log/mysql/dradis/general.fifo

Versão que estou executando 5.6.20-68.0-log Percona Server.

Como posso fazer isso funcionar?

Ponto de leitura inicial: https://www.percona.com/blog/2015/04/29/generated-virtual-columns-in-mysql-5-7-labs/

Fazendo alguns testes com o percona 5.7 mais recente, eles parecem funcionar bem. Explique os planos e o tempo de parede parece muito bom, mas não estou vendo nenhuma diferença em mostrar o status da tabela index_length ou data_length.

Como você encontra a verdadeira pegada ou sobrecarga para usá-los?

Ao contrário das exibições, elas parecem ser mais rápidas do que as seleções marcadas.

Eu estava tentando avaliar o Hotbackup tokudb mais recente para o mecanismo tokudb do percona.

Esta instalação está no debian (Ubuntu 14)

Consegui instalar todos os pacotes sem erro e instalar todos os plug-ins toku básicos.

Tentando instalar o plugue de backup, recebo

mysql> install plugin tokudb_backup soname 'tokudb_backup.so';
ERROR 1126 (HY000): Can't open shared library '/usr/lib/mysql/plugin/tokudb_backup.so' (errno: 2 /usr/lib/mysql/plugin/tokudb_backup.so: undefined symbol: tokubackup_version_string)

mysql> select @@version;
+-------------+
| @@version   |
+-------------+
| 5.6.27-75.0 |
+-------------+
1 row in set (0.00 sec)

mysql> select @@tokudb_version;
+------------------+
| @@tokudb_version |
+------------------+
| 5.6.27-75.0      |
+------------------+
1 row in set (0.00 sec)

*Edições nos comentários: *

Este arquivo existe no sistema de arquivos

# ls -l /usr/lib/mysql/plugin/tokudb_backup.so
-rw-r--r-- 1 root root 23736 Nov  3 05:30 /usr/lib/mysql/plugin/tokudb_backup.so

Como posso instalar isso?

Eu li os documentos dizendo que log_slave_updates é necessário. Faz sentido para uma situação geral de promoção.

Mas isso ainda é necessário para algo que você pretende ser um escravo somente leitura que nunca será promovido?

Brincando com o TokuDB, estou descobrindo que mesmo depois de "otimizar a tabela" para coisas como alterar a compactação de linha ou outros DDLs, leva uma quantidade de tempo não determinística para que o espaço liberado seja refletido no sistema de arquivos.

Existe alguma maneira de forçar isso mais imediatamente ou visualizar o status de se a limpeza está em andamento ou agendada?

Eu queria saber se alguém tinha alguma indicação sobre a migração de tabelas MyIASM do mysql 5.5 para 5.6, especificamente usando compilações Percona, por meio de um rsync?

Isso é seguro?

Sei que precisamos fazer um mysqldump/reload completo para uma migração para tabelas InnoDB, mas não vi nenhuma observação sobre alterações significativas no formato MyISAM entre os dois.

Isso tornaria as coisas um pouco melhores para um banco de dados MyISAM bastante grande que levaria vários dias para ser concluído com um mysqldump.

Eu estava configurando um escravo e fazendo algumas somas de verificação da tabela para verificar se as coisas estavam bem antes de colocá-las no ar.

Eu fiz uma tabela de soma de verificação mysql nativa nos escravos depois de sincronizar o escravo com um ponto parado e comparar com um escravo preexistente.

Duas tabelas diferiam. Para detalhar, executei pt-table-checksum que relatou que o antigo e o novo escravo não tinham diferenças e as mesmas contagens de linha.

Para obter uma terceira opinião, fiz um select * into outfile ordenado por PK e executei um md5sum nas saídas. Aqueles também combinaram.

Uma diferença notável é que o escravo mais novo está executando uma versão mais recente (5.5.34 vs 5.5.29); ambas as construções de percona.

Esta diferença de versão é algo esperado ao causar diferenças nas somas de verificação? Nesse caso, parece estranho, eram apenas duas mesas e algumas dúzias.

Recentemente, promovi um novo membro a primário de um replicaset mongo. As coisas parecem estar funcionando bem por vários dias e não estou vendo nenhum sintoma de aplicativo de nenhum problema. No entanto, olhando para rs.status() hoje, notei que está listando maintenanceMode -7. Eu não acho que isso deveria ser possível, pois é o principal. Estou tendo problemas para encontrar algo útil nos documentos sobre o que isso significa.

O que isto significa?

    {
        "_id" : 26,
        "name" : "mongohost5:27032",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "uptime" : 106966,
        "optime" : Timestamp(1379627877000, 77),
        "optimeDate" : ISODate("2013-09-19T21:57:57Z"),
        "maintenanceMode" : -7,
        "self" : true
    }

A API JDBC lista um parâmetro includeThreadNamesAsStatementComment que parece indicar que ele prefixará todas as consultas com o ID do encadeamento Java. Achei que isso seria útil para vincular a atividade do banco de dados aos logs do aplicativo. Adicionei-o aos meus URLs de recursos e parecia estar funcionando apenas parte do tempo.

Curiosamente, era apenas o encadeamento de pulsação do aplicativo que executava pings periodicamente no banco de dados como parte de uma verificação de integridade. Nenhuma das consultas "reais" estava sendo marcada.

Por que isso não está funcionando para todas as consultas?

Eu tenho duas tabelas com esquemas idênticos. uma é uma tabela "principal" que é podada periodicamente e mantida pequena. A outra é uma tabela de "relatórios" que é um arquivo de tudo o que já existiu. Para simplificar, digamos que os esquemas da tabela se pareçam com

create table main_table(
    pk int unsigned not null primary key,
    value int unsigned
);

create table reporting_table(
    pk int unsigned not null primary key,
    value int unsigned
);

Eu tenho dois gatilhos, um AFTER INSERT e um AFTER UPDATE que se parecem com

create trigger reporting_insert after insert on main_table
    for each row 
        insert into reporting_table (id,value) VALUES
        (NEW.id, NEW.value);

create trigger trigger reporting_update after update on main_table
    for each row 
        update reporting_table  set
            value=NEW.value
        where
            id=NEW.id;

A tabela principal é preenchida com consultas como

insert into main_table values (1,10) on duplicate key update value=value+1;

Meu problema é que a tabela de relatórios não está capturando este ODKU +1 para o valor (e claramente está atualizando na tabela principal).

Dos documentos do gatilho :

Um exemplo potencialmente confuso disso é a sintaxe INSERT INTO ... ON DUPLICATE KEY UPDATE ...: um gatilho BEFORE INSERT será ativado para cada linha, seguido por um gatilho AFTER INSERT ou ambos os gatilhos BEFORE UPDATE e AFTER UPDATE , dependendo sobre se havia uma chave duplicada para a linha.

Ao ler isso, acho que seguiria o último caminho executado qualquer gatilho de atualização Antes/Depois. Fazer uma consulta UPDATE direta em main_table resulta na propagação das alterações para a tabela de relatórios.

o que estou perdendo?

Estou enfrentando um problema que parece ser um problema com as limitações do mysql 5.1s em caracteres UTF8.

De http://dev.mysql.com/doc/refman/5.1/en/charset-unicode-utf8.html

Currently, MySQL support for UTF-8 does not include 4-byte sequences.

Nosso aplicativo está lançando exceções periódicas como

java.sql.SQLException: Incorrect string value: '\xF4\x80\x82\x8C  ...'

A solução definitiva parece estar migrando para 5.5, que suporta UTF-8 > 3 bytes

Infelizmente, isso não seria tão simples quanto devolver as instâncias em binários mais recentes. Sendo um despejo de versão principal, precisaríamos fazer um recarregamento de despejo completo, o que exigiria algum tempo de inatividade programado.

Alguém já teve que lidar com essa situação antes? Existem boas alternativas de trabalho?

A abordagem ingênua parece ser fazer com que o aplicativo pesquise e substitua as sequências de vários bytes por pontos de interrogação ou � . Isso parece bastante hacky e não é uma opção muito palatável para mim ou para os desenvolvedores.

Então eu tive minha bagunça da semana hoje. Eu estava adicionando outro par de escravos e defini o mesmo ID de servidor no novo escravo como um escravo antigo.

O layout parece

Master
|     |
\/    |
oldS  |
      \/
      newS1
      |
      |
      \/
      newS2

Portanto, para esclarecer, o antigo escravo (oldS) e o primeiro novo escravo (novoS1) compartilham o mesmo ID de servidor.

Não é uma replicação circular, então espero que tudo dê certo. Eu não teria esperado as consequências embora.

Os alarmes começaram a disparar porque o oldS1 começou a ficar cada vez mais para trás. Olhando para o logdir, ele estava fazendo milhares e milhares de logs de retransmissão vazios.

Parei de trabalhar como escravo no newS1 e isso pareceu esclarecer as coisas, pois o oldS1 parou de fazer logs de retransmissão vazios e recuperou.

Ambos os escravos parecem estar em um estado consistente até o ponto em que parei de escravizar em newS1.

• Consertar tudo será tão simples quanto devolver newS1 com um novo e exclusivo ID ser kosher, especialmente considerando que newS1 é escravo de newS2?
• Há algo mais para ser cauteloso?
• Por que isso resultou em oldS gerando log de retransmissão vazio após log de retransmissão vazio? Eu teria pensado que oldS e newS1 não tinham conhecimento da existência dos outros.
• Achei que a rolagem do registro de retransmissão fosse determinada apenas pelo próprio escravo. O mestre está enviando algum sinal de que deve gerar um novo log de retransmissão?

Estou no processo de desativação de um antigo servidor mysql. É claro que restam algumas coisas conectadas a ele periodicamente que as pessoas esqueceram. Ativei o log de consulta geral para obter uma visão melhor do que ainda estava acontecendo lá para rastrear os culpados e notei algo estranho.

Houve uma entrada como:

870 Connect     <user>@<server> on

Ele continuou e fez sua coisa terminando com um

870 Quit

A próxima linha foi

1143 Connect     <user>@<server>

Por que o salto nos IDs de thread? Apenas verificando todas as linhas "Conectar", há rajadas de incrementos de IDs de encadeamento +1 e intervalos de tamanho variados para o próximo ID de conexão.

Esse é o comportamento esperado?

Existe alguma maneira de dizer com SQL se uma coluna indexada é a primeira parte de um índice.

A coisa mais próxima parece ser information_schema.columns. Mas isso parece apenas me dizer se é uma chave PRI ou MUL (não se é o único membro desse índice ou em que posição está se for uma chave composta).

Estou tentando descobrir a diferença entre algumas mensagens de aviso relacionadas ao truncamento de dados. Considere a seguinte tabela:

CREATE TABLE `txttest` (   
     `mycol` text NOT NULL ) 
ENGINE=InnoDB DEFAULT CHARSET=utf8;

Comportamento praticamente esperado:

mysql > insert into txttest (mycol) values (repeat('a',65535));
Query OK, 1 row affected (0.17 sec)

mysql > insert into txttest (mycol) values (repeat('a',65536));
Query OK, 1 row affected, 1 warning (0.16 sec)

mysql > show warnings;
+---------+------+--------------------------------------------+
| Level   | Code | Message                                    |
+---------+------+--------------------------------------------+
| Warning | 1265 | Data truncated for column 'mycol' at row 1 |
+---------+------+--------------------------------------------+
1 row in set (0.00 sec)

No entanto, quando estou usando caracteres multibyte, o estado de aviso esperado ocorre, mas a mensagem é diferente:

mysql > insert into txttest (mycol) values (repeat('é',65536/2-1));
Query OK, 1 row affected (0.17 sec)

mysql > insert into txttest (mycol) values (repeat('é',65536/2));
Query OK, 1 row affected, 1 warning (0.16 sec)

mysql > show warnings;
+---------+------+----------------------------------------------------------------+
| Level   | Code | Message                                                        |
+---------+------+----------------------------------------------------------------+
| Warning | 1366 | Incorrect string value: '\xC3\xA9' for column 'mycol' at row 1 |
+---------+------+----------------------------------------------------------------+
1 row in set (0.00 sec)

As tentativas do Google não são muito úteis, pois estou principalmente executando pastas desta mensagem para diferentes contextos.

Basicamente, o que eu quero saber é: isso é simplesmente o código de texto/erro que o Mysql usa ao truncar uma sequência de caracteres multibyte ou há algo mais revelador que eu deveria extrair dessa mensagem?

Inicialmente, pensei que isso significava que a sequência de bytes estava sendo dividida de tal forma que resultava em caracteres malformados. As tentativas de tentar fazer isso não funcionaram (por exemplo, o mysql parecia bom em reconhecer limites de bytes adequados para uma codificação de caracteres).

Editar:

Depois de reexaminar, parece ser a divisão de caracteres que inicialmente descartei. Eu tive um peido de um cérebro olhando para ele inicialmente.

Tenho algumas perguntas para os mais familiarizados. A maioria das minhas instâncias está executando o Antelope apesar de ter suporte para o Barracuda.

Eu estava procurando brincar com algumas tabelas innodb compactas. Meu entendimento é que isso só está disponível no formato Barracuda.

1. Vejo que o innodb_file_format é dinâmico, então posso alternar sem um salto. Existem quaisquer implicações de fazer isso que eu deveria estar ciente. Tudo o que posso dizer é que significa que novas tabelas ou alteradas posteriormente serão criadas com esse formato. Isso tudo está correto?
2. Eu esperava não ter que passar e converter todas as minhas tabelas. É kosher ter tabelas de antílopes e barracudas coexistindo no mesmo espaço de tabela? Mesmo que funcione , há alguma pegadinha para procurar?

Pelo que li e reuni dos meus testes, as respostas são: Sim. Sim. Não tenho certeza.

Atualizar

Eu tenho executado com algumas tabelas dinâmicas e compactadas em várias instâncias desde este post sem problemas. Além disso, deixei de ler http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html na época.

Depois de habilitar um determinado innodb_file_format, essa alteração se aplica apenas às tabelas recém-criadas, e não às existentes. Se você criar uma nova tabela, o tablespace que contém a tabela será marcado com o formato de arquivo “mais antigo” ou “mais simples” necessário para os recursos da tabela. Por exemplo, se você habilitar o formato de arquivo Barracuda e criar uma nova tabela que não seja compactada e não use ROW_FORMAT=DYNAMIC, o novo tablespace que contém a tabela será marcado como usando o formato de arquivo Antelope.

Assim, as tabelas serão criadas como Antelope mesmo se você permitir Barracuda. A mistura é inevitável, a menos que você especifique cada tabela como row_format dinâmica ou uma tabela compactada.

Não há indicação de que você deva fazer um dump completo e recarregar ao introduzir sua primeira tabela Barracuda (como é recomendado ao atualizar as versões principais do mysql )

Eu estou supondo que a resposta é não, mas eu queria saber se havia alguma maneira de dizer ao innodb para não armazenar as páginas buscadas no buffer pool?

A razão para fazer isso é verificar as tabelas de soma. Eu gostaria de minimizar os efeitos da lixeira dos dados úteis em cache.

Existe uma maneira de determinar o nome do host do servidor em que você está executando com um procedimento armazenado?

Você pode executar o nome do host do sistema de um cliente, mas não pode fazer chamadas de sistema do SP. Não vejo nenhuma das variáveis ​​globais ou status.

Desejo criar um procedimento/evento armazenado para fazer algumas tarefas de manutenção. Minhas configurações são mestre/escravo configuradas para cenários de failover (o que significa que o escravo não é usado para geração de relatórios, apenas pode ser promovido em caso de falha do mestre primário).

Eu gostaria que este procedimento armazenado fosse executado no agendador de eventos em ambos. Durante o curso normal da operação, gostaria que ele fizesse isso e deixasse essas operações fluírem pela cadeia normal de replicação. No caso de failover, gostaria apenas de detectar que não é o mestre e continuar o trabalho no que era anteriormente o escravo. (Menos coisas com que se preocupar durante um evento como esse).

Eu estava pensando em envolver a chamada inicial em um bloco de pseudocódigo que parecia

se I_AM_MASTER então

chamar real_work_sp;

fim se;

Qual é a melhor maneira de testar I_AM_MASTER? Sei que posso mostrar o status do mestre na linha de comando, mas não tenho certeza de como capturar isso para fins deste teste. Como eu faria isso, ou existe uma maneira melhor?

PS As operações não são apenas exclusões, eu poderia simplesmente deixar "cair" se elas fossem executadas duas vezes.