1)
주의 사항
n 세션 종료시 kill -9, kill -11 절대 수행하면
안됨.
-
Database가 다운되고, Startup 되지 않을 수 있음.
n Database startup 이 안될 경우,
절대 pg_resetxlog 수행하면 안됨.
-
DB를 복구하지 못할 수 있음.
ð 2차적인 문제가 발생할 수 있으며, support 팀만이 수행 가능 함.
2)
DB가 startup 실패
또는 오래 걸리는 경우
n 로그
확인
-
Database 로그 및 gpAdmin 로그 확인
$ cd ~/gpAdminlog
$ vi gpstart_yyyy-mm-dd.log
$ cd $MASTER_DATA_DIRECTORY/pg_log
$ vi gpdb-yyyy-mm-dd_000000.csv
|
n Pg_hba.conf
파일 확인
-
DB를 내리고 올렸을 때 DB가
start 하지 않는 경우에 확인 필요
$ vi pg_hba.conf
host bmt
u1234 192.168.10..101/32 md5
보통 발생되는 경우에는IP 넣었을 때 0.0.0.0/0
“/0”을 넣지 않을 경우 발생 됨
|
n Postgresql.conf
파일 확인
-
DB를 내리고 올렸을 때 DB가
start 하지 않는 경우에 확인 필요
$ cd $MASTER_DATA_DIRECTORY
$ ls –lrt
$ vi postgresq.conf
=> 잘못된 파라미터, Max 값 이상의 파라미터 설정했을 때 발생
|
n DB Start 가 오래 걸릴 경우 #1(startup pass 2 process)
-
조치 방법: 자동으로 복구하기 때문에 정상 Startup 할 때 까지 대기
-
마스터/세그먼트 동일
$ ps –ef | grep postgres
gpadmin 25073 25069 0 03:12 ? 00:00:06 postgres: port 40000, primary
recovery process
gpadmin 25074 25069 0 03:12 ? 00:00:03 postgres: port 40000, primary
verification process
gpadmin 25095 24956 2 03:14 ? 00:04:30 postgres: port 40000, startup pass 2 process
gpadmin 29266 29231 0 06:31 pts/2 00:00:00 grep 40000
|
n DB Start 가 오래 걸릴 경우 #1(startup pass 3 process)
-
조치 방법: 자동으로 복구하기 때문에 정상 Startup 할 때 까지 대기
-
보통 마스터에서 발생
## 프로세스 확인
$ ps –ef | grep postgres
[gpadmin@avw7hdm2p1 gpseg-1]$ ps -ef|grep -i post |grep process
gpadmin 9841 9840 0 Feb05 ? 00:00:24 postgres: port 5432, master logger
process
gpadmin 365107 9840 33 05:38 ? 02:18:09 postgres: port 5432, startup pass 3 process
## 진행상황 확인
[gpadmin@avw7hdm2p1 gpseg-1]$ /usr/sbin/lsof
-p 745108 | grep pg_xlog
postgres 745108 gpadmin 4r REG 8,64 67108864 85899379122
/data/hawq/master_new/gpseg-1/pg_xlog/000000010000036E00000025
[gpadmin@avw7hdm2p1 gpseg-1]$ cd pg_xlog
[gpadmin@avw7hdm2p1 gpseg-1]$ ls –la
-rw------- 1 gpadmin gpadmin 67108864 Feb 25 20:30
000000010000036E00000030
-rw------- 1 gpadmin gpadmin 67108864 Feb 25 20:48
000000010000036E00000031
..
-rw------- 1 gpadmin gpadmin 67108864 Feb 26 01:48 000000010000036E00000037
=> xlog 진행상황 확인 가능함.
|
n DB Start 가 오래 걸릴 경우 #3
-
조치 방법: gpdb 재시작
-
보통 세그먼트에서 발생 (32 node,
256 segment instance 로 클러스터가 클 경우)
-
대기시간 15~20분 있어도
DB Start가 되지 않을 경우
## 현상
[gpadmin@mdw gpseg-1]$ gpstart -a
20170719:20:36:28:045332 gpstart:mdw:gpadmin-[INFO]:-Starting gpstart
with args: -a
20170719:20:36:28:045332 gpstart:mdw:gpadmin-[INFO]:-Gathering
information and validating the environment...
20170719:20:36:28:045332 gpstart:mdw:gpadmin-[INFO]:-Greenplum Binary
Version: 'postgres (Greenplum Database) 4.3.15.0 build 1'
20170719:20:36:28:045332 gpstart:mdw:gpadmin-[INFO]:-Greenplum Catalog
Version: '201310150'
20170719:20:36:28:045332 gpstart:mdw:gpadmin-[INFO]:-Starting Master
instance in admin mode
20170719:20:36:29:045332 gpstart:mdw:gpadmin-[INFO]:-Obtaining Greenplum
Master catalog information
20170719:20:36:29:045332 gpstart:mdw:gpadmin-[INFO]:-Obtaining Segment
details from master...
20170719:20:36:29:045332 gpstart:mdw:gpadmin-[INFO]:-Setting new master
era
20170719:20:36:29:045332 gpstart:mdw:gpadmin-[INFO]:-Master Started...
20170719:20:36:29:045332 gpstart:mdw:gpadmin-[INFO]:-Shutting down master
20170719:20:36:31:045332 gpstart:mdw:gpadmin-[INFO]:-Commencing parallel
primary and mirror segment instance startup, please wait...
……………………………………………. ####>>>
계속 점(.) 만 찍기는 현상
## 다른 세션에서 프로세스 확인
$ all
=> ps -ef | grep postgres | wc -l
[sdw2] 22
[sdw3] 22
[ mdw] 10
[sdw1] 18
###<< 특정 세그먼트에서 프로세스 수가 적으면서, 뜨지 않는 경우
[smdw] 5
=>
## GPDB Restart 수행 방법
## 마스터 instance
$ gpstart -a ## 수행되는 커멘드에서 CTRL+c 시도,
cancel 되지 않을 경우CTRL+z 로 중지시킴
## CTRL + z 수행시
[gpadmin@mdw ~]$ gpstart –a
20170719:20:39:50:045618 gpstart:mdw:gpadmin-[INFO]:-Starting gpstart
with args: -a
….
^Z
[1]+
Stopped gpstart
-a
[gpadmin@mdw ~]$
[gpadmin@mdw ~]$ kill %1 ### 프로세스 kill
[1]+ Stopped gpstart -a
[gpadmin@mdw ~]$
[1]+ Terminated gpstart -a
[gpadmin@mdw ~]$
[gpadmin@mdw gpseg-1]$ ps -ef | grep gpstart ### 프로세스가 잔류하는지 확인
gpadmin 45682 28239
0 20:42 pts/2 00:00:00 grep
gpstart
[gpadmin@mdw gpseg-1]$
##GPDB Restart
$ gpstart –m
##마스터만 시작
$ gpstop -af
## 모든 인스턴스 shutdown
$ all
## 모든 노드 접속
=> ps -ef | grep postgres | wc –l ## 프로세스 확인
=> ipcs
## 공유 메모리 있는 확인(gpadmin 계정),
예시
[smdw] ------ Shared Memory Segments --------
[smdw] key shmid owner perms bytes nattch status
[smdw] 0x00000000 98304
gpadmin 600 393216 2
dest
[smdw] 0x00000000 131073 gpadmin
600 393216 2 dest
[smdw] 0x00000000 163842
gpadmin 600 393216 2
dest
[smdw] 0x00000000 196611
gpadmin 600 393216 2
dest
[smdw] 0x00000000 229380
gpadmin 600 393216
2 dest
=> source
/usr/local/greenplum-db/greenplum_path.sh
=> ipcclean
[ mdw] ipcclean: nothing removed
[sdw1] ipcclean: nothing removed
=> exit
$ gpstart -a ## DB Restart
## 만약 다시 수행해도 되지 않을 경우, GSS 연락 필요
|
3)
로그 추출 공통사항
n gpmt 툴 설치
1. download from support.pivotal.io (위의
링크)
2. Copy gpmt.gz to /home/gpadmin
3. $ gunzip /home/gpadmin/gpmt.gz
4. $ chmod +x gpmt
5. $ /home/gpadmin/gpmt -h
|
n 기타
로그 반출 사항
-
시스템 메시지 로그, 성능 로그
-
반출 항목
1.
/var/log/message ## Master / 장애 발생 Segment 노드
2. /var/log/sa ##시스템 성능 로그
|
4)
프로세스 Hang 발생 시
n 로그
수집 시작 – 원인 분석을 위함.
-
락 정보 확인
$ qq ## 세션 확인
$ cq ## 쿼리 확인
$ lt ##
락 발생된 세션 확인
$ locks ## 락 확인
$ psql
#
select * from pg_stat_activity where sess_id = sessionid
# select * from pg_locks |
-
프로세스 로깅
$ gpssh -f hostfile
"ps -ef | grep con세션ID"
=> ps -ef | grep sessionid | grep -v grep | grep -v idle $ strace -p processid $ pstack processid $ netstat -anp | grep processid $ gpmt analyze_session -session 12345 -a ## 세션 관련 모든정보 수집 |
-
Table Lock 정보 로깅
-- 쿼리 #1
SELECT
(select datname from pg_database where
oid=a.database) AS "Database Name",
a.locktype AS "Lock Type",
a.relation::regclass AS "Relation
Name",
(select rsqname from pg_resqueue where
oid=a.objid) AS "Resource Queue",
count(*) AS "Total Waiters"
FROM pg_locks a
WHERE a.granted='f'
GROUP BY 1,2,3,4;
-- 쿼리 #2
SELECT
l.locktype AS "Blocker
locktype",
d.datname AS "Database",
l.relation::regclass AS "Blocking
Table",
a.usename AS "Blocking
user",
l.pid AS "Blocker pid",
l.mppsessionid AS "Blockers
SessionID",
l.mode AS "Blockers
lockmode",
now()-a.query_start AS "Blocked
duration",
substring(a.current_query from 1 for
40) AS "Blocker Query"
FROM
pg_locks l,
pg_stat_activity a,
pg_database d
WHERE l.pid=a.procpid
AND l.database=d.oid
AND l.granted = true
AND relation in ( select relation from
pg_locks where granted='f')
ORDER BY 3;
-- 쿼리 #3
SELECT
w.relation::regclass AS
"Table",
w.mode AS "Waiters Mode",
w.pid AS "Waiters PID",
w.mppsessionid AS "Waiters
SessionID",
b.mode AS "Blockers Mode",
b.pid AS "Blockers PID",
b.mppsessionid AS "Blockers
SessionID",
(select 'Hostname: ' || c.hostname ||'
Content: '|| c.content || ' Port: ' || port from gp_segment_configuration c
where c.content=b.gp_segment_id and role='p') AS "Blocking Segment"
FROM pg_catalog.pg_locks AS w,
pg_catalog.pg_locks AS b
Where ((w."database" =
b."database" AND w.relation = b.relation)
OR w.transactionid = b.transaction)
AND w.granted='f'
AND b.granted='t'
AND w.mppsessionid <>
b.mppsessionid
AND w.mppsessionid in (SELECT
l.mppsessionid FROM pg_locks l WHERE l.granted = true AND relation in (
select relation from pg_locks where granted='f'))
AND w.gp_segment_id = b.gp_segment_id
ORDER BY 1;
|
-
Core 파일 덤프 및 packore 수행
## core 파일 덤프
$ ./gpmt packcore -cmd COMMAND -core COREFILE [
-binary BINARY ]
$ ./gpmt packcore -cmd collect -core core.1234
–binary /usr/local/greenplum-db/postgres
## Packcore : Core 파일 관련 Library
파일 묶음
$ GPHOME/sbin/packcore core.3326 -b
/usr/local/greenplum/bin/postgres
## 리스트 확인
[gpadmin@mdw ~]$ ls -lrth | tail -2
core.3326
packcore-core.3326.tgz è support 팀에
업로드 (파일 안에 core.xxxx 도 포함이 되어 있음)
|
n 세션 Kill
-
반드시 DB에서에서
kill 을 함
-
Kill -9,
kill -11 절대 금지
$ psql
=# select
pg_terminate_backend(PID)
|
-
세션이
끊기지 않을 경우, 타 세션에서 대용량 처리할 경우 발생 가능하며, Busy한 세션이 끝날 경우 세션이
close 됨
-
만약
세션이 끊기지 않을 경우, Support
Team 에 연락
5) 에러 발생 시
n 로그 수집
- DB 로그 수집, 마스터 노드/세그먼트 노드의 발생시간 전후 로그 수집
- 에러 로그 별도로 정리=> SR 올리기 위한 커뮤니케이션 자료로 활용(참고 SR 등록 편 참조)
$ cd $MASTER_DATA_DIRECTORY/pg_log
$ gplogfilter –t gpstart_yyyy-mm-dd.log > err_yyyy-mm-dd.log
# 마스터 노드 및 세그먼트 노드의 pg_log 추출
$ gpmt gp_log_collector -hostfile ~/gpconfig/hostfile -start 2017-03-13 -end 2017-03-15
# 특정 세그먼트 에러시 (컨텐츠 ID로 추출시) 오늘 데이터 추출 시 (failover 수행되는 경우)
$ gpmt gp_log_collector -c "13,12,15"
|
6) Recovery Mode 발생 및 쿼리 재현 필요 시 (minirepro utility)
n 쿼리 플랜 작성시 Recovery Mode 발생
- GSS 및 개발팀에서 재현 가능하도록 테이블 정보와 통계 정보 수집- 참고 사이트: https://community.pivotal.io/s/article/How-to-Collect-DDL-and-Statistics-Information-Using-the-Minirepro-Utility
|
# 마스터 노드 및 세그먼트 노드의 pg_log 추출
$ minirepro prod_db -q query.sql -f /data/query_minirepro.out
-U gpadmin
#
# 재현 테스트 (Local on VM)
$ createdb
dbname
$ psql
-ef query_minirepro.out > query_minirepro.log
$ psql -ef query.sql
|
7) Core 덤프로 문제 쿼리 / 세션ID 찾기
n Core 덤프로 문제 쿼리 찾기
-
마스터 또는 세그먼트
노드에서 core dump 파일 확인
- strings core 덤프 파일로 확인하면, 세션 번호/쿼리에 대해서 간략한 정보 나옴.
|
[gpadmin@mdw]$ gpssh -f hostfile_all
=> cd /var/crash/user-processed
=> ll
[sdw4] total 0
[sdw1] total 0
[ mdw] total 4835820
[ mdw] -rw------- 1 gpadmin
gpadmin 472215552 Nov 7 18:05
core.postgres.286140.1541581540.11.500.500
[ mdw] -rw------- 1 gpadmin
gpadmin 472133632 Nov 7 18:07
core.postgres.290569.1541581700.11.500.500
[ mdw] -rw------- 1 gpadmin
gpadmin 157307180 Nov 8 16:35
packcore-core.postgres.315818.1541582687.11.500.500.tgz
[ mdw] -rw------- 1 gpadmin
gpadmin 156884505 Nov 8 16:37
packcore-core.postgres.301945.1541582163.11.500.500.tgz
[ mdw] -rw------- 1 gpadmin
gpadmin 149782388 Nov 8 16:38
packcore-core.postgres.286140.1541581540.11.500.500.tgz
[ mdw] -rw------- 1 gpadmin
gpadmin 469831680 Nov 8 16:53
core.postgres.13303.1541663645.11.500.500
[ mdw] -rw------- 1 gpadmin
gpadmin 426209280 Nov 9 10:10
core.postgres.22585.1541725851.11.500.500
[sdw2] total 0
[sdw3] total 273224
[sdw3] -rw------- 1 gpadmin gpadmin 288505856 Oct 19 10:28 core.postgres.212344.1539912514.11.500.500
[smdw] total 0
[sdw5] total 0
[sdw7] total 0
[sdw6] total 0
[sdw8] total 0
[gpadmin@mdw]$
[gpadmin@mdw] ssh sdw3
[gpadmin@sdw3] cd /var/crash/user-processed
[gpadmin@sdw3] strings
core.postgres.212344.1539912514.11.500.500 | more
CORE
ptQo
aQo
CORE
postgres
postgres: 5432, etlusr testdw
17.4.110.88(22865) con5281 cmd3 SELECT
CORE
CORE
LINUX
CORE
CORE
...
...
... 계속 내려가보면 문제
쿼리 나옴
…
pg_multixact/offsets
SELECT * FROM XXXXX => Error SQL 이 있음.
/tmp/.s.PGSQL.5432
HH24:MI:SS
|
댓글 없음:
댓글 쓰기