Então, estou implementando uma estratégia de backup para nosso projeto e encontrei um texto que preciso de esclarecimento absoluto, falsos positivos são a morte da TI.

Estou procurando fazer sua estratégia de backup típica, backup completo semanal com backups incrementais diários. Aqui está o problema:

De acordo com os documentos , ao fazer um backup completo, você deve 'prepará-lo', que é executar todas as transações não confirmadas, etc. Você pode preparar o backup usando o comando innobackupex --apply-log /path/to/BACKUP-DIR .

Mas, de acordo com esses documentos , se você fizer um backup incremental, precisará 'prepará-lo' de maneira diferente, usando o comando innobackupex --apply-log --redo-only BASE-DIR.

Meu plano é escrever um cronjob para fazer um backup completo no domingo às 12h01 e um incremental no M-Sa às 12h01. Portanto, minha pergunta é: o cronjob deve preparar todos os backups com o sinalizador --redo-only, para garantir que o backup completo possa ser mesclado com os seguintes backups incrementais?

Durante minha pesquisa superficial, não consegui encontrar uma resposta definitiva sobre os benefícios que ela SELECT INTO OUTFILEoferece INSERT INTO ... SELECT. Ao ler os documentos relacionados a INSERT INTO ... SELECTbloqueios em tabelas InnoDB, ele declara:

define um registro de índice exclusivo sem um bloqueio de lacuna em cada linha inserida em T. Se o nível de isolamento da transação for READ COMMITTED ou innodb_locks_unsafe_for_binlog estiver ativado e o nível de isolamento da transação não for SERIALIZABLE, o InnoDB faz a pesquisa em S como uma leitura consistente (sem fechaduras). Caso contrário, o InnoDB define bloqueios de próxima chave compartilhados em linhas de S.

Para evitar o bloqueio com INSERT INTO ... SELECTparece que devo garantir o nível READ COMMITTEDde isolamento é evitar bloqueios na tabela de origem durante a consulta.

No entanto, não consegui encontrar nenhuma resposta oficial sobre bloqueios e uso SELECT INTO OUTFILE, nem mesmo as informações de bloqueio de referência dos documentos do MySQL.

Meu objetivo é evitar o bloqueio da tabela de origem enquanto a consulta é executada para evitar o empilhamento de conexões.

Estou executando o Percona MySQL 5.5.39 em dois mestres com manutenção de monitoramento de um VIP que fará o failover para o mestre em espera se o mestre primário ficar escuro. Ao testar a tolerância a falhas da minha configuração no laboratório, notei que estou obtendo entradas de chave duplicadas em ambos os mestres.

Basicamente, eu executo o cerco para emular a carga do usuário, por cinco minutos, dentro desse tempo, desligo o mestre primário e, após cerca de 10 segundos, o keepalived detecta a interrupção, o VIP é trocado pelo mestre em espera, momento em que tudo está funcionando como esperado. Então, depois de um minuto ou mais, enquanto o cerco ainda está em execução, ligo o mestre primário e, quando online, ele assume o VIP.

É durante a troca do VIP que acho que está ocorrendo o problema de entrada duplicada. Eu segui esta postagem explicando como implementar a replicação 'resistente a falhas', mas depois de implementar as alterações sugeridas no my.cnf e reexecutar a simulação do usuário, acabei com a mesma replicação quebrada.

Há também a capacidade do mestre em espera de incrementar seus índices em 2 em vez de 1 para evitar colisões com o mestre primário, mas acho que isso é mais um truque do que uma solução.

Existe alguma maneira melhor de evitar colisões de chave primária em um ambiente HA?

Estou procurando melhorar nossa tolerância a falhas para nosso armazenamento persistente. Depois de ler vários documentos on-line sobre como configurar a replicação master <> master, ainda gostaria de perguntar aos especialistas sobre a ordem de configuração, para garantir que não perca nada importante.

Nossa configuração será um mestre <> mestre, no entanto, apenas um mestre será gravado por vez. Isso será controlado via "ip flutuante", que pode ser configurado para apontar para o mestre secundário, se o mestre primário falhar.

1. Com uma única configuração mestre de gravação <> mestre, não preciso me preocupar em definir a configuração auto_increment_offsetcorreta?

2. O MySQL replica todos os bancos de dados por padrão ou preciso identificá-los explicitamente por meio de binlog-do-db?

3. Preciso fazer uma exportação do master1 e importar para o master2, antes de iniciar a replicação, ou posso iniciar o master 2 para coletar todas as transações dos últimos meses?

4. Só para esclarecer, preciso configurar um usuário "replicador" (com permissões de replicação) em master1 e master2?

-- Atualização 15/08/2014 --

Este é o guia que segui para minha configuração inicial

Para responder à pergunta nº 2 , fiz o seguinte:

