詳細検索
↑↓移動
↵選択
ESC閉じる

Tentei o mysqlfailover depois de virar um daemon

Avatar
por komi01/04/2014
Tags failover ha mysqlutility
Tentei o mysqlfailover depois de virar um daemon
Traduzido do 日本語 • Ver original
  • Por favor, note **que este é um artigo desatualizado. **

Olá. Aqui é a Komiya.

Não sei se alguém ainda quer usar, mas testei e vou compartilhar aqui.
Este é um artigo longo, então por favor leia quando tiver tempo.

Inicie mysqlfailover sem usar --force e --daemon=start

Quando testei antes,
　--força não funcionava a menos que você instalasse,
　Não havia opção de ativá-lo com um demônio
Então, deixe-me confirmar isso mais uma vez.

・Estrutura: 

192.168.1.133 komiya-test-mysql01 my1
192.168.1.155 komiya-test-mysql02 my2
192.168.1.150 komiya-test-mysql03 my3
192.168.1.241 komiya-test-mysql04 gerenciador my4
192.168.1.222 VIP

・Instalação:
Você pode baixar o pacote no site oficial ou em algum lugar parecido.
Por enquanto, instalei o MySQL 5.6 e os utilitários no Chef.
SSH-Copy-ID e Preparação Solo de Faca
Especifique o papel do banco de dados na lista de execuções do arquivo de nó,
Apenas fazendo cozimento solo com faca, os seguintes e necessários arquivos de configuração são colocados,
Criei o servidor_host_id e o relatório\ o input automático.
Aqui está a receita que mencionei.

Abaixo estão os pacotes relacionados.
mysql-utilities é uma ferramenta escrita em Python, então mysql-connector-python é necessário. 

$ rpm -qa|grep -i mysql
MySQL-shared-compat-5.6.15-1.linux_glibc2.5.x86_64
MySQL-test-5.6.15-1.linux_glibc2.5.x86_64
perl-DBD-MySQL-4.013-3.el6.x86_64
mysql-utilities-1.4.1-1.el6.noarch
mysqltuner-1.1.1-1.el6.noarch
MySQL-client-5.6.15-1.linux_glibc2.5.x86_64
MySQL-server-5.6.15-1.linux_glibc2.5.x86_64
MySQL-devel-5.6.15-1.linux_glibc2.5.x86_64
mysql-connector-python-1.1.4-1.el6.noarch
mysqlreport-3.5-4.el6.noarch

・Build replicaiton
Como o servidor_id está definido para o quarto octeto do endereço IP, não deve haver duplicação.
O _host de relatório também deve ser configurado automaticamente para o seu próprio IP.

As configurações para replicação são as seguintes 

## Replicação (mestre/escravo)
log-bin=mysql-bin
log-bin-index=mysql-bin.index
binlog_format=misto
server-id = 133
relay-log=mysqld-relay-bin
relay-log-index=mysql-relay-bin.index
log_slave_updates=1
replicar-ignorar-db=mysql,information_schema,performance_schema
binlog-ignore-db=mysql,information_schema,performance_schema
skip_slave_start
read_only
#slave_net_timeout=120

## Replicação (para 5.6)
Modo gtid = DESLIGADO
enforce_gtid_consistency=falso
master-info-repository=TABLE
relay-log-info-repository=TABLE
relay_log_recovery=ON
#sync-master-info=1
trabalhadores-paralelos=0
binlog-checksum=CRC32
#master-verificar-checksum=1
#slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
#log_bin_use_v1_row_events=LIGADO
#sync_binlog=1
reporte-porto=3306
apresentador de relatório = 192.168.1.133

*Ajustes de parâmetros eram necessários. 

gtid-mode = ON
enforce_gtid_consistency=verdadeiro

Caso contrário, o mysqlfailover não vai funcionar. Tenho quase certeza.
Aliás, se o GTID estiver LIGADO, você não poderá processar transações que não sejam seguras para transações.
(O motor de armazenamento MyISAM não pode ser usado, Criar... Impossível de selecionar, etc.) 

sed -i 's/gtid-mode = OFF/gtid-mode = ON/g' /etc/my.cnf
sed -i 's/enforce_gtid_consistency=false/enforce_gtid_consistency=true/g' /etc/my.cnf
Service MySQL Restart

Faça um mestre e os outros escravos.

Os extratos GRANT necessários para contas adicionais como repl estão incluídos na receita, então é só conferi-los. 

mysql> selecione usuário, host, senha do mysql.user;
+------+---------------------+-------------------------------------------+
| usuário | apresentador | senha |
+------+---------------------+-------------------------------------------+
| raiz | localhost | *E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8 |
| raiz | komiya-test-mysql01 | *6A60A70C59535B75A79FDE4C7C55FDA55FC40A55 |
| raiz | 127.0.0.1 | *E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8 |
| raiz | ::1 | *E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8 |
| raiz | 192,168,% | *E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8 |
| repl | 192,168,% | *43E209EED080057E35C2630AC06D32960A46D120 |
+------+---------------------+-------------------------------------------+

Resetar mestre com 1~3; para inicializar a posição (isso foi feito porque os dados não estavam disponíveis). A implementação em certas condições é proibida. Cuidado com inconsistências)

Em 2 e 3 

mysql> MUDAR MASTER PARA 
MASTER_HOST='192.168.1.133',
MASTER_PORT=3306,
MASTER_USER='repl',
MASTER_PASSWORD='re*****',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=120;

mysql> iniciar escravo;
mysql> mostrar status de escravo\G
mysql> definir global read_only=1;
mysql> mostrar variáveis globais como 'read_only';
+---------------+-------+
| Variable_name | Valor |
+---------------+-------+
| read_only | ON |
+---------------+-------+

Quando ativar a posição automática 

parar o escravo;
mysql> MUDAR MASTER PARA 
MASTER_HOST='192.168.1.133',
MASTER_PORT=3306,
MASTER_USER='repl',
MASTER_PASSWORD='re*****',
MASTER_AUTO_POSITION = 1;
iniciar escravo;
  • Se o GTID estiver ativado, você pode especificar automaticamente sua posição,
    　Parece que você pode facilmente escrever receitas sem complicar a replicação com o chef.

Replicação confirmada em 1 

MySQL> apresentadores escravos;
+-----------+---------------+------+-----------+--------------------------------------+
| Server_id | Apresentador | Porto | Master_id | Slave_UUID |
+-----------+---------------+------+-----------+--------------------------------------+
|       150 | 192.168.1.150 | 3306 |       133 | afee6fde-978F-11E3-9F2A-02883E765295 |
|       155 | 192.168.1.155 | 3306 |       133 | 896d4156-9846-11e3-a3d2-02619050bb48 |
+-----------+---------------+------+-----------+--------------------------------------+
2 carreiras em conjunto (0,00 seg)

Verificação de Replicação Usando Utilidade em 4
Por enquanto, cada host precisa ser acessível via autenticação de chave SSH
(Parece que você precisa de permissão para definir o replicaiton, então eu defini como chave raiz.) 

# mysqlrpladmin --master=root:'cat /path_to_file'@192.168.1.133:3306 \
> --slaves=root:'cat /path_to_file'@192.168.1.155:3306,root:'cat /path_to_file'@192.168.1.150:3306 vida
# Conferindo privilégios.
#
# Topologia de Replicação Saúde:
+----------------+-------+---------+--------+------------+---------+
| apresentador | Porto | Função | estado | gtid_mode | Saúde |
+----------------+-------+---------+--------+------------+---------+
| 192.168.1.133 | 3306 | MESTRE | UP | ON | OK |
| 192.168.1.150 | 3306 | ESCRAVO | UP | ON | OK |
| 192.168.1.155 | 3306 | ESCRAVO | UP | ON | OK |
+----------------+-------+---------+--------+------------+---------+
# ... Pronto.

# mysqlrplcheck --master=root:'cat /path_to_file'@192.168.1.133:3306 --slave=root:'cat /path_to_file'@192.168.1.155:3306
# Mestre em 192.168.1.133: ... conectados.
# Escravo em 192.168.1.155: ... conectados.
Status da Descrição do Teste
---------------------------------------------------------------------------
Verificando o registro binário no master [pass]
Existem exceções para binlogs?                                         [AVISO]

+---------+--------+----------------------------------------------+
| servidor | do_db | ignore_db |
+---------+--------+----------------------------------------------+
| mestre |        | mysql,information_schema,performance_schema |
| escravo |        | mysql,information_schema,performance_schema |
+---------+--------+----------------------------------------------+

Existe um usuário de replicação?                                             [passo]
Verificando valores server_id [passar]
Verificando valores server_uuid [passar]
O slave está conectado ao mestre?                                        [passo]
Verifique o arquivo de informações mestre [pass]
Verificando a compatibilidade com o InnoDB [pass]
Verificando a compatibilidade dos motores de armazenamento [pass]
Verificando lower_case_table_names configurações [pass]
Verificando atraso escravo (segundos atrás do mestre) [passar]
# ... Pronto.

# mysqlrplcheck --master=root:'cat /path_to_file'@192.168.1.133:3306 --slave=root:'cat /path_to_file'@192.168.1.150:3306
# Mestre em 192.168.1.133: ... conectados.
# Escravo em 192.168.1.150: ... conectados.
Status da Descrição do Teste
---------------------------------------------------------------------------
Verificando o registro binário no master [pass]
Existem exceções para binlogs?                                         [AVISO]

