마스터1대, 슬레이브 3대로 구성된 디비 서버들인데     

 

          Slave_IO_State: Waiting for master to send event
                   Master_Host: 192.168.0.212
                   Master_User: slave1
                   Master_Port: 3813
                 Connect_Retry: 60
               Master_Log_File: mariadb-bin.602137
           Read_Master_Log_Pos: 163251227
                Relay_Log_File: localhost-relay-bin.013096
                 Relay_Log_Pos: 100492948
         Relay_Master_Log_File: mariadb-bin.602137
              Slave_IO_Running: Yes
             Slave_SQL_Running: No
               Replicate_Do_DB: 
           Replicate_Ignore_DB: 
            Replicate_Do_Table: 
        Replicate_Ignore_Table: 
       Replicate_Wild_Do_Table: 
   Replicate_Wild_Ignore_Table: 
                    Last_Errno: 1032
                    Last_Error: Could not execute Delete_rows_v1 event on table gameworkr.offer_account; Can't find record in 'offer_account', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mariadb-bin.602137, end_log_pos 101337573
                  Skip_Counter: 0
           Exec_Master_Log_Pos: 100492647
               Relay_Log_Space: 700123700
               Until_Condition: None
                Until_Log_File: 
                 Until_Log_Pos: 0
            Master_SSL_Allowed: No
            Master_SSL_CA_File: 
            Master_SSL_CA_Path: 
               Master_SSL_Cert: 
             Master_SSL_Cipher: 
                Master_SSL_Key: 
         Seconds_Behind_Master: NULL
 Master_SSL_Verify_Server_Cert: No
                 Last_IO_Errno: 0
                 Last_IO_Error: 
                Last_SQL_Errno: 1032
                Last_SQL_Error: Could not execute Delete_rows_v1 event on table gameworkr.offer_account; Can't find record in 'offer_account', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mariadb-bin.602137, end_log_pos 101337573
   Replicate_Ignore_Server_Ids: 
              Master_Server_Id: 1
                Master_SSL_Crl: 
            Master_SSL_Crlpath: 
                    Using_Gtid: No
                   Gtid_IO_Pos: 
       Replicate_Do_Domain_Ids: 
   Replicate_Ignore_Domain_Ids: 
                 Parallel_Mode: conservative
                     SQL_Delay: 0
           SQL_Remaining_Delay: NULL
       Slave_SQL_Running_State: 
              Slave_DDL_Groups: 552
Slave_Non_Transactional_Groups: 0
    Slave_Transactional_Groups: 2545153712

 

위와같이 1032 에러 발생, 리플리케이션 장애발생

 

 

먼저
STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;START SLAVE;
슬레이브 1번서버 에러 스킵후 데이터를 확인해보니 에러 난 슬레이브1번 서버의 데이터가 정상이고 나머지가 비정상임을 확인

 


마스터, 슬레이브2,3 의 데이터는 비정상이고 슬레이브1의 데이터가 정상이기에 슬레이브 1의 데이터를 마스터, 슬레이브2,3에 옮겨야 한다.

 

아래와 같이 작업 진행

1.모든 디비서버들 외부에서의 접속 차단(iptables로 디비 서버끼리는 통신되도록 하고 나머지 외부에서 들어오는건 차단) 그리고 한 1~2분정도 기다려서 리플리케이션 확인

2.슬레이브1 서버에서 정상 테이블 덤프 - drop table이나 no create 옵션 사용하여 insert 구문만 들어가도록 덤프

3.마스터 서버에서 문제있는 테이블 트렁케이트 후 기달려서 동기화 까지 확인
4.마스터 서버에 덤프받은 디비 복원 후 동기화 확인

 

 

ps.

디비 차단 안한상태에서, 즉 서비스에 최대한 문제 없이 진행하고자 한다면 아래와 같이 했으면 됐을듯싶다.

1.문제있는 테이블 수정권한이 있는 계정의 수정권한을 빼서 해당 테이블 변경되지 않도록 설정
2.나머지는 기존처럼 정상 테이블 백업 후 마스터에서 truncate 한 뒤 복원하기

 

물리적인 박스형 스위치 2대 또는 그 이상을 하나의 논리적인 스위치로 구성하는것, 명칭은 벤더마다 다르다.

제조사명칭

화웨이 istack
주니퍼 VC(버츄얼샤시)
익스트림 stack
시스코 stack



 

stack 구성도
2대로 스택 구성
두대의 장비가 stack 구성, prio 숫자 높을수록 우선순위 높음(prio 를 1,2 등으로 설정하면 1이 더 우선순위 높다고 헷갈릴 수 있음)

 

 

stack과 별개로 cascade 라는게 있는데 이건 |스위치1 <-> 스위치2 <-> 스위치 3| 이런식으로 연결된다.

차이점은
1.루프가 날 수 있다.
2.스택은 대역폭이 증가, cascade 는 대역폭 증가 없음
3.스택은 마스터 하나에서만 설정 변경, cascade 은 각각 관리
4.스택은 대부분 동일 제조사,모델로만 가능(스택 전용 케이블)


http://www.fiber-optic-equipment.com/differentiate-3-technologies-switch-stacking-vs-cascading-vs-clustering.html

'job > etc' 카테고리의 다른 글

k8s  (0) 2023.01.10
소프트웨어 공부  (0) 2021.01.30
L4 알테온 설정중 metric rmetric  (0) 2019.02.13
그누보드 디렉토리 설명  (0) 2018.09.03
서버 이전시 mysql 4 to 5 password 함수 안맞아서 php 에러 날때  (0) 2018.09.03

[root@localhost ~]# /opt/mysql/bin/mysql -uroot -p'123123' -e 'SHOW SLAVE STATUS \G' | egrep "Master_Log_Pos"
           Read_Master_Log_Pos: 478353559
           Exec_Master_Log_Pos: 452076624

 

         Seconds_Behind_Master: 3971

 

위와같이 싱크가 잘 안맞는다.

 

bin 로그 확인시 지연될만한 쿼리가 아니고 개발자에게 문의해봐도 따로 쿼리 업데이트가 된건 없다고 한다.

 

iostat 
Linux 2.6.32-754.17.1.el6.x86_64 ()       08/05/2019      _x86_64_        (24 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.77    0.00    0.55    3.28    0.00   89.40

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               1.04         7.48        24.84    3539870   11757640
sdb               2.26         0.15      2158.02      70244 1021591088
sdc               0.00         0.01         0.00       6378          8
sdd             694.72      2571.53     18588.32 1217341239 8799565808

(sdd 디스크가 mysql data 디렉토리)

 

디스크 i/o가 높긴한데... 예전부터 높았다. 디스크 문제도 아닌것으로 보이고..

 

커널업데이트 한 이후부터 싱크가 안맞고 있음

 

i/o 스케쥴링이 cfg 로 설정돼있는 상태여서 noop(ssd 디스크임)으로 변경해봤으나 큰 차이가 없음

 

commitinnodb_flush_log_at_trx_commit = 2 으로 설정(기본 1)
https://santander.co.kr/151 참고

 

         Seconds_Behind_Master: 0

 

우선 조치완료.. 했으나 개운치않다. 추가 점검할 예정

 

+ Recent posts