mysqldump로 백업을 진행하다 보니 테스트 기회가 생겨 테스트를 진행해 보았다.


sql파일을 바로 Import 진행하니 중간에 세션이 끊기거나 한다면 ㅊㅓ음부터 다시 진행해야하는 불상사가 발생해서.

검색 도중 innodb를 myisam으로 변경 후 진행하는 방식을 추천해 주어 진행해 보았다.


기본 테스트 테이블의 정보는 아래와 같다.


2번째 테이블이 대상이고 빈 테이블에 myisam으로 변경 후



68,769,549 건을 진행했다.



시간을 보면 알 수 있듯이

대략 7시간 정도 소요 되었다.

(메모리는 32G 기준 )


참고로, 동일 테이블에 동일 방식으로 innodb를 진행하였을 경우 10시간 이상 진행해도 끝나지 않았다.


이렇게 되면 MyISAM 으로 변경 후 진행해야 되는 걸까??

이 부분에 대해서 추가 작업이 있음을 인지하고 있어야 한다.


해당 테이블을 MyISAM 에서 InnoDB로 Storage 엔진을 또 변경해야 된다는 것이다.

데이터가 없을 때에는 바로 변경이 된다.


하지만 데이터가 있을 경우 temp 테이블에 추가하였다가 진행해야 되기에 시간이 만만치 않게 소요 된다.



아쉽게도 정확한 측정을 못했지만 대략 4시간 정도 소요 되었다.


약 7억건의 데이터를 옮기는데 이정도 소요된다.


다시 한번 21건에 대해서 진행 중인데, 정확한 수치를 알고 있어야 될 듯 싶으며,

이번 기회를 통해 백업 방식을 xtrabackup으로 테스트 및 변경을 고려 해 봐야 할 듯 싶다.


반응형

좋은 정보가 있어서 공유 합니다.


https://www.cockroachlabs.com/docs/stable/cockroachdb-in-comparison.html#yes-feedback





CockroachDB in Comparison

 CONTRIBUTE 
This page shows you how key features of CockroachDB stack up against other databases. Hover over features for their intended meanings, and click CockroachDB answers to view related documentation.

CockroachDBMySQLPostgreSQLOracleSQL ServerCassandraHBaseMongoDBDynamoDBSpanner
Automated ScalingYesNo No No No Yes Yes Yes Yes Yes
Automated FailoverYesOptional Optional Optional Optional Yes Yes Yes Yes Yes
Automated RepairYesNo No No No Yes Yes Yes Yes Yes
Strongly Consistent ReplicationYesNo No Optional Optional Optional No No Yes Yes
Consensus-Based ReplicationYesNo No No No Optional No No Yes Yes
Distributed TransactionsYesNo No Yes Yes No No No No* Yes
ACID SemanticsYesYes Yes Yes Yes No Row-only Document-only Row-only* Yes
Eventually Consistent ReadsNo Yes Yes Yes Yes Yes Yes Yes Yes Yes
SQLYesYes Yes Yes Yes No No No No Read-only
Open SourceYesYes Yes No No Yes Yes Yes No No
Commercial VersionOptional Optional No Yes Yes Optional Optional Optional Yes Yes
SupportFullFull Full Full Full Full Full Full Full Full

* In DynamoDB, distributed transactions and ACID semantics across all data in the database, not just per row, requires an additional transaction library.


반응형

'MySQL' 카테고리의 다른 글

[MySQL] InnoDB Adaptive Hash index [펌]  (0) 2018.04.16
[MySQL] ARCHIVE Engine  (0) 2017.07.19
[펌] [MyISAM] myisamchk 사용하기  (0) 2016.11.25
[MySQL] auto_increment duplicate entry for key 1  (0) 2016.11.14
[MySQL] MS SQL to MySQL Migration  (3) 2016.11.09

MariaDB로 누가 접속 했는지 어떠한 행동을 했는지 확인을 위해서 Audit를 테스트 진행해 보았다.


진행 방식은 다음과 같다.


1. 지속적으로 로그인 성공 및 시간 조회 / 로그인 암호 실패 

2. 지속적으로 Sysbench를 이용하여 10000000 건의 테이블에 대해 select 진행 

3. 이 부분에 대해 cpu / Disk IO / QPS 등을 체크


처음에는 이와 같은 방식으로 지속적으로 체크를 한다.


이후 Audit을 on으로 한 이후에 (로그를 남김) 해당 부하들의 변화률을 체크 하기로 하자.




참고로 Audit 은 아래 블로그를 참고해서 플러그인을 설치하자. 

직접 올려도 되지만 더 자세하게 잘 알려준 블로그가 오히려 좋을 듯 싶다.



1. 지속적으로 로그인 아웃을 하는 스크립트는 파이썬을 이용했다. Thread를 이용하면 좋겠지만...간단하게 개발하기 위해서..내 실력이 안되기에..ㅠ


#-*- coding:utf-8 -*-

import pymysql
import time