+---------+--------+----------------------------------------------+
| servidor | do_db | ignore_db |
+---------+--------+----------------------------------------------+
| mestre |        | mysql,information_schema,performance_schema |
| escravo |        | mysql,information_schema,performance_schema |
+---------+--------+----------------------------------------------+

Existe um usuário de replicação?                                             [passo]
Verificando valores server_id [passar]
Verificando valores server_uuid [passar]
O slave está conectado ao mestre?                                        [passo]
Verifique o arquivo de informações mestre [pass]
Verificando a compatibilidade com o InnoDB [pass]
Verificando a compatibilidade dos motores de armazenamento [pass]
Verificando lower_case_table_names configurações [pass]
Verificando atraso escravo (segundos atrás do mestre) [passar]
# ... Pronto.

# Mysqlrplshow \
> --master=root:'cat /path_to_file'@192.168.1.133:3306 \
> --discover-slaves-login=root:'cat /path_to_file'
# Mestre em 192.168.1.133: ... conectados.
# Encontrando escravos para o mestre: 192.168.1.133:3306

# Grafo de Topologia de Replicação
192.168.1.133:3306 (MESTRE)
   |
   +--- 192.168.1.150:3306 - (ESCRAVA)
   |
   +--- 192.168.1.155:3306 - (ESCRAVA)

・Verifique a ajuda para o comando mysqlfailover 

# mysqlfailover --ajuda
------------------------------------------------
MySQL Utilities mysqlfailover versão 1.4.1 (parte da MySQL Workbench Distribution 6.0.0)
Tipo de licença: GPLv2
Uso: mysqlfailover --master=root@localhost --discover-slaves-login=root --candidates=root@host123:3306,root@host456:3306

mysqlfailover - monitoramento automático da saúde da replicação e failover

Opções:
  --versão mostrar o número da versão do programa e sair
  --ajuda para exibir esta mensagem de ajuda e sair
  --licença e saída do programa de exibição de licenças
  --candidatos=CANDIDATOS
                        Informações de conexão para servidores escravos candidatos para
                        Failover na forma:
                        <user>[:<password>]@<host>[:<port>][:<socket>] ou
                        <login-path>[:<porta>][:<socket>]. Válido apenas com
                        Comando de failover. Liste múltiplos escravos em vírgula-
                        Lista separada.
  --discover-slaves-login=DISCOVER
                        No início, mestre de consulta para todos os escravos registrados e
                        Use o nome de usuário e a senha especificados para se conectar.
                        Forneça o usuário e a senha no formulário
                        <usuário>[:<senha>] ou <login-path>. Por exemplo,
                        --discover-slaves-login=joe:secret usará 'joe' como
                        o usuário e 'secreto' como senha para cada um
                        Escravo descoberto.
~Omitido~

Se você especificar como --daemon=DAEMON, é instruído a escolher entre 'iniciar', 'parar', 'reiniciar' ou 'desanexar'. 

mysqlfailover: erro: option --daemon: escolha inválida: 'DAEMON' (escolha entre 'iniciar', 'parar', 'reiniciar', 'nodetach')

Tente o seguinte no passo 4. 

mysqlfailover \
--master=root:'cat /path_to_file'@192.168.1.133:3306 \
--candidate=root:'cat /path_to_file'@192.168.1.155:3306,root:'cat /path_to_file'@192.168.1.150:3306 \
--discover-slaves-login=root:'cat /path_to_file' \
--log=/tmp/failover.log \
--rpl-user=repl:re***** \
--redescobrir \
--modo de failover=auto \
--daemon=start \
-v
# mysqlfailover \
> --master=root:'cat /path_to_file'@192.168.1.133:3306 \
> --candidate=root:'cat /path_to_file'@192.168.1.155:3306,root:'cat /path_to_file'@192.168.1.150:3306 \
> --discover-slaves-login=root:'cat /path_to_file' \
> --log=/tmp/failover.log \
> --rpl-user=repl:re***** \
> --redescobrir \
> --failover-mode=auto \
> --daemon=start \
> -v
NOTA: O arquivo de log '/tmp/failover.log' não existe. Será criado.
Iniciando o daemon de failover...

Como a saída padrão não mostra status, verifique os logs 

# cauda /tmp/failover.log
2014-02-17 23:34:12 INFO Desregistrando instâncias existentes de escravos.
2014-02-17 23:34:12 INFO Registrando instância no master.
2014-02-17 23:34:12 INFO Privilégios de verificação.
2014-02-17 23:34:12 INFO Verificando privilégios de candidatos.
2014-02-17 23:34:12 PM CRÍTICO A raiz de usuário em 192.168.1.133 não tem privilégios suficientes para executar o comando de failover.
2014-02-17 23:34:12 CRÍTICO A raiz do usuário em 192.168.1.150 não tem privilégios suficientes para executar o comando de failover.
2014-02-17 23:34:12 PM CRÍTICO A raiz do usuário em 192.168.1.155 não tem privilégios suficientes para executar o comando de failover.
2014-02-17 23:34:12 PM CRÍTICO A raiz do usuário em 192.168.1.155 não tem privilégios suficientes para executar o comando de failover.
2014-02-17 23:34:12 CRÍTICO A raiz do usuário em 192.168.1.150 não tem privilégios suficientes para executar o comando de failover.
2014-02-17 23:34:12 INFO Desregistrando instância no master.

Parece que você não tem o direito de fazer failover na raiz especificada.
Eu não entendia direito, então pesquisei no Google e olhei o manual ORACLE (em inglês)
Utilitários MySQL (manual PDF)
3.4.3 Configuração Automática de Failover (P28) é escrita aproximadamente na mesma época.
O japonês parece não existir, mas HTML parece existir. (Mas parece que o PDF é mais preciso.)
Utilitários MySQL (manual HTML)

Havia uma página explicando a autoridade. 

3.4.3.4 Permissões Necessárias

O usuário deve ter permissões para configurar a replicação.
Os usuários devem ter permissão para configurar a replicação. 

Bem, mas raiz é para todos. Você está falando de 'com opção de concessão' ou algo assim?
Abaixo está uma explicação das permissões necessárias para comandos de definir replicação (como mysqlrpladmin).

3.4.2.4 Permissões Necessárias

O usuário m_account precisa dos seguintes privilégios para o mysqlreplicate: privilégios SELECT e INSERT no banco de dados mysql, REPLICATION SLAVE, REPLICATION CLIENT e GRANT OPTION. Quanto aos usuários slave_acc, eles precisam do privilégio SUPER. O usuário repl, usado como argumento para a opção --rpl-user, é criado automaticamente ou, se existir, precisa do privilégio REPLICATION SLAVE.

Para rodar a utilidade mysqlrpladmin com o comando saúde, o m_account usado no mestre precisa de um privilégio SUPER extra.

Quanto ao comando de troca, todos os usuários precisam dos seguintes privilégios: SUPER, CONCEDER OPÇÃO, SELECIONAR, RECARREGAR, SOLTAR, CRIAR e REPLICATION SLAVE

★ Ao traduzir a declaração de permissão necessária,
m_account (o usuário que se conecta ao mestre) requer as seguintes permissões:
    SELECT e INSERT no banco de dados mysql, REPLICATION SLAVE, REPLICATION CLIENT e GRANT OPTION.
slave_acc (o usuário que se conecta ao escravo) requer as seguintes permissões:
    SUPER privilégio.
repl (usuário de replicação) requer privilégios de REPLICATION SLAVE. Se você usar a opção --rpl-user, ela será gerada automaticamente (ou já gerada)
Todos os usuários que usam o comando toggle precisam dos seguintes privilégios:
    SUPER, CONCEDER OPÇÃO, SELECIONAR, RECARREGAR, SOLTAR, CRIAR e REPLICATION SLAVE

Aqui vão outras dicas

3.4.3.5 Dicas e Truques
O modo console que apresentei antes é o modo. No entanto, você também pode fazê-los correr como demônios.
Para isso、-- você precisa usar daemon, especificamente começando com '--daemon=start'.
Neste momento, mysqlfailover executa como um daemon e não envia nada para o console, gravando no arquivo especificado.
Para parar o daemon mysqlfailover, basta usar '--daemon=stop'.
 A menos que você especifique a opção --pidfile na inicialização, nenhuma outra opção é necessária; se especificada, a mesma opção é necessária.

Outro recurso útil é a possibilidade de personalizar o ambiente especificando scripts de extensão em tempo de execução.
--exec-fail-check Especifique um script para rodar regularmente em intervalos predefinidos para cada verificação padrão.
--exec-before Especifique o script a ser executado antes de iniciar o failover
--exec-after especifica o script a ser executado quando o processo de failover terminar
--exec-post-failover: Especifica o script a ser executado após failover (como um relatório de saúde)

Enfim, vamos verificar as permissões da minha conta atual. 

