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

데몬이 된 후 mysql failover를 시도해 봤습니다

아바타
글쓴이 komi2014. 04. 01.
태그 failover ha mysqlutility
데몬이 된 후 mysql failover를 시도해 봤습니다
日本語에서 번역 • 원문 보기
  • **이 문서는 오래된 문서임을 참고해 주세요. **

안녕하세요. 여기는 코미야야.

아직 사용하려는 사람이 있을지 모르겠지만, 테스트해보고 여기서 공유할게요.
이 글은 길어서 시간이 될 때 꼭 읽어보시길 바란다.

--force와 --daemon=start 없이 mysqlfailover를 시작하세요

전에 테스트해봤을 때,
　--포스는 설치하지 않으면 작동하지 않았어,
　악마로 활성화할 수 있는 옵션은 없었다
다시 한 번 확인해 보겠습니다.

·구조: 

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 my4 Manager
192.168.1.222 VIP

·설치:
공식 사이트나 이런 곳에서 패키지를 다운로드할 수 있습니다.
지금은 MySQL 5.6과 유틸리티를 Chef에 설치했습니다.
SSH-Copy-ID와 칼 단독 준비
노드 파일의 런리스트에서 db 역할을 지정하세요,
칼로 혼자 요리하는 것만으로도 다음과 같은 필수 구성 파일이 배치됩니다,
서버_id와 보고_host 자동으로 입력했어요.
제가 참고한 레시피가 여기 있습니다.

아래는 관련 패키지들입니다.
mysql-utilities는 파이썬으로 작성된 도구이므로 mysql-connector-python이 필요합니다. 

$ 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

·복제인간 건설
server_id가 IP 주소의 네 번째 옥텟으로 설정되어 있으니 중복이 없어야 합니다.
신고 _host 자동으로 본인 IP로 설정되어야 합니다.

복제자 설정은 다음과 같습니다 

## 복제 (마스터/슬레이브)
log-bin=mysql-bin
log-bin-index=mysql-bin.index
binlog_format=혼합
서버-ID = 133
Relay-Log=mysqld-relay-bin
relay-log-index=mysql-relay-bin.index
log_slave_updates=1
replicate-ignore-db=mysql,information_schema,performance_schema
binlog-ignore-db=mysql,information_schema,performance_schema
skip_slave_start
read_only
#slave_net_timeout=120

## 복제 (5.6을 위해)
GTID-모드 = 꺼
enforce_gtid_consistency=거짓
master-info-repository=TABLE
relay-log-info-repository=TABLE
relay_log_recovery=ON
#sync-master-info=1
노예-병렬-노동자=0
binlog-checksum=CRC32
#master-검증-체크섬=1
#slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
#log_bin_use_v1_row_events=켜
#sync_binlog=1
report-port=3306
report-host = 192.168.1.133

*매개변수 조정이 필요했습니다. 

gtid-mode = ON
enforce_gtid_consistency=참

그렇지 않으면 mysql failover가 작동하지 않습니다. 확실해.
참고로, GTID가 켜져 있으면 거래 안전하지 않은 거래를 처리할 수 없습니다.
(MyISAM 저장 엔진은 사용할 수 없으며, 생성... 선택 불가 등) 

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
서비스 MySQL 재시작

1명은 마스터, 나머지는 노예로 설정하세요.

repl 같은 추가 계정에 필요한 GRANT 명세서가 레시피에 포함되어 있으니 꼭 확인하세요. 

mysql> mysql.user에서 user, host, password를 선택하세요;
+------+---------------------+-------------------------------------------+
| 사용자 | 진행자 | 비밀번호 |
+------+---------------------+-------------------------------------------+
| 어루 | localhost | *E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8 |
| 어루 | Komiya-test-mySQL01 | *6A60A70C59535B75A79FDE4C7C55FDA55FC40A55 |
| 어루 | 127.0.0.1 | *E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8 |
| 어루 | ::1 | *E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8 |
| 어루 | 192.168.% | *E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8 |
| repl | 192.168.% | *43E209EED080057E35C2630AC06D32960A46D120 |
+------+---------------------+-------------------------------------------+

마스터를 1~3으로 리셋; 위치 초기화를 위해 (데이터가 없었기 때문에 시작됨). 특정 조건에서는 시행이 금지됩니다. 모순에 주의하세요)

2편과 3편에서 

MYSQL> MASTER CHANGE to 
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> Start slave;
mysql> show slave status\G
mysql> set global read_only=1;
mysql> 'read_only'와 같은 전역 변수를 표시하고;
+---------------+-------+
| Variable_name | 가치 |
+---------------+-------+
| read_only | 온(ON) |
+---------------+-------+

자동 위치 설정 활성화 시기 

노예 멈추기;
MYSQL> MASTER CHANGE to 
MASTER_HOST='192.168.1.133',
MASTER_PORT=3306,
MASTER_USER='repl',
MASTER_PASSWORD='re*****',
MASTER_AUTO_POSITION = 1;
노예 시작;
  • GTID가 활성화되어 있으면 자동으로 위치를 지정할 수 있습니다,
    　셰프를 사용하면 복제 시스템을 복잡하게 만들지 않고도 레시피를 쉽게 작성할 수 있는 것 같아요.

1에서 복제 확인 

mysql> show slave hosts;
+-----------+---------------+------+-----------+--------------------------------------+
| Server_id | 진행자 | 포트 | 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행 (0.00초)

유틸리티 4를 이용한 복제자 검증
현재로서는 각 호스트가 SSH 키 인증을 통해 접근 가능해야 합니다
(replicaiton을 설정하려면 권한이 필요해 보여서 루트 키로 설정했습니다.) 

# 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 Health
# 권한 확인.
#
# 복제 위상학 건강성:
+----------------+-------+---------+--------+------------+---------+
| 진행자 | 항구 | 역할 | 상태 | gtid_mode | 건강 |
+----------------+-------+---------+--------+------------+---------+
| 192.168.1.133 | 3306 | 주인님 | 업 | 온(ON) | 알겠어요 |
| 192.168.1.150 | 3306 | 노예 | 업 | 온(ON) | 알겠어요 |
| 192.168.1.155 | 3306 | 노예 | 업 | 온(ON) | 알겠어요 |
+----------------+-------+---------+--------+------------+---------+
# ... 끝났다.

# mysqlrplcheck --master=root:'cat /path_to_file'@192.168.1.133:3306 --slave=root:'cat /path_to_file'@192.168.1.155:3306
# 마스터 192.168.1.133: ... 연결되어 있었다.
# 노예 192.168.1.155: ... 연결되어 있었다.
테스트 설명 상태
---------------------------------------------------------------------------
마스터 [패스] 에서 이진 로그 확인
binlog 예외가 있나요?                                         [경고음]

+---------+--------+----------------------------------------------+
| 서버 | do_db | ignore_db |
+---------+--------+----------------------------------------------+
| 주인 |        | MySQL,information_schema,performance_schema |
| 노예 |        | MySQL,information_schema,performance_schema |
+---------+--------+----------------------------------------------+

복제 사용자가 존재하나요?                                             [패스]
server_id 값 확인 [패스]
server_uuid 값 확인하기 [통과]
노예가 주인과 연결되어 있나요?                                        [패스]
마스터 정보 파일 확인 [패스]
InnoDB 호환성 확인 [통과]
스토리지 엔진 호환성 확인 [패스]
설정 확인 lower_case_table_names [통과]
슬레이브 딜레이 확인 중(마스터보다 몇 초 늦음) [패스]
# ... 끝났다.

# mysqlrplcheck --master=root:'cat /path_to_file'@192.168.1.133:3306 --slave=root:'cat /path_to_file'@192.168.1.150:3306
# 마스터 192.168.1.133: ... 연결되어 있었다.
# 노예 192.168.1.150: ... 연결되어 있었다.
테스트 설명 상태
---------------------------------------------------------------------------
마스터 [패스] 에서 이진 로그 확인
binlog 예외가 있나요?                                         [경고음]

+---------+--------+----------------------------------------------+
| 서버 | do_db | ignore_db |
+---------+--------+----------------------------------------------+
| 주인 |        | MySQL,information_schema,performance_schema |
| 노예 |        | MySQL,information_schema,performance_schema |
+---------+--------+----------------------------------------------+

복제 사용자가 존재하나요?                                             [패스]
server_id 값 확인 [패스]
server_uuid 값 확인하기 [통과]
노예가 주인과 연결되어 있나요?                                        [패스]
마스터 정보 파일 확인 [패스]
InnoDB 호환성 확인 [통과]
스토리지 엔진 호환성 확인 [패스]
설정 확인 lower_case_table_names [통과]
슬레이브 딜레이 확인 중(마스터보다 몇 초 늦음) [패스]
# ... 끝났다.

