38탄-6. EKS DB - 워드프레스 DB사용 3/3
앞에서 만든 DB를 워드프레스에서 사용해보자.
스토리지 EFS도 사용해보자.
<1> 워드프레스 설치
<2> [장애1] MySQL 서버 파드(인스턴스) 1대 강제 삭제 및 동작 확인
<3> [장애2] MySQL 서버 파드(인스턴스) 가 배포된 노드 1대 drain 설정 및 동작 확인
<4> MySQL 서버 파드(인스턴스) / 라우터 파드 증가 및 감소해보기
<5> 스케일 테스트
<6> mysql 오퍼레이터를 통해 스케쥴 백업 해보자.
<7> MySQL 오퍼레이터를 활용한 데이터베이스 DR 구성
<8> 삭제
<9> 도전과제
<10> sysbench 툴을 통한 MySQL 성능 측정 해보기 - GithubHoing사용기
<1> 워드프레스 설치
https://artifacthub.io/packages/helm/bitnami/wordpress
백단에 설치된 이노디비를 사용한다.
EFS 를 사용해 보자.
Pod가 공용 저장소를 사용해 보자.
워드 프레스 설치하고 나면 아래 내용이 나온다.
# NFS 마운트 확인
ssh ec2-user@$N1 sudo df -hT --type nfs4
ssh ec2-user@$N2 sudo df -hT --type nfs4
ssh ec2-user@$N3 sudo df -hT --type nfs4
1
# MySQL 에 wordpress 데이터베이스 생성
kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e "create database wordpress;"
kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e "show databases;"
워드프레스 3대가 설치 된다.
ALB 로 3대가 나누어 진다.
2
# 파라미터 파일 생성
cat <<EOT > wp-values.yaml
wordpressUsername: admin
wordpressPassword: "password"
wordpressBlogName: "DOIK Study"
replicaCount: 3
service:
type: NodePort
ingress:
enabled: true
ingressClassName: alb
hostname: wp.$MyDomain
path: /*
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
alb.ingress.kubernetes.io/group.name: study
alb.ingress.kubernetes.io/ssl-redirect: '443'
persistence:
enabled: true
storageClass: "efs-sc"
accessModes:
- ReadWriteMany
mariadb:
enabled: false
externalDatabase:
host: mycluster.mysql-cluster.svc
port: 3306
user: root
password: sakila
database: wordpress
EOT
3
# wordpress 설치 : MySQL 접속 주소(mycluster.mysql-cluster.svc), MySQL 데이터베이스 이름 지정(wordpress) , 장애 테스트를 위해서 3대의 파드 배포
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-wordpress bitnami/wordpress --version 18.0.7 -f wp-values.yaml
helm get values my-wordpress
// 설치에 좀 시간이 걸린다. = EFS 작업 시간
# 설치 확인
watch -d kubectl get pod,svc,pvc
kubectl get deploy,ingress,pvc my-wordpress
kubectl get pod -l app.kubernetes.io/instance=my-wordpress
kubectl get sc,pv
# NFS 마운트 확인
ssh ec2-user@$N1 sudo df -hT --type nfs4
ssh ec2-user@$N2 sudo df -hT --type nfs4
ssh ec2-user@$N3 sudo df -hT --type nfs4
# Wordpress 웹 접속 주소 확인 : 블로그, 관리자
echo -e "Wordpress Web URL = https://wp.$MyDomain"
echo -e "Wordpress Admin URL = https://wp.$MyDomain/admin" # 관리자 페이지 : admin, password
# 모니터링
while true; do kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e "SELECT post_title FROM wordpress.wp_posts;"; date;sleep 1; done
# (참고) EFS 확인
베스천 호스트 서버에서 마운트해서 확인도 가능하다.
mount -t efs -o tls $EFS_ID:/ /mnt/myefs
df -hT --type nfs4
tree /mnt/myefs/ -L 4
# (참고) 관리자 로그인 후 새 글 작성(이미지 첨부) 후 아래 확인
kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e "SELECT * FROM wordpress.wp_term_taxonomy;"
kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e "SELECT post_content FROM wordpress.wp_posts;"
admin/ password
게시글 1개 작성해보기.
EFS를 사용하므로 어느 pod에 들어가더라도 동일한 내용이 표시 된다.
<2> [장애1] MySQL 서버 파드(인스턴스) 1대 강제 삭제 및 동작 확인
1
프라이머리 파드가 어느 노드에 있는지 확인
2
# PRIMARY 파드 정보 확인
kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e 'SELECT VIEW_ID FROM performance_schema.replication_group_member_stats LIMIT 1;SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;'
kubectl get pod -n mysql-cluster -owide
# 파드들에서 mysql 라우터 서비스로 접속 확인 : TCP 6447 접속 시 round-robin-with-fallback 정책에 의해서 2대에 라운드 로빈(부하분산) 접속됨 >> 3초 간격으로 확인!
kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila --port=6447 -e "SELECT @@HOSTNAME,@@SERVER_ID;"
3초 간격
kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila --port=6447 -e "SELECT @@HOSTNAME,@@SERVER_ID;"
3
동작확인
# 모니터링 : 터미널 3개로 각각 모니터링 한다.
watch -d 'kubectl get pod -o wide -n mysql-cluster;echo;kubectl get pod -o wide'
while true; do kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e 'SELECT VIEW_ID FROM performance_schema.replication_group_member_stats LIMIT 1;SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;'; date;sleep 1; done
while true; do kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila --port=6447 -e 'SELECT @@HOSTNAME;'; date;sleep 2; done
# 신규터미널4 : test 데이터베이스에 원하는 갯수 만큼 데이터 INSERT, CTRL+C 로 취소
for ((i=1001; i<=5000; i++)); do kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e "SELECT NOW();INSERT INTO test.t1 VALUES ($i, 'Luis$i');";echo; done
# 신규터미널5 : 프라이머리 파드 삭제 kubectl delete pod -n mysql-cluster <현재 프라이머리 MySQL 서버파드 이름> && kubectl get pod -n mysql-cluster -w
kubectl delete pod -n mysql-cluster mycluster-0 && kubectl get pod -n mysql-cluster -w
혹은
kubectl delete pod -n mysql-cluster mycluster-1 && kubectl get pod -n mysql-cluster -w
혹은
kubectl delete pod -n mysql-cluster mycluster-2 && kubectl get pod -n mysql-cluster -w
# 워드프레스에 글 작성 및 접속 확인 : 1초 미만으로 자동 절체! >> 원상복구 FailBack 확인(파드 재생성 후 그룹 멤버 Join 확인)
# 만약 <세컨더리 MySQL 서버파드> 를 삭제했을 경우에는 자동 Join 되지 않음 >> 아래 수동 Join 실행하자
2
확인?
글 써보자~~
잘 되는가?
데이터 동기화도 된다!
참고
https://malwareanalysis.tistory.com/343?category=1099737
<3> [장애2] MySQL 서버 파드(인스턴스) 가 배포된 노드 1대 drain 설정 및 동작 확인
노드 1대의 장애를 일으켜 보자.
워커 노드가 3개.
노드 1대가 보안패치로 1대 작업해야 하는 경우 발생.
파드를 다른 노드로 이동시키는 (드레인) 것을 한다.
워드프레스 정상 접속 및 포스팅 작성 가능, 데이터베이스에 반복해서 INSERT 시도
1
노드를 재부팅해야 하는 상황.
파드를 다른 노드로 쫓아 낸다.
2
# 모니터링 : 터미널 3개 >> 장애1 모니터링과 상동
watch -d 'kubectl get pod -o wide -n mysql-cluster;echo;kubectl get pod -o wide'
while true; do kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e 'SELECT VIEW_ID FROM performance_schema.replication_group_member_stats LIMIT 1;SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;'; date;sleep 1; done
while true; do kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila --port=6447 -e 'SELECT @@HOSTNAME;'; date;sleep 2; done
# 신규터미널4 : test 데이터베이스에 원하는 갯수 만큼 데이터 INSERT, CTRL+C 로 취소
for ((i=5001; i<=10000; i++)); do kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e "SELECT NOW();INSERT INTO test.t1 VALUES ($i, 'Luis$i');";echo; done
# 신규터미널5 : EC2 노드 1대 drain(중지) 설정 : 세컨더리 노드 먼저 테스트 =>> 이후 프라이머리 노드 테스트 해보자! 결과 비교!
kubectl get pdb -n mysql-cluster # 왜 오퍼레이터는 PDB 를 자동으로 설정했을까요?
# kubectl drain <<노드>> --ignore-daemonsets --delete-emptydir-data
kubectl get node
NODE=<각자 자신의 EC2 노드 이름 지정>
NODE=ip-192-168-2-58.ap-northeast-2.compute.internal
kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --force && kubectl get pod -n mysql-cluster -w
# 워드프레스에 글 작성 및 접속 확인 & INSERT 및 확인
# 노드 상태 확인
kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-m Ready control-plane,master 65m v1.23.6
k8s-w1 Ready <none> 64m v1.23.6
k8s-w2 Ready,SchedulingDisabled <none> 64m v1.23.6
k8s-w3 Ready <none> 64m v1.23.6
# 파드 상태 확인
kubectl get pod -n mysql-cluster -l app.kubernetes.io/component=database -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mycluster-0 2/2 Running 2 (15m ago) 58m 172.16.158.10 k8s-w1 <none> 1/2
mycluster-1 2/2 Running 0 21m 172.16.24.6 k8s-w3 <none> 2/2
mycluster-2 0/2 Pending 0 6m15s <none> <none> <none> 0/2
# EC2 노드 1대 uncordon(정상복귀) 설정
# kubectl uncordon <<노드>>
kubectl uncordon $NODE
<4> MySQL 서버 파드(인스턴스) / 라우터 파드 증가 및 감소해보기
1
# 현재 MySQL InnoDB Cluster 정보 확인 : 서버파드(인스턴스)는 3대, 라우터파드(인스턴스)는 1대
kubectl get innodbclusters -n mysql-cluster
NAME STATUS ONLINE INSTANCES ROUTERS AGE
mycluster ONLINE 3 3 1 17m
# 모니터링
while true; do kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e 'SELECT VIEW_ID FROM performance_schema.replication_group_member_stats LIMIT 1;SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;'; date;sleep 1; done
# MySQL 서버 파드(인스턴스) 2대 추가 : 기본값(serverInstances: 3, routerInstances: 1) >> 복제 그룹 멤버 정상 상태(그후 쿼리 분산)까지 다소 시간이 걸릴 수 있다(데이터 복제 등)
helm upgrade mycluster mysql-operator/mysql-innodbcluster --reuse-values --set serverInstances=5 --namespace mysql-cluster
# MySQL 라우터 파드 3대로 증가
helm upgrade mycluster mysql-operator/mysql-innodbcluster --reuse-values --set routerInstances=3 --namespace mysql-cluster
# 확인
kubectl get innodbclusters -n mysql-cluster
kubectl get pod -n mysql-cluster -l app.kubernetes.io/component=database
kubectl get pod -n mysql-cluster -l app.kubernetes.io/component=router
# MySQL 서버 파드(인스턴스) 1대 삭제 : 스테이트풀셋이므로 마지막에 생성된 서버 파드(인스턴스)가 삭제
됨 : PV/PVC 는 어떻게 될까요?
helm upgrade mycluster mysql-operator/mysql-innodbcluster --reuse-values --set serverInstances=4 --namespace mysql-cluster
#kubectl delete pvc -n mysql-clutser datadir-mycluster-4 # (옵션) PV는 어떻게 될까요?
# MySQL 라우터 파드 1대로 축소
helm upgrade mycluster mysql-operator/mysql-innodbcluster --reuse-values --set routerInstances=1 --namespace mysql-cluster
# 확인
kubectl get innodbclusters -n mysql-cluster
<5> 스케일 테스트
MySQL 서버 파드(인스턴스) / 라우터 파드 증가 및 감소해보기
1
# 현재 MySQL InnoDB Cluster 정보 확인 : 서버파드(인스턴스)는 3대, 라우터파드(인스턴스)는 1대
kubectl get innodbclusters -n mysql-cluster
NAME STATUS ONLINE INSTANCES ROUTERS AGE
mycluster ONLINE 3 3 1 17m
# 모니터링
while true; do kubectl exec -it myclient1 -- mysql -h mycluster.mysql-cluster -uroot -psakila -e 'SELECT VIEW_ID FROM performance_schema.replication_group_member_stats LIMIT 1;SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;'; date;sleep 1; done
# MySQL 서버 파드(인스턴스) 2대 추가 :
기본값(serverInstances: 3, routerInstances: 1) >> 복제 그룹 멤버 정상 상태(그후 쿼리 분산)까지 다소 시간이 걸릴 수 있다(데이터 복제 등)
mysql 서버 5대로 바꿔보자~
helm upgrade mycluster mysql-operator/mysql-innodbcluster --reuse-values --set serverInstances=5 --namespace mysql-cluster
# MySQL 라우터 파드 3대로 증가
업그레이드하자, reuse = 재사용 하면서 set 으로 파라미터를 변경하자. 라우터를 3대로
helm upgrade mycluster mysql-operator/mysql-innodbcluster --reuse-values --set routerInstances=3 --namespace mysql-cluster
# 확인
kubectl get innodbclusters -n mysql-cluster
kubectl get pod -n mysql-cluster -l app.kubernetes.io/component=database
kubectl get pod -n mysql-cluster -l app.kubernetes.io/component=router
# MySQL 서버 파드(인스턴스) 1대 삭제 : 스테이트풀셋이므로 마지막에 생성된 서버 파드(인스턴스)가 삭제됨 : PV/PVC 는 어떻게 될까요?
helm upgrade mycluster mysql-operator/mysql-innodbcluster --reuse-values --set serverInstances=4 --namespace mysql-cluster
# MySQL 라우터 파드 1대로 축소
helm upgrade mycluster mysql-operator/mysql-innodbcluster --reuse-values --set routerInstances=1 --namespace mysql-cluster
# 확인
kubectl get innodbclusters -n mysql-cluster
<6> mysql 오퍼레이터를 통해 스케쥴 백업 해보자.
pv , pvc 이용.
크론을 이용해
backupProfiles 설정을 통한 (스케줄) 백업 : PVCPersistentVolumeClaim 와 OCI ociObjectStorage 로 백업 가능 - 링크
MySQL InnoDB Cluster 에 backup 설정 추가 with Helm
# backup 관련 설정 정보 확인 : 5분 마다 백업 실행(스케줄)
kubectl describe innodbcluster -n mysql-cluster | grep Spec: -A12
Spec:
Backup Profiles:
Dump Instance:
Storage:
Persistent Volume Claim:
Claim Name: backup-pvc
Name: dump-instance-profile-pvc
Backup Schedules:
Backup Profile Name: dump-instance-profile-pvc
Delete Backup Data: false
Enabled: true
Name: schedule-inline
Schedule: */5 * * * *
# 모니터링 : 설정 후 최소 5분 이후에 결과 확인
watch -d kubectl get mysqlbackup,cronjobs,jobs -n mysql-cluster
# 백업 작업 정보 확인
kubectl get mysqlbackup -n mysql-cluster
NAME CLUSTER STATUS OUTPUT AGE
mycluster-schedule-inline220513170040 mycluster Completed mycluster-schedule-inline220513170040 14m
mycluster-schedule-inline220513170502 mycluster Completed mycluster-schedule-inline220513170502 10m
...
# 크론잡 cronjobs 확인 : backup 설정 시 자동으로 크론잡 설정됨
kubectl get cronjobs -n mysql-cluster
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
mycluster-schedule-inline-cb */5 * * * * False 0 119s 20m
# 잡 확인 : 실제로 수행 기록 확인
kubectl get jobs -n mysql-cluster
NAME COMPLETIONS DURATION AGE
mycluster-schedule-inline220513170040 1/1 4m40s 17m
mycluster-schedule-inline220513170502 1/1 17s 13m
...
# 백업으로 사용되는 PVC 확인 : 백업 수행 전까지는 Pending 상태였다가 한번이라도 실행 시 Bound 로 변경됨
kubectl get pvc -n mysql-cluster backup-pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
backup-pvc Bound pvc-b0b4f5b5-284a-48ac-b94b-c2dd1fa2cb7c 10Gi RWO local-path 15m
# 백업으로 사용되는 PVC 가 실제 저장되는 노드 확인
kubectl describe pvc -n mysql-cluster backup-pvc | grep selected-node
volume.kubernetes.io/selected-node: k8s-w3
# 백업으로 사용되는 PV 가 실제 저장되는 노드의 Path 확인
kubectl describe pv pvc-<YYY> | grep Path:
Path: /opt/local-path-provisioner/pvc-b0b4f5b5-284a-48ac-b94b-c2dd1fa2cb7c_mysql-cluster_backup-pvc
# 마스터노드에서 PV Path 디렉터리 내부 정보 확인 : 하위 디렉터리 1개씩이 매 5분 백업 시마다 생성
BNODE=<PV 저장노드>
BNODE=k8s-w3
BPATH=<PV 의 Path>
BPATH=/opt/local-path-provisioner/pvc-b0b4f5b5-284a-48ac-b94b-c2dd1fa2cb7c_mysql-cluster_backup-pvc
sshpass -p "Pa55W0rd" ssh -o StrictHostKeyChecking=no root@$BNODE ls $BPATH
mycluster-schedule-inline220513170040
mycluster-schedule-inline220513170502
mycluster-schedule-inline220513171002
...
sshpass -p "Pa55W0rd" ssh -o StrictHostKeyChecking=no root@$BNODE tree $BPATH
...(생략)...
└── mycluster-schedule-inline220513172502
├── @.done.json
├── @.json
├── @.post.sql
├── @.sql
├── @.users.sql
├── mysql_innodb_cluster_metadata.json
├── mysql_innodb_cluster_metadata.sql
├── mysql_innodb_cluster_metadata@async_cluster_members.json
├── mysql_innodb_cluster_metadata@async_cluster_members.sql
├── mysql_innodb_cluster_metadata@async_cluster_members@@0.tsv.zst
├── mysql_innodb_cluster_metadata@async_cluster_members@@0.tsv.zst.idx
├── mysql_innodb_cluster_metadata@async_cluster_views.json
├── mysql_innodb_cluster_metadata@async_cluster_views.sql
├── mysql_innodb_cluster_metadata@async_cluster_views@@0.tsv.zst
├── mysql_innodb_cluster_metadata@async_cluster_views@@0.tsv.zst.idx
├── mysql_innodb_cluster_metadata@clusters.json
├── mysql_innodb_cluster_metadata@clusters.sql
├── mysql_innodb_cluster_metadata@clusters@@0.tsv.zst
├── mysql_innodb_cluster_metadata@clusters@@0.tsv.zst.idx
...(생략)...
<7> MySQL 오퍼레이터를 활용한 데이터베이스 DR 구성
: 오퍼레이터로 DB Clone 후 DR 사이트에 클러스터 구성
https://github.com/HallsHolicker/k8s-doik-sturdy/blob/master/InnodbCluster-DR/Readme.md
<8> 삭제
1
mysql-cluster 와 PVC 삭제 후 아래 삭제
helm uninstall mycluster -n mysql-cluster
위 삭제 후 아래 pvc 삭제
kubectl delete pvc -n mysql-cluster --all
2
삭제 방안 : 장점(1줄 명령어로 완전 삭제), 단점(삭제 실행과 완료까지 SSH 세션 유지 필요)
eksctl delete cluster --name $CLUSTER_NAME && aws cloudformation delete-stack --stack-name $CLUSTER_NAME
<9> 도전과제
책 샘플 애플리케이션 : 방문자 사이트는 홈페이지에 대한 요청 사용자의 정보를 기록 (클라이언트IP, 백엔드서버, 시간) - Githubch05
# MySQL 배포
curl -s -O https://raw.githubusercontent.com/kubernetes-operators-book/chapters/master/ch05/database.yaml
kubectl apply -f database.yaml
# 백엔드 배포
curl -s -O https://raw.githubusercontent.com/kubernetes-operators-book/chapters/master/ch05/backend.yaml
kubectl apply -f backend.yaml
# 프론트엔드 배포
curl -s -O https://raw.githubusercontent.com/kubernetes-operators-book/chapters/master/ch05/frontend.yaml
kubectl apply -f frontend.yaml
# 프론트엔드 웹 접속
NODEPIP=$(curl -s ipinfo.io/ip)
NODEPORT=$(kubectl get svc visitors-frontend-service -o jsonpath={.spec.ports[0].nodePort})
echo -e "Visitors URL = http://$NODEPIP:$NODEPORT"
# MySQL 접속 확인 : MySQL 접속 계정 정보는 Secret 입력하였음 : 계정 visitors-user , 암호 visitors-pass
apt install mariadb-client -y
MYSQLIP=$(kubectl get pod -l tier=mysql -o jsonpath={.items[0].status.podIP})
mysql -h $MYSQLIP -uvisitors-user -pvisitors-pass -e "status;"
mysql -h $MYSQLIP -uvisitors-user -pvisitors-pass -e "show databases;"
mysql -h $MYSQLIP -uvisitors-user -pvisitors-pass -e "USE visitors_db;show tables;"
mysql -h $MYSQLIP -uvisitors-user -pvisitors-pass -e "USE visitors_db;SELECT * FROM service_visitor"
while true; do mysql -h $MYSQLIP -uvisitors-user -pvisitors-pass -e "SELECT * FROM visitors_db.service_visitor"; date; sleep 1; done
Mon May 23 05:36:21 KST 2022
+----+--------------+--------------+----------------------------+
| id | service_ip | client_ip | timestamp |
+----+--------------+--------------+----------------------------+
| 1 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:19:49.601245 |
| 2 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:20:21.448382 |
| 3 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:20:22.473153 |
| 4 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:20:23.246066 |
| 5 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:20:23.742947 |
| 6 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:20:24.153246 |
| 7 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:20:24.550975 |
| 8 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:20:24.922541 |
| 9 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:20:25.320265 |
| 10 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:20:25.716565 |
| 11 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:32:16.839118 |
| 12 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:32:18.730660 |
| 13 | 172.16.184.2 | 172.16.116.0 | 2022-05-22 20:32:22.519020 |
+----+--------------+--------------+----------------------------+
# 삭제
kubectl delete deploy,svc,secret --all
<10> sysbench 툴을 통한 MySQL 성능 측정 해보기 - GithubHoing사용기
https://flavono123.github.io/posts/sysbench-mysql-operator/
1
# 스터디 인원님 작성한 컨테이너 이미지를 사용했습니다 : help 정보 확인
kubectl run sysbench --image=vonogoru123/sysbench -it --restart=Never --rm -- sysbench --help
...
# 테스트는 내장된 lua 스크립트 사용 : help 정보로 옵션 확인
kubectl run sysbench --image=vonogoru123/sysbench -it --restart=Never --rm -- /usr/local/share/sysbench/oltp_read_only.lua help
# run 실행 옵션 예시
sysbench --db-driver=mysql \
--mysql-host=mycluster.mysql-cluster --mysql-port=3306
--mysql-user=sysbench --mysql-password=sysbench --mysql-db=sysbench \
--report-interval=1 --table-size=100000 --threads=4 --tables=2 \
/usr/local/share/sysbench/oltp_read_only.lua run
# 테스트를 위한 mysql 설정 : sysbench 계정 생성(+권한), sysbench 데이터베이스 생성
kubectl exec -it -n mysql-operator deploy/mysql-operator -- \
mysqlsh mysqlx://root@mycluster.mysql-cluster --password=sakila --sqlx \
-e "CREATE DATABASE IF NOT EXISTS sysbench;
CREATE USER IF NOT EXISTS 'sysbench'@'%' IDENTIFIED WITH 'mysql_native_password' BY 'sysbench';
GRANT ALL ON sysbench.* to 'sysbench'@'%';
FLUSH PRIVILEGES;"
# job 리소스 생성
cat ~/DOIK/2/sysbench-oltp-read-only.yaml
kubectl apply -f ~/DOIK/2/sysbench-oltp-read-only.yaml
# 모니터링(신규 터미널 2개 새용)
watch kubectl top node
while true; do mysql -h $MYSQLIP -uroot -psakila -e "SELECT TABLE_NAME, ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) 'Size in MB' FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'sysbench';" ; date; sleep 1; done
mysql -h $MYSQLIP -uroot -psakila -e "SELECT TABLE_NAME, ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) 'Size in MB' FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'test';"
+------------+------------+
| TABLE_NAME | Size in MB |
+------------+------------+
| sbtest1 | 68.59 |
| sbtest2 | 78.59 |
+------------+------------+
# 컨테이너 로그 확인
kubectl logs -f job/sysbench-oltp-read-only sysbench-prepare
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)
Initializing worker threads...
Creating table 'sbtest2'...
Inserting 1000000 records into 'sbtest2'
Creating table 'sbtest1'...
Inserting 1000000 records into 'sbtest1'
Creating a secondary index on 'sbtest2'...
Creating a secondary index on 'sbtest1'...
# run 컨테이너 로그를 확인해 벤치마크 보고서 작성
kubectl logs -f job/sysbench-oltp-read-only sysbench-run
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)
Running the test with following options:
Number of threads: 4
Report intermediate results every 10 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 10s ] thds: 4 tps: 111.86 qps: 1792.74 (r/w/o: 1568.62/0.00/224.12) lat (ms,95%): 51.94 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 4 tps: 116.10 qps: 1857.05 (r/w/o: 1624.96/0.00/232.09) lat (ms,95%): 47.47 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 4 tps: 116.42 qps: 1861.30 (r/w/o: 1628.45/0.00/232.85) lat (ms,95%): 48.34 err/s: 0.00 reconn/s: 0.00
[ 40s ] thds: 4 tps: 117.30 qps: 1878.58 (r/w/o: 1643.88/0.00/234.70) lat (ms,95%): 46.63 err/s: 0.00 reconn/s: 0.00
[ 50s ] thds: 4 tps: 114.88 qps: 1839.43 (r/w/o: 1609.66/0.00/229.77) lat (ms,95%): 50.11 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 4 tps: 117.32 qps: 1875.30 (r/w/o: 1640.66/0.00/234.64) lat (ms,95%): 46.63 err/s: 0.00 reconn/s: 0.00
[ 70s ] thds: 4 tps: 115.46 qps: 1849.62 (r/w/o: 1618.71/0.00/230.92) lat (ms,95%): 48.34 err/s: 0.00 reconn/s: 0.00
[ 80s ] thds: 4 tps: 116.48 qps: 1862.24 (r/w/o: 1629.27/0.00/232.97) lat (ms,95%): 47.47 err/s: 0.00 reconn/s: 0.00
[ 90s ] thds: 4 tps: 116.86 qps: 1871.22 (r/w/o: 1637.51/0.00/233.72) lat (ms,95%): 46.63 err/s: 0.00 reconn/s: 0.00
[ 100s ] thds: 4 tps: 117.60 qps: 1880.56 (r/w/o: 1645.35/0.00/235.21) lat (ms,95%): 45.79 err/s: 0.00 reconn/s: 0.00
[ 110s ] thds: 4 tps: 115.49 qps: 1847.52 (r/w/o: 1616.55/0.00/230.98) lat (ms,95%): 51.02 err/s: 0.00 reconn/s: 0.00
[ 120s ] thds: 4 tps: 117.73 qps: 1883.88 (r/w/o: 1648.42/0.00/235.46) lat (ms,95%): 46.63 err/s: 0.00 reconn/s: 0.00
[ 130s ] thds: 4 tps: 114.53 qps: 1833.07 (r/w/o: 1604.01/0.00/229.06) lat (ms,95%): 50.11 err/s: 0.00 reconn/s: 0.00
[ 140s ] thds: 4 tps: 115.51 qps: 1846.64 (r/w/o: 1615.62/0.00/231.02) lat (ms,95%): 47.47 err/s: 0.00 reconn/s: 0.00
[ 150s ] thds: 4 tps: 116.54 qps: 1865.79 (r/w/o: 1632.71/0.00/233.07) lat (ms,95%): 46.63 err/s: 0.00 reconn/s: 0.00
[ 160s ] thds: 4 tps: 114.36 qps: 1828.50 (r/w/o: 1599.78/0.00/228.71) lat (ms,95%): 50.11 err/s: 0.00 reconn/s: 0.00
[ 170s ] thds: 4 tps: 117.55 qps: 1880.53 (r/w/o: 1645.44/0.00/235.09) lat (ms,95%): 44.98 err/s: 0.00 reconn/s: 0.00
[ 180s ] thds: 4 tps: 118.39 qps: 1895.18 (r/w/o: 1658.49/0.00/236.68) lat (ms,95%): 45.79 err/s: 0.00 reconn/s: 0.00
SQL statistics:
queries performed:
read: 292712
write: 0
other: 41816
total: 334528
transactions: 20908 (116.13 per sec.)
queries: 334528 (1858.15 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 180.0314s
total number of events: 20908
Latency (ms):
min: 21.85
avg: 34.43
max: 156.55
95th percentile: 48.34
sum: 719952.96
Threads fairness:
events (avg/stddev): 5227.0000/103.18
execution time (avg/stddev): 179.9882/0.01
# 테스트 완료 후 job 상태 확인
kubectl describe job sysbench-oltp-read-only
kubectl get job
NAME COMPLETIONS DURATION AGE
sysbench-oltp-read-only 1/1 4m12s 4m29s
# 실습 완료 후 job 삭제
kubectl delete job sysbench-oltp-read-only
다음은
https://brunch.co.kr/@topasvga/3507
위 내용은 주말 CloudNet 스터디 내용 참고하여 정리한 부분입니다.
https://gasidaseo.notion.site/gasidaseo/CloudNet-Blog-c9dfa44a27ff431dafdd2edacc8a1863
감사합니다.