# pt-show-grants -u raiz -p'cat /path_to_file'
-- Subsídios descartados por subsídios de exposição de pacientes
-- Extraído do servidor Localhost via socket UNIX, MySQL 5.6.15-log em 2014-02-18 15:32:11
-- Subsídios para 'repl'@'192.168.%'
CONCEDER CLIENTE DE REPLICAÇÃO, ESCRAVO DE REPLICAÇÃO EM *.* PARA 'repl'@'192.168.%' IDENTIFICADO POR SENHA '*43E209EED080057E35C2630AC06D32960A46D120';
-- Subsídios para 'root'@'127.0.0.1'
CONCEDER TODOS OS PRIVILÉGIOS EM *.* A 'root'@'127.0.0.1' IDENTIFICADO PELA SENHA '*E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8' COM OPÇÃO DE CONCEDER;
-- Subsídios para 'root'@'192.168.%'
CONCEDA TODOS OS PRIVILÉGIOS EM *.* A 'root'@'192.168.%' IDENTIFICADO PELA SENHA '*E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8';
-- Subsídios para 'root'@'::1'
CONCEDER TODOS OS PRIVILÉGIOS EM *.* A 'root'@'::1' IDENTIFICADO PELA SENHA '*E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8' COM OPÇÃO DE CONCEDER;
-- Bolsas para 'root'@'komiya-test-mysql01'
CONCEDER TODOS OS PRIVILÉGIOS EM *.* A 'root'@'komiya-test-mysql01' IDENTIFICADO PELA SENHA '*6A60A70C59535B75A79FDE4C7C55FDA55FC40A55' COM OPÇÃO DE CONCESSÃO;
CONCEDER PROXY EM ''@'' PARA 'root'@'komiya-test-mysql01' COM OPÇÃO DE CONCESSÃO;
-- Subsídios para 'root'@'localhost'
CONCEDER TODOS OS PRIVILÉGIOS EM *.* A 'root'@'localhost' IDENTIFICADO PELA SENHA '*E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8' COM OPÇÃO DE CONCEDER;
CONCEDER PROXY EM ''@'' PARA 'root'@'localhost' COM OPÇÃO DE CONCESSÃO;

Como você precisa MUDAR MASTER ao mudar a topologia,
Parece que você precisa das permissões necessárias para a transição do mysqlreplicate ou do mysqladmin.

Quando tentei traduzir o capítulo anterior, percebi que as seguintes permissões eram necessárias. 

m_account (o usuário que se conecta ao mestre) requer as seguintes permissões:
    SELECT e INSERT no banco de dados mysql, REPLICATION SLAVE, REPLICATION CLIENT e GRANT OPTION.
slave_acc (o usuário que se conecta ao escravo) requer as seguintes permissões:
    SUPER privilégio.
Repl (usuário de replicação) requer as seguintes permissões:
    ESCLAVE DE REPLICAÇÃO。 Se você usar a opção --rpl-user, ela será gerada automaticamente (ou já gerada)
Todos os usuários que usam o comando toggle precisam dos seguintes privilégios:
    SUPER, CONCEDER OPÇÃO, SELECIONAR, RECARREGAR, SOLTAR, CRIAR e REPLICATION SLAVE

Pelo que vejo, a opção de master grant é insuficiente. Vou tentar criar um usuário de failover em vez de root.
Não quero adicionar uma opção de concessão em uma conta tão simples como o root, que permite execução pela rede.
Até agora, a opção de concessão de concessão só havia sido anexada a usuários locais.
Se eu tinha uma conta conectada remotamente, reconhecia como erro de operação.

Adicione isso ao master. Mas como o master também pode trocar, acho que tudo bem adicionar todos. 

CONCEDER TUDO em *.* até failover@'192.168.%' identificado por "xxxxxxxx" COM OPÇÃO DE CONCESSÃO;

Se você quiser ser rigoroso, seria assim. 

CONCEDER SELEÇÃO, INSERÇÃO, ESCRAVO DE REPLICAÇÃO, CLIENTE DE REPLICAÇÃO em *.* até m_failover@'192.168.%' identificado por "xxxxxxxx" COM OPÇÃO DE CONCESSÃO;
GRANT SUPER em *.* até s_failover@'192.168.%' identificado por "xxxxxxxx";
CONCEDER ESCRAVO DE REPLICAÇÃO em *.* até repl@'192.168.%' identificado por "xxxxxxxx";

Vou tentar abrir. 

mysqlfailover \
--master=failover:xxxxxxxx@192.168.1.133:3306 \
--candidato=failover:xxxxxxxx@192.168.1.155:3306 \
--discover-slaves-login=failover:xxxxxxxx \
--log=/tmp/failover.log \
--rpl-user=repl:re***** \
--redescobrir \
--modo de failover=auto \
--daemon=start \
-v
Iniciando o daemon de failover...
Múltiplas instâncias de daemon de failover encontradas para master 192.168.1.133:3306.
Se isso for um erro, reinicie o daemon com --force.
O modo de failover mudou para 'FAIL' neste caso.
Daemon começa em 10 segundos.
......... começando Daemon.

Vamos olhar os registros 

# cauda /tmp/failover.log
2014-03-27 02:06:32 AM INFO Descobrindo escravo em 192.168.1.150:3306
2014-03-27 02:06:32 AM INFO Descobrindo escravo em 192.168.1.155:3306
2014-03-27 02:06:32 INFO Informações Mestras
2014-03-27 02:06:32 AM INFO Arquivo Binário de Log: mysql-bin.000008, Posição: 191, Binlog_Do_DB: N/A, Binlog_Ignore_DB: mysql,information_schema,performance_schema
2014-03-27 02:06:32 AM INFO GTID Conjunto Executado: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
2014-03-27 02:06:32 AM INFO Obtendo saúde para o mestre: 192.168.1.133:3306.
2014-03-27 02:06:32 INFO Estado de Saúde:
2014-03-27 02:06:32 AM INFO host: 192.168.1.133, porta: 3306, função: MASTER, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000008, master_log_pos: 191, IO_Thread: , SQL_Thread: , Secs_Behind: , Remaining_Delay: , IO_Error_Num: , IO_Error: , SQL_Error_Num: , SQL_Error: , Trans_Behind:
2014-03-27 02:06:32 AM INFO host: 192.168.1.150, porta: 3306, função: ESCAVADA, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000008, master_log_pos: 191 , IO_Thread: Sim, SQL_Thread: Sim, Secs_Behind: 0, Remaining_Delay: Não, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
2014-03-27 02:06:32 AM INFO host: 192.168.1.155, porta: 3306, função: SLAVE, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000008, master_log_pos: 191 , IO_Thread: Sim, SQL_Thread: Sim, Secs_Behind: 0, Remaining_Delay: Não, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0

Havia um registro mostrando o vento que realmente havia se movido.

Olhando para o processo, parece assim 

# ps -ef|grep failover
root 1091 1 0 02:06 ?        00:00:00 /usr/bin/python /usr/bin/mysqlfailover --master=failover:xxxxxxxx@192.168.1.133:3306 --candidate=failover:xxxxxxxx@192.168.1.155:3306,failover: xxxxxxxx@192.168.1.150:3306 --discover-slaves-login=failover:xxxxxxxx --log=/tmp/failover.log --rpl-user=repl:re***** --rediscover --failover-mode=auto --daemon=start -v

Olhando atentamente para os troncos, 

2014-03-27 02:16:11 AM INFO Modo de failover = falha.

Tenho curiosidade de saber como coisas assim são mostradas. Eu me pergunto por quê.
Parece que falhar significa que não vai fazer failover, o que é um problema.
Depois de procurar, encontrei a página a seguir.
Tentei mysqlfailover com MySQL 5.6-rc - diário do hiroi10 

mysql> selecione * de mysql.failover_console;
+---------------+------+
| apresentador | Porto |
+---------------+------+
| 192.168.1.133 | 3306 |
+---------------+------+

Se você apagar isso e depois reiniciar o mysqlfailover, parece que o modo Failover não vai falhar.
É meio que como um arquivo de bloqueio em MHA.
Parece que o monitoramento de log para "Modo de failover = falha" é necessário.
Só pelo nome, monitorar logs com falha parece um pouco problemático, então você realmente precisa escolher as palavras-chave com cuidado.

Por enquanto, vou parar 

# mysqlfailover \
> --master=failover:xxxxxxxx@192.168.1.133:3306 \
> --candidato=failover:xxxxxxxx@192.168.1.155:3306 \
> --discover-slaves-login=failover:xxxxxxxx \
> --log=/tmp/failover.log \
> --rpl-user=repl:re***** \
> --redescobrir \
> --failover-mode=auto \
> --daemon=stop \
> -v
Parando o daemon de failover...
# ps -ef|grep failover

No mestre
mysql> excluir do mysql.failover_console;
Consulta OK, 1 linha afetada (0,02 seg)

mysql> selecione * de mysql.failover_console;
Conjunto vazio (0,00 seg)

No momento, não há alteração na configuração de replicação existente.
MySQL> apresentadores escravos;
+-----------+---------------+------+-----------+--------------------------------------+
| Server_id | Apresentador | Porto | Master_id | Slave_UUID |
+-----------+---------------+------+-----------+--------------------------------------+
|       150 | 192.168.1.150 | 3306 |       133 | afee6fde-978F-11E3-9F2A-02883E765295 |
|       155 | 192.168.1.155 | 3306 |       133 | 896d4156-9846-11e3-a3d2-02619050bb48 |
+-----------+---------------+------+-----------+--------------------------------------+

Lançamento 

# mysqlfailover \
> --master=failover:xxxxxxxx@192.168.1.133:3306 \
> --candidato=failover:xxxxxxxx@192.168.1.155:3306 \
> --discover-slaves-login=failover:xxxxxxxx \
> --log=/tmp/failover.log \
> --rpl-user=repl:re***** \
> --redescobrir \
> --failover-mode=auto \
> --daemon=start \
> -v
Iniciando o daemon de failover...