# Mysqlrplshow \
> --master=root:'cat /path_to_file'@192.168.1.133:3306 \
> --discover-slaves-login=root:'cat /path_to_file'
# 마스터 192.168.1.133: ... 연결되어 있었다.
# 주인을 위한 노예 찾기: 192.168.1.133:3306

# 복제 위상수 그래프
192.168.1.133:3306 (마스터)
   |
   +--- 192.168.1.150:3306 - (슬레이브)
   |
   +--- 192.168.1.155:3306 - (슬레이브)

・mysqlfailover 명령어에 대한 도움말을 확인해 보세요 

# mysqlfailover --도움
------------------------------------------------
MySQL 유틸리티 mysqlfailover 버전 1.4.1 (MySQL Workbench Distribution 6.0.0의 일부)
라이선스 유형: GPLv2
Usage: mysqlfailover --master=root@localhost --discover-slaves-login=root --candidates=root@host123:3306,root@host456:3306

MySQLfailover - 자동 복제 상태 모니터링 및 장애 조치

선택지:
  --버전 쇼 프로그램 버전 번호와 종료
  --도움말 메시지 표시 및 종료
  --라이선스 표시 프로그램의 라이선스와 종료
  --후보자=후보자
                        후보 슬레이브 서버의 연결 정보
                        장애 전환 방식은 다음과 같습니다:
                        <user>[:<password>]@<host>[:<port>][:<socket>] 또는
                        <login-path>[:<port>][:<socket>]. 오직 다음과 같은 조건에서만 유효합니다
                        장애 전환 명령. 쉼표로 여러 노예를 나열하세요-
                        분리된 목록.
  --발견-노예-로그인=발견
                        시작 시, 모든 등록된 슬레이브에 대한 쿼리 마스터를 작성하고,
                        연결하려면 지정된 사용자 이름과 비밀번호를 사용하세요.
                        양식에 사용자와 비밀번호를 제공하세요
                        <user>[:<password>] 또는 <login-path>. 예를 들어,
                        --discover-slaves-login=joe:secret은 'joe'를 다음과 같이 사용합니다.
                        각 비밀번호는 사용자 이름이고 'secret'은
                        발견된 노예.
~생략~

--daemon=DAEMON으로 지정하면 'start', 'stop', 'restart', 'nodetach' 중 하나를 선택하라고 안내받습니다. 

mysqlfailover: error: option --daemon: invalid choice: 'DAEMON' ('start', 'stop', 'restart', 'nodetach' 중에서 선택)

4단계에서 다음 방법을 시도해 보세요. 

MySQL필립 \
--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' \
--로그=/tmp/failover.log \
--rpl-user=repl:re***** \
--재발견 \
--failover-mode=auto \
--데몬=시작 \
-v
# MySQL필립 \
> --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***** \
> --재발견 \
> --failover-mode=auto \
> --daemon=시작 \
> -v
참고: 로그 파일 '/tmp/failover.log'는 존재하지 않습니다. 만들어질 것입니다.
페일오버 데몬 시작...

표준 출력에는 상태가 없으니 로그를 확인하세요 

# 꼬리 /TMP/failover.log
2014-02-17 오후 23:34:12 정보 기존 인스턴스를 노예에서 등록 해제하기.
2014-02-17 오후 23:34:12 정보 마스터에 인스턴스 등록 중.
2014-02-17 오후 23:34:12 정보 사용 권한 확인.
2014-02-17 오후 23:34:12 정보 지원자 권한 확인.
2014-02-17 오후 23:34:12 치명: 192.168.1.133 사용자 루트가 장애 전환 명령을 실행할 충분한 권한이 없습니다.
2014-02-17 오후 23:34:12 치명적 192.168.1.150 사용자 루트가 페일오버 명령을 실행할 충분한 권한이 없습니다.
2014-02-17 오후 23:34:12 치명: 192.168.1.155 사용자 루트가 장애 전환 명령을 실행할 충분한 권한이 없습니다.
2014-02-17 오후 23:34:12 치명: 192.168.1.155 사용자 루트가 장애 전환 명령을 실행할 충분한 권한이 없습니다.
2014-02-17 오후 23:34:12 치명적 192.168.1.150 사용자 루트가 페일오버 명령을 실행할 충분한 권한이 없습니다.
2014-02-17 오후 23:34:12 정보 마스터에서 인스턴스 등록 취소.

지정된 루트 파일을 페일오버할 권리가 없는 것 같습니다.
잘 이해가 안 돼서 구글링하고 ORACLE 매뉴얼(영어)을 봤어요
MySQL 유틸리티 (PDF 매뉴얼)
3.4.3 설정 자동 장애 조치(P28)는 거의 같은 시기에 작성되었습니다.
일본어는 존재하지 않는 것 같지만, HTML은 존재하는 것 같습니다. (하지만 PDF가 더 정확한 것 같습니다.)
MySQL 유틸리티 (HTML 매뉴얼)

권한이 설명된 페이지가 있었다. 

3.4.3.4 필요 권한

사용자는 복제 구성을 위한 권한이 필요합니다.
사용자는 복제 설정을 위해 권한이 필요합니다. 

하지만 루트는 모두를 위한 모든 것을 위해서입니다. '그랜트옵션' 같은 걸 말씀하시는 건가요?
아래는 복제 설정 명령어(예: mysqlrpladmin)에 필요한 권한을 설명합니다.

3.4.2.4 필요 권한

m_account 사용자는 mysqlreplicate에 대해 다음 권한을 필요로 합니다: mysql 데이터베이스에 대한 SELECT 및 INSERT 권한, REPLICATION SLAVE, REPLICATION CLIENT, GRANT OPTION. slave_acc 사용자들은 SUPER 권한이 필요합니다. --rpl-user 옵션의 인수로 사용되는 repl 사용자는 자동으로 생성되거나, 존재한다면 REPLICATION SLAVE 권한이 필요합니다.

mysqlrpladmin 유틸리티를 health 명령어와 함께 실행하려면, 마스터에서 사용하는 m_account에 추가 SUPER 권한이 필요합니다.

전환 명령어와 관련해서는 모든 사용자가 다음 권한을 필요로 합니다: SUPER, GRANT OPTION, SELECT, RELOAD, DROP, CREATE, REPLICATION SLAVE

★ 필요한 허가 진술문을 번역할 때,
m_account(마스터에 접속하는 사용자)는 다음과 같은 권한을 요구합니다:
    SELECT 및 INSERT는 mysql 데이터베이스에서 수행하고, REPLICATION SLAVE, REPLICATION CLIENT, GRANT 옵션을 선택했습니다.
slave_acc(슬레이브에 접속하는 사용자)는 다음과 같은 권한을 요구합니다:
    슈퍼 특권이야.
repl(복제 사용자)은 복제 SLAVE 권한이 필요합니다. --rpl-user 옵션을 사용하면 자동으로 생성되거나 이미 생성되어 있습니다
토글 명령을 사용하는 모든 사용자는 다음과 같은 권한이 필요합니다:
    SUPER, GRANT OPTION, SELECT, RELOAD, DROP, CREATE, REPLICATION SLAVE

여기 몇 가지 다른 팁도 있습니다

3.4.3.5 팁과 요령
앞서 소개한 콘솔 모드가 바로 그 모드입니다. 하지만 악마로 운영할 수도 있습니다.
이를 위해서는 daemon을 사용해야 하며、-- 특히 '--daemon=start'로 시작해야 합니다.
이 시점에서 mysqlfailover는 데몬으로 실행되며 콘솔에 아무것도 출력하지 않고 지정된 파일에 기록합니다.
mysqlfailover 데몬을 멈추려면 '--daemon=stop'을 사용하면 됩니다.
 시작 시 --pidfile 옵션을 지정하지 않는 한, 다른 옵션은 필요하지 않습니다; 지정이 있으면 동일한 옵션이 필요합니다.

또 다른 유용한 기능은 런타임에 확장 스크립트를 지정하여 환경을 맞춤화할 수 있다는 점입니다.
--exec-fail-check 각 기본 체크마다 미리 정해진 간격으로 정기적으로 실행되도록 스크립트를 지정하세요.
--exec-before 페일오버 시작 전에 실행할 스크립트를 지정하세요
--exec-after는 페일오버 프로세스가 종료될 때 실행할 스크립트를 지정합니다
--exec-post-failover: 장애 조치 후 실행할 스크립트(예: 건강 보고서)

어쨌든, 현재 계정의 권한을 확인해 봅시다. 