Observe que tenho uma performance_schematabela, porque estou usando o Percona MySQL. Pela edição de Rolando, o seguinte não é necessário se você deseja replicar TODOS os bancos de dados, no entanto, estou deixando aqui para a posteridade mostrar aos outros como eles podem especificar vários bancos de dados, se não quiserem exportar todos.

binlog_do_db = information_schema
binlog_do_db = mysql
binlog_do_db = performance_schema
binlog_do_db = example_blog
binlog_do_db = example_core
binlog_do_db = example_log

Para responder à pergunta nº 3 , acabei criando um instantâneo do Master1 emitindo o seguinte comando:

mysqldump -h localhost -p -u root --opt --all-databases --single-transaction --master-data  > /tmp/example_snapshot_`date +%Y_%m_%d__%H_%M_%S`.sql

Observe o --master-dataparâmetro, de acordo com a documentação do mysql, isso nos permite criar um instantâneo sem precisar criar uma nova sessão e lidar com o bloqueio da tabela. No entanto, adiciona uma linha extra ao .sqlarquivo resultante:

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000029', MASTER_LOG_POS=107;

Eu removi esta linha porque queria fazer essa alteração manualmente, em cada mestre.

Fico feliz em informar que a replicação parece estar funcionando. Obrigado Rolando!

Estou trabalhando em um projeto em que o trabalho em uma fila requer uma leitura de banco de dados em esquemas de tabelas heterogêneas (InnoDB/MyISAM). As consultas construídas durante o processo de "leitura" podem resultar em tempos de execução de 10 a 15 minutos e serão executadas em paralelo, digamos 10 a 15 por vez, mas cada uma será mutuamente exclusiva e não terá conhecimento de nenhum processo irmão.

PERGUNTAS

• É melhor interromper a replicação, emitir a consulta de leitura e reiniciar a replicação? Em caso afirmativo, o que acontece com uma consulta de leitura em execução no momento se a replicação for reativada repentinamente (por um processo irmão)?
• é seguro permitir consultas de leitura simultâneas e processamento de replicação?

Estou trabalhando em um projeto em que uma coluna enum está sendo convertida em uma coluna de texto (não posso alterar isso). A cardinalidade da coluna é baixa (7 valores exclusivos). Eu obteria um aumento de desempenho adicionando um índice de 10 a 15 caracteres ou a cardinalidade é baixa o suficiente para que o índice resulte em retornos decrescentes?

Acabei de encontrar um problema estranho, segundo o qual, dependendo de como eu crio um índice, é necessário um nome de índice.

http://dev.mysql.com/doc/refman/5.5/en/create-index.html

http://dev.mysql.com/doc/refman/5.5/en/alter-table.html

CREATE INDEX `random_name` ON `my_table` (`my_column`); # Requires an index name

ALTER TABLE `my_table` ADD INDEX (`my_column`); # Does not require an index name

Parece-me que a chamada CREATE INDEX não deve tornar o nome do índice obrigatório. Eu estou querendo saber se isso é um MySQLismo, ou um padrão SQL?

Estou tendo um problema com uma consulta bastante complexa em que preciso armazenar os IDs de uma tabela (com base em critérios pesados) em uma tabela alternativa estreita para referência futura, mas continuo encontrando um erro de construção de sql ruim.

Se eu executar a seguinte consulta sozinha, ela funcionará bem:

(SELECT DISTINCT a.id FROM accounts AS a
WHERE a.createdate >= date_sub(now(), INTERVAL 1 YEAR)
AND a.email NOT LIKE '%gmail.com')
UNION DISTINCT
(SELECT DISTINCT a.id FROM accounts AS a
WHERE a.createdate < date_sub(now(), INTERVAL 1 YEAR)
AND a.email NOT LIKE '%yahoo.com') AND a.email NOT IN
(SELECT email FROM inactive_clients));

No entanto, se eu tentar executar a mesma consulta assim:

INSERT INTO my_backup_table (account_id) VALUES ($aboveQuery);

Estou tendo o erro a seguir:

MySQL server version for the right syntax to use near 'UNION DISTINCT (SELECT DISTINCT a.id FROM accounts at line 1

Eu tentei qualquer número de permutações entre parênteses e ainda recebi o mesmo erro.

É possível emitir várias consultas de seleção cujos conjuntos de resultados são combinados via união, no mesmo arquivo de saída?

O que estou tentando fazer, mas não está funcionando:

(SELECT email FROM table WHERE createdate >= date_sub(now(), interval 1 year))
UNION DISTINCT
(SELECT email FROM table WHERE createdate < date_sub(now(), interval 1 year) AND email not like '%@gmail.com')
INTO OUTFILE '/tmp/emailDump.txt' FIELDS TERMINATED BY "," LINES TERMINATED BY "\n";