Talvez seja melhor adicionar --pidfile=.

Quando verifiquei os logs, estava configurado com sucesso como automático, como mostrado abaixo. 

# ver /tmp/failover.log
27-03-2014 03:00:21 AM INFO Modo failover = auto.

Vamos revisar as questões restantes aqui.
Outros itens para verificar:
　--daemon=reiniciar e outros testes
　Teste de Mudança
　Migração VIP Tente adicionar outros scripts externos
　Tente criar um script de início

・Verifique se reiniciações e outras funções são possíveis

Outras opções disponíveis no modo Deamon são 'iniciar', 'parar', 'reiniciar' e 'desligar', então vou tentar todas
Também encontrei um manual aqui.
Utilitário MySQL:: 5.9.1 mysqlfailover - Monitoramento automático da saúde da replicação e failover
Pelo que vi no manual, 'nodetach' parece exibir a tela do console também. 

# ps -ef|grep failover
root 1343 1 0 03:00 ?        00:00:08 /usr/bin/python /usr/bin/mysqlfailover --master=failover:xxxxxxxx@192.168.1.133:3306 --candidate=failover:xxxxxxxx@192.168.1.155:3306 --discover-slaves-login= failover:xxxxxxxx --log=/tmp/failover.log --rpl-user=repl:re***** --rediscover --failover-mode=auto --daemon=start -v

# mysqlfailover \
> --master=failover:xxxxxxxx@192.168.1.133:3306 \
> --candidato=failover:xxxxxxxx@192.168.1.155:3306 \
> --discover-slaves-login=failover:xxxxxxxx \
> --log=/tmp/failover.log \
> --rpl-user=repl:re***** \
> --redescobrir \
> --failover-mode=auto \
> --daemon=reiniciar \
> -v
Reiniciando o daemon de failover...
Múltiplas instâncias de daemon de failover encontradas para master 192.168.1.133:3306.
Se isso for um erro, reinicie o daemon com --force.
O modo de failover mudou para 'FAIL' neste caso.
Daemon começa em 10 segundos.
......... começando Daemon.
# ps -ef|grep failover
raiz 1500 1 0 03:30 ?        00:00:00 /usr/bin/python /usr/bin/mysqlfailover --master=failover:xxxxxxxx@192.168.1.133:3306 --candidate=failover:xxxxxxxx@192.168.1.155:3306 --discover-slaves-login= failover:xxxxxxxx --log=/tmp/failover.log --rpl-user=repl:re***** --rediscover --failover-mode=auto --daemon=reiniciar -v

# ver /tmp/failover.log
2014-03-27 03:30:09 AM INFO Modo de failover = fail.

Então, parece melhor não usar o reinício em geral,
Se você usar, pode ser sobre adicionar ---força.

Tentei adicionar --force 

# mysqlfailover --master=failover:xxxxxxxx@192.168.1.133:3306 --candidate=failover:xxxxxxxx@192.168.1.155:3306 --discover-slaves-login=failover:xxxxxxxx --log=/tmp/ failover.log --rpl-user=repl:re***** --rediscover --failover-mode=auto --daemon=restart --force -v
Reiniciando o daemon de failover...

# ps -ef|grep failover
raiz 1523 1 0 03:33 ?        00:00:00 /usr/bin/python /usr/bin/mysqlfailover --master=failover:xxxxxxxx@192.168.1.133:3306 --candidate=failover:xxxxxxxx@192.168.1.155:3306 --discover-slaves-login= failover:xxxxxxxx --log=/tmp/failover.log --rpl-user=repl:re***** --rediscover --failover-mode=auto --daemon=reiniciar --force -v

# ver /tmp/failover.log
2014-03-27 03:33:52 AM INFO Modo de failover = auto.

Bem, parece estar tudo bem. Quando uso o Photoshop, a saída de força de alguma forma parece uma perda.

Vou tentar o no-detach depois de parar uma vez. 

# mysqlfailover --master=failover:xxxxxxxx@192.168.1.133:3306 --candidate=failover:xxxxxxxx@192.168.1.155:3306 --discover-slaves-login=failover:xxxxxxxx --log=/tmp/ failover.log --rpl-user=repl:re***** --rediscover --failover-mode=auto --daemon=stop -v
Parando o daemon de failover...

# ps -ef|grep failover

Não esqueça de deletar o console no master também. 

mysql> selecione * de mysql.failover_console;
+---------------+------+
| apresentador | Porto |
+---------------+------+
| 192.168.1.133 | 3306 |
+---------------+------+
1 fileira em conjunto (0,00 seg)

mysql> excluir do mysql.failover_console;
Consulta OK, 1 linha afetada (0,00 seg)

mysql> selecione * de mysql.failover_console;
Conjunto vazio (0,00 seg)

Lançamento com nodetach 

# mysqlfailover \
> --master=failover:xxxxxxxx@192.168.1.133:3306 \
> --candidato=failover:xxxxxxxx@192.168.1.155:3306 \
> --discover-slaves-login=failover:xxxxxxxx \
> --log=/tmp/failover.log \
> --rpl-user=repl:re***** \
> --redescobrir \
> --failover-mode=auto \
> --daemon=nodetach \
> -v
Iniciando o daemon de failover...
# Descobrindo escravos para o mestre em 192.168.1.133:3306
# Descobrindo escravo em 192.168.1.150:3306
# Escravo encontrado: 192.168.1.150:3306
# Descobrindo escravo em 192.168.1.155:3306
# Escravo encontrado: 192.168.1.155:3306
# Conferindo privilégios.
# Conferindo privilégios nos candidatos.
# Descobrindo escravos para o mestre em 192.168.1.133:3306
# Tentando contato com 192.168.1.133 ... Sucesso
# Tentando contato com 192.168.1.150 ... Sucesso
# Tentando contato com 192.168.1.155 ... Sucesso
# Descobrindo escravos para o mestre em 192.168.1.133:3306
# Tentando contato com 192.168.1.133 ... Sucesso
# Tentando contato com 192.168.1.150 ... Sucesso
# Tentando contato com 192.168.1.155 ... Sucesso
# Descobrindo escravos para o mestre em 192.168.1.133:3306
# Tentando contato com 192.168.1.133 ... Sucesso
# Tentando contato com 192.168.1.150 ... Sucesso
# Tentando contato com 192.168.1.155 ... Sucesso

Parece que o registro continua fluindo sem parar no console.
Se você pressionar Ctl+C para sair, o processo parece travar.

ps -ef|grep failover

Não há nada

・Teste de Switch

Por enquanto, não vou lidar com VIP ou algo assim; apenas instalo o processo mestre MySQL.
Vamos verificar se o mestre de replicação faz switches.

DB1: 

mysql> selecione * de mysql.failover_console;
mysql> excluir do mysql.failover_console;
mysql> selecione * de mysql.failover_console;

DB4: 

ps -ef |grep failover
cauda -f /tmp/failover.log

mysqlfailover \
--master=failover:xxxxxxxx@192.168.1.133:3306 \
--candidato=failover:xxxxxxxx@192.168.1.155:3306 \
--discover-slaves-login=failover:xxxxxxxx \
--log=/tmp/failover.log \
--rpl-user=repl:re***** \
--redescobrir \
--modo de failover=auto \
--daemon=start \
-v

DB1: 

Parada de serviço MySQL

DB4: 