# pt-show-grants -u root -p'cat /path_to_file'
-- pt-show-grants가 덤벼 주는 보조금들
-- 서버 Localhost에서 UNIX 소켓을 통해 덤프됨, MySQL 5.6.15-log 2014-02-18 15:32:11
-- 'repl'@'192.168.%'에 대한 보조금
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'REPL'@'192.168.%' 비밀번호로 식별됨 '*43E209EED080057E35C2630AC06D32960A46D120';
-- 'root'@'127.0.0.1'에 대한 보조금
*.*에 대한 모든 권한을 'root'@'127.0.0.1'에 부여하고, 비밀번호 '*E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8'로 식별되며, 부여 옵션으로 지정됩니다;
-- 'root'@'192.168.%'에 대한 보조금
*.*에 대한 모든 권한을 비밀번호 '*E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8'로 식별한 'root'@'192.168.%'에 부여합니다;
-- 'root'@'::1'에 대한 보조금
*.*에 대한 모든 권한을 'root'@'::1'에 부여하고, 비밀번호 '*E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8'로 식별됨;
-- 'root'@'komiya-test-mysql01'에 대한 보조금
*.*에 모든 권한을 'root'@'komiya-test-mysql01'에 부여하고, 비밀번호 '*6A60A70C59535B75A79FDE4C7C55FDA55FC40A55'로 부여 옵션으로 부여하세요;
'@'에서 'root'@'komiya-test-mysql01'로 GRANT 옵션을 사용하면;
-- 'root'@'localhost' 보조금
*.*에 대한 모든 권한을 'root'@'localhost'에게 부여하고, 비밀번호 '*E8DD65E018E30F27D962FB9BFA2F4E8206DC3AF8'로 식별하고 부여 옵션을 부여합니다;
'@'에서 'root'@'localhost'로 그랜트 옵션을 사용;

위상을 변경할 때 MASTER 변경이 필요하기 때문에,
mysqlreplicate나 mysqladmin 전환을 위해서는 필요한 권한이 필요한 것 같습니다.

이전 장을 번역하려고 했을 때, 다음과 같은 권한이 필요하다는 것을 알게 되었습니다. 

m_account(마스터에 접속하는 사용자)는 다음과 같은 권한을 요구합니다:
    SELECT 및 INSERT는 mysql 데이터베이스에서 수행하고, REPLICATION SLAVE, REPLICATION CLIENT, GRANT 옵션을 선택했습니다.
slave_acc(슬레이브에 접속하는 사용자)는 다음과 같은 권한을 요구합니다:
    슈퍼 특권이야.
Repl(복제 사용자)은 다음과 같은 권한을 요구합니다:
    복제 슬레이브. --rpl-user 옵션을 사용하면 자동으로 생성되거나 이미 생성되어 있습니다
토글 명령을 사용하는 모든 사용자는 다음과 같은 권한이 필요합니다:
    SUPER, GRANT OPTION, SELECT, RELOAD, DROP, CREATE, REPLICATION SLAVE

제가 보기에는 마스터 그랜트 옵션이 부족한 것 같습니다. root 대신 페일오버 사용자 생성을 시도해보겠습니다.
root처럼 네트워크를 통한 실행이 가능한 지나치게 단순한 계정에 그랜트 옵션을 추가하고 싶지 않습니다.
지금까지 보조금 옵션은 지역 사용자에게만 부여되었습니다.
원격으로 연결된 계정이 있으면 운영 오류로 인식했습니다.

이걸 마스터에 추가하세요. 하지만 마스터도 전환될 수 있으니 모두 추가해도 괜찮다고 생각합니다. 

"xxxxxxxx"로 식별되는 *.*에서 failover@'192.168.%'까지 모든 항목을 부여하고, 그랜트 옵션으로 식별;

엄격하게 말하고 싶다면 이렇게 할 거예요. 

*.* m_failover@'192.168.%'로 식별되는 'XXXXXXXX'로 식별되는 'GRANT SELECT, INSERT, REPLICATION SLAVE, REPLICATION CLIENT를 부여합니다;
그랜트 슈퍼 *.*에서 s_failover@'192.168.%' 'xxxxxxxx'로 식별;
*.*에서 repl@'192.168.%'로 식별되는 복제 슬레이브 부여, "xxxxxxxx"로 식별됨;

실행해 보겠습니다. 

MySQL필립 \
--master=failover:xxxxxxxx@192.168.1.133:3306 \
--candidate=failover:xxxxxxxx@192.168.1.155:3306 \
--discover-slaves-login=failover:xxxxxxxx \
--로그=/tmp/failover.log \
--rpl-user=repl:re***** \
--재발견 \
--failover-mode=auto \
--데몬=시작 \
-v
페일오버 데몬 시작...
마스터 192.168.1.133:3306에 대해 여러 번의 장애 전환 데몬 인스턴스가 발견됨.
만약 오류가 있다면, --force로 데몬을 재시작하세요.
이 경우 페일오버 모드가 'FAIL'으로 변경되었습니다.
데몬이 10초 후에 시작한다.
......... 데몬을 시작했다.

로그를 봅시다 

# 꼬리 /TMP/failover.log
2014-03-27 오전 2:06:32 정보 노예 발견 중 192.168.1.150:3306
2014-03-27 오전 2:06:32 정보 노예 발견 중 192.168.1.155:3306
2014-03-27 오전 2:06:32 정보 마스터 정보
2014-03-27 오전 2:06:32 정보 이진 로그 파일: mysql-bin.000008, 위치: 191, Binlog_Do_DB: 해당 없음, Binlog_Ignore_DB: mysql,information_schema,performance_schema
2014-03-27 02:06:32 AM 정보 GTID 실행 세트: e97B08CA-6798-11E3-a666-02c0661dc6e6:1-64
2014-03-27 오전 2:06:32 정보 마스터 체력 회복: 192.168.1.133:3306.
2014-03-27 오전 2:06:32 정보 건강 상태:
2014-03-27 오전 2:06:32 정보 호스트: 192.168.1.133, 포트: 3306, 역할: 마스터, 상태: UP, gtid_mode: 켜, 건강: OK, 버전: 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 오전 2:06:32 정보 호스트: 192.168.1.150, 포트: 3306, 역할: 슬레이브, 상태: UP, gtid_mode: ON, 건강: OK, 버전: 5.6.15-log, master_log_file: mysql-bin.000008, master_log_pos: 191 , IO_Thread: 네, SQL_Thread: 네, Secs_Behind: 0, Remaining_Delay: 아니요, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
2014-03-27 오전 2:06:32 정보 호스트: 192.168.1.155, 포트: 3306, 역할: 슬레이브, 상태: UP, gtid_mode: ON, 건강: OK, 버전: 5.6.15-log, master_log_file: mysql-bin.000008, master_log_pos: 191 , IO_Thread: 네, SQL_Thread: 네, Secs_Behind: 0, Remaining_Delay: 아니요, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0

바람이 실제로 움직였다는 기록이 있었다.

과정을 보면 이렇게 보입니다 

# 추신 -에브|그렙 장애 조치
루트 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***** --재발견 --failover-mode=자동 --daemon=시작 -v

통나무를 자세히 보면, 

2014-03-27 02:16:11 AM 정보 페일오버 모드 = 실패.

그런 것들이 어떻게 보여지는지 궁금합니다. 왜 그런지 궁금하네요.
실패하면 장애 전환이 안 된다는 뜻인 것 같아서 문제가 됩니다.
검색을 해보니 다음 페이지를 찾았습니다.
MySQL 5.6-rc로 mysqlfailover를 시도해 봤습니다 - hiroi10의 일기 

mysql> mysql.failover_console에서 * 선택;
+---------------+------+
| 진행자 | 항구 |
+---------------+------+
| 192.168.1.133 | 3306 |
+---------------+------+

이 모드를 삭제한 후 mysql failover를 재시작하면 Failover 모드가 실패하지 않는 것 같습니다.
이건 MHA의 잠금 파일 같은 느낌이에요.
"장애 조치 모드 = 실패"에 대한 로그 모니터링이 필요한 것 같습니다.
이름만 봐도 실패 로그를 모니터링하는 것은 다소 문제가 있어 보여서 키워드를 신중히 선택해야 합니다.

일단 그만할게 

# MySQL필립 \
> --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***** \
> --재발견 \
> --failover-mode=auto \
> --데몬=멈추고 \
> -v
장애 전환 데몬 중지...
# 추신 -에브|그렙 장애 조치

마스터에서
mysql> mysql.failover_console에서 삭제;
쿼리 OK, 1행 영향 (0.02초)

mysql> mysql.failover_console에서 * 선택;
빈 집합 (0.00초)

