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?
Você precisa estar ciente dos resultados da consulta e do comportamento da consulta com a replicação em execução. Embora haja um mínimo de dois encadeamentos para a replicação do MySQL, é o encadeamento SQL que pode atrapalhar as consultas SELECT. Por quê?
MyISAMGenericName
Cada vez que um INSERT, um UPDATE ou um DELETE é executado, uma tabela completa bloqueada é emitida. Isso pode bloquear SELECTs. A única exceção é quando você tem concurrent_insert definido como 2 e a tabela MyISAM não experimenta nenhum UPDATE ou DELETE.
Por favor, veja minhas postagens anteriores sobre o comportamento do MyISAM.
Dec 04, 2013: Devemos bloquear tabelas MyISAM explicitamente ou é implícito....?Nov 25, 2011: Pergunta de bloqueio MyISAM do MySQLAFFECTS ON REPLICATION : Você deve se preocupar um pouco aqui porque o thread SQL processa apenas INSERTs, UPDATEs, DELETEs e vários comandos DDL. Se algum desses comandos for emitido pelo thread SQL durante a replicação do MySQL em uma tabela MyISAM que você está lendo, haverá alguma latência devido ao bloqueio momentâneo da tabela.
InnoDBGenericName
O InnoDB pode ser um pouco mais tolerante ao permitir que você leia uma tabela do InnoDB que está sendo gravada, mas tem um preço. Qual é o preço ???
InnoDB permite MVCC (Multiversion Concurrency Control) e Transaction Isolation . Isso significa que o InnoDB gravará muitas informações de limpeza e de ponto no tempo para que você possa ler as linhas de uma tabela do InnoDB sem bloquear as gravações de entrada e vice-versa.
Aqui está uma representação pictórica da arquitetura do InnoDB
Todas essas informações de limpeza e ponto no tempo ficam dentro dos segmentos Undo Space e Rollback dentro do tablespace do sistema.
AFETA NA REPLICAÇÃO : Quando se trata de replicação do MySQL, INSERTs, UPDATEs e DELETEs contra um InnoDB de um thread SQL ativo não bloquearão SELECTs das mesmas tabelas InnoDB. Obviamente, qualquer DDL em uma tabela InnoDB bloqueará SELECTs da mesma forma que uma tabela MyISAM faria .
REPLICAÇÃO do MySQL
A replicação do MySQL também pode ser afetada pelos mesmos motivos que mencionei. O sapato estaria no outro pé: o thread SQL ficaria bloqueado se precisasse fazer um INSERT, UPDATE ou DELETE em uma tabela MyISAM. Para InnoDB, as informações do MVCC seriam escritas para permitir SELECTs no Slave.
EPÍLOGO
Se o escravo tiver centenas de conexões de banco de dados, mais uma conexão de banco de dados (o thread SQL) pode não ser muito para se preocupar
Se você sabe que o Escravo pode experimentar um ataque de INSERTs, UPDATEs e DELETEs provenientes do SQL Thread do Escravo, você pode executar
STOP SLAVE;para desconectar o thread SQL e parar de processar comandos SQL e também parar de baixar os eventos binlog do Master. Como alternativa, você pode executarSTOP SLAVE SQL_THREAD;para desconectar o encadeamento SQL, mas permitir que o evento binlog mestre de entrada continue a ser baixado para seus logs reais e aguardar o processamento quandoSTART SLAVE;for emitido posteriormente. Se o número de comandos SQL provenientes da replicação do MySQL for pequeno e distante, a replicação do MySQL poderá ser deixada em execução.