cauda /tmp/failover.log
27-03-2014 03:48:41 AM INFO Falhei ao reconectar ao master após 3 tentativas.
2014-03-27 03:48:41 AM CRÍTICO O Master está confirmado como fora do ar ou inacessível.
2014-03-27 03:48:41 AM INFO Failover iniciando no modo 'automático'...
2014-03-27 03:48:41 AM INFO Verificando a elegibilidade do escravo 192.168.1.155:3306 para o candidato.
2014-03-27 03:48:41 AM INFO GTID_MODE=ON ... Ok
2014-03-27 03:48:41 AM INFO Usuário de replicação existe ... Ok
2014-03-27 03:48:41 AM INFO Candidato escravo 192.168.1.155:3306 se tornará o novo mestre.
2014-03-27 03:48:41 AM INFO Verificando o status dos escravos (antes do failover).
2014-03-27 03:48:41 AM AVISO Problema detectado com a thread SQL para o escravo '192.168.1.150'@'3306' que pode resultar em uma topologia instável.
2014-03-27 03:48:41 AM AVISO - Tópico SQL rodando: Não
27-03-2014 03:48:41 AM AVISO - Erro SQL: 1146 - Worker 0 falhou na execução da transação 'e97b08ca-6798-11e3-a666-02c0661dc6e6:65' no log mestre mysql-bin.000008, end_log_pos 485; Erro ao executar evento de linha: 'Tabela 'mysql.failover_console' não existe'
2014-03-27 03:48:41 AM AVISO Problema detectado com thread SQL para o escravo '192.168.1.155'@'3306' que pode resultar em uma topologia instável.
2014-03-27 03:48:41 AM AVISO - Tópico SQL rodando: Não
2014-03-27 03:48:41 AM AVISO - Erro SQL: 1146 - Erro ao executar evento de linha: 'Tabela 'mysql.failover_console' não existe'
2014-03-27 03:48:41 AM INFO Preparando candidato para failover.
27-03-2014 03:48:41 AM INFO Lendo eventos no registro de retransmissão para o escravo 192.168.1.150:3306
2014-03-27 03:48:41 AM INFO Transações desaparecidas encontradas em 192.168.1.150:3306. SELECT gtid_subset() = 0
27-03-2014 03:48:41 AM INFO Conectando candidato ao 192.168.1.150:3306 como escravo temporário para recuperar GTIDs não processados.
2014-03-27 03:48:41 AM INFO Aguardando o candidato alcançar o escravo 192.168.1.150:3306.
2014-03-27 03:48:42 AM INFO Criando usuário de replicação caso não exista.
2014-03-27 03:48:42 AM INFO Parando escravos.
2014-03-27 03:48:42 AM INFO Executando STOP em todos os escravos.
2014-03-27 03:48:42 AM AVISO Executando parada no escravo 192.168.1.150:3306 AVISO - o escravo não está configurado com este mestre
2014-03-27 03:48:42 AM INFO Executando parada no escravo 192.168.1.150:3306 Ok
2014-03-27 03:48:42 AM AVISO Executando parada no escravo 192.168.1.155:3306 AVISO - o escravo não está configurado com este mestre
2014-03-27 03:48:42 AM INFO Executando parada no escravo 192.168.1.155:3306 Ok
2014-03-27 03:48:42 AM INFO Trocando escravos para o novo mestre.
27-03-2014 03:48:42 AM INFO Desconectando novo mestre como escravo.
2014-03-27 03:48:42 AM INFO Executar em 192.168.1.155:3306: REDEFINIR O ESCRAVO TUDO
27-03-2014 03:48:42 AM INFO Iniciando escravos.
2014-03-27 03:48:42 AM INFO Executando START em todos os escravos.
2014-03-27 03:48:42 AM INFO Executando início no escravo 192.168.1.150:3306 Ok
2014-03-27 03:48:42 AM INFO Verificando escravos em busca de erros.
2014-03-27 03:48:42 AM INFO 192.168.1.150:3306 status: Ok
27-03-2014 03:48:42 AM INFO Failover concluído.
2014-03-27 03:48:42 AM INFO Descobrindo escravos para mestre em 192.168.1.155:3306
2014-03-27 03:48:42 AM INFO Descobrindo escravo em 192.168.1.150:3306
2014-03-27 03:48:42 AM INFO Encontrado escravo: 192.168.1.150:3306
2014-03-27 03:48:47 AM INFO Desregistrando instâncias existentes de escravos.
2014-03-27 03:48:47 AM INFO Registrando instância no novo master 192.168.1.155:3306.
2014-03-27 03:48:47 INFO Informações Mestras
2014-03-27 03:48:47 AM INFO Arquivo Binário Binário: mysql-bin.000004, Posição: 547000, Binlog_Do_DB: N/A, Binlog_Ignore_DB: mysql,information_schema,performance_schema
27-03-2014 03:48:47 AM INFO GTID Conjunto Executado: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
2014-03-27 03:48:47 AM INFO Obtendo saúde para o mestre: 192.168.1.155:3306.
2014-03-27 03:48:47 AM INFO Estado de Saúde:
2014-03-27 03:48:47 AM INFO host: 192.168.1.155, porta: 3306, função: MASTER, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: , SQL_Thread: , Secs_Behind: , Remaining_Delay: , IO_Error_Num: , IO_Error: , SQL_Error_Num: , SQL_Error: , Trans_Behind:
27-03-2014 03:48:47 AM INFO host: 192.168.1.150, porta: 3306, função: SLAVE, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: Sim, SQL_Thread: Sim, Secs_Behind: 0, Remaining_Delay: Não, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
2014-03-27 03:49:05 AM INFO Descobrindo escravos para mestre em 192.168.1.155:3306
2014-03-27 03:49:05 AM INFO Descobrindo escravo em 192.168.1.150:3306
27-03-2014 03:49:05 INFO Informações Mestras
27-03-2014 03:49:05 AM INFO Arquivo Binário de Log: mysql-bin.000004, Posição: 547000, Binlog_Do_DB: N/D, Binlog_Ignore_DB: mysql,information_schema,performance_schema
27-03-2014 03:49:05 AM INFO GTID Conjunto Executado: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
2014-03-27 03:49:05 AM INFO Obtendo saúde para o mestre: 192.168.1.155:3306.
27-03-2014 03:49:05 INFO Status de Saúde:
2014-03-27 03:49:05 AM INFO host: 192.168.1.155, porta: 3306, função: MASTER, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: , SQL_Thread: , Secs_Behind: , Remaining_Delay: , IO_Error_Num: , IO_Error: , SQL_Error_Num: , SQL_Error: , Trans_Behind:
27-03-2014 03:49:05 AM INFO host: 192.168.1.150, porta: 3306, função: ESCAVADA, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: Sim, SQL_Thread: Sim, Secs_Behind: 0, Remaining_Delay: Não, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
2014-03-27 03:49:23 AM INFO Descobrindo escravos para mestre em 192.168.1.155:3306
2014-03-27 03:49:23 AM INFO Descobrindo escravo em 192.168.1.150:3306
2014-03-27 03:49:23 INFO Informações Mestras
2014-03-27 03:49:23 AM INFO Arquivo Binário de Log: mysql-bin.000004, Posição: 547000, Binlog_Do_DB: N/A, Binlog_Ignore_DB: mysql,information_schema,performance_schema
27-03-2014 03:49:23 AM INFO GTID Conjunto Executado: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
2014-03-27 03:49:23 AM INFO Obtendo saúde para o mestre: 192.168.1.155:3306.
27-03-2014 03:49:23 AM INFO Estado de Saúde:
2014-03-27 03:49:23 AM INFO host: 192.168.1.155, porta: 3306, função: MASTER, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: , SQL_Thread: , Secs_Behind: , Remaining_Delay: , IO_Error_Num: , IO_Error: , SQL_Error_Num: , SQL_Error: , Trans_Behind:
2014-03-27 03:49:23 AM INFO host: 192.168.1.150, porta: 3306, função: SLAVE, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: Sim, SQL_Thread: Sim, Secs_Behind: 0, Remaining_Delay: Não, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
2014-03-27 03:49:41 AM INFO Descobrindo escravos para mestre em 192.168.1.155:3306
27-03-2014 03:49:41 AM INFO Descobrindo escravo em 192.168.1.150:3306
27-03-2014 03:49:41 INFO Informações Mestras
2014-03-27 03:49:41 AM INFO Arquivo Binário de Log: mysql-bin.000004, Posição: 547000, Binlog_Do_DB: N/A, Binlog_Ignore_DB: mysql,information_schema,performance_schema
2014-03-27 03:49:41 AM INFO GTID Conjunto Executado: e97b08ca-6798-11e3-a666-02c0661dc6e6e6:1-64
27-03-2014 03:49:41 INFO Recuperando saúde para o mestre: 192.168.1.155:3306.
27-03-2014 03:49:42 AM INFO Situação de Saúde:
27-03-2014 03:49:42 AM INFO host: 192.168.1.155, porta: 3306, função: MASTER, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: , SQL_Thread: , Secs_Behind: , Remaining_Delay: , IO_Error_Num: , IO_Error: , SQL_Error_Num: , SQL_Error: , Trans_Behind:
2014-03-27 03:49:42 AM INFO host: 192.168.1.150, porta: 3306, função: SLAVE, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: Sim, SQL_Thread: Sim, Secs_Behind: 0, Remaining_Delay: Não, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
27-03-2014 03:50:00 AM INFO Descobrindo escravos para mestre em 192.168.1.155:3306
27-03-2014 03:50:00 AM INFO Descobrindo escravo em 192.168.1.150:3306
2014-03-27 03:50:00 INFO Informações Mestras
27-03-2014 03:50:00 AM INFO Arquivo Binário de Log: mysql-bin.000004, Posição: 547000, Binlog_Do_DB: N/A, Binlog_Ignore_DB: mysql,information_schema,performance_schema
2014-03-27 03:50:00 AM INFO GTID Conjunto Executado: e97b08CA-6798-11e3-A666-02C0661DC6E6:1-64
2014-03-27 03:50:00 AM INFO Recuperando saúde para o mestre: 192.168.1.155:3306.
27-03-2014 03:50:00 INFO Status de Saúde:
2014-03-27 03:50:00 AM INFO host: 192.168.1.155, porta: 3306, função: MASTER, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: , SQL_Thread: , Secs_Behind: , Remaining_Delay: , IO_Error_Num: , IO_Error: , SQL_Error_Num: , SQL_Error: , Trans_Behind:
27-03-2014 03:50:00 AM INFO apresentadora: 192.168.1.150, porta: 3306, função: ESCAVADA, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: Sim, SQL_Thread: Sim, Secs_Behind: 0, Remaining_Delay: Não, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
2014-03-27 03:50:18 AM INFO Descobrindo escravos para o mestre em 192.168.1.155:3306
27-03-2014 03:50:18 AM INFO Descobrindo escravo em 192.168.1.150:3306
2014-03-27 03:50:18 INFO Informações Mestras
2014-03-27 03:50:18 AM INFO Arquivo de Registro Binário: mysql-bin.000004, Posição: 547000, Binlog_Do_DB: N/A, Binlog_Ignore_DB: mysql,information_schema,performance_schema
2014-03-27 03:50:18 INFO GTID Conjunto executado: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
27-03-2014 03:50:18 AM INFO Obtendo saúde para o mestre: 192.168.1.155:3306.
2014-03-27 03:50:18 INFO Status de Saúde:
2014-03-27 03:50:18 AM INFO host: 192.168.1.155, porta: 3306, função: MASTER, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: , SQL_Thread: , Secs_Behind: , Remaining_Delay: , IO_Error_Num: , IO_Error: , SQL_Error_Num: , SQL_Error: , Trans_Behind:
2014-03-27 03:50:18 AM INFO host: 192.168.1.150, porta: 3306, função: SLAVE, estado: UP, gtid_mode: ON, saúde: OK, versão: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: Sim, SQL_Thread: Sim, Secs_Behind: 0, Remaining_Delay: Não, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0