현재 기존 복제 구성에는 변화가 없습니다.
mysql> show slave hosts;
+-----------+---------------+------+-----------+--------------------------------------+
| Server_id | 진행자 | 포트 | 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 |
+-----------+---------------+------+-----------+--------------------------------------+

진수 

# MySQL필립 \
> --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***** \
> --재발견 \
> --failover-mode=auto \
> --daemon=시작 \
> -v
페일오버 데몬 시작...

--pidfile=을 추가하는 것이 더 나을 수도 있습니다.

로그를 확인해보니, 아래와 같이 자동으로 설정되어 있었습니다. 

# 보기/TMP/failover.log
2014-03-27 오전 3:00:21 정보 페일오버 모드 = 자동.

여기서 남은 문제들을 살펴보겠습니다.
기타 확인해야 할 항목들:
　--daemon=재시작 및 기타 검사
　스위치 테스트
　VIP 마이그레이션 다른 외부 스크립트를 추가해 보세요
　시작 스크립트를 만들어 보세요

・재부팅 및 기타 기능이 가능한지 확인해

Deamon 모드에서 제공하는 다른 옵션으로는 '시작', '정지', '재시작', '노드태크' 등이 있어서 모두 시도해보겠습니다
여기서 매뉴얼도 찾았어요.
MySQL 유틸리티:: 5.9.1 mysqlfailover - 자동 복제 상태 모니터링 및 장애 조치
매뉴얼에서 본 바로는, 'nodetach'가 콘솔 화면도 표시하는 것 같더군요. 

# 추신 -에브|그렙 장애 조치
루트 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***** --재발견 --failover-mode=자동 --daemon=시작 -v

# MySQL필립 \
> --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***** \
> --재발견 \
> --failover-mode=auto \
> --daemon=재시작 \
> -v
페일오버 데몬 재시작...
마스터 192.168.1.133:3306에 대해 여러 번의 장애 전환 데몬 인스턴스가 발견됨.
만약 오류가 있다면, --force로 데몬을 재시작하세요.
이 경우 페일오버 모드가 'FAIL'으로 변경되었습니다.
데몬이 10초 후에 시작한다.
......... 데몬을 시작했다.
# 추신 -에브|그렙 장애 조치
루트 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***** --재발견 --failover-mode=auto --daemon=restart -v

# 보기/TMP/failover.log
2014-03-27 오전 3:30:09 정보 페일오버 모드 = 실패.

그래서 일반적으로 재시작을 사용하지 않는 것이 가장 좋을 것 같습니다.
만약 사용한다면, 아마도 --힘을 더하는 것일 수 있습니다.

--힘을 추가해 보려고 했어요 

# 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
페일오버 데몬 재시작...

# 추신 -에브|그렙 장애 조치
루트 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***** --재발견 --페일오버-모드=자동 --데몬=재시작 --강제 -v

# 보기/TMP/failover.log
2014-03-27 오전 3:33:52 정보 페일오버 모드 = 자동.

음, 괜찮은 것 같아. 포토샵을 사용할 때는 --force 출력이 뭔가 손실된 느낌이 듭니다.

한 번 멈춘 후 노-디타치(no-detach)를 시도해볼게요. 

# 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
장애 전환 데몬 중지...

# 추신 -에브|그렙 장애 조치

마스터 콘솔도 잊지 마세요. 

mysql> mysql.failover_console에서 * 선택;
+---------------+------+
| 진행자 | 항구 |
+---------------+------+
| 192.168.1.133 | 3306 |
+---------------+------+
집합 내 1행 (0.00초)

mysql> mysql.failover_console에서 삭제;
쿼리 OK, 1행 영향 (0.00초)

mysql> mysql.failover_console에서 * 선택;
빈 집합 (0.00초)

노드태크를 이용한 발사 

# MySQL필립 \
> --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***** \
> --재발견 \
> --failover-mode=auto \
> --데몬=노드타크 \
> -v
페일오버 데몬 시작...
# 주인을 위한 노예 발견 중 192.168.1.133:3306
# 노예 발견 중 192.168.1.150:3306
# 발견된 노예: 192.168.1.150:3306
# 192.168.1.155:3306에서 노예 발견
# 노예 발견: 192.168.1.155:3306
# 권한 확인.
# 후보자 특권 확인.
# 주인을 위한 노예 발견 중 192.168.1.133:3306
# 192.168.1.133 연락 시도 중 ... 성공
# 192.168.1.150 ... 성공
# 192.168.1.155 연락 시도 중 ... 성공
# 주인을 위한 노예 발견 중 192.168.1.133:3306
# 192.168.1.133 연락 시도 중 ... 성공
# 192.168.1.150 ... 성공
# 192.168.1.155 연락 시도 중 ... 성공
# 주인을 위한 노예 발견 중 192.168.1.133:3306
# 192.168.1.133 연락 시도 중 ... 성공
# 192.168.1.150 ... 성공
# 192.168.1.155 연락 시도 중 ... 성공

로그가 콘솔에서 끝없이 이어지는 것 같아요.
Ctl+C를 눌러 종료하면 프로세스가 크래시되는 것 같습니다.

추신 -에브|그렙 장애 조치

아무것도 없어

·스위치 테스트

지금은 VIP 같은 건 처리하지 않을게요; 마스터 MySQL 프로세스를 설치하는 것만 하면 됩니다.
복제 마스터가 스위치되는지 확인해 봅시다.

DB1: 

mysql> mysql.failover_console에서 * 선택;
mysql> mysql.failover_console에서 삭제;
mysql> mysql.failover_console에서 * 선택;

DB4: 

PS -ef |grep failover
꼬리 -f /TMP/failover.log

MySQL필립 \
--master=failover:xxxxxxxx@192.168.1.133:3306 \
--candidate=failover:xxxxxxxx@192.168.1.155:3306 \
--discover-slaves-login=failover:xxxxxxxx \
--로그=/tmp/failover.log \
--rpl-user=repl:re***** \
--재발견 \
--failover-mode=auto \
--데몬=시작 \
-v

DB1: 

서비스 MySQL 정지

DB4: 

