mysql 리플리케이션 운영중 슬레이브 서버에 문제가 발생

 

mysql 리플리케이션 구동방식이

 

데이터 업데이트 > master에서 업데이트된 쿼리를 bin로그에 기록 > slave의 io쓰레드에서 bin log를 토대로 relay  로그를 작성 > sql쓰레드에서 relay 로그를 토대로 slave의 DB 업데이트 > relay 로그 쓸모가 없어지면(master의 bin log가 삭제되면) relay 퍼지 옵션 디폴트가 on이기 때문에 자동으로 삭제됨

 

근데... slave서버에서 상태를 보면 

                Relay_Log_File: localhost-relay-bin.999999

위와같이 릴레이 로그-999999 를 보고 있따. 

[root@localhost data]# ls -lat localhost-relay-bin.11* | more
-rw-rw---- 1 mysql mysql  2891938 May  3 09:35 localhost-relay-bin.1157093

실제로는 위 파일을 바라봐야 한다.

 

order by limit 1 주고 계속 확인해보면 다행히도 실시간으로 동기화는 잘 되고 있다..
select count(*) from table 같은걸로 레코드 수 새보면 좋겠찌만... 실서비스중인데 부하 생길포인트 만드는건 쫌 아닌것같다.

 

여튼 상황 정리하면 아래와 같다.
1.디비 동기화는 잘 되고 있음
2.마스터 서버의 bin 로그는 잘 삭제되고 있음
3.슬레이브 서버의 relay bin 로그를 999999를 바라보고 있음
ㄴ실제로는 1157093 을 봐야함

4.relay 로그 삭제가 안되고 있음
5.error log는 없음

 

inc_group_relay_log_pos() 이 함수에 문제가 있다고 한다.
strcmp() 라는 함수를 통해 전/후 두개의 relay log를 비교하는데 이때 둘다 6자리까지는 정상적으로 비교가 되는데 6자리에서 7자리로 바뀔 때 즉, 999999 => 1000000 이때 문제가 있다고 한다.

추가로 handle_queued_pos_update() 라는 함수에서도 7자리로 변경될 때 parallel replication 이슈가 발생할 수 있다고 한다.

https://jira.mariadb.org/browse/MDEV-8134

 

패치는 뭐... 재컴파일하기엔 좀 무리가 있으니... 일단 relaylog 전부 reset으로 날리고 다시 맞춰준다음 relay log 용량을 10M(디폴트)에서 512M로 바꿔야겠다. 그럼 그렇게 많이 차진 않겠찌...
그래도 많이 차면 패치하고 재컴파일 해야할듯

 

----조치 한 사항---

1.우선 데이터 백업 한번 해주고

2.새벽에(접속자 최대한 없을 때)웹페이지 공지 띄우고 디비서버로의 접근 차단(마스터 서버 업데이트 없도록)
ㄴiptables 에서 마스터-슬레이브만 3306 포트 통신하도록 변경하고 나머지는 전체 차단, 웹에서도 차단
ㄴ마스터서버 binlog 파일 넘버랑 로그 포지션 안바뀌는거 확인

3.stop slave

4.reset slave
ㄴreset slave 하니까 삭제되지 않던 relay log 파일도 전부 삭제됨

5.start slave

6.CHANGE MASTER TO MASTER_LOG_FILE='<master-bin.number>', MASTER_LOG_POS=;

7.위와같이 작업하고 bin 로그파일 넘버랑 로그 포지션 넘버 동일한지 확인

 

위와같이 슬레이브 서버들 전부 진행하니까 잘 해결됐다.

추가로 10MB씩 쌓이던 relay 로그 파일 512MB로 변경함

gather_facts // 우선 엔서블에서의 facts 란 클라이언트 서버 정보(OS버전같은거)다.  gather는 모으다. 즉 클라이언트 서버의 정보들(os 버전이나 이런것들)을 가져올꺼냐 안가져올꺼냐.. 정보가 필요하면 당연히 가져와야하고 필요없는 작업이면 안가져와도 된다. 속도차이가 있음


