Início / dba / Perguntas / 87018
Accepted
Paddy Carroll
Asked: 2014-12-26 20:42:12 +0800 CST

Tabelas replicadas MySQL para Cognos BI

  • 772

o cara do Business Intelligence está pedindo máquinas mais rápidas, software mais recente, etc. e alguns de seus clientes estão reclamando de tempos de consulta superiores a uma hora. A ferramenta é Cognos/Insight e o banco de dados é uma cópia replicada de um MySQL mestre que em breve migraremos para o MariaDB.

Minha intuição (antes de começar a trabalhar com os planos SQL e de execução) é que estamos simplesmente lidando com consultas mal otimizadas vindas do Cognos e uma coleção inadequada de índices para apoiá-los.

Minha pergunta é (antes de propor uma solução): Existem estratégias aceitas para tabelas escravas em tempo real que permitem índices que não estão presentes na tabela mestre?

mysql replication

1 respostas

  1. Best Answer

    Ative o log de consulta lenta e log_queries_not_using_indexesno servidor escravo e poderá confirmar o que seu instinto está lhe dizendo. Você pode pegar as consultas capturadas, executá EXPLAIN-las e obter uma documentação melhor de suas suspeitas.

    Para responder mais diretamente à pergunta, é absolutamente válido declarar índices em um escravo que não são declarados no mestre. Eu sugeriria que é uma prática comum e uma das muitas razões pelas quais as réplicas são úteis para tantas coisas. Conecte-se ao escravo com uma conta com privilégios suficientes e altere a tabela diretamente no escravo.

    As únicas exceções a isso - que devem ser intuitivamente óbvias, já que os dados da linha precisam ser consistentes no mestre e na réplica - é que você não pode declarar com segurança uma UNIQUErestrição ou uma restrição de chave estrangeira em um escravo quando ela não existe em O mestre. Isso não vai funcionar, o que é bom, já que não faz sentido de forma alguma.

    Lembre-se também que os índices no MySQL possuem nomes, que são gerados automaticamente se não forem fornecidos quando o índice for adicionado. Uma boa prática pode ser nomear explicitamente esses índices na réplica para que os índices futuros adicionados ao mestre não possam causar uma colisão de nome de índice, o que interromperia a replicação. Minha convenção local é prefixar o nome do índice com "ix_repl_", que obviamente nunca seria usado no mestre.

    ALTER TABLE t1 ADD KEY ix_repl_last_first (last_name,first_name);

    Observe também que os índices duplicados adequados (onde exatamente as mesmas colunas, e nenhuma outra, estão incluídas em mais de um índice) são obsoletos no MySQL 5.6 e não são permitidos por padrão no MySQL 5.7, tornando aparentemente possível em versões posteriores causar a parada da replicação se você posteriormente declarar um índice idêntico (mesmo com um nome diferente) no mestre. Isso não seria um problema crítico (contanto que você esteja monitorando a replicação - você está, certo?) Uma vez que a replicação seria segura para reiniciar simplesmente removendo o índice agora redundante na réplica antes de reiniciar o encadeamento SQL escravo. O evento com falha seria repetido e agora seria válido, pois não há índice conflitante, e o índice de substituição seria criado na réplica.

    Observação lateral: lembre-se de que a replicação do MySQL exige que a versão do MySQL nos servidores de réplica seja a mesma ou mais recente que a versão no mestre ... portanto, ao atualizar (ou migrar para o MariaDB), você quase certamente desejará atualizar as réplicas primeiro e depois o mestre. A razão para isso é que uma réplica mais nova entenderá os recursos e peculiaridades de um mestre mais antigo, mas um mestre mais novo pode introduzir comportamentos no fluxo de replicação que um servidor de réplica mais antigo não conseguirá interpretar. Existem exceções limitadas a esta regra, mas é definitivamente a regra.

    • 1

relate perguntas