brunch

매거진 Amazon EKS 스터디

라이킷 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Master Seo Oct 25. 2023

EKS 9탄-6. EKS DB-워드프레스DB-6/18

앞에서 만든 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 성능 측정 해보기 - Github Hoing 사용기

<1> 워드프레스 설치

https://artifacthub.io/packages/helm/bitnami/wordpress

wordpress 18.0.8 · bitnami/bitnami

WordPress is the world's most popular blogging and content management platform. Powerful yet simple, everyone from students to global corporations use it to build beautiful, functional websites.

artifacthub.io

백단에 설치된 이노디비를 사용한다.

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

# 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대가 나누어 진다.

# 파라미터 파일 생성

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

# 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대 강제 삭제 및 동작 확인

프라이머리 파드가 어느 노드에 있는지 확인

# 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개로 각각 모니터링 한다.

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 실행하자

확인?

글 써보자~~

잘 되는가?

데이터 동기화도 된다!

참고

https://malwareanalysis.tistory.com/343?category=1099737

쿠버네티스 오퍼레이터 스터디 2주차 - mysql operator 장애테스트

이 글은 mysql operator 장애 테스트를 다룹니다. 1. 장애 테스트 시나리오 시나리오1: pod레벨 장애 데이터 삽입도중에 pod를 삭제 시나리오2: node레벨 장애 node drain을 실행하여 mysql 쿠버네티스 리소스

malwareanalysis.tistory.com

<3> [장애2] MySQL 서버 파드(인스턴스) 가 배포된 노드 1대 drain 설정 및 동작 확인

노드 1대의 장애를 일으켜 보자.

워커 노드가 3개.

노드 1대가 보안패치로 1대 작업해야 하는 경우 발생.

파드를 다른 노드로 이동시키는 (드레인) 것을 한다.

워드프레스 정상 접속 및 포스팅 작성 가능, 데이터베이스에 반복해서 INSERT 시도

노드를 재부팅해야 하는 상황.

파드를 다른 노드로 쫓아 낸다.

# 모니터링 : 터미널 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 --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 서버 파드(인스턴스) / 라우터 파드 증가 및 감소해보기

# 현재 MySQL InnoDB Cluster 정보 확인 : 서버파드(인스턴스)는 3대, 라우터파드(인스턴스)는 1대

kubectl get innodbclusters -n mysql-cluster

NAME STATUS ONLINE INSTANCES ROUTERS AGE

mycluster ONLINE 3 3 1 17m

# 모니터링

# 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 서버 파드(인스턴스) / 라우터 파드 증가 및 감소해보기

# 현재 MySQL InnoDB Cluster 정보 확인 : 서버파드(인스턴스)는 3대, 라우터파드(인스턴스)는 1대

kubectl get innodbclusters -n mysql-cluster

NAME STATUS ONLINE INSTANCES ROUTERS AGE

mycluster ONLINE 3 3 1 17m

# 모니터링

# 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> 삭제

mysql-cluster 와 PVC 삭제 후 아래 삭제

helm uninstall mycluster -n mysql-cluster

위 삭제 후 아래 pvc 삭제

kubectl delete pvc -n mysql-cluster --all

삭제 방안 : 장점(1줄 명령어로 완전 삭제), 단점(삭제 실행과 완료까지 SSH 세션 유지 필요)

eksctl delete cluster --name $CLUSTER_NAME && aws cloudformation delete-stack --stack-name $CLUSTER_NAME

<9> 도전과제

책 샘플 애플리케이션 : 방문자 사이트는 홈페이지에 대한 요청 사용자의 정보를 기록 (클라이언트IP, 백엔드서버, 시간) - Github ch05

# 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

+----+--------------+--------------+----------------------------+

+----+--------------+--------------+----------------------------+

| 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 성능 측정 해보기 - Github Hoing 사용기

https://flavono123.github.io/posts/sysbench-mysql-operator/

# 스터디 인원님 작성한 컨테이너 이미지를 사용했습니다 : 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:

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

위 내용은 주말 CloudNet 스터디 내용 참고하여 정리한 부분입니다.

https://gasidaseo.notion.site/gasidaseo/CloudNet-Blog-c9dfa44a27ff431dafdd2edacc8a1863

다음은

https://brunch.co.kr/@topasvga/3507

7. EKS DB - PostgreSQL설치 1/3

2023년 현재 Mysql보다 PstgreSQL이 지원이 더 잘 된다. 목표 PostgreSQL 설치법 알아보자 PostgreSQL 사용법 알아보자 CloudNativePG 사용해보자 <1> 기본 - 우분트에 PostgreSQL 설치하기 <2> 기본 - PostgreSQL 사용하

brunch.co.kr/@topasvga/3507

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari

brunch

EKS 9탄-6. EKS DB-워드프레스DB-6/18

<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> 워드프레스 설치

<2> [장애1] MySQL 서버 파드(인스턴스) 1대 강제 삭제 및 동작 확인

<3> [장애2] MySQL 서버 파드(인스턴스) 가 배포된 노드 1대 drain 설정 및 동작 확인

<4> MySQL 서버 파드(인스턴스) / 라우터 파드 증가 및 감소해보기

<5> 스케일 테스트

<6> mysql 오퍼레이터를 통해 스케쥴 백업 해보자.

<7> MySQL 오퍼레이터를 활용한 데이터베이스 DR 구성

<8> 삭제

<9> 도전과제

<10> sysbench 툴을 통한 MySQL 성능 측정 해보기 - GithubHoing사용기

다음은

<10> sysbench 툴을 통한 MySQL 성능 측정 해보기 - Github Hoing 사용기

<10> sysbench 툴을 통한 MySQL 성능 측정 해보기 - Github Hoing 사용기