delegate_to // 인벤토리에 없는 호스트를 작업할 때 사용, 127.0.0.1(로컬)이 들어가있음 로컬 서버에 있는 쉘을 실행한다거나 그럴때 쓰임
run_once  // 위에 delegate_to 와 같이 자주 사용된다. delegate_to와 자주 사용되는이유는 실제 실행되는 서버에서 변수 한번 뽑으면 되는거니까
- name: test_delegate
  delegate_to: 127.0.0.1
  run_once: true
  command: /root/bin/tast_string
  register: test_exe


when   // if문같은거 옵션이 여러가지 많음
shell  // 쉘 실행
ignore_errors  // 에러나도 다음작업을 진행(ex. 백업해야할 때 mv로 파일을 옮겨야하는데 서버에 파일이 없으면 에러남, 이경우 백업할께 없으면 에러나도 상관없는거니까 mv로 진행)
  - name: centos 5 version mv test1sh cmd_test1.sh_date
    shell: mv /root/test1.sh /root/test1.sh_{{ansible_date_time.date}}
    when: ansible_distribution == "CentOS" and ansible_distribution_major_version == '5'
    ignore_errors: True

set_fact  // 변수 설정하는거임
- name: cur_time_var
  delegate_to: 127.0.0.1
  run_once: true
  set_fact: date_time="{{lookup('pipe','date \"+%Y%m%d\"')}}"


local_action // 로컬 서버에서 작업을 실행하겠다. delegate_to=127.0.0.1 이랑 같은건데 딜리게이트를 더 권장한다. 왜냐하면 로컬액션으로 처리가 안되는 것들이 많음
- name: cat ip
  local_action: shell cat /root/ip
  register: sip

register // task 실행 결과를 저장하고자 할 때에는 register 지시어를 사용하면 됨.
- name: IP check.
  shell: ip addr show eth0 | grep inet | grep -v inet6 | awk '{print $2}' | cut -d/ -f1
  register: real_ip

copy  //  말그대로 복사

lineinfile  // 이 모듈은 echo "문구" >> 파일.txt 와 같이 파일에 내용을 추가하는 모듈인데...ansible -m lineinfile "path=test.txt line=test11" 이런식으로 애드혹를 입력할경우 test.txt 하단에 test11이라는 구문이 추가된다.  근데 사람이 실수로 ansible -m lineinfile "path=test.txt line=test11" 이런 명령어를 두번 넣었을경우 lineinfile은 멱등성을 지원하기 때문에 해당 파일에 test11 이 두줄 추가 되지 않고 한줄만 추가된다. 
- name: password to /root/test
  lineinfile: dest=/root/test mode=0600 create=yes line="{{test.stdout}}"

with_items  // 반복처리할때 사용함, slave_ip.stdout_lines 리스트들

replace // 말그대로 단어교체 파일안의 내용들만 되는듯(mv 이름 이름.old 처럼 파일도 가능하진 않음)



debug // 말그대로 디버그, 이거는 status를 보기위한 용도로 한듯



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

ansible - windows Win32ErrorCode 1058  (0) 2019.05.23
windows host에서 ansible 실행하는법  (0) 2019.05.23
ansible - 디렉토리 구조  (0) 2019.05.02
ansible- error  (0) 2019.04.26
ansible-3 playbook  (0) 2019.04.25

데몬의 실행여부를 체크하는 플레이북 짤건데 디렉토리 구조는 아래와 같다

데몬실행여부 체크 플레이북이니까 디렉토리명은 daemon_check로 주고
[root@localhost daemon_check]# pwd
/root/ansible/test/daemon_check

구조,간략설명

ll[root@q352-3552 daemon_check]# ll
total 4
drwxr-xr-x. 2 root root 66 May  2 13:38 group_vars   ##hosts에 지정되는 그룹들의 변수를 지정하는 디렉토리

-rw-r--r--. 1 root root  0 May  2 10:37 hosts    ###/etc/ansible/hosts와 동일한 기능이다.
drwxr-xr-x. 6 root root 82 May  2 13:32 roles   ### site.yml 에 들어가는 roles 
-rw-r--r--. 1 root root 90 May  2 10:48 site.yml

 