꼬리 /TMP/failover.log
2014-03-27 오전 3:48:41 정보 3번 시도 후 마스터에 재연결되지 않았습니다.
2014-03-27 오전 3:48:41 CRITICAL 마스터가 다운되었거나 연락이 닿지 않음이 확인됨.
2014-03-27 오전 3:48:41 정보 '자동' 모드에서 페일오버 시작...
2014-03-27 오전 3:48:41 정보 노예 자격 확인 192.168.1.155:3306 후보자.
2014-03-27 오전 3:48:41 정보 GTID_MODE=온... 알겠습니다
2014-03-27 오전 3:48:41 정보 복제 사용자가 존재합니다 ... 알겠습니다
2014-03-27 오전 3:48:41 정보 후보 노예 192.168.1.155:3306이 새로운 주인이 될 것입니다.
2014-03-27 오전 3:48:41 정보 노예 상태 확인 중(장애 전환 전).
2014-03-27 오전 3:48:41 경고 슬레이브 '192.168.1.150'@'3306'에 대한 SQL 스레드에서 문제가 감지되어 불안정한 토폴로지가 발생할 수 있습니다.
2014-03-27 오전 3:48:41 경고 - SQL 스레드 실행 중: 아니오
2014-03-27 오전 3:48:41 경고 - SQL 오류: 1146 - 워커 0이 트랜잭션 'e97b08ca-6798-11e3-a666-02c0661dc6e6:65'를 마스터 로그 mysql-bin.000008, end_log_pos 485에서 실행 실패; 행 이벤트 실행 오류: '테이블 'mysql.failover_console'이 존재하지 않습니다'
2014-03-27 오전 3:48:41 경고: 슬레이브 '192.168.1.155'@'3306'에 대한 SQL 스레드에서 불안정한 토폴로지를 유발할 수 있는 문제가 감지되었습니다.
2014-03-27 오전 3:48:41 경고 - SQL 스레드 실행 중: 아니오
2014-03-27 오전 3:48:41 경고 - SQL 오류: 1146 - 실행 실행 중 '테이블 'mysql.failover_console'이 존재하지 않음'
2014-03-27 오전 3:48:41 정보 후보자 페이일오버 준비 중.
2014-03-27 오전 3:48:41 정보 192.168.1.150:3306 슬레이 로그 내 이벤트 읽기
2014-03-27 오전 3:48:41 정보 192.168.1.150:3306에서 누락된 거래가 발견되었습니다. 선택 gtid_subset() = 0
2014-03-27 오전 3:48:41 정보 후보자를 192.168.1.1.150:3306에 임시 슬레이브로 연결하여 처리되지 않은 GTID를 복구합니다.
2014-03-27 오전 3:48:41 정보 후보가 노예 192.168.1.150:3306을 따라잡기를 기다리고 있습니다.
2014-03-27 오전 3:48:42 정보 복제 사용자가 존재하지 않는다면 생성.
2014-03-27 오전 3:48:42 정보 노예 막기.
2014-03-27 오전 3:48:42 정보 모든 노예에게 STOP 수행 중.
2014-03-27 오전 3:48:42 경고: 슬레이브 192.168.1.150:3306에서 정지 실행 중 경고 - 슬레이브가 이 마스터로 설정되어 있지 않습니다
2014-03-27 오전 3:48:42 정보 슬레이브 192.168.1.150:3306 실행 중지 완료
2014-03-27 오전 3:48:42 경고 슬레이브 192.168.1.155:3306에서 정지 실행 중 경고 - 슬레이브가 이 마스터로 설정되어 있지 않습니다
2014-03-27 오전 3:48:42 정보 슬레이브 192.168.1.155:3306 실행 중지 완료
2014-03-27 오전 3:48:42 정보 노예를 새 주인으로 전환하는 중.
2014-03-27 오전 3:48:42 정보 새 마스터를 노예로 분리하기.
2014-03-27 오전 3:48:42 정보 실행 192.168.1.155:3306: 모두 슬레이브 리셋
2014-03-27 오전 3:48:42 정보 노예 시작
2014-03-27 오전 3:48:42 정보 모든 노예에게 START 실행 중.
2014-03-27 오전 3:48:42 정보 슬레이브 시작 실행 중 192.168.1.150:3306 알겠습니다
2014-03-27 오전 3:48:42 정보 노예 오류 확인.
2014-03-27 오전 03:48:42 정보 192.168.1.150:3306 상태: OK
2014-03-27 오전 3:48:42 정보 장애 전환 완료.
2014-03-27 오전 3:48:42 정보 주인을 위한 노예 발견 192.168.1.155:3306
2014-03-27 오전 3:48:42 정보 노예 발견 중 192.168.1.150:3306
2014-03-27 오전 3:48:42 정보 노예 발견: 192.168.1.150:3306
2014-03-27 오전 3:48:47 정보 노예에서 기존 인스턴스 등록 해제.
2014-03-27 오전 3:48:47 정보 새 마스터에 인스턴스 등록 중 192.168.1.155:3306.
2014-03-27 오전 3:48:47 정보 마스터 정보
2014-03-27 오전 3:48:47 정보 바이너리 로그 파일: mysql-bin.000004, 위치: 547000, Binlog_Do_DB: 해당 없음, Binlog_Ignore_DB: mysql,information_schema,performance_schema
2014-03-27 오전 03:48:47 정보 GTID 실행 세트: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
2014-03-27 오전 3:48:47 정보 마스터 체력 회복: 192.168.1.155:3306.
2014-03-27 오전 3:48:47 정보 건강 상태:
2014-03-27 오전 3:48:47 정보 호스트: 192.168.1.155, 포트: 3306, 역할: 마스터, 상태: 위, gtid_mode: 켜, 건강: OK, 버전: 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 오전 3:48:47 정보 호스트: 192.168.1.150, 포트: 3306, 역할: 슬레이브, 상태: 위, gtid_mode: 켜, 건강: 괜찮음, 버전: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: 예, SQL_Thread: Secs_Behind: 0, Remaining_Delay: 아니, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
2014-03-27 오전 3:49:05 정보 주인을 위한 노예 발견 중 192.168.1.155:3306
2014-03-27 오전 3:49:05 정보 노예 발견 중 192.168.1.150:3306
2014-03-27 오전 3:49:05 정보 마스터 정보
2014-03-27 오전 3:49:05 정보 이진 로그 파일: mysql-bin.000004, 위치: 547000, Binlog_Do_DB: 해당 없음, Binlog_Ignore_DB: mysql,information_schema,performance_schema
2014-03-27 03:49:05 AM 정보 GTID 실행 세트: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
2014-03-27 오전 3:49:05 정보 마스터 체력 회복: 192.168.1.155:3306.
2014-03-27 오전 3:49:05 정보 건강 상태:
2014-03-27 오전 3:49:05 정보 호스트: 192.168.1.155, 포트: 3306, 역할: 마스터, 상태: UP, gtid_mode: ON, 건강: OK, 버전: 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 오전 3:49:05 정보 호스트: 192.168.1.150, 포트: 3306, 역할: 슬레이브, 상태: UP, gtid_mode: ON, 건강: OK, 버전: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: 예, SQL_Thread: Secs_Behind: 0, Remaining_Delay: 아니, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
2014-03-27 오전 3:49:23 정보 주인을 위한 노예 발견 192.168.1.155:3306
2014-03-27 오전 3:49:23 정보 노예 발견 중 192.168.1.150:3306
2014-03-27 오전 3:49:23 정보 마스터 정보
2014-03-27 오전 3:49:23 정보 바이너리 로그 파일: mysql-bin.000004, 위치: 547000, Binlog_Do_DB: 해당 없음, Binlog_Ignore_DB: mysql,information_schema,performance_schema
2014-03-27 03:49:23 AM 정보 GTID 실행 세트: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
2014-03-27 오전 3:49:23 정보 마스터 체력 획득: 192.168.1.155:3306.
2014-03-27 오전 3:49:23 정보 건강 상태:
2014-03-27 오전 3:49:23 정보 호스트: 192.168.1.155, 포트: 3306, 역할: 마스터, 상태: UP, gtid_mode: 켜, 건강: OK, 버전: 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 오전 3:49:23 정보 호스트: 192.168.1.150, 포트: 3306, 역할: 슬레이브, 상태: UP, gtid_mode: ON, 건강: OK, 버전: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: 예, SQL_Thread: Secs_Behind: 0, Remaining_Delay: 아니, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
2014-03-27 오전 3:49:41 정보 주인을 위한 노예 발견 192.168.1.155:3306
2014-03-27 오전 3:49:41 정보 192.168.1.150:3306에서 노예 발견
2014-03-27 오전 3:49:41 정보 마스터 정보
2014-03-27 오전 3:49:41 정보 바이너리 로그 파일: mysql-bin.000004, 위치: 547000, Binlog_Do_DB: 해당 없음, Binlog_Ignore_DB: mysql,information_schema,performance_schema
2014-03-27 03:49:41 AM 정보 GTID 실행 세트: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
2014-03-27 오전 3:49:41 정보 마스터 체력 획득: 192.168.1.155:3306.
2014-03-27 오전 3:49:42 정보 건강 상태:
2014-03-27 오전 3:49:42 정보 호스트: 192.168.1.155, 포트: 3306, 역할: 마스터, 상태: 위, gtid_mode: 켜, 건강: OK, 버전: 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 오전 3:49:42 정보 호스트: 192.168.1.150, 포트: 3306, 역할: 노예, 상태: 위, gtid_mode: 켜, 건강: OK, 버전: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: 예, SQL_Thread: Secs_Behind: 0, Remaining_Delay: 아니, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
2014-03-27 오전 3:50:00 정보 주인을 위한 노예 발견 중 192.168.1.155:3306
2014-03-27 오전 3:50:00 정보 192.168.1.150:3306에서 노예 발견
2014-03-27 오전 3:50:00 정보 마스터 정보
2014-03-27 오전 3:50:00 정보 바이너리 로그 파일: mysql-bin.000004, 위치: 547000, Binlog_Do_DB: 해당 없음, Binlog_Ignore_DB: mysql,information_schema,performance_schema
2014-03-27 오전 3:50:00 정보 GTID 실행 세트: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
2014-03-27 오전 3:50:00 정보 마스터 체력 획득: 192.168.1.155:3306.
2014-03-27 오전 3:50:00 정보 건강 상태:
2014-03-27 오전 3:50:00 정보 호스트: 192.168.1.155, 포트: 3306, 역할: 마스터, 상태: 위, gtid_mode: 켜, 건강: OK, 버전: 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 오전 3:50:00 정보 호스트: 192.168.1.150, 포트: 3306, 역할: 슬레이브, 상태: UP, gtid_mode: ON, 건강: OK, 버전: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: 예, SQL_Thread: Secs_Behind: 0, Remaining_Delay: 아니, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0
2014-03-27 오전 3:50:18 정보 주인을 위한 노예 발견 192.168.1.155:3306
2014-03-27 오전 3:50:18 정보 192.168.1.150:3306에서 노예 발견
2014-03-27 오전 3:50:18 정보 마스터 정보
2014-03-27 오전 3:50:18 정보 이진 로그 파일: mysql-bin.000004, 위치: 547000, Binlog_Do_DB: 해당 없음, Binlog_Ignore_DB: mysql,information_schema,performance_schema
2014-03-27 03:50:18 INFO GTID 실행 세트: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
2014-03-27 오전 3:50:18 정보 마스터 체력 획득: 192.168.1.155:3306.
2014-03-27 오전 3:50:18 정보 건강 상태:
2014-03-27 오전 3:50:18 정보 호스트: 192.168.1.155, 포트: 3306, 역할: 마스터, 상태: UP, gtid_mode: ON, 건강: OK, 버전: 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 오전 3:50:18 정보 호스트: 192.168.1.150, 포트: 3306, 역할: 슬레이브, 상태: 위, gtid_mode: 켜, 건강: OK, 버전: 5.6.15-log, master_log_file: mysql-bin.000004, master_log_pos: 547000, IO_Thread: 예, SQL_Thread: Secs_Behind: 0, Remaining_Delay: 아니, IO_Error_Num: 0, IO_Error: , SQL_Error_Num: 0, SQL_Error: , Trans_Behind: 0

