기록의 공간 :: mightytedkim

주말 쉬고 오니까 mariadb가 내려가있더라고요 crashloopbackoff 가 돌고 있길래 급하게 pvc를 백업하고 살펴봤습니다. $ k get pod -n mariadb NAME READY STATUS RESTARTS AGE mariadb-primary-0 0/1 CrashLoopBackOff 562 (2m2s ago) 117d 요약 결론 부터 말하면, innodb_force_recovery=5로 해결했습니다. 여전히 tablespace error가 나오길래, sqldump 후 .sql 을 local에 저장하고 새로운 mariadb를 만들고 import 시켰습니다. 예상 독자는 아래와 같아요 helm mariadb를 돌리다 장애나신 분 mariadb heuristic recovery가 안되는 분 ..

요약 1. disk 용량이 꽉참 2. mysql binary 때문이었음 3. 삭제하고, 저장 주기 조정함 설명 1. disk 용량이 꽉참 2. mysql binary 때문이었음 ls -al | grep mysql total 14916268 drwxrwsr-x 11 1001 1001 4096 Apr 25 04:24 . drwxrwsrwx 4 root 1001 4096 Dec 6 09:26 .. drwxrws--- 2 1001 1001 4096 Dec 6 09:26 mysql -rw-rw---- 1 1001 1001 1453 Dec 6 09:26 mysql-bin.000001 -rw-rw---- 1 1001 1001 509183729 Dec 14 05:59 mysql-bin.000002 -rw-rw---- ..

구글링할 때 이런 에러로 검색하니 나옴, pvc 할당을 늘려줌 -> binary 파일을 삭제하지 않아서 그런거였음 + 추가 갑자기 pvc가 늘어난 원인을 찾았음 실시간 대용량 log 데이터를 바로 mariadb로 insert하고 있었음 그것도 1 connection, 1 insert kafka, redis 같은 큐 사용 왜하지 않았냐고 물으니까. 이렇게 많을 줄 몰랐다고.. 말인지 방구인지 문제 오픈했는데, 일단 이렇게 진행하자는 대답이 들어옴... 믿을 수 없음. 책임만 있고 권한은 없는 관리자가 나임 요약 문제발생 원인분석 조치 설명 1. 문제 발생 HQ mariadb 접속 안되는 문제 발생 2. 원인 분석 kubernetes pod CrashLoopBackOff, 재시작이 안되는 문제 -> pvc를..

timezone 변경 default-timzone으로 변경하면 tz 자체가 변경되고 extraEnvVar로 설정하면, system_time_zone이 변경되고, tz이 system을 따라간다는것을 확인함 방법1: default-timezone primary: configuration: |- [mysqld] default-time-zone='+9:00' 방법2: extraEnv로 적용 extraEnvVars: - name: TZ value: "Asia/Seoul" #"UTC" MariaDB [(none)]> show variables like '%time_zone%'; +------------------+--------+ | Variable_name | Value | +------------------+-..

Kubernetes 1.12+ Helm 2.11+ or Helm 3.0-beta3+ PV provisioner support in the underlying infrastructure https://github.com/helm/charts/tree/master/stable/mariadb 결과 $ k get all -n mariadb NAME READY STATUS RESTARTS AGE pod/mariadb-20220222-primary-0 1/1 Running 0 114s pod/mariadb-20220222-secondary-0 1/1 Running 0 114s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/mariadb-20220222-primary ..