# ps -ef |grep mysql
raiz 1599 1 0 03:46 ?        00:00:01 /usr/bin/python /usr/bin/mysqlfailover --master=failover:xxxxxxxx@192.168.1.133:3306 --candidate=failover:xxxxxxxx@192.168.1.155:3306 --discover-slaves-login= failover:xxxxxxxx --log=/tmp/failover.log --rpl-user=repl:re***** --rediscover --failover-mode=auto --daemon=start -v

DB3: 

mysql> mostrar status de escravo\G
*************************** 1. fileira ***************************
Slave_IO_State: Esperando o mestre enviar o evento
                  Master_Host: 192.168.1.155
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000004
          Read_Master_Log_Pos: 547000
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 408
        Relay_Master_Log_File: mysql-bin.000004
             Slave_IO_Running: Sim
            Slave_SQL_Running: Sim
              Replicate_Do_DB:
          Replicate_Ignore_DB: mysql, information_schema, performance_schema
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 547000
              Relay_Log_Space: 613
              Until_Condition: Nenhum
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: Não
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: Não
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 155
                  Master_UUID: 896d4156-9846-11e3-a3d2-02619050bb48
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: O escravo leu todo o registro de retransmissão; esperando o tópico de I/O escravo atualizar
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
                Auto_Position: 1
1 fileira em conjunto (0,00 seg)

O mestre alterna automaticamente.

DB2: 

mysql> mostrar status de escravo\G
Conjunto vazio (0,00 seg)

MySQL> apresentadores escravos;
+-----------+---------------+------+-----------+--------------------------------------+
| Server_id | Apresentador | Porto | Master_id | Slave_UUID |
+-----------+---------------+------+-----------+--------------------------------------+
|       150 | 192.168.1.150 | 3306 |       155 | afee6fde-978F-11E3-9F2A-02883E765295 |
+-----------+---------------+------+-----------+--------------------------------------+
1 fileira em conjunto (0,00 seg)

mysql> mostrar status mestre\G
*************************** 1. fileira ***************************
Arquivo: mysql-bin.000004
         Posição: 547000
     Binlog_Do_DB:
 Binlog_Ignore_DB: mysql, information_schema, performance_schema
Executed_Gtid_Set: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
1 fileira em conjunto (0,00 seg)

mysql> mostrar variáveis globais como 'read_only';
+---------------+-------+
| Variable_name | Valor |
+---------------+-------+
| read_only | ON |
+---------------+-------+
1 fileira em conjunto (0,00 seg)

O mestre comutou corretamente.
No entanto, não parece desligar automaticamente a leitura/_only do novo mestre.
Pelo que vejo sobre ajuda, essas opções não existem.
Parece que scripts externos precisam ser usados para lidar com operações de failover.

・Tente reestruturar a estrutura.

Assumindo que os dados absolutamente não estejam atualizados e que os hosts que executam a replicação estejam alinhados,
RESETAR MESTRE; e RESETAR ESCRAVO TODO; Então vou responder novamente e reverter.

Por enquanto, não há necessidade de trocar, então vou parar o processo de failover do MySQL 

# mysqlfailover --master=failover:xxxxxxxx@192.168.1.155:3306 --candidate=failover:xxxxxxxx@192.168.1.150:3306 --discover-slaves-login=failover:xxxxxxxx --log=/tmp/ failover.log --rpl-user=repl:re***** --rediscover --failover-mode=auto --daemon=stop -v
Parando o daemon de failover...

De alguma forma, ao parar após a troca, você precisa ajustar os valores de --master e --candidate=failover para travar.
Mas parece que, se você adicionar a opção --pidfile, ele trava mesmo sem adicionar --master ao especificar stop.

Vou restaurar a reputação.
DB1: 

NetStat -TANP
Início do serviço MySQL
mysql -u raiz -p
mostrar status mestre\G
mostrar status de escravo\G
apresentadores escravos do programa;
mostrar variáveis globais como 'read_only';
selecione * de mysql.failover_console;
excluir do mysql.failover_console;
selecione * de mysql.failover_console;
RESETAR MESTRE;

DB2: 

mysql -u raiz -p
mostrar status mestre\G
mostrar status de escravo\G
parar o escravo;
RESETAR TUDO ESCRAVO;
MUDAR MESTRE PARA 
MASTER_HOST='192.168.1.133',
MASTER_PORT=3306,
MASTER_USER='repl',
MASTER_PASSWORD='re*****',
MASTER_AUTO_POSITION = 1;
iniciar escravo;
mostrar status de escravo\G
apresentadores escravos do programa;
mostrar variáveis globais como 'read_only';
definir global read_only=1;