먼저 group_vars는 를들어 엔서블을 사용하려면 클라이언트에 파이썬 2.6버전이상이 설치 돼 있어야 하는데 클라이언트 centos5버전이라면 기본적으로 파이썬 2.4가 설치돼있다. 따라서 파이썬 2.6을 따로 설치해주고 인터럽트를 직접 지정해줘야 하는데 

이런식으로 centos5 서버들154,155,156,157,158에 하나하나 인터럽터를 지정해줘야 한다. 근데 group_vars에 centos5 라는 파일 만들고 그 안에 ansible_python_interpreter=/usr/bin/python2.6 를 적어주거나 하면 된다.

hosts 파일에

[centos5:vars]

ansible_python_interpreter=/usr/bin/python2.6

이런식으로 직접 지정해줘도 된다.

 

그다음 hosts는 클라이언트 서버 리스트고... 그룹으로 지정할 수 있고 위에 사진처럼

roles랑 site.yml 이 중요하다.

먼저 site.yml 의 내용을 보면

site.yml

crond_check 는 모든 서버가 다 실행돼야하니까 hosts 대상은 all , roles는 crond_check
마찬가지로 httpd는 방화벽도 체크해야하니까 iptables_open롤도 추가, mysql 은 mysql_check 롤만 들어간다.

우리가 실행하는건 site.yml 이다. ansible-playbook site.yml 명령어로 실행해주면 
  roles:
    - crond_check
여기에 적어준 roles들이 차례대로 실행되는데 적어준 roles 이름과 디렉토리 이름은 꼭 같아야 한다. 

[root@q352-3552 roles]# ll
total 0
drwxr-xr-x. 5 root root 52 May  2 12:57 crond_check
drwxr-xr-x. 5 root root 52 May  2 12:57 httpd_check
drwxr-xr-x. 5 root root 52 May  2 12:57 iptables_open
drwxr-xr-x. 5 root root 52 May  2 12:57 mysql_check
drwxr-xr-x. 5 root root 52 May  2 12:57 nginx_check

 

roles 디렉토리 안에 crond_check 들어가보면
[root@q352-3552 crond_check]# ll
total 0
drwxr-xr-x. 2 root root  6 May  2 15:37 defaults
drwxr-xr-x. 2 root root  6 May  2 15:37 files
drwxr-xr-x. 2 root root 22 May  2 13:01 handlers
drwxr-xr-x. 2 root root 22 May  2 13:12 tasks
drwxr-xr-x. 2 root root 21 May  2 13:23 templates
내용은 위와같은데 tasks안에 있는 main.yml(실행되는 roles들의 야믈 파일은 무조건 파일명이 main.yml 이어야 함) 파일이 가장 먼저 실행하는데 main.yml 이 실행시 templates 모듈을 사용할 때 필요한 파일은 templates 안에 있어야 하고 마찬가지로 files 모듈을 사용할 때의 파일은 files 안에 있어야 한다. defaults는 변수설정(vars보다 순쉬 높음) meta같은것도 있다는데 잘 모르겠음.. 하여튼 모든 작업이 완료되면 마지막으로 handlers가 진행된다.(이거는 보통 시작,재시작만 들어감)
ㄴ왜 시작,재시작만 들어가느냐? 모르겠음.... 대충 생각해본다면... handlers는 무조건 tasks다음 즉 마지막에 실행이 되니까 예를들어 뭐... httpd.conf 수정후 마지막에 해야할 작업이 서비스 재시작밖에 더 있을까 ?싶다.

 

 

여튼 정리하자면..

site.yml 실행 > 그안에 있는 role들이 차례대로 실행 > ./roles 디렉토리에 roles와 동일한 이름 디렉토리가 있음 > 디렉토리 안에 ./tasks/main.yml 을 실행 > 실행되면서 탬플릿,파일들의 모듈 사용시 templates, files 디렉토리가 있고 그안에 파일을 사용 > 마지막에 ./handlers/main.yml 실행 

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

windows host에서 ansible 실행하는법  (0) 2019.05.23
ansible 공부한 모듈들 정리  (0) 2019.05.02
ansible- error  (0) 2019.04.26
ansible-3 playbook  (0) 2019.04.25
ansible-2 hosts(그룹), 멱등성  (0) 2019.04.22

+ Recent posts