def LoginSucess(tp=''):
db = pymysql.connect(host='192.168.0.1', port=int(3306), user='root', passwd='root', db='mysql',
autocommit=True, use_unicode=True, charset="utf8")
if tp.lower() == 'dict':
cursor = db.cursor(pymysql.cursors.DictCursor)
else:
cursor = db.cursor()
query = """
SELECT now();
"""
cursor.execute(query)
row = cursor.fetchone()
print(row)

def LoginFail(tp =''):
try:
db = pymysql.connect(host='192.168.0.1', port=int(3306), user='root', passwd='1234', db='mysql',
autocommit=True, use_unicode=True, charset="utf8")
if tp.lower() == 'dict':
cursor = db.cursor(pymysql.cursors.DictCursor)
else:
cursor = db.cursor()

except Exception as e:
print(str(e))


if __name__ == "__main__" :
while True :
LoginSucess()
LoginFail()
time.sleep(1)


- 여기서는 지속적으로 돌면서 로그인 아웃을 시도한다....mysql close하는 부분이 없네.......OTL


2. Sysbench를 이용해서 다른 서버에서 해당 서버로 스트레스 테스트를 진행하는 것이다.


- 데이터 추가를 먼저 진행하자
sysbench --test=/usr/local/Cellar/sysbench/1.0.6/share/sysbench/tests/include/oltp_legacy/oltp_simple.lua --num-threads=8 \
--mysql-host=db1 --mysql-user=root --mysql-password='root' \
--mysql-table-engine=innodb --db-driver=mysql \
--mysql-engine-trx=yes \
--oltp-table-size=10000000 \
--oltp-test-mode=complex --max-requests=10000 \
--oltp-read-only=off \
prepare

- 데이터 실행 (while문으로 계속 실행)

while true; do
sysbench --test=/usr/local/Cellar/sysbench/1.0.6/share/sysbench/tests/include/oltp_legacy/oltp_simple.lua --num-threads=8 \
--mysql-host=db1 --mysql-user=root --mysql-password='root' \
--mysql-table-engine=innodb --db-driver=mysql \
--mysql-engine-trx=yes \
--oltp-table-size=10000000 \
--oltp-test-mode=complex --max-requests=10000 \
--max-time=4 \
--oltp-read-only=off \
--db-ps-mode=disable \
run
sleep 1

done


주석을 달아 놨듯이.. 처음에는 10,000,000 건을 Insert 이후에 해당 건을 while문이 돌면서 지속적으로 스트레스를 주는 것이다.


왜 while로 했냐면 해당 가상 머신 사양이 좋지 않아 CPU를 100%로 만들지 않으면서도 지속적인 스트레스를 주기 위함이다..

CPU를 100%하면 이후에 어떠한 반응도 체크를 하기 힘들기에 나는 적정선이 70%내를 유지하기 위함이다.


이렇게 한 후 이제 CPU와 QPS등을 체크를 해보자.

체크하는 것은 또한 Python을 이용하였다.



보는 바와 같이 QPS / CPU 등이 일정한 것을 확인할 수 있다...아쉬운 건 Disk I/O를 발생시키지 못한 점이다...


이제는 Audit을 ON으로 한 후 다시 진행 해 보자.


Audit을 제대로 설치 하였다면 아래와 같이 진행할 수 있다.


MariaDB [(none)]> show global status like 'server_audit%';

MariaDB [(none)]> set global server_audit_logging = on;


정상적으로 로그가 남기고 있는지 확인해 보자


따로 경로를 설정하지 않았다면, Data폴더에 가면 확인할 수 있다.

Data폴더에서는 일정 크기의 로그가 쌓이면 자동 백업을 진행하게 된다.

아래 일부를 캡쳐했는데, 유저 / 어디서 들어오는지..쿼리는 어떤것을 남기는지 확인할 수 있다.


여기까지 진행하고 DB / OS 상황을 보자.


별다른 특이 사항은 없어 보인다.


이제는 위와 같은 방법으로 로그인 성공 / 실패 를 하는 스크립트를 실행하고, 추가로 스트레스 테스트도 진행하자.

이렇게 어느정도의 스트레스가 완료 되었다면 둘을 비교해 보자.


비교는 ipython Jupyter를 이용하였다. 추가로 matplotlib을 이용하여 둘의 결과를 그래프로 표현해 보았다.


파란색 선이 Audit 을 Off로 한 후에 진행한 그래프이며, 녹색 선이 Audit 을 On 으로 한 후 진행 하였다.

결과를 보면 큰 차이가 없는 것을 확인할 수 있다.





간단한 결과만 보고 Audit을 On으로 한다고 부하가 발생ㅎㅏ지 않는다고 단정할 수 없다.

8 쓰레드로 진행하였으며(sysbench에서 8쓰레드로 명시했지만 제대로 됬는지는 확인을 못했다..), session도 30 내외로 진행하였기 때문에 더더욱 실제 운영에는 적용할 수 없다.


하지만 간단하게 테스트한 부분이기에 이 부분을 조금 더 보완하여 진행 한다면 분명 좋은 결과를 도출해 낼 수 있을 것이다.

반응형

+ Recent posts