DB3:``` mysql -u raiz -p mostrar status de escravo\G parar o escravo; RESETAR TUDO ESCRAVO; mostrar status de escravo\G MUDAR MESTRE PARA MASTER_HOST='192.168.1.133', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='re*****', MASTER_AUTO_POSITION = 1; iniciar escravo; mostrar status de escravo\G mostrar variáveis globais como 'read_only'; definir global read_only=1; mostrar variáveis globais como 'read_only';


DB1:

apresentadores escravos do programa; +-----------+---------------+------+-----------+--------------------------------------+ | Server_id | Apresentador | Porto | Master_id | Slave_UUID | +-----------+---------------+------+-----------+--------------------------------------+ | 155 | 192.168.1.155 | 3306 | 133 | 896d4156-9846-11e3-a3d2-02619050bb48 | | 150 | 192.168.1.150 | 3306 | 133 | afee6fde-978F-11E3-9F2A-02883E765295 | +-----------+---------------+------+-----------+--------------------------------------+


Com isso, a configuração de replicação foi restaurada.  
MESTRE\_AUTO\_POSITION = 1; É muito conveniente.  
Se você apagar o mysql.failover\_console precisa pular isso,  
Resetar o MASTER com db1; Decidi fazer isso.  
  
・Considere usar um script externo para substituir o VIP  

Primeiro, sobre a opção de reconhecer scripts.

--exec-fail-check Especifique um script para rodar regularmente em intervalos predefinidos para cada verificação padrão. --exec-before Especifique o script a ser executado antes de iniciar o failover --exec-after especifica o script a ser executado quando o processo de failover terminar --exec-post-failover: Especifica o script a ser executado após failover (como um relatório de saúde)


Talvez eu devesse fazer cerca de quatro dos seguintes  

1. Faço uma verificação de F/O e baixo o MySQL mestre (talvez um papel parecido com o de Mon). Talvez você não precise disso? ）  
　　Se você fizer isso, o sistema principal verifica a conexão com o MySQL, então parece melhor encerrar quando o ping VIP não estiver passando.  
2. Antes do F/O começar, remova o VIP do velho mestre,  
3. Ao final do processo de F/O, adicione o VIP ao novo master e desative a leitura_only  
4. Depois que o F/O for concluído e o status for confirmado, reporte (se você conseguir monitorar a situação com o Zabbix, talvez não precise disso).  
  
São necessários pelo menos dois ou três.  
Além disso, dependendo do ambiente, você pode precisar de scripts que alterem a carga do escravo quando ele está distribuído por carga.  
Se o trabalho manual após a detecção causar uma nova carga mestra difícil e falhas secundárias provavelmente ocorrerem, isso é necessário.  
  
・Tente criar um script de início  
  
Como especificar várias coisas é complicado, parece melhor ter um, então decidi fazer um  
Parece que você poderia reutilizar o Redis que fiz outro dia.

cat /etc/init.d/mysqlfailover

#!/lixo/sh

Script simples mysqlfailover init.d concebido para funcionar em sistemas Linux

assim como usa o sistema de arquivos /proc.

chkconfig: - 85 15

Descrição: mysqlfailover

Nomedo do processo: mysqlfailover

. /etc/rc.d/init.d/functions

EXEC=/usr/bin/mysqlfailover prog=$(nome base $EXEC)

PIDFILE=/var/run/mysqld/failover.pid LOGFILE=/tmp/failover.log PORTO=3306 fouser=failover fopass=xxxxxxxx rpluser=repl rplpass=re***** old_master=192.168.1.133 new_master=192.168.1.155 intervalsec=15 exec_failchk=/usr/local/bin/failchk.sh exec_before=/usr/local/bin/before_failover.sh exec_after=/usr/local/bin/after_failover.sh exec_postfail=/usr/local/bin/post_failover.sh

start() { se [ -f $PIDFILE ] então echo "$PIDFILE existe, o processo já está rodando ou travou" senão $EXEC --master=${fouser}:${fopass}@${old_master}:${PORT}
--candidate=${fouser}:${fopass}@${new_master}:${PORT}
--discover-slaves-login=${fouser}:${fopass}
--log=${LOGFILE} --pidfile=${PIDFILE} -i ${intervalsec}
--rpl-user=${rpluser}:${rplpass} --rediscover
--failover-mode=auto --daemon=start -vv --force ##--exec-after=${exec_after} --exec-before=${exec_before}
##--exec-post-failover=${exec_postfail}
##--exec-fail-check=${exec_failchk}
fi } stop() { se [ ! -f $PIDFILE ] então eco "$PIDFILE não existe, o processo não está rodando" senão PID=$(gato $PIDFILE) $EXEC --log=${LOGFILE} --pidfile=${PIDFILE}
--daemon=stop -vv enquanto [ -x /proc/${PID} ] faça eco: "Esperando o mysqlfailover desligar... " Sono 1 Feito Echo "mysqlfailover parado" fi }

rh_status() { Status $prog }

Caso "$1" em início) Início ;; pare) Pare ;; reiniciar) Pare Início ;; status) rh_status ;; *) eco: "Por favor, use start ou stop como primeiro argumento" ;;

ESAC

chmod +x mysqlfailover

chkconfig --adicione mysqlfailover


Tentei adicionar só por precaução, mas parece que não começa a ser que a configuração de replicação esteja configurada corretamente.  
Como parece que vai ser manual de qualquer forma, decidi desligar a inicialização automática.

/etc/init.d/mysqlfailover start

Iniciando o daemon de failover...

ps -ef|grep fail

root 1095 1 1 00:43 ? 00:00:00 /usr/bin/python /usr/bin/mysqlfailover --master=failover:xxxxxxxx@192.168.1.133:3306 --candidate=failover:xxxxxxxx@192.168.1.155:3306 --discover-slaves-login= failover:xxxxxxxx --log=/tmp/failover.log --pidfile=/var/run/mysqld/failover.pid -i 15 --rpl-user=repl:re***** --rediscover --failover-mode=auto --daemon=start -vv

/etc/init.d/mysqlfailover status

mysqlfailover (pid 1095) está rodando...

/etc/init.d/mysqlfailover stop

Parando o daemon de failover... mysqlfailover parou

ps -ef|grep fail


Comecei com sucesso, parou e obtive o status normalmente.  

Remover mysql.failover\_console e reconfigurar a replicação é um pouco complicado,  
Talvez seja melhor adicionar --force ao começar após o início.  
Se você não deletar, o modo failover vai falhar.

/etc/init.d/mysqlfailover start

Iniciando o daemon de failover... Múltiplas instâncias de daemon de failover encontradas para master 192.168.1.133:3306. Se isso for um erro, reinicie o daemon com --force. O modo de failover mudou para 'FAIL' neste caso. Daemon começa em 10 segundos. ......... começando Daemon.


Quando instalei \--force, o modo failover funcionava normalmente como auto.  
  
Você pode precisar verificar se múltiplos processos podem iniciar para cada configuração de replicação diferente,  
Desta vez, como não tenho muito tempo, vou tentar outra vez.  
  
・Crie um script para gerenciar VIP e leitura\_only  
  
Defini o seguinte no script de inicialização.

exec_failchk=/usr/local/bin/failchk.sh exec_before=/usr/local/bin/before_failover.sh exec_after=/usr/local/bin/after_failover.sh exec_postfail=/usr/local/bin/post_failover.sh


O mínimo que você deve cumprir é o seguinte.  
2. Antes de começar o F/O, remova o VIP do mestre antigo e baixe o MySQL do mestre antigo  
3. Ao final do processo de F/O, adicione o VIP ao novo master e desative a leitura_only  
Parece que não precisa ser um script shell.  
  
Como estou testando na AWS, às vezes preciso me comunicar com a API para reinstalar o VIP.  
  
Comando para reconectar manualmente o VIP:

IP addr del 10.35.31.202/23 BRD 10.35.31.255 dev eth0 addr de ip adicionar 10.35.31.202/23 brd 10.35.31.255 dev eth0


Parte de referência do comando sytem chamada por um script externo que troca VIP em MHA:

sub start_vip() { 'ssh $ssh_user@$new_master_host " $ssh_start_vip "'; }

Uma chamada simples de sistema que desativa o VIP da old_master

sub stop_vip() { 'ssh $ssh_user@$orig_master_host " $ssh_stop_vip "'; system("ssh $ssh_user@$orig_master_host " $ssh_stop_mysqld ""); } meu $ssh_start_vip = "sudo /sbin/ip addr add $vip BRD $brd $nic"; My $ssh_stop_vip = "sudo /sbin/ip addr del $vip brd $brd dev $nic"; my $ssh_stop_mysqld = "sudo /sbin/service mysql stop";


Acho que preciso tornar possível a autenticação por chave SSH para substituição VIP.  
Fico pensando se preciso de permissões do sudo.  
  
Por enquanto, uso autenticação por chave SSH (aqui, root) do servidor de gerenciamento 04 para cada banco de dados  
DB4:

ssh-copy-id -i ~/.ssh/id_rsa komiya-test-mysql01

ssh-copy-id -i ~/.ssh/id_rsa komiya-test-mysql02

ssh-copy-id -i ~/.ssh/id_rsa komiya-test-mysql03

Visudo

#Defaults necessidade


Vou tentar criar um script baseado no HA que troque de IP privado na AWS.  
Como o anfitrião que conduz a execução não é um gerente, ajustes nessa área provavelmente são necessários.  
Pode ser necessário pré-definir o ENI tanto do mestre antigo quanto do novo.  
  
Por enquanto, adicionei VIP ao antigo mestre com comandos e conferi.  

AWS EC2 Assignar-Endereços-IP-privados \
--network-interface-id eni-27a2a945 \
--endereços-ip privados 192.168.1.222 --permitir-reatribuição

addr de ip add 192.168.1.222/24 brd 192.168.1.255 dev eth0


Confirmação por ping de outro servidor (a gestão da AWS também exige acesso VIP ao ping)

ping 192.168.1.222

vi /usr/local/bin/before_failover.sh

#!/lixo/batida

before_failover.sh: Antes de iniciar o F/O, remova o VIP do mestre antigo e instale o MySQL do mestre antigo

Dependência: mysqlfailover,after_failover.sh

Histórico de atualizações: 20140331 - criar komiyay

export PATH=$PATH:/usr/local/bin export AWS_CONFIG_FILE=/root/.ec2/aws.config datetime='date +%Y%m%d_%H%M%S' mailto=< endereço de e-mail do destinatário> velho mestre=192.168.1.133 mestre novo=192.168.1.155 VIP=192.168.1.222 subnetmask=24 BRD=192.168.1.255 nic=eth0 ssh_user=raiz oldmaster_eni='aws ec2 describe-network-interfaces --filters Name=addresses.private-ip-address,Values=${oldmaster} --query 'NetworkInterfaces[]. [NetworkInterfaceId]' --texto de saída'

ssh_stop_vip="sudo /sbin/ip addr del ${vip}/${subnetmask} brd ${brd} dev ${nic}" ssh_stop_mysqld="sudo /sbin/service mysql stop"

stop_vip() { eco: "Desativando o VIP no velho mestre" ssh ${ssh_user}@${oldmaster} "${ssh_stop_vip}" }

stop_mysql() { eco: "Pare o Mysql no velho mestre" ssh ${ssh_user}@${oldmaster} "${ssh_stop_mysqld}" }

aws_pip_unassign() { echo "Desabilitando os addres de IP privados virtuais da AWS" AWS EC2 UNASSIGN-Private-IP-Addresses
--network-interface-id ${oldmaster_eni}
--endereços ip privados ${vip}|tee /tmp/res.txt }

principal

#さきにsshの接続性を確認してダメならawsの処理だけする ssh ${ssh_user}@${oldmaster} ls /etc/hosts result_ssh='eco $?' se [ $result_ssh -eq 0 ]; então aws_pip_unassign grep true /tmp/res.txt res_unassign='eco $?' se [ ${res_unassign} -ne 0 ]; então printf "Erro: aws privateip unassign fail.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} Saída 1 fi stop_vip result_vip='eco $?' se [ ${result_vip} -ne 0 ]; então printf "Erro: parar vip é falha.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} Saída 1 fi stop_mysql result_mysql='eco $?' se [ ${result_mysql} -ne 0 ]; então printf "Erro: parar mysql está falhando.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} Saída 1 fi senão aws_pip_unassign grep true /tmp/res.txt res_unassign='eco $?' se [ ${res_unassign} -ne 0 ]; então printf "Erro: aws privateip unassign fail.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} Saída 1 fi printf "Aviso: o velho mestre está fora do ar.\nssh NG."
|mail -s "mysqlfailover-info_${datetime}" ${mailto} fi

saída 0

chmod +x /usr/local/bin/before_failover.sh

vi /usr/local/bin/after_failover.sh

#!/lixo/batida

after_failover.sh: Anexe o VIP ao novo mestre ao final do processo de F/O e desligue o read_only

Dependência: mysqlfailover,before_failover.sh

Histórico de atualizações: 20140331 - criar komiyay

export PATH=$PATH:/usr/local/bin export AWS_CONFIG_FILE=/root/.ec2/aws.config datetime='date +%Y%m%d_%H%M%S' mailto=< endereço de e-mail do destinatário> velho mestre=192.168.1.133 mestre novo=192.168.1.155 VIP=192.168.1.222 subnetmask=24 BRD=192.168.1.255 nic=eth0 ssh_user=raiz mysql_user=raiz mysql_pass='/path_to_file' newmaster_eni='aws ec2 describe-network-interfaces --filters Name=addresses.private-ip-address,Values=${newmaster} --query 'NetworkInterfaces[]. [NetworkInterfaceId]' --texto de saída'

ssh_start_vip="sudo /sbin/ip addr add ${vip}/${subnetmask} brd ${brd} dev ${nic}"

start_vip() { ssh ${ssh_user}@${newmaster} "${ssh_start_vip}" }

set_readonly() { mysql -u ${mysql_user} -p${mysql_pass} -h ${newmaster} -e 'set global read_only=0;' }

aws_pip_assign() { Echo "Ativando os Addres de IP Privados Virtuais da AWS" AWS EC2 Assignar-Endereços-IP-privados
--interface-rede-id ${newmaster_eni}
--endereços ip privados ${vip} --allow-reassignment|tee /tmp/res.txt }

principal

set_readonly result_ro='eco $?' se [ ${result_ro} -ne 0 ]; então printf "Erro: desliga somente leitura é falha.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} Saída 1 fi

aws_pip_assign grep true /tmp/res.txt result_pip='eco $?' se [ ${result_pip} -ne 0 ]; então printf "Erro: falha de atribuição do AWS PrivateIP.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} Saída 1 fi

start_vip result_vip='eco $?' se [ ${result_vip} -ne 0 ]; então printf "Erro: iniciar vip está falhando.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} Saída 1 fi

saída 0

chmod +x /usr/local/bin/after_failover.sh


Testes unitários aqui

bash -x /usr/local/bin/before_failover.sh


Principalmente checando o mestre antigo (se o IP foi removido e se o MySQL está fora do ar)

bash -x /usr/local/bin/after_failover.sh


Principalmente verificando o novo master (se o IP está ligado ou se a leitura_only está desligada)  
  
Modificar o script de inicialização

cp -p /etc/init.d/mysqlfailover{,.'date %Y%m%d'}

vi /etc/init.d/mysqlfailover

diff /etc/init.d/mysqlfailover{,.'date %Y%m%d'}

data: data inválida '%Y%m%d' 39,40c39,40 < --failover-mode=auto --daemon=start -vv --force
< --exec-before=${exec_before} --exec-after=${exec_after}

--failover-mode=auto --daemon=start -vv --force ##--exec-after=${exec_after} --exec-before=${exec_before} \

Início do serviço mysqlfailover

Iniciando o daemon de failover...

ps -ef|grep fail

raiz 1229 1 2 14:56 ? 00:00:00 /usr/bin/python /usr/bin/mysqlfailover --master=failover:xxxxxxxx@192.168.1.133:3306 --candidate=failover:xxxxxxxx@192.168.1.155:3306 --discover-slaves-login= failover:xxxxxxxx --log=/tmp/failover.log --pidfile=/var/run/mysqld/failover.pid -i 15 --rpl-user=repl:re***** --rediscover --failover-mode=auto --daemon=start -vv --force --exec-before=/usr/local/bin/before_failover.sh --exec-after=/usr/local/bin/after_failover.sh

ver /tmp/failover.log


Aqui, vamos tentar baixar o MySQL no DB1.  
  
Verifique com antecedência  

db1,2:

Programa IP addr MySQL> apresentadores escravos;


db2,3:

mostrar status de escravo\G mostrar programas globais como 'read_only';


DB3:

ping 192.168.1.222


DB4:

AWS EC2 Describe-Network-Interfaces
--filters Nome=endereços.endereço-ip-privado,Values=192.168.1.222
--consultar 'NetworkInterfaces[]. [NetworkInterfaceId]' --texto de saída

AWS EC2 Descreve-Network-Interfaces \

--filters Nome=endereços.endereço-ip-privado,Values=192.168.1.133
--consultar 'NetworkInterfaces[]. [NetworkInterfaceId]' --texto de saída ENI-27A2A945

AWS EC2 Descreve-Network-Interfaces \

--filters Nome=endereços.endereço-ip-privado,Values=192.168.1.155
--consultar 'NetworkInterfaces[]. [NetworkInterfaceId]' --texto de saída ENI-6CB3B90E

cauda -f /tmp/failover.log


Tente deixar cair o mestre  
DB1:

Parada de serviço MySQL


Confira novamente o endereço IP previamente confirmado e outros  
  
DB2:  
DB2 vem com VIP

IP addr show eth0|grep sec

INET 192.168.1.222/24 BRD 192.168.1.255 Escopo Secundário Global ETH0


Até IPs privados no estilo AWS foram movidos para a NIC do DB2.

AWS EC2 Descreve-Network-Interfaces \

--filters Name=addresses.private-ip-address,Values=192.168.1.222
--consultar 'NetworkInterfaces[]. [NetworkInterfaceId]' --texto de saída ENI-6CB3B90E


A leitura_only no db2 está desligada,

mysql> mostrar variáveis globais como 'read_only'; +---------------+-------+ | Variable_name | Valor | +---------------+-------+ | read_only | DESLIGADO | +---------------+-------+


Assistindo db3 como mestre de db2

MySQL> apresentadores escravos; +-----------+---------------+------+-----------+--------------------------------------+ | Server_id | Apresentador | Porto | Master_id | Slave_UUID | +-----------+---------------+------+-----------+--------------------------------------+ | 150 | 192.168.1.150 | 3306 | 155 | afee6fde-978F-11E3-9F2A-02883E765295 | +-----------+---------------+------+-----------+--------------------------------------+


A informação do escravo do DB2 foi resetada

mysql> mostrar status de escravo\G Conjunto vazio (0,00 seg)


Só para ter certeza, verifiquei no db1 que o mesmo comando não tinha um VIP anexado.

IP addr show eth0|grep sec


Então, como a operação esperada foi feita, a verificação está completa.  
Vou tentar baixar o sistema operacional e pular scripts de relatórios dependendo das circunstâncias.  

・Reconfigure  

DB4:

AWS EC2 UNASSIGN-Private-IP-Addresses
--network-interface-id eni-6cb3b90e
--endereços ip privados 192.168.1.222|tee /tmp/res.txt

AWS EC2 Assignar-Endereços-IP-privados
--network-interface-id eni-27a2a945
--endereços-ip privados 192.168.1.222 --permitir-reatribuição

AWS EC2 Describe-Network-Interfaces
--filters Nome=endereços.endereço-ip-privado,Values=192.168.1.222
--consultar 'NetworkInterfaces[]. [NetworkInterfaceId]' --texto de saída


DB2:

IP addr del 192.168.1.222/24 BRD 192.168.1.255 dev eth0 Programa IP addr DB1: addr de ip add 192.168.1.222/24 brd 192.168.1.255 dev eth0 Programa IP addr


*O representante foi mencionado antes, mas está sendo repostado  
DB1:

NetStat -TANP Início do serviço MySQL mysql -u raiz -p apresentadores escravos do programa; mostrar variáveis globais como 'read_only'; selecione * de mysql.failover_console; excluir do mysql.failover_console; selecione * de mysql.failover_console; RESETAR MESTRE;


DB2:

mysql -u raiz -p mostrar status mestre\G mostrar status de escravo\G parar o escravo; RESETAR TUDO ESCRAVO; MUDAR MESTRE PARA MASTER_HOST='192.168.1.133', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='re*****', MASTER_AUTO_POSITION = 1; iniciar escravo; mostrar status de escravo\G apresentadores escravos do programa; mostrar variáveis globais como 'read_only'; definir global read_only=1;


DB3:

mysql -u raiz -p mostrar status de escravo\G parar o escravo; RESETAR TUDO ESCRAVO; mostrar status de escravo\G MUDAR MESTRE PARA MASTER_HOST='192.168.1.133', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='re*****', MASTER_AUTO_POSITION = 1; iniciar escravo; mostrar status de escravo\G mostrar variáveis globais como 'read_only'; definir global read_only=1; mostrar variáveis globais como 'read_only';

Iniciar o serviço mysqlfailover ps -ef|grep fail


Aliás, a velocidade de comutação era mais ou menos a mesma do MHA, e ele alternava de forma suave e rápida.  
No entanto, havia um log mostrando três vezes esperando pelo interbal após detectar que o mestre poderia ter travado, então, por padrão, o tempo de espera provavelmente é de cerca de 45 segundos.  
Comparado ao MHA, acho que o problema é que você não precisa manter um registro de retransmissão do escravo por um certo período, e pode rodar no modo demoníaco.  
Existe uma limitação de que o 5.6 exige que o GTID esteja LIGADO, mas se o GTID estiver ativado no 5.6, a única opção para o HA por enquanto pode ser o mysqlfailover.  
Mas acontece que [MHA 0.56 (compatível com GTID 0.56](https://code.google.com/p/mysql-master-ha/wiki/ReleaseNotes#Changes_in_Manager_0.56_\(Apr_1_2014\)) apareceu (2014/4)!  
Que timing incrível.  
  
O motivo dos troncos estarem à meia-noite não é fixo e é EDT.  
Muito obrigado por ler tão longamente.

Veja mais

Related Articles