끄적끄적 개발노트

원하는 위치에서 git bash 실행

$ git init

$ git add .

$ git commit -m "first commit"

$ git remote add origin [복사한 주소 붙여넣기]

$ git push -u origin master

MQ 설정 관련

- 메모리 부족으로 인한 application shut down 현상 발생

-  ./rabbitmqctl status 명령어로 status 확인

- memory detail 확인해보니 queue 인입량이 급격히 증가(기존에 처리하지 못한 queue가 쌓여, flush 되지 못한 것으로 보임)

- application 재시작(./rabbitmqctl stop_app, ./rabbitmqctl start_app) 동일 현상 발생

- cluster 제거

server 1 : 문제발생

server 2 : ./rabbitmqctl forget_cluster_node rabbit@server1 (단, 1번서버 stop 시켜준 상태에서 진행 ./rabbitmqctl stop_app)

server1 : ./rabbitmqctl reset < 반드시 진행해야함!!!

- cluster 넣기

server1 : ./rabbtmqctl stop_app

server1 : ./rabbitmqctl join_cluster rabbit@server2

server1 : ./rabbtmqctl start_app

./rabbitmqctl cluster_status 를 통해 running node 확인

아래와 같이 정상화 되었다.

* 실수로...

reset이 안되어 ./rabbitmq-server stop(./rabbitmqctl stop_app 대신)을 진행하게 될경우, node 자체가 죽는다. ./rabbitmqctl 관련 명령어는 node가 떠있을때만 가능하므로.. 관련 명령어가 전혀 수행되지않는다.

 ./rabbitmq-server -detached  < 도 안먹혔다. 불능상태처럼 빠지는데...

이유는 sever1, server2가 있을때 server2에서 cluster를 빼줬지만, server1은 reset전 상태가 되버리므로, 서로 보는 conf 가 달라, 에러 발생

/home1/irteam/apps/rabbitmq/var/lib/rabbitmq/mnesia/rabbit@host 파일을 제거하고, 위의 상태를 재반복해서 해결

*관련

mq설정 포스팅 : http://pigbrain.github.io/opensource/2016/04/11/RabbitMQ_6_Clustering_on_RabbitMQ
트러블슈팅 솔루션 : https://stackoverflow.com/questions/21018210/rabbitmq-inconsistent-cluster

Transaction Isolation Level

• READ UNCOMMITTED
  다른 트랜잭션이 Commit 전 상태를 볼 수 있음
  Binary Log가 자동으로 Row Based로 기록됨 (Statement설정 불가, Mixed 설정 시 자동 변환)

> dirty read 현상(서로 다른 데이터를 읽게됨) 

한 트랜잭션(T1)이 데이타에 접근하여 값을 'A'에서 'B'로 변경했고 아직 커밋을 하지 않았을때, 다른 트랜잭션(T2)이 해당 데이타를 Read 하면?

T2가 읽은 데이타는 B가 될 것이다. 하지만 T1이 최종 커밋을 하지 않고 종료된다면, T2가 가진 데이타는 꼬이게 된다.

출처: http://feco.tistory.com/45 [wmJun]

• READ-COMMITTED
  Commit된 내역을 읽을 수 있는 상태로, 트랜잭션이 다르더라도 특정 타 트랜잭션이 Commit을 수행하면 해당 데이터를 Read할 수 있음
  Binary Log가 자동으로 Row Based로 기록됨 (Statement설정 불가, Mixed 설정 시 자동 변환)

> Non-Repeatable Read

한 트랜잭션(T1)이 데이타를 Read 하고 있다. 이때 다른 트랜잭션(T2)가 데이타에 접근하여 값을 변경 또는, 데이타를 삭제하고 커밋을 때려버리면?

그 후 T1이 다시 해당 데이타를 Read하고자 하면 변경된 데이타 혹은 사라진 데이타를 찾게 된다.

출처: http://feco.tistory.com/45 [wmJun]

• REPEATABLE READ
  MySQL InnoDB 스토리지 엔진의 Default Isolation Level
  Select 시 현재 데이터 버전의 Snapshot을 만들고, 그 Snapshot으로부터 데이터를 조회
  동일 트랜잭션 내에서 데이터 일관성을 보장하고 데이터를 다시 읽기 위해서는 트랜잭션을 다시 시작해야 함

> Phantom Read

트랜잭션(T1) 중에 특정 조건으로 데이타를 검색하여 결과를 얻었다. 이때 다른 트랜잭션(T2)가 접근해 해당 조건의 데이타 일부를 삭제 또는 추가 했을때, 아직 끝나지 않은 T1이 다시 한번 해당 조건으로 데이타를 조회 하면 T2에서 추가/삭제된 데이타가 함께 조회/누락 된다. 그리고 T2가 롤백을 하면? 데이타가 꼬인다

출처: http://feco.tistory.com/45 [wmJun]

• SERIALIZABLE
  가장 높은 Isolation Level로 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 Shared Lock이 걸림
  다른 트랜잭션에서는 해당 영역에 관한 데이터 변경 뿐만 아니라 입력도 불가

> 문제점 모두 커버 가능 but 성능이슈

*** mysql의 기본이 repeatable read라 dead lock 현상 이슈 존재

출처 : http://gywn.net/2012/05/mysql-transaction-isolation-level/