ALTER TABLE ADD PARTITION 시에 장애

운영중인 시스템에서 mariadb를 사용 파티션 ADD 시에 ADD 프로세스가 문제가 생겨 테이블 락이 걸려서 해당 테이블을 사용하는 서비스에서 쓰레드가 밀리고 있었다.

여기서 궁금증이 나왔다. 파티션 add/drop 시에 테이블 락이 걸려야 되냐?

• 실제 파티셔닝을 하는이유가 time series를 하기 위해서 사용한다고 use cases에도 나와 있다. 이것은 미래에 들어올 데이터를 위해 신규 파티션을 만들고 더이상 쓰지 않는 파티션에 대해 삭제 하는작업을 하기 위해서 이다. 그렇다면 파티션을 추가 하거나 삭제 할때는 락을 걸필요가 없는것이 아닌가라는 생각이 들었다.

그럼 mariadb에서 alter table할때 테이블 락은 어떻게 걸리는지 확인해 보았다.

기본적으로 LOCK 절을 사용하면 락을 전략적으로 사용할수 있는데. alter table에서 누락된 lock절은 기본전략이 DEFAULT이다

• DEFAULT: 허용되는 최대 동시성 레벨이 사용됩니다.
• NONE: 잠금이 획득되지 않거나 오류가 발행됩니다.
• SHARED: 읽기 잠금이 확보되거나 오류가 발행됩니다.
• EXCLUSIVE: 쓰기 잠금이 획득됩니다.

lock 없음을 사용할때는 ALTER ONLINE TABLE 이라는 명령어로 할수 있는데 이것은 LOCK=NONE가 같다.

참조

• mysql Partitioning and Locking
• mariadb partition-maintenance
• mariadb alter-table

마리아 DB 교체후 장애 사항 대처

운영중인 시스템에서 mariadb를 사용하고 있는데 디스크가 98%까지 찼다, 예상은 하고 있었는데 차주 화요일로 교체시기를 예상하고 있었지만 주말에 디스크 확보를 보장하기 어려워 바로 교체하는 작업을 했다. 교체이후에 문제가 없는줄 알고 있던 시스템에서 하나씩 장애가 발생하기 시작했다. 가장 큰 문제는 옵티마이저에서 발생하고 있었다 cost-based로 움직이는 옵티마이저에서 다르게 판단되고 있다고 생각하여서 STRAIGHT_JOIN 을 넣어서 처리하라고 했다.

여기서 궁금증이 나왔다.

1. 기존 DB에서 마이그레이션 작업을 했을때 통계DB까지 다 옴겨졌냐?( 답변 : 옴겨 졌다. DB 덤프를 떠서 옴겼다고 함)
2. 그럼 통계정보가 변경된것이 있냐?(인덱스작업과, 데이터 삭제 작업을 진행했다.)
3. 그럼 문제된 쿼리에서 테이블에 새로운 인텍스가 걸린것이 있냐?(없다.)

위에 질문에서 더이상 질문 하지 못한것이 있다.

1. 삭제 작업을 한다고 해서 통계정보가 바뀌냐?(기존 DB에는 영향이 없음, 부과적으로 삭제한다고 해서 테이블 스페이스가 다시 돌아 오는것읕 아니다 최적화시에 돌아오는데 이때바뀔꺼로 예상함)

아 궁금한것이 많은데 찾아보질 못함 ㅜㅜ

p.s : 궁금해 죽겠는데 제대로 된 답변이 안됨 샤머니즘으로 끝난듯 해서 아쉽다.

참조

• mariadb optimizer-switch

GCE_TIMEZONE

sql을 사용했는데 select now() 시간이 한국 시간이 아니였다 해당 설정은

sql 설정에 들어가서 수정을 누른 다음 데이터베이스 플래그 추가에 default_time_zone 설정을 +09:00 항목을 추가했다.

또 서버 인스턴스에서도 타임존이 맞지 않아 rdate를 이용해서 맞출려고 했지만 맞지 않았다.

해당 설정은 .bash_profile 에서 export TZ=’Asia/Seoul’ 를 추가해서 해결을 하였다.