# PS -EF |그렙 MySQL
루트 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> show slave status\G
*************************** 1. 줄 ***************************
Slave_IO_State: 주인님이 이벤트를 보내길 기다리고 있습니다
                  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: 네
            Slave_SQL_Running: 네
              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: 없습니다
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: 아니요
           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: 아니요
                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: 슬레이브가 모든 중계 로그를 읽었고; 슬레이브 I/O 스레드가 업데이트되기를 기다리고 있습니다
           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행 (0.00초)

마스터는 자동으로 전환됩니다.

DB2: 

mysql> show slave status\G
빈 집합 (0.00초)

mysql> show slave hosts;
+-----------+---------------+------+-----------+--------------------------------------+
| Server_id | 진행자 | 포트 | Master_id | Slave_UUID |
+-----------+---------------+------+-----------+--------------------------------------+
|       150 | 192.168.1.150 | 3306 |       155 | afee6FDE-978F-11E3-9F2A-02883E765295 |
+-----------+---------------+------+-----------+--------------------------------------+
집합 내 1행 (0.00초)

mysql> show master status\G
*************************** 1. 줄 ***************************
파일: mysql-bin.000004
         위치: 547000
     Binlog_Do_DB:
 Binlog_Ignore_DB: mysql,information_schema,performance_schema
Executed_Gtid_Set: e97b08ca-6798-11e3-a666-02c0661dc6e6:1-64
집합 내 1행 (0.00초)

mysql> 'read_only'와 같은 전역 변수를 표시하고;
+---------------+-------+
| Variable_name | 가치 |
+---------------+-------+
| read_only | 온(ON) |
+---------------+-------+
집합 내 1행 (0.00초)

마스터가 제대로 전환했다.
하지만 새 마스터의 읽기/_only 자동으로 꺼지는 것 같지는 않습니다.
제가 본 도움말에서는 그런 옵션이 없더라고요.
장애 전환 작업을 처리하려면 외부 스크립트를 사용해야 하는 것 같습니다.

·구조를 재구성해 보세요.

데이터가 전혀 업데이트되지 않았고 복제를 실행하는 호스트들이 정렬되어 있다고 가정할 때,
리셋 마스터; 그리고 모든 노예 재설정; 그래서 다시 답변해서 원래대로 돌릴게요.

지금은 전환할 필요가 없으니 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
장애 전환 데몬 중지...

어떻게든 전환 후 중단할 때 --master와 --candidate=failover 값을 조정해 충돌을 일으켜야 합니다.
그런데 --pidfile 옵션을 추가하면 --master를 추가하지 않아도 멈추는 것 같아요.

평판을 회복하겠습니다.
DB1: 

Netstat -tanp
Service MySQL Start
mysql -u root -p
마스터 지위 표시\G
노예 상태 표시\G
쇼 슬레이브 진행자들;
'read_only'와 같은 전역 변수를 표시하고;
mysql.failover_console에서 * 선택;
mysql.failover_console에서 삭제;
mysql.failover_console에서 * 선택;
리셋 마스터;

DB2: 

mysql -u root -p
마스터 지위 표시\G
노예 상태 표시\G
노예 멈추기;
노예 모두 초기화;
마스터를 변경하여 
MASTER_HOST='192.168.1.133',
MASTER_PORT=3306,
MASTER_USER='repl',
MASTER_PASSWORD='re*****',
MASTER_AUTO_POSITION = 1;
노예 시작;
노예 상태 표시\G
쇼 슬레이브 진행자들;
'read_only'와 같은 전역 변수를 표시하고;
전역 read_only=1을 설정;

