안녕하세요.

playbook 이란

각본이라고 나오는데 작업계획서 ??같은거다.

예를들어 서버에 apache를 설치할 때

1.아파치를 다운로드 받고

2.압축풀고

3.소스설치하고 등등

작업들을 나열한 파일(이름.yml)을 플레이북이라 하고 playbook에 입력돼있는 모듈, 작업들을 순차적으로 진행한다.

yaml로 짜여져있어서 첫줄에는 --- 을 적어야한다.

그리고 -name: 작업이름을 적어준다. 여기서 : 이거 뒤에 스페이스로 한칸 뛰어야한다. 야믈 문법은 계속 공부하면서 읶혀야할듯

##name은 필수가 아니다. 다만 무조건 적는 습관을 들이자. playbook 실행시 어느 구간이 작업되고 있는지 확인할 수 있고 다른사람이 볼때도 쉽게 알아야 하니까.

아래는 /root/test.txt 라는 파일을 /root/test.txt_ori로 옮기고(만약 /root/test.txt가 없을경우는 무시)

/root/ansible/template/test.j2를 /root/test.txt로 업로드하는 플레이북이다.

--- ## 첫줄은 무조건 --- 적어줘야한다. yml 명시
- hosts: all ## 작업 대상은 /etc/ansible/hosts에 적혀있는 모든 서버들, : 땡땡 뒤에는 므조건 스페이스로 한칸 띄어줘야 한다. 
  remote_user: root  ##맨앞에는 스페이스로 두칸 띄어주고
  tasks: ##마찬가지로 여기도 맨앞에는 스페이스로 두칸 띄어주고
  - name: centos 5 version mv test.txt test.txt_ori   
    shell: bash -c 'mv /root/test.txt /root/test.txt_ori'   ###이번에는 4칸. 들여쓰기 해줘야됨. / root/test.txt 라는 파일을 /root/test.txt_ori로 옮긴다.
    when: ansible_distribution == "CentOS" and ansible_distribution_major_version == '6' ###서버 os가 centos 6버전일때만
    ignore_errors: True ###/root/test.txt 가 서버에 없으면 에러발생하고 그다음작업 진행을 안한다. ignore_errors:True 해야지 /root/test.txt 가 없어도 무시하고 다음작업을 진행한다.
  - name: centos 5 version new test.txt upload | Template test.txt
    template: src="/root/ansible/template/test.j2" dest="/root/test.txt" force=yes owner=root group=root mode="0644" ##test.txt 새로 업로드

그룹관리

/etc/ansible/group_vars 하위에다가 그룹-그룹 그룹-변수 지정도 가능하다.

ansible]# cat /etc/ansible/hosts              
[nginx]
1.1.1.1         ansible_user=root       ansible_ssh_pass='qlqjs'
[apache]
2.2.2.2         ansible_user=root       ansible_ssh_pass='qlqjs'

파일 내용은 위와같고

ansible]# ansible all -m shell -a "df -h" --list-hosts
  hosts (2):
    1.1.1.1 
    2.2.2.2

ansible]# ansible nginx -m shell -a "df -h"   
1.1.1.1 | CHANGED | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       235G   37G  187G  17% /
tmpfs           3.9G     0  3.9G   0% /dev/shm
/dev/sda1       200M  120M   70M  64% /boot

ansible]# ansible all -m shell -a "df -h"     
2.2.2.2 | FAILED | rc=-1 >>
Using a SSH password instead of a key is not possible because Host Key checking is enabled and sshpass does not support this.  Please add this host's fingerprint to your known_hosts file to manage this host.

1.1.1.1 | CHANGED | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       235G   37G  187G  17% /
tmpfs           3.9G     0  3.9G   0% /dev/shm
/dev/sda1       200M  120M   70M  64% /boot

##
-m 옵션은 어떤 모듈을 선택할지..

yum, service, shell등 많다. -m 옵션의 기본값은 shell 이다. 다만 남들이 좀 더 보기 편하게 shell도 써주기

다만 위 명령들은 ansible 단일명령? 뭐 그런느낌이다. 에드혹이라고 하는듯. 대부분 플레이북을 이용해 사용한다.

-------여기까지가 가장 기본적인 ansible 사용법------------

----멱등성-----

엔서블하면 멱등성이 꼭 나온다.
멱등성이란 연산을 여러번 적용해도 결과가 달라지지 않는 성질인데 엔서블이 멱등성을 지원한다.
난 이부분이 처음에 굉장히 헷갈렸다. 도대체 어떻게 무조건 값이 같을 수 있지 ??근데 최대한 멱등성을 지원하려고 노력한다는거지(대부분의 모듈들이) 멱등성을 지원하지 않을수도 있다. 