DB3:``` mysql -u root -p 노예 상태 표시\G 노예 멈추기; 노예 모두 초기화; 노예 상태 표시\G 마스터를 변경하여 MASTER_HOST='192.168.1.133', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='re*****', MASTER_AUTO_POSITION = 1; 노예 시작; 노예 상태 표시\G 'read_only'와 같은 전역 변수를 표시하고; 전역 read_only=1을 설정; 'read_only'와 같은 전역 변수를 표시하고;


DB1:

쇼 슬레이브 진행자들; +-----------+---------------+------+-----------+--------------------------------------+ | Server_id | 진행자 | 포트 | 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 | +-----------+---------------+------+-----------+--------------------------------------+


이로써 복제 구성이 복원되었습니다.  
마스터\_AUTO\_POSITION = 1; 정말 편리하죠.  
mysql.failover\_console 삭제하면 건너뛴 수 있습니다.  
MASTER 를 db1로 재설정; 그래서 그렇게 하기로 결심했습니다.  
  
・VIP 대신 외부 스크립트를 사용하는 것을 고려해  

먼저, 스크립트 인식 옵션에 대해 말씀드리겠습니다.

--exec-fail-check 각 기본 체크마다 미리 정해진 간격으로 정기적으로 실행되도록 스크립트를 지정하세요. --exec-before 페일오버 시작 전에 실행할 스크립트를 지정하세요 --exec-after는 페일오버 프로세스가 종료될 때 실행할 스크립트를 지정합니다 --exec-post-failover: 장애 조치 후 실행할 스크립트(예: 건강 보고서)


아마 다음 중 네 개 정도를 만들어야 할 것 같아요  

1. F/O 체크를 하고 마스터 MySQL을 다운로드하러 갑니다(아마도 몬과 비슷한 역할). 아마 필요 없는 걸 수도 있겠네요? ）  
　　그렇게 하면 메인 시스템이 MySQL 연결을 확인하니, VIP 핑이 통과하지 않을 때는 차단하는 게 더 나을 것 같습니다.  
2. F/O 시작 전에 VIP를 늙은 주인에게서 제거해,  
3. F/O 과정이 끝나면 VIP를 새 마스터에 추가하고 읽음을 끄세요_only  
4. F/O가 완료되고 상태가 확인되면 보고하세요(Zabbix로 상황을 모니터링할 수 있다면 꼭 필요 없을 수도 있습니다).  
  
최소 두세 개는 필요합니다.  
또한, 환경에 따라 슬레이브가 부하 분산될 때 부하를 변경하는 스크립트가 필요할 수도 있습니다.  
감지 후 수작업 때문에 새로운 마스터 부하가 강하게 발생하고 2차 고장이 발생할 가능성이 높다면, 이는 필수적입니다.  
  
・시작 스크립트를 만들어 보세요  
  
여러 가지를 명시하는 게 번거로워서 하나 갖는 게 더 낫다고 생각해서 하나 만들기로 했어요  
며칠 전에 만든 Redis 사진을 재사용할 수 있을 것 같아요.

cat /etc/init.d/mysqlfailover

#!/빈/쉬

Linux 시스템에서 작동하도록 고안된 간단한 mysqlfailover init.d 스크립트

#는 /proc 파일 시스템을 사용합니다.

chkconfig: - 85 15

설명: mysql 필러 오버

프로세스명: mysqlfailover

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

EXEC=/usr/bin/mysqlfailover prog=$(베이스명 $EXEC)

PIDFILE=/var/run/mysqld/failover.pid LOGFILE=/tmp/failover.log PORT=3306 fouser=failover fopass=xxxxxxxx rpluser=repl rplpass=re***** old_master=192.168.1.133 new_master=192.168.1.155 인터벌섹스=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() { 만약 [ -f $PIDFILE ] 그럼 에코 "$PIDFILE 존재합니다, 프로세스가 이미 실행 중이거나 크래시가 났습니다" 그렇지 않으면 $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() { 만약 [ ! -$PIDFILE ] 그럼 에코 "$PIDFILE 존재하지 않습니다, 프로세스가 실행되지 않습니다" 그렇지 않으면 PID=$(cat $PIDFILE) $EXEC --log=${LOGFILE} --pidfile=${PIDFILE}
--데몬=멈춰 -vv [ -x /proc/${PID} ] 해야 할 에코 "mysql 장애 조치가 종료되기를 기다리고 있습니다... " 수면 1 끝났어 에코 "MySQLFailover가 중단됨" Fi }

rh_status() { 현황 $prog }

케이스 "$1" 시작) 시작 ;; 멈춤) 멈춰 ;; 재시작) 멈춰 시작 ;; 현황) rh_status ;; *) 에코 "첫 번째 논거로 시작 또는 정지를 사용하세요" ;;

ESAC

chmod +x mysqlfailover

chkconfig --MySQL failover 추가하세요


혹시 몰라서 추가해봤는데, 복제 설정이 제대로 설정되지 않으면 시작이 안 되는 것 같아요.  
어차피 수동으로 작동할 것 같아서 자동 시작 기능을 꺼보기로 했습니다.

/etc/init.d/mysqlfailover start

페일오버 데몬 시작...

추신 -에브렉 실패

루트 1095 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***** --재발견 --failover-mode=auto --daemon=start -vv

/etc/init.d/mysqlfailover status

MySQLfailover(PID 1095)가 실행 중입니다...

/etc/init.d/mysqlfailover stop

장애 전환 데몬 중지... MySQL필러오버가 중단되었습니다

추신 -에브렉 실패


정상적으로 시동, 정지, 상태 확인 완료.  

mysql.failover\_console 제거하고 복제를 재구성하는 것은 약간 번거롭습니다.  
시작을 반복할 때는 --force를 추가하는 게 더 나을 수도 있습니다.  
삭제하지 않으면 장애 전환 모드가 실패합니다.

/etc/init.d/mysqlfailover start

페일오버 데몬 시작... 마스터 192.168.1.133:3306에 대해 여러 번의 장애 전환 데몬 인스턴스가 발견됨. 만약 오류가 있다면, --force로 데몬을 재시작하세요. 이 경우 페일오버 모드가 'FAIL'으로 변경되었습니다. 데몬이 10초 후에 시작한다. ......... 데몬을 시작했다.


\--force를 설치했을 때, 페일오버 모드가 자동 모드로 잘 작동했습니다.  
  
각 복제 구성마다 여러 프로세스가 시작할 수 있는지 확인해야 할 수도 있습니다.  
이번에는 시간이 많지 않아서 다음에 시도해볼게요.  
  
・VIP 관리와 독서 스크립트 만들기_only  
  
저는 시작 스크립트에서 다음과 같이 정의했습니다.

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


최소한의 조건은 다음과 같습니다.  
2. F/O를 시작하기 전에 이전 마스터에서 VIP를 제거하고 이전 마스터에서 MySQL을 다운로드하세요  
3. F/O 과정이 끝나면 VIP를 새 마스터에 추가하고 읽음을 끄세요_only  
꼭 셸 스크립트일 필요는 없는 것 같아요.  
  
AWS에서 테스트하다 보니 가끔 API와 통신해서 VIP를 재설치해야 할 때가 있습니다.  
  
VIP를 수동으로 재부착하는 명령:

IP addr del 10.35.31.202/23 brd 10.35.31.255 dev eth0 IP addr add 10.35.31.202/23 brd 10.35.31.255 dev eth0


MHA에서 VIP 전환을 하는 외부 스크립트가 호출하는 시스템 명령의 참조 부분:

서브 start_vip() { 'ssh $ssh_user@$new_master_host " $ssh_start_VIP "''; }

old_master 위의 VIP를 무력화하는 간단한 시스템 호출

서브 stop_vip() { 'ssh $ssh_user@$orig_master_host " $ssh_stop_VIP "''; System("ssh $ssh_user@@$orig_master_host " $ssh_stop_mysqld ""); } 내 $ssh_start_VIP = "sudo /sbin/ip addr add $vip brd $brd 개발 $nic"; 내 $ssh_Stop_VIP = "sudo /sbin/ip addr del $vip brd $brd 개발 $nic"; my $ssh_stop_mysqld = "sudo /sbin/service mysql stop";


VIP 교체를 위해 SSH 키 인증을 가능하게 만들어야 할 것 같아요.  
Sudo 권한이 필요한지 궁금하네요.  
  
현재는 관리 서버 04에서 각 DB로 SSH 키 인증(여기서는 루팅)을 사용합니다  
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

비수도

#Defaults 요구사항


AWS에서 사설 IP를 전환하는 HA를 기반으로 스크립트를 만들어 보겠습니다.  
진행자가 매니저가 아니기 때문에 그 부분에 대한 조정이 필요할 가능성이 큽니다.  
구(舊)와 신(新) 마스터 모두의 ENI를 미리 정의해야 할 수도 있습니다.  
  
일단 VIP를 명령어로 구마스터에 추가하고 확인했습니다.  

AWS EC2 assign-private-ip-addresses \
--네트워크-인터페이스-ID ENI-27A2A945 \
--private-ip-주소 192.168.1.222 --재할당 허용

IP addr add 192.168.1.222/24 brd 192.168.1.255 dev eth0


다른 서버에서 핑을 통한 확인 (AWS 경영진도 VIP 핑 접근 권한이 필요합니다)

핑 192.168.1.222

vi /USR/local/bin/before_failover.sh

#!/빈/쾅

before_failover.sh: F/O를 시작하기 전에 구마스터에서 VIP를 제거하고 MySQL을 설치하세요

의존성: mysql failover,after_failover.sh

업데이트 기록: 20140331 - 코미야이 만들기

export PATH=$PATH:/usr/local/bin export AWS_CONFIG_FILE=/root/.ec2/aws.config datetime='date +%Y%m%d_%H%M%S' mailto=< 수신자 이메일 주소> 올드마스터=192.168.1.133 newmaster=192.168.1.155 VIP=192.168.1.222 서브넷마스크=24 brd=192.168.1.255 nic=eth0 ssh_user=근 oldmaster_eni='aws ec2 describe-network-interfaces --filters Name=addresses.private-ip-address,Values=${oldmaster} --query 'NetworkInterfaces[]. [NetworkInterfaceId]' --출력 텍스트'

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

stop_vip() { 메아리 "올드 마스터의 VIP 비활성화 중" ssh ${ssh_user}@${oldmaster} "${ssh_stop_vip}" }

stop_mysql() { 에코 "올드 마스터에서 MySQL 중지" ssh ${ssh_user}@${oldmaster} "${ssh_stop_mysqld}" }

aws_pip_unassign() { 에코 "AWS의 가상 개인 IP 차단 해제" AWS EC2 unassign-private-ip-addresses
--네트워크-인터페이스-ID ${oldmaster_eni}
--private-ip-addresses ${vip}|tee /tmp/res.txt }

메인

#さきにsshの接続性を確認してダメならawsの処理だけする ssh ${ssh_user}@${oldmaster} ls /etc/hosts result_ssh='에코 $?' 만약 [ $result_ssh -eq 0 ]; 그럼 aws_pip_unassign 그렙 트루 /TMP/res.txt res_unassign='에코 $?' 만약 [ ${res_unassign} -ne 0 ]; 그럼 printf "오류: aws privateip unassign fail.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} 출구 1 Fi stop_vip result_vip='에코 $?' 만약 [ ${result_vip} -ne 0 ]; 그럼 printf "오류: stop vip는 fail.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} 출구 1 Fi stop_mysql result_mysql='에코 $?' 만약 [ ${result_mysql} -ne 0 ]; 그럼 printf "오류: stop mysql is fail.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} 출구 1 Fi 그렇지 않으면 aws_pip_unassign 그렙 트루 /TMP/res.txt res_unassign='에코 $?' 만약 [ ${res_unassign} -ne 0 ]; 그럼 printf "오류: aws privateip unassign fail.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} 출구 1 Fi 인쇄 "경고: 노인 주인이 쓰러졌어.\nssh NG."
|mail -s "mysqlfailover-info_${datetime}" ${mailto} Fi

출구 0

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

vi /usr/local/bin/after_failover.sh

#!/빈/쾅

after_failover.sh: F/O 프로세스 종료 시 VIP를 새 마스터에 부착하고 read_only

의존성: mysql failover,before_failover.sh

업데이트 기록: 20140331 - 코미야이 만들기

export PATH=$PATH:/usr/local/bin export AWS_CONFIG_FILE=/root/.ec2/aws.config datetime='date +%Y%m%d_%H%M%S' mailto=< 수신자 이메일 주소> 올드마스터=192.168.1.133 newmaster=192.168.1.155 VIP=192.168.1.222 서브넷마스크=24 brd=192.168.1.255 nic=eth0 ssh_user=근 mysql_user=근원 mysql_pass='/path_to_file' newmaster_eni='aws ec2 describe-network-interfaces --filters Name=addresses.private-ip-address,Values=${newmaster} --query 'NetworkInterfaces[]. [NetworkInterfaceId]' --출력 텍스트'

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() { 에코 "AWS의 가상 사설 IP ADDRES 활성화" AWS EC2 assign-private-ip-addresses
--네트워크-인터페이스-ID ${newmaster_eni}
--private-ip-addresses ${vip} --allow-reassignment|tee /tmp/res.txt }

메인

set_readonly result_ro='메아리 $?' 만약 [ ${result_ro} -ne 0 ]; 그럼 printf "오류: 읽기 전용으로 설정하면 실패한다.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} 출구 1 Fi

aws_pip_assign 그렙 트루 /TMP/res.txt result_pip='에코 $?' 만약 [ ${result_pip} -ne 0 ]; 그럼 printf "오류: aws privateip assign fail.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} 출구 1 Fi

start_vip result_vip='에코 $?' 만약 [ ${result_vip} -ne 0 ]; 그럼 printf "오류: VIP 시작 is fail.\nfailover NG."
|mail -s "mysqlfailover-err_${datetime}" ${mailto} 출구 1 Fi

출구 0

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


여기서 유닛 테스트

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


주로 이전 마스터를 확인하려고 합니다(IP가 제거되었는지, MySQL이 다운됐는지 여부)

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


주로 새 마스터를 확인했습니다(IP가 켜져 있는지 읽기 _only 꺼져 있는지).  
  
시작 스크립트를 수정하세요

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

vi /etc/init.d/mysqlfailover

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

날짜: 유효하지 않은 날짜 '%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} \

서비스 MySQL 장애 전환 시작

페일오버 데몬 시작...

추신 -에브렉 실패

근 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***** --재발견 --failover-mode=auto --daemon=start -vv --force --exec-before=/usr/local/bin/before_failover.sh --exec-after=/usr/local/bin/after_failover.sh

보기/TMP/failover.log


여기, DB1에서 MySQL을 다운로드해 봅시다.  
  
미리 확인해 주세요  

DB1,2:

IP ADDR 쇼 mysql> show slave hosts;


DB2,3:

노예 상태 표시\G 'read_only' 같은 글로벌 vairables를 보여주고;


DB3:

핑 192.168.1.222


DB4:

AWS EC2 describe-network-interfaces
--filters Name=addresses.private-ip-address,Values=192.168.1.222
--쿼리 'NetworkInterfaces[]. [NetworkInterfaceId]'' -출력 텍스트

AWS EC2 네트워크 인터페이스 설명 \

--filters Name=addresses.private-ip-address,값=192.168.1.133
--쿼리 'NetworkInterfaces[]. [NetworkInterfaceId]'' -출력 텍스트 ENI-27A2A945

AWS EC2 네트워크 인터페이스 설명 \

--filters Name=addresses.private-ip-address,values=192.168.1.155
--쿼리 'NetworkInterfaces[]. [NetworkInterfaceId]'' -출력 텍스트 ENI-6CB3B90E

꼬리 -f /TMP/failover.log


마스터를 내려보세요  
DB1:

서비스 MySQL 정지


이전에 확인된 IP 주소와 기타 주소들을 다시 한 번 확인하세요  
  
DB2:  
DB2는 VIP가 포함되어 있습니다

IP addr show eth0|grep sec

inet 192.168.1.222/24 BRD 192.168.1.255 범위 글로벌 세컨더리 ETH0


AWS 스타일의 사설 IP도 DB2의 NIC로 옮겨졌습니다.

AWS EC2 네트워크 인터페이스 설명 \

--filters Name=addresses.private-ip-address,값=192.168.1.222
--쿼리 'NetworkInterfaces[]. [NetworkInterfaceId]'' -출력 텍스트 ENI-6CB3B90E


db2의 읽기\_only 기능은 꺼져 있습니다.

mysql> 'read_only'와 같은 전역 변수를 표시하고; +---------------+-------+ | Variable_name | 가치 | +---------------+-------+ | read_only | 꺼 | +---------------+-------+


db2의 달인으로서 db3를 시청하다

mysql> show slave hosts; +-----------+---------------+------+-----------+--------------------------------------+ | Server_id | 진행자 | 포트 | Master_id | Slave_UUID | +-----------+---------------+------+-----------+--------------------------------------+ | 150 | 192.168.1.150 | 3306 | 155 | afee6FDE-978F-11E3-9F2A-02883E765295 | +-----------+---------------+------+-----------+--------------------------------------+


DB2 슬레이브 정보가 초기화되었습니다

mysql> show slave status\G 빈 집합 (0.00초)


확실히 하기 위해 db1에서 같은 명령어에 VIP가 추가되지 않았는지 확인해봤습니다.

IP addr show eth0|grep sec


따라서 예상 작업이 완료되었으므로 검증이 완료된 것입니다.  
운영체제를 다운로드하고 상황에 따라 보고 스크립트를 건너뛰는 것도 시도해보겠습니다.  

・재구성  

DB4:

AWS EC2 unassign-private-ip-addresses
--네트워크-인터페이스-ID ENI-6CB3B90E
--private-ip-addresses 192.168.1.222|tee /tmp/res.txt

AWS EC2 assign-private-ip-addresses
--네트워크-인터페이스-ID ENI-27A2A945
--private-ip-주소 192.168.1.222 --재할당 허용

AWS EC2 describe-network-interfaces
--filters Name=addresses.private-ip-address,Values=192.168.1.222
--쿼리 'NetworkInterfaces[]. [NetworkInterfaceId]'' -출력 텍스트


DB2:

IP addr del 192.168.1.222/24 brd 192.168.1.255 dev eth0 IP ADDR 쇼 DB1: IP addr add 192.168.1.222/24 brd 192.168.1.255 dev eth0 IP ADDR 쇼


*해당 대표는 앞서 언급되었으나 다시 게시되고 있습니다  
DB1:

Netstat -tanp Service MySQL Start mysql -u root -p 쇼 슬레이브 진행자들; 'read_only'와 같은 전역 변수를 표시하고; mysql.failover_console에서 * 선택; mysql.failover_console에서 삭제; mysql.failover_console에서 * 선택; 리셋 마스터;


DB2:

mysql -u root -p 마스터 지위 표시\G 노예 상태 표시\G 노예 멈추기; 노예 모두 초기화; 마스터를 변경하여 MASTER_HOST='192.168.1.133', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='re*****', MASTER_AUTO_POSITION = 1; 노예 시작; 노예 상태 표시\G 쇼 슬레이브 진행자들; 'read_only'와 같은 전역 변수를 표시하고; 전역 read_only=1을 설정;


DB3:

mysql -u root -p 노예 상태 표시\G 노예 멈추기; 노예 모두 초기화; 노예 상태 표시\G 마스터를 변경하여 MASTER_HOST='192.168.1.133', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='re*****', MASTER_AUTO_POSITION = 1; 노예 시작; 노예 상태 표시\G 'read_only'와 같은 전역 변수를 표시하고; 전역 read_only=1을 설정; 'read_only'와 같은 전역 변수를 표시하고;

서비스 MySQLfailover 시작 PS -ef|grep fail


참고로, 전환 속도는 MHA와 거의 같았고, 부드럽고 빠르게 전환되었습니다.  
하지만 마스터가 크래시가 났을 가능성을 감지한 후 인터발을 기다린 로그가 세 번 있었기 때문에, 기본적으로 대기 시간은 약 45초 정도일 것입니다.  
MHA와 비교하면, 특정 기간 동안 노예의 릴레이 로그를 유지할 필요가 없고, 악마 모드로 돌릴 수 있다는 점인 것 같아요.  
5.6은 GTID가 켜져 있어야 한다는 제한이 있지만, 5.6에서 GTID가 켜져 있다면 현재로서는 HA의 유일한 선택지는 mysql failover일 수 있습니다.  
그런데 알고 보니 [MHA 0.56(GTID 호환 0.56](https://code.google.com/p/mysql-master-ha/wiki/ReleaseNotes#Changes_in_Manager_0.56_\(Apr_1_2014\))이 등장했습니다(2014/4년)!  
정말 놀라운 타이밍이네요.  
  
로그가 자정에 있는 이유는 고정되지 않았고, EDT입니다.  
길게 읽어주셔서 정말 감사합니다.

더 보기

Related Articles