여튼.. 멱등성이 뭔지 예를들자면 lineinfile 이란 모듈이 있다. 이 모듈은 echo "문구" >> 파일.txt 와 같이 파일에 내용을 추가하는 모듈인데...ansible -m lineinfile "path=test.txt line=test11" 이런식으로 애드혹를 입력할경우 test.txt 하단에 test11이라는 구문이 추가된다.  근데 사람이 실수로 ansible -m lineinfile "path=test.txt line=test11" 이런 명령어를 두번 넣었을경우 lineinfile은 멱등성을 지원하기 때문에 해당 파일에 test11 이 두줄 추가 되지 않고 한줄만 추가된다. 

반대로 shell 이라는 모듈을 통해 입력을 하면 당연히 test11이 두줄 추가 돼겠지. 이경우는 멱등성이 지원되지 않은거다.

innodb 의 경우 instert 속도가 myisam에 비해 느리다.

이경우 여러가지 튜닝을 할 수 있는데 대표적인것만 몇개 수정, 비교 해보려고 한다.

1.innodb_flush_log_at_trx_commit 를 0으로 변경하면 속도를 많이 올릴 수 있다고 한다.
innodb_flush_log_at_trx_commit 란...
https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html

요약하자면

innodb_flush_log_at_trx_commit 이란 쿼리 요청이 디스크에 저장되는 방법이 지정된 변수이다. 즉 이 값을 변경하면 트랜잭션 방법을 수정해서 insert 속도를 올릴 수 있따.

##트랜잭션, commit이란

먼저 DB에서의 트랜잭션이란 정상적으로 완료된 일련의 작업들이라고 생각하면된다. 예를들어 insert , update , delete가 순차적으로 일어나고 그후 commit을 하게되면 트랜잭션이 정상적으로 완료됐다할 수 있다. 즉 commit이란 저장되지 않은(메모리에 적혀있는)데이터를 디비에 저장 후 트랜잭션을 종료한다.

innodb_flush_log_at_trx_commit  값이 디폴트일때의 과정(즉 1일 때)은 아래 처럼 진행된다.

쿼리 하나당 [log buffer(메모리 영역)를 거쳐서 >os buffer/cache(메모리 영역)를 거쳐서  > 마지막으로 ib_logfile(디스크영역)에 저장(flush) 된다.] 즉 1회 요청당 1회 commit - 한번의 요청때마다 매번 commit을 진행한다. - (요게 핵심임)

0 또는 2로 바꾼다면 저 과정이 간략해진다.

innodb_flush_log_at_trx_commit  =0
쿼리 하나당 [log buffer(메모리 영역)저장]하고 1초에 한번씩 나머지 commit을 수행(os buffer/cache(메모리 영역)를 거쳐서  > 마지막으로 ib_logfile(디스크영역)에 저장(flush)])

innodb_flush_log_at_trx_commit  = 2

쿼리 하나당 [log buffer(메모리 영역)를 거쳐서 >os buffer/cache(메모리 영역)에 저장] 후 1초에 한번씩 나머지 commit을 수행ib_logfile(디스크영역)에 저장(flush)])

즉 0과 2의 차이는 쿼리하나당 log buffer까지 저장하느냐 os buffer/cache 까지 저장하느냐의 차이임

(혹시 이글을 읽으시는 분들중 틀린 내용이 있다면 제발 코멘트 부탁드립니다. 구글링하면서 다른 내용이 적잖이 보여서 사실 저도 좀 헷갈립니다.)

이론적으로 보면 속도 순서는 0 - 2 -1 순으로 빨라야 한다. 

비교를 해보자.

0이랑 2랑 거의 비슷하고(0이쫌더 빠르긴함) 확실히 1로 줬을때보단 빠르긴 한듯합니다. 용량 작으면 그냥 하고 용량 크면 데이터 유실될 가능성이 좀 더 적은 2로 주고 하는게 좋겠네요. 

2.innodb buffer pool size 

아마 이게 가장 대표적이고 또 확실히 눈에 보이게 성능 향상이 이루어질걸로 판단한다.

극단적으로 보기위해 기존에는 디폴트 값(128MB)과 서버 메모리(32GB)에 맞게끔 변경해서 비교했는데

7GB 짜리 덤프파일 복원 하는데 3시간 쫌 넘게 걸렸고
real    187m17.825s 
user    2m21.802s 
sys     0m6.869s

이번에는 innodb buffer pool size = 20GB로 변경하고 .sql 용량 =8GB 짜리 복원시(키 버퍼랑 등등 추가로 알맞게 진행)

real    40m44.386s
user    2m21.319s
sys     0m8.349s

역시... innodb buffer pool size 는 튜닝 필수다.

내용 요약.

1.innodb buffer pool size 수정은 필수(그에따른 키 버퍼나 솔트 버퍼등도 구글링해서 알맞게 수정)

2.용량이 큰 dump파일 복원시 innodb_flush_log_at_trx_commit 는 2로 변경
ㄴ실제 사용시 상황에 맞게(안전성이냐 속도냐) 1또는 2로 사용