MySQL 소개
간략한 소개
version history
MySQL 사용처
제품 군 변화
시장 변화
MySQL 구성
MySQL 클라이언트 / 서버 개념
클라이언트 프로그램
MySQL 설치
MySQL 버전
MySQL 설치
MySQL 환경 설정
환경설정, 변수 설정
MySQL 스토리지 엔진 소개
MySQL tuning 소개 및 방법
데이터 백업/복구 방법
백업
복구
MySQL Upgrade
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
The document discusses two MySQL high availability solutions: MySQL InnoDB Cluster and MySQL NDB Cluster. MySQL InnoDB Cluster provides easy high availability built into MySQL with write consistency, read scalability, and application failover using MySQL Router. MySQL NDB Cluster is an in-memory database that provides automatic sharding, native access via several APIs, read/write consistency, and read/write scalability using the NDB storage engine. The document compares the two solutions and discusses their architectures and key features.
MaxScale is a database proxy that provides high availability and scalability for MariaDB servers. It can be used to configure load balancing of read/write connections, auto failover/switchover/rejoin using MariaDB GTID replication. Keepalived can be used with MaxScale to provide high availability by monitoring MaxScale and failing over if needed. The document provides details on setting up MariaDB replication with GTID, installing and configuring MaxScale and Keepalived. It also describes testing the auto failover functionality.
MySQL Database Architectures - MySQL InnoDB ClusterSet 2021-11Kenny Gryp
Oracle's MySQL solutions make it easy to setup various database architectures and achieve high availability with the introduction MySQL InnoDB Cluster and MySQL InnoDB ReplicaSet meeting various high availability requirements. MySQL InnoDB ClusterSet provides a popular disaster recovery solution.
Completely built in-house and supported by Oracle, many enterprises large and small have adopted these solutions into business critical applications.
In this presentation the various database architecture solutions for high availability and disaster recovery will be covered and help you choose the right solutions based on your business requirements.
The document discusses MySQL Group Replication, which is a plugin that provides multi-master replication capability for MySQL. It allows data to be replicated between multiple MySQL servers so that they can stay in sync. The replication works by having each server send transaction writesets to other servers through a group communication system, and then each server certifies and applies the changes locally in an asynchronous manner.
24시간 365일 서비스를 위한 MySQL DB 이중화.
MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다.
목차
1. DB 이중화 필요성
2. 이중화 방안
- HW 이중화
- MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교
대상
- MySQL을 서비스하고 있는 인프라 담당자
- MySQL 이중화에 관심 있는 개발자
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
High Availability in MySQL 8 using InnoDB ClusterSven Sandberg
InnoDB Cluster is the built-in and open-source High Availability solution for MySQL 8. It consists of three components. The engine is MySQL Group Replication: the highly available cluster of database servers. This is where your data is safe and available, due to the replicated state machine, relying on the famous Paxos protocol. At the driver's seat is MySQL Shell: the DevOp's multilingual console. Here you can deploy, query, and arrange your cluster using either Javascript or Python, to your taste. Your application is welcomed to join the ride by connecting to MySQL Router: the intelligent, seamless interface to the cluster. We introduce all three components, with a special focus on Group Replication.
MySQL InnoDB Cluster - A complete High Availability solution for MySQLOlivier DASINI
MySQL InnoDB Cluster provides a complete high availability solution for MySQL. It uses MySQL Group Replication, which allows for multiple read-write replicas of a database to exist with synchronous replication. MySQL InnoDB Cluster also includes MySQL Shell for setup, management and orchestration of the cluster, and MySQL Router for intelligent connection routing. It allows databases to scale out writes across replicas in a fault-tolerant and self-healing manner.
Wars of MySQL Cluster ( InnoDB Cluster VS Galera ) Mydbops
MySQL Clustering over InnoDB engines has grown a lot over the last decade. Galera began working with InnoDB early and then Group Replication came to the environment later, where the features are now rich and robust. This presentation offers a technical comparison of both of them.
PostgreSQL uses MVCC which creates multiple versions of rows during updates and deletes. This leads to bloat and fragmentation over time as unused row versions accumulate. The VACUUM command performs garbage collection to recover space from dead rows. HOT updates and pruning help reduce bloat by avoiding index bloat during certain updates. Future improvements include parallel and eager vacuuming as well as pluggable storage engines like zheap to further reduce bloat.
MaxScale is a database proxy that provides high availability and scalability for MariaDB servers. It can be used to configure load balancing of read/write connections, auto failover/switchover/rejoin using MariaDB GTID replication. Keepalived can be used with MaxScale to provide high availability by monitoring MaxScale and failing over if needed. The document provides details on setting up MariaDB replication with GTID, installing and configuring MaxScale and Keepalived. It also describes testing the auto failover functionality.
MySQL Database Architectures - MySQL InnoDB ClusterSet 2021-11Kenny Gryp
Oracle's MySQL solutions make it easy to setup various database architectures and achieve high availability with the introduction MySQL InnoDB Cluster and MySQL InnoDB ReplicaSet meeting various high availability requirements. MySQL InnoDB ClusterSet provides a popular disaster recovery solution.
Completely built in-house and supported by Oracle, many enterprises large and small have adopted these solutions into business critical applications.
In this presentation the various database architecture solutions for high availability and disaster recovery will be covered and help you choose the right solutions based on your business requirements.
The document discusses MySQL Group Replication, which is a plugin that provides multi-master replication capability for MySQL. It allows data to be replicated between multiple MySQL servers so that they can stay in sync. The replication works by having each server send transaction writesets to other servers through a group communication system, and then each server certifies and applies the changes locally in an asynchronous manner.
24시간 365일 서비스를 위한 MySQL DB 이중화.
MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다.
목차
1. DB 이중화 필요성
2. 이중화 방안
- HW 이중화
- MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교
대상
- MySQL을 서비스하고 있는 인프라 담당자
- MySQL 이중화에 관심 있는 개발자
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
High Availability in MySQL 8 using InnoDB ClusterSven Sandberg
InnoDB Cluster is the built-in and open-source High Availability solution for MySQL 8. It consists of three components. The engine is MySQL Group Replication: the highly available cluster of database servers. This is where your data is safe and available, due to the replicated state machine, relying on the famous Paxos protocol. At the driver's seat is MySQL Shell: the DevOp's multilingual console. Here you can deploy, query, and arrange your cluster using either Javascript or Python, to your taste. Your application is welcomed to join the ride by connecting to MySQL Router: the intelligent, seamless interface to the cluster. We introduce all three components, with a special focus on Group Replication.
MySQL InnoDB Cluster - A complete High Availability solution for MySQLOlivier DASINI
MySQL InnoDB Cluster provides a complete high availability solution for MySQL. It uses MySQL Group Replication, which allows for multiple read-write replicas of a database to exist with synchronous replication. MySQL InnoDB Cluster also includes MySQL Shell for setup, management and orchestration of the cluster, and MySQL Router for intelligent connection routing. It allows databases to scale out writes across replicas in a fault-tolerant and self-healing manner.
Wars of MySQL Cluster ( InnoDB Cluster VS Galera ) Mydbops
MySQL Clustering over InnoDB engines has grown a lot over the last decade. Galera began working with InnoDB early and then Group Replication came to the environment later, where the features are now rich and robust. This presentation offers a technical comparison of both of them.
PostgreSQL uses MVCC which creates multiple versions of rows during updates and deletes. This leads to bloat and fragmentation over time as unused row versions accumulate. The VACUUM command performs garbage collection to recover space from dead rows. HOT updates and pruning help reduce bloat by avoiding index bloat during certain updates. Future improvements include parallel and eager vacuuming as well as pluggable storage engines like zheap to further reduce bloat.
2021년 11월 18일(목)
- 14:00 ~ 15:00 MySQL Operator for Kubernetes
: Kubernetes 환경에서 MySQL에 대한 더 쉬운 운영
- 15:00 ~ 15:15 MySQL HA and Auto-Failover
: MySQL replication과 오픈소스 MHA를 통한 고가용성 확보
- MariaDB 소개
- MariaDB 서버 구성 및 아키텍처 이해
- MariaDB 스토리지 엔진
- MariaDB 데이터베이스 관리
- 트랜잭션 / Locking 의 이해
- MariaDB 보안
- 백업과 복구를 통한 데이터베이스 관리
- MariaDB upgrade
- MariaDB 모니터링
- MySQL 에서 MariaDB 로의 전환
공유 스토리지를 이용한 H/A Cluster 뿐만 아니라
Replication을 이용한 Shared Nothing H/A Cluster 제공
내장된 Application 인지형의 고가용성 기능 제공
DB에 대하여 이중으로 Check 하는 Depth 모니터링 기능
30개의 주요한 Applications 지원
Just Model It 이벤트에서 사용할 Backend.AI 에 관한 소개입니다. Backend.AI의 개괄, 주요 기능 및 사용예들을 다룹니다. 또한 Backend.AI 를 이용한 End-to-end ML model 개발 시나리오도 소개합니다.
An Introduction to Backend.AI to use in Just Model It event. It covers the overview of Backend.AI, its main features and examples. It also introduces the scenario of developing end-to-end ML model using Backend.AI.
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
기존에 저희 회사에서 사용하던 모니터링은 Zabbix 였습니다.
컨테이너 모니터링 부분으로 옮겨가면서 변화가 필요하였고, 이에 대해서 프로메테우스를 활용한 모니터링 방법을 자연스럽게 고민하게 되었습니다.
이에 이영주님께서 테크세션을 진행하였고, 이에 발표자료를 올립니다.
5개의 부분으로 구성되어 있으며, 세팅 방법에 대한 내용까지 포함합니다.
01. Prometheus?
02. Usage
03. Alertmanager
04. Cluster
05. Performance
2018년도 Amazon AWS re:Invent Machine Learning 부분에 대한 요약을 오픈소스컨설팅 서경빈(AWS SA)님이 해주셨습니다.
사내 발표 때 아주 쉽게 설명해주셔서 좋았는데, 해당 내용은 Tech Blog에서도 확인이 가능합니다.
https://tech.osci.kr/2018/12/06/50693623/
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트Ji-Woong Choi
Docker를 활용하여 Gitlab CI/CD 설치 구성 및 샘플 테스트를 위한 가이드 문서이며, Docker 및 Gitlab에 대한 개요 및 사용법에 대해서는 다루지 않습니다. Docker image를 이용 Gitlab 및 Gitlab CI/CD 설치 및 구성 후 Sample Spring boot web application을 이용하여 소스 변경에 따른 commit이 발생 했을 때 Gitlab CI/CD 기능을 통해 application 테스트, 빌드, 배포까지의 일련의 과정이 자동으로 진행되는지를 테스트 하는 내용입니다.
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항Ji-Woong Choi
Cloud 기반으로 U2C(Unix to Cloud),U2L(Unix to Linux) 마이그레이션에 대한 가이드 라인과 사이징 관련 고려 사항에 대해 설명한 자료입니다.
많은 전환 프로젝트에서 추출된 경험치가 들어가 있으며, 전환별 난이도 및 고려사항이 들어가 있습니다.
장소 : 미국 보스턴 Hynes Convention Center
일시 : 2017년 5월 6일 ~ 11일 (미국 동부 시각)
참가 인원 : 5000명 이상
참가 업체 : 1014개
참가국 : 63개국
세션 수 : 750여 개(이전 Summit 대비 약 250여 개 증가)
[오픈소스컨설팅] Red Hat ReaR (relax and-recover) Quick GuideJi-Woong Choi
본 문서는 RHEL에 내장된 재해복구솔루션 ReaR (Relax and Recover)를 이용하여 OS 영역의 데이터를 백업하고 복구하는 방법을 다루고 있습니다. ReaR는 iso를 비롯한 다양한 백업 데이터 포맷을 지원하나, 이 문서에서는 CD/DVD 미디어 반입/보관이 보안상 대부분 허용되지 않는 기업 환경에서도 원활히 사용할 수 있는 PXE boot를 지원하는 포맷으로 ReaR 백업 데이터를 생성하고 복구하는 방법만을 자세히 설명합니다.
[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-RegionJi-Woong Choi
OpenStack Ceph & Neutron에 대한 설명을 담고 있습니다.
1. OpenStack
2. How to create instance
3. Ceph
- Ceph
- OpenStack with Ceph
4. Neutron
- Neutron
- How neutron works
5. OpenStack HA- controller- l3 agent
6. OpenStack multi-region
아틀라시안 JIRA를 사용할 때 가장 핵심적으로 해야 할 내용들만 추려서 가이드 문서를 작성하였습니다.
그러한 작업들로는 프로젝트, 스킴(Scheme), 이메일 세팅, 권한 관리, 백업/복구 등이 있습니다.
관리자가 이런 일을 잘 할 수 있도록 핵심적인 내용만으로 구성한 문서를 공유합니다.
레드햇 엔터프라이즈 리눅스 7 기반에 대한 운영자 가이드 기초편을 공유합니다.
부트로더 관리, 패키지, 네트워크, 스토리지 및 크래쉬 덤프 발생에 대한 관리까지 기초 운영 지식에 대한 부분을 본 문서를 통해 얻으실 수 있습니다.
오픈소스컨설팅의 문경윤차장께서 공유해주신 내용입니다.
2. 2
- Internal Use Only -
회사 소개
오픈소스 컨설팅은 오픈 소스에 전문적인 컨설팅 기업으로써 Technical
Architect/Application Architect 컨설팅, 클라우드 관련 솔루션을 제공하고 있으며, 레드햇과
같은 오픈소스 벤더의 솔루션의 기술지원 사업을 수행합니다.
오픈소스 컨설팅은 오픈소스 운영체제/웹서버/미들웨어를 전문적으로 지원
하는 회사입니다. 또한 시스템 인프라, 개발 인프라를 위한 TA/AA에 대한
컨설팅 서비스를 지원하고 있으며, Athena 제품군을 보유하고 있습니다.
Solution
• Athena SQS
• Athena Provisioning
• Athena Monitoring
• Other Solution Frameworks
Consulting
• 시스템 아키텍처 컨설팅
• Amazon AWS 컨설팅
• Technical/Application Architect
• Middleware/Linux Dedicated Engineer
Technical
Support
• Red Hat Linux, Virtualization
• Red Hat JBoss Middleware
• Apache Web Server, Tomcat
• MySQL/MariaDB/Percona
컨설팅 영역 오픈소스 기술지원
솔루션 영역
4. 4
- Internal Use Only -
목차
MySQL 소개
간략한 소개
version history
MySQL 사용처
제품 군 변화
시장 변화
MySQL 구성
MySQL 클라이언트 / 서버 개념
클라이언트 프로그램
MySQL 설치
MySQL 버전
MySQL 설치
MySQL 환경 설정
환경설정, 변수 설정
MySQL 스토리지 엔진 소개
MySQL tuning 소개 및 방법
데이터 백업/복구 방법
백업
복구
MySQL Upgrade
6. 6
- Internal Use Only -
MySQL 소개 MySQL 은 세계에서 가장 많이 쓰이는 오픈 소스 관계형 데이터베이스 관리 시스템(RDBMS)
•빠른 성능과 쉬운 사용자 구성
•다중 스레드, 다중 사용자 형식의 구조 질의어 형식
•이중 라이선스 ( GPL, 상용 라이선스 )
•다수의 API 제공 PHP, Perl, 파이썬, 자바, .NET, MyODBC, Ruby , delphi , MySQL C 커넥터….
•플랫폼에 대한 자유
•크로스 플랫폼 지원
•수 많은 커뮤니티 인프라
MySQL에 대한 간략한 소개
7. 7
- Internal Use Only -
MySQL version history
1994년 MySQL의 원 개발 1995년 5월 최초의 국제화판 1998년 1월 8일 www.mysql.com 에서 출시 2004년 10월 4.1 출시
•R 트리와 B 트리, 서브쿼리, prepared statements 지원 2005년 10월 5.0 제품 출시
•커서, 저장 프로시저, 트리거, 뷰, XA 트랜잭션 지원 2008년 11월 27일 5.1 출시
•이벤트 스케줄러, 파티셔닝, 플러그인 API, 열 기반의 복제, 서버 로그 테이블 2010년 12월 5.5 성능 향상과 특징
•기본 스토리지 엔진이 InnoDB이며, 이것은 트랜잭션과 참조 무결성 제한을 지원한다.
•개선된 InnoDB I/O 서브시스템
•향상된 SMP 지원
•Semi synchronous 복제
•SQL 표준에 대응한 SIGNAL 과 RESIGNAL 구문
•유니코드 문자 셋 utf16, utf32, utf8mb4 지원
•사용자 정의 파티셔닝에 대한 새로운 옵션
이슈로 살펴 본 MySQL history
9. 9
- Internal Use Only -
MySQL 제품 군 변화
provider
오픈 소스 시장에서의 MySQL 제품 군의 변화
개발지침 등에 대한 의견 차이
2009년 Monty Program AB사를 설립하고 MariaDB 개발 시작
provider
10. 10
- Internal Use Only -
MariaDB 시장변화
Oracle에 대한 MySQL 사용자들의 입장변화
2009년 12월 설문 결과에 따르면, MySQL 사용자들은 Oracle의 MySQL 인수에 대한 입장이 '변화 없음(No Change)'에 60% 이상이었으나, 2013년 초 설문 결과에 따르면 '변화 없음(No Change)'이 45%, '덜 쓰겠다(Less likely to use MySQL)'가 47% 수준으로 과거에 비해 MySQL 사용자들은 Oracle사의 인수에 대해 부정적 견해가 더 많아진 것
11. 11
- Internal Use Only -
MariaDB 시장변화
MySQL 제품 군들의 시장 변화
MySQL 생태계 내에서 Oracle MySQL의 비중이 점점 줄어들고 있다는 결과이다. 2012년 MySQL, MariaDB, Percona 3개 제품 중 압도적으로 높은 비율(91%)을 보인 MySQL은, MySQL로부터 분기(fork)된 다양한 Eco 제품 군의 선전으로 인해 2013년 점유율이 62%로 감소되었고, 2018년에는 무려 50% 미만으로 예측하고 있다.
13. 13
- Internal Use Only -
MySQL 구성
MySQL 클라이언트 / 서버 개념
mysqld
데이터베이스 엑세스 관리
멀티 스레드 접속
멀티 스토리지 엔진 지원
서버와 호스트
TCP/IP
데이터베이스 엑세스 툴
데이터를 질의/수정/삭제 하거나 반환하기 위해 그 서버에 접속하는 프로그램
일반 클라이언트/GUI 프로그램
상용, free
Client
15. 15
- Internal Use Only -
MySQL 버전
MySQL 버전 별 차이점
Version
Features
추가
변경
삭제
5.5
MyISAM 대신 InnoDB가 MySQL의 기본 스토리지 엔진으로 채택
5.4.2
Plugin버전의 InnoDB가 Built-in 버전으로 다시 적용
5.1.38
InnoDB Plugin
5.1.24
"SHOW PROFILE"
(Enterprise version)
5.1.12
"general log" 파라미터
General query log를 동적으로 변경 가능
5.1.8
"Mixed" 복제 모드
5.1.6
Partition pruning 기능
5.1.5
EXPLAIN PARTITIONS(파티션 테이블의 실행 계획) 지원
"RBR"(Row Based Replication) 복제 모드
5.1
Plugin API 도입
Plugin버전의 InnoDB 릴리즈 (InnoDB 의 많은 성능 개선과 변화가 있음)
BDB 스토리지 엔진
5.0.32
(Community version)
"SHOW PROFILES"
5.0.7
LIMIT의 파라미터도 PreparedStatement에서 변수화 가능
5.0.5
BIT 데이터 타입이 MEMORY, InnoDB, BDB, NDBCLUSTER 스토리지 엔진에 구현됨
16. 16
- Internal Use Only -
Version
Features
추가
변경
삭제
5.0.3
FEDERATED 스토리지 엔진
신규 함수 추가
STDDEV_POP()
STDDEV_SAMP()
VAR_POP()
VAR_SAMP()
BIT 데이터 타입이 TINYINT와 호환성 없어짐
NUMERIC와 DECIMAL 타입의 저장 방식이 String에서 Binary로 변경
5.0.2
TRIGGER 도입
HAVING 조건에 SELECT컬럼, GROUP-BY컬럼, OUTER-서브쿼리의 값 사용 가능(ANSI 표준)
5.0.1
VIEW 도입
HAVING 조건에 SELECT컬럼, GROUP-BY컬럼, OUTER-서브쿼리의 값 사용 가능(ANSI 표준)
5
StoredRoutine (Procedure,Function) 도입
ISAM 스토리지 엔진 제거
CURSOR 도입
Archive 스토리지 엔진
INFORMATION_SCHEMA 딕셔너리 데이터베이스 도입 (ANSI 표준)
4.1.11
Blackhole 스토리지 엔진
4.1.4
CVS 스토리지 엔진
MySQL 버전 별 차이점
MySQL 버전
17. 17
- Internal Use Only -
Version
Features
추가
변경
삭제
4.1
SubQuery 도입
WHOW WARNINGS
CREATE TABLE ... LIKE ...
GROUP_CONCAT() 구현
유니코드(UTF8, UCS2) 지원
GIS 관련 기능(Spatial extension) 지원
ALTER DATABASE 명령 지원
DUAL 테이블 내부 지원(타 DBMS와의 호환성 유지)
"SELECT 1" 명령과 "SELECT 1 FROM DUAL" 명령은 동일
Memory 스토리지 엔진에서 B-Tree 허용
EXPLAIN EXTENDED 구현
Column 코멘트 구현(CREATE TABLE...)
PASSWORD() 함수의 알고리즘 업그레이드
기존 알고리즘은 OLD_PASSWORD()로 변경됨
CHAR, VARCHAR 타입의 길이가 바이트 수에서 문자수로 변경됨
파생 테이블(Derived tables) 내에서 UNION 사용 가능
4.0.18
"TYPE" 키워드가 "ENGINE" 키워드로 변경(CREATE TABLE...)
4.0.14
InnoDB의 BLOB와 TEXT 타입에 대한 인덱스 지원
4.0.4
JOIN DELETE (Multiple Delete) 도입
JOIN UPDATE (Multiple Update) 도입
4.0.2
Memory 스토리지 엔진에서 NULLABLE 컬럼의 인덱스 지원
VARCHAR 컬럼의 길이가 1~255에서 0~255로 변경됨
4.0.1
Query Cache 도입
4
UNION 집합 연산 도입
SQL_CALC_FOUND_ROWS 힌트와 FOUND_ROWS() 함수 구현
UPDATE와 DELETE 구문에 ORDER BY 사용 허용
3.23
EXPLAIN(쿼리 실행계획) 구현
전문 검색(Fulltext search) 도입
JOIN(SELECT만) 도입
NULL-SAFE 연산자(<=>) 도입
길이가 0인 CHAR 컬럼 허용
MySQL 버전 별 차이점
MySQL 버전
18. 18
- Internal Use Only -
yum -y install mysql mysql-server mysql-devel
sudo apt-get install mysql-server mysql-client
MySQL 설치
MySQL 설치 각 플랫폼 별, OS 별 다양한 설치방법 지원
OS별 binary package down load
unpack
cp / mv
set configure option
source file down load
make – option
Install
set configure option
RPM 설치
Binary 설치
Source 설치
19. 19
- Internal Use Only -
설치 완료 상태, 환경설정 필요
MySQL 설치
root@lcoalhost # yum –y install mysql mysql-server mysql-devel
…
MySQL yum install
20. 20
- Internal Use Only -
MySQL 설치
MySQL Binary install
root@lcoalhost # vi un pack directory/INSTALL-BINARY …
설치 완료 상태
환경설정 필요
21. 21
- Internal Use Only -
MySQL 설치
MySQL Source install
root@lcoalhost # cmake -DCMAKE_INSTALL_PREFIX=/opt/mysql
-DDEFAULT_CHARSET=utf8
-DDEFAULT_COLLATION=utf8_general_ci
-DWITH_EXTRA_CHARSETS=all
-DMYSQL_DATADIR=/opt/database/mysql
-DENABLED_LOCAL_INFILE=1
-DWITH_INNOBASE_STORAGE_ENGINE=1
root@lcoalhost # chown -R mysql /opt/mysql
root@lcoalhost # chown -R mysql /opt/database
root@lcoalhost # ./scripts/mysql_install_db --user=mysql
--datadir=/opt/databases/mysql
root@lcoalhost # cp support-files/my-medium.cnf /etc/my.cnf
root@lcoalhost # cp support-file/mysql.server /etc/init.d/mysqld
의존성 패키지 설치 필요
시스템 관리 능력 필요
23. 23
- Internal Use Only -
MySQL 환경설정
공식 사이트와 제공되는 예제 conf 파일 참조
제공되는 예제 conf 파일 참조
my-small.conf, my-medium.conf, my-large.conf, my-huge.conf ….
24. 24
- Internal Use Only -
MySQL 환경설정
[client] #password = [your_password] port = 3306 socket = /tmp/mysql.sock
[mysqld] # generic configuration options port = 3306 # socket = /tmp/3306.mysql.sock socket = /tmp/mysql.sock
port 설정
client
server
25. 25
- Internal Use Only -
MySQL 환경설정
datadir=/usr/local/mysql/data
데이터 디렉토리 설정
pid-file=/usr/local/mysql/data/3306.pid
pid 설정
# log_bin = /opt/log/bin-log/mysql-bin
log_bin = mysql-bin
binlog_cache_size = 1M
binlog_format = row
bin-log 설정
26. 26
- Internal Use Only -
MySQL 환경설정
log-error=/usr/local/mysql/data/3306.mysql.log
error log 설정
slow_query_log=1
slow_query_log_file=/directory/slow_query.log
slow log 설정
그 외 수 많은 설정 값들
Replication
Cluster
Turning variables
28. 28
- Internal Use Only -
MySQL 스토리지 엔진 소개
향상된 엔진과 새로 추가된 엔진들
29. 29
- Internal Use Only -
MySQL 스토리지 엔진 소개
Merge My Isam
강남구
강남구 삼성동
번지 : 123
동 구분 : 삼성동
거주자 명 : 아무개
강남구 역삼동
번지 : 456
동 구분 : 역삼동
거주자 명 : 김수한무
번지 : 123
동 구분 : 삼성동
거주자 명 : 아무개
30. 30
- Internal Use Only -
MySQL 스토리지 엔진 소개
Merge My Isam
CREATE TABLE `table001`
(
`aseq` INT(11) NOT NULL AUTO_INCREMENT,
`dong-name` VARCHAR(64) COLLATE utf8_bin NOT NULL,
`aname` VARCHAR(255) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`aseq`)
) ENGINE=MYISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin ;
CREATE TABLE `table002`
(
`aseq` INT(11) NOT NULL AUTO_INCREMENT,
`dong-name` VARCHAR(64) COLLATE utf8_bin NOT NULL,
`aname` VARCHAR(255) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`aseq`)
) ENGINE=MYISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin ;
삼성동 테이블
역삼동 테이블
31. 31
- Internal Use Only -
MySQL 스토리지 엔진 소개
Merge My Isam
CREATE TABLE `xxx`
(
`aseq` INT AUTO_INCREMENT PRIMARY KEY,
`dong-name` VARCHAR(64) NOT NULL,
`aname` VARCHAR(255) NOT NULL
) ENGINE=MERGE UNION=(`table001`, `table002`) INSERT_METHOD=LAST;
강남구 테이블
primary key
머지 된 데이터를 볼 수 있다
32. 32
- Internal Use Only -
MySQL 스토리지 엔진 소개
CSV 스토리지 엔진은 CSV에 저장된 파일 (쉼표로 분리 값) 형식을 읽고 추가 가능
null column 미 지원
CSV
CREATE TABLE `csv_test`
(
`seq` INT default 0,
`bank` VARCHAR(64) NOT NULL,
`op_time` VARCHAR(64) NOT NULL,
`end_time` VARCHAR(64) NOT NULL
)
CSV 형식의 데이터
확인 가능
file
인덱스 미 지원
33. 33
- Internal Use Only -
MySQL 스토리지 엔진 소개
InnoDB
Default engine
MySQL Built-in Engine 중 유일하게 트랜잭션을 지원하는 엔진
Low-level(record level) lock 지원
대용량 데이터 처리에 적합
Version 3
Version 5
Version 4
Isam
MyIsam
InnoDB
Other DB engines xtraDB / TokuDB Socket handler
< MySQL default storage engine의 변화 과정 >
34. 34
- Internal Use Only -
MySQL 스토리지 엔진 소개
InnoDB
장점
단점
트랜잭션 지원
Row level lock
장애 복구 향상
다양한 튜닝 옵션
진행중인 성능 및 확장 성 향상
비유동적 Table space 영역
Update 진행중인 engine
고성능을 위해선 고 용량 메모리 요구
pk
주민번호
이름
나이
주소
1
**********
이순신
9
서울
2
**********
강감찬
10
충남
3
**********
권율
10
충북
…
101
**********
정약용
11
경남
102
**********
성삼문
9
강원
103
**********
이동현
7
전남
…
MySQL 공식 제안사항
35. 35
- Internal Use Only -
MySQL 스토리지 엔진 소개
그 외 engine`s
ARCHIVE 스토리지 엔진 특징
mysql> SHOW VARIABLES LIKE 'have_archive';
INSERT 및 SELECT은 지원
DELETE, REPLACE, 또는 UPDATE는 비 지원
ORDER BY 지원, BLOB 컬럼, 및 기본적으로 모든 공간(spatial)데이터 타입을 지원
줄-레벨 잠금(row-level locking)을 사용
필요 시 configure를 --with-archive-storage-engine 옵션과 함께 호출
ARCHIVE 스토리지 엔진 지원여부 확인
Row 삽입 때 압축된다.
ARCHIVE 엔진은 zlib 무손실(lossless)데이터 압축을 사용, 여러분은 OPTIMIZE TABLE 를 사용해서 테이블을 분석하고 보다 작은 포맷에 저장할 수 있다
ARCHIVE 스토리지 엔진의 데이터 저장 방법
36. 36
- Internal Use Only -
MySQL 스토리지 엔진 소개
그 외 engine`s
FEDERATED engine
로컬 데이터 파일이 존재하지 않음
로컬 서버와 리모트 서버의 테이블 구조가 동일해야 함
모든 스토리지 타입 지원
로컬에서 SQL 호출 실행
MySQL 핸들러 API (핸들러 포맷의 데이터)
MySQL 클라이언트 API (SQL 호출로 변환된 데이터)
리모트 데이터베이스 -> MySQL 클라이언트 API
핸들러 포맷으로 결과 셋 변환
핸들러 API -> 결과 열 또는 열 – 로컬에 영향을 주는 카운트
FEDERATED engine process flow
38. 38
- Internal Use Only -
MySQL tuning 소개 및 방법 각각 구성요소들의 조율을 통해서 성능을 향상 시키는 것
병목지점 찾기
벤치마킹
프로파일링
스키마 최적화와 인덱싱
쿼리 성능 최적화
고급 MySQL 기능 활용
서버 설정 최적화
운영체제와 하드웨어 최적화
성능 확장 및 고가용성
응용프로그램 수준의 최적화
39. 39
- Internal Use Only -
MySQL tuning 소개 및 방법 - Thread pool MySQL은 상용버전에서만 사용가능, MariaDB, Percona 는 기본 사용가능
기본 스레드 생성 방식
스레드 풀 방식
Request
MySQL은 connection 당 Thread 를 생성한다.
Result 가 반환되고 Thread 가 더 이상 사용되지 않으면 종료 루틴
Response
Request
1
2
3
4
5
6
…
Thread pool
Response
1
recycle
요청이 오고 connection 이 이루어지는 순간 부하발생
이미 생성되어 있는 connection이 요청에 응답, connection overhead 없음
40. 40
- Internal Use Only -
MySQL tuning 소개 및 방법 - Query Profiling MySQL 5.1 버전 이후 내장 기능
현재 세션 과정 동안 실행 문에 대한 리소스 사용을 나타냄
프로파일링 과정
> set profiling=1;
프로파일링을 설정해준다.
> Select * from store;
> Show profiles;
분석할 쿼리
분석 시작
Query ID
> show profile for query 1
쿼리 별 상세내역
Query ID
해당 쿼리의 실행 내역
41. 41
- Internal Use Only -
MySQL tuning 소개 및 방법 - Explain 활용법 MySQL이 SELECT 명령문을 실행하는 방법에 대한 정보를 얻기 위한 수단
MySQL은 쿼리 실행 플랜(query execution plan) 정보를 옵티마이져 (optimizer)에서 가져 와서 출력 한다. 즉, MySQL은 테이블들이 어떤 순서로 조인(join)하는지에 대한 정보를 포함해서, SELECT를 처리하는 방법에 대해서 알려 준다.
> Explain select * from store
id
•SELECT 번호, 쿼리내의 SELECT 의 구분번호
Select type
•SIMPLE: 단순 SELECT (UNION 이나 서브쿼리를 사용하지 않음)
•PRIMARY: 가장 외곽의 SELECT
•UNION: UNION 에서의 두 번째 혹은 나중에 따라오는 SELECT
•DEPENDENT UNION: UNION 에서의 두 번째 혹은 나중에 따라오는 SELECT, 외곽쿼리에 의존적
•UNION RESULT: UNION 의 결과물
•SUBQUERY: 서브쿼리의 첫 번째 SELECT
•DEPENDENT SUBQUERY: 서브쿼리의 첫 번째 SELECT, 외곽쿼리에 의존적
•DERIVED: SELECT 로 추출된 테이블 (FROM 절 내부의 서브쿼리)
42. 42
- Internal Use Only -
MySQL tuning 소개 및 방법 - Explain 활용법
> Explain select * from store
type
System
•테이블에 단 하나의 행만 존재(시스템 테이블). const join 의 특수한 경우
const
•많아야 하나의 매치되는 행만 존재할 때
•PRIMARY KEY 나 UNIQUE index 를 상수와 비교할 때
•각 컬럼 값은 나머지 연산에서 상수로 간주, 처음 한번만 읽어 들이면 되므로 매우 빠름
eq_ref
•조인수행을 위해 각 테이블에서 하나씩의 행만이 읽히는 경우
•조인연산에 PRIMARY KEY 나 UNIQUE index 인덱스가 사용되는 경우
•인덱스 된 컬럼이 = 연산에 사용되는 경우
ref
•이 전 테이블과의 조인에 사용될 매치되는 인덱스의 모든 행이 이 테이블에서 읽혀질 때
•leftmost prefix 키만을 사용하거나 사용된 키가 PRIMARY KEY 나 UNIQUE 가 아닐 때
•(즉 키 값으로 단일 행을 추출할 수 없을 때)
•사용된 키가 적은 수의 행과 매치되면 이것은 적절한 조인 타입
•ref 는 인덱스 된 컬럼과 = 연산에서 사용됨
ref_or_null
•ref 와 같지만 NULL 값을 포함하는 행에 대한 검색이 수반될 때
•서브쿼리 처리에서 대개 사용됨
•index_merge
•인덱스 병합 최적화가 적용되는 조인 타입
•이 경우, key 컬럼은 사용된 인덱스의 리스트를 나타내며
•key_len 컬럼은 사용된 인덱스 중 가장 긴 key 명을 나타냄
43. 43
- Internal Use Only -
MySQL tuning 소개 및 방법 - Explain 활용법
> Explain select * from store
index_merge
•인덱스 병합 최적화가 적용되는 조인 타입
•이 경우, key 컬럼은 사용된 인덱스의 리스트를 나타내며
•key_len 컬럼은 사용된 인덱스 중 가장 긴 key 명을 나타냄
unique_subquery
•몇몇 IN 서브쿼리 처리에서 ref 타입대신 사용됨
•unique_subquery 는 성능향상을 위해 서브쿼리를 단순 index 검색 함수로 대체함
index_subquery
•unique_subquery 와 마찬가지로 IN 서브쿼리를 대체
•단, 서브쿼리에서 non-unique 인덱스가 사용될 때 동작 함
range
•인덱스를 사용하여 주어진 범위 내의 행들만 추출
•key 컬럼: 사용된 인덱스
•key_len: 사용된 가장 긴 key 부분
•ref 컬럼: 이 타입의 조인에서 NULL
•키 컬럼이 상수와 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN 또는 IN 연산에 사용될 때 적용됨
index
•인덱스가 스캔된다는걸 제외하면 ALL 과 같음
•일반적으로 인덱스 파일이 데이터파일보다 작기 때문에 ALL 보다는 빠름
•MySQL 은 쿼리에서 단일 인덱스의 일부분인 컬럼을 사용할 때 이 조인타입을 적용함
ALL
•이전 테이블과의 조인을 위해 풀 스캔
•(조인에 쓰인) 첫 번째 테이블이 고정이 아니라면 비효율적
•대부분의 경우에 아주 느린 성능
44. 44
- Internal Use Only -
MySQL tuning 소개 및 방법 - Explain 활용법
> Explain select * from store
possible_keys
•MySQL 이 해당 테이블의 검색에 사용할 수 있는 인덱스들
•possible_keys 에 나타난 인덱스들이 결과에 나타난 테이블 순서에서 실제 사용할 수 없을 수도 있음
> Explain select * from store
key
•MySQL 이 실제 사용한 key(index)
45. 45
- Internal Use Only -
MySQL tuning 소개 및 방법 - Explain 활용법
> Explain select * from store
key_len
•MySQL 이 사용한 인덱스의 길이, key 컬럼 값이 NULL 이면 이 값도 NULL
•key_len 값으로 MySQL 이 실제 복수컬럼 키 중 얼마나 많은 부분을 사용할 것인지 알 수 있음
> Explain select * from store
ref
•행을 추출하는데 키와 함께 사용된 컬럼이나 상수 값
46. 46
- Internal Use Only -
MySQL tuning 소개 및 방법 - Explain 활용법
> Explain select * from store
rows
•쿼리 수행에서 MySQL 이 예상하는 검색해야 할 행수
> Explain select * from store
extra
•MySQL 이 쿼리를 해석한 추가적인 정보를 나타냄 Distinct : MySQL 이 매치되는 첫 행을 찾는 즉시 검색을 중단한다는 의미 Not exists : MySQL 이 LEFT JOIN 을 수행함에 매치되는 한 행을 찾으면 더 이상 매치되는 행을 검색x range checked for each record (index map: #) : MySQL 이 사용할 좋은 인덱스가 없음 의미 Using filesort : MySQL 이 정렬을 위해 추가적인 과정을 필요로 함 Using index : 컬럼정보가 실제 테이블이 아닌 인덱스 트리에서 추출, 쿼리에서 단일 인덱스 된 컬럼들만을 사용하는 경우 Using temporary : MySQL 이 결과의 재사용을 위해 임시테이블을 사용, 쿼리 내에 GROUP BY 와 ORDER BY 절이 각기 다른 컬럼을 사용할 때 발생 Using where : WHERE 절이 다음 조인에 사용될 행이나 클라이언트에게 돌려질 행을 제한하는 경우 테이블의 모든 행을 검사할 의도가 아니면 ALL 이나 index 라면 쿼리사용이 잘못된 것임 Using sort_union(…) , Using union(…) , Using intersect(…) Using index for group-by : Using index 와 접근방식이 같으며, 추가적인 디스크 접근 없이 GROUP BY 나 DICTINCT 쿼리에 사용된 모든 컬럼에 대한 인덱스를 찾았음을 의미
47. 47
- Internal Use Only -
MySQL tuning 소개 및 방법 - Error log 활용법
2013-09-11 03:07:51 51331 [Warning] 'user' entry 'root@eusamsdb01' ignored in --skip-name-resolve mode. 2013-09-11 03:07:51 51331 [Warning] 'proxies_priv' entry '@ root@eusamsdb01' ignored in --skip-name-resolve mode. 2013-09-11 03:11:02 51331 [ERROR] Event Scheduler: [[email protected]][scop_fm.EFM_ICDT_EVNT_STAT_EVNT] Lock wait timeout exceeded; try restarting transaction 2013-09-11 03:11:02 51331 [Note] Event Scheduler: [[email protected]].[scop_fm.EFM_ICDT_EVNT_STAT_EVNT] event execution failed. 2013-09-11 04:11:02 51331 [ERROR] Event Scheduler: [[email protected]][scop_fm.EFM_ICDT_EVNT_STAT_EVNT] Lock wait timeout exceeded; try restarting transaction 2013-09-11 04:11:02 51331 [Note] Event Scheduler: [[email protected]].[scop_fm.EFM_ICDT_EVNT_STAT_EVNT] event execution failed. 2013-09-11 05:11:02 51331 [ERROR] Event Scheduler: [[email protected]][scop_fm.EFM_ICDT_EVNT_STAT_EVNT] Lock wait timeout exceeded; try restarting transaction 2013-09-11 05:11:02 51331 [Note] Event Scheduler: [[email protected]].[scop_fm.EFM_ICDT_EVNT_STAT_EVNT] event execution failed. 2013-09-11 06:11:02 51331 [ERROR] Event Scheduler: [[email protected]][scop_fm.EFM_ICDT_EVNT_STAT_EVNT] Lock wait timeout exceeded; try restarting transaction 2013-09-11 06:11:02 51331 [Note] Event Scheduler: [[email protected]].[scop_fm.EFM_ICDT_EVNT_STAT_EVNT] event execution failed. 07:09:52 UTC - mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=16777216 read_buffer_size=8388608 max_used_connections=234 max_threads=500 thread_count=189 connection_count=183 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6167145 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0xcf984700 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong...
Error log example
Error 상황일 때 시스템 정보
48. 48
- Internal Use Only -
MySQL tuning 소개 및 방법 - Error log 활용법
stack_bottom = 2b45c45f8def thread_stack 0x40000
/app/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x925a65]
/app/mysql/bin/mysqld(handle_fatal_signal+0x3e8)[0x69b1b8]
/lib64/libpthread.so.0[0x3db560f500]
/app/mysql/bin/mysqld(_ZNK12Field_string4typeEv+0x19)[0x809679]
/app/mysql/bin/mysqld(_Z10field_convP5FieldS0_+0x74)[0x810894]
/app/mysql/bin/mysqld(_ZN10Item_field13save_in_fieldEP5Fieldb+0x44)[0x5c7464]
/app/mysql/bin/mysqld(_Z12sp_eval_exprP3THDP5FieldPP4Item+0x88)[0x69baf8]
/app/mysql/bin/mysqld(_ZN11sp_rcontext12set_variableEP3THDP5FieldPP4Item+0x1a)[0x6a60ca]
/app/mysql/bin/mysqld(_ZN9sp_cursor24Select_fetch_into_spvars9send_dataER4ListI4ItemE+0x60)[0x6a6150]
/app/mysql/bin/mysqld(_ZN19Materialized_cursor5fetchEm+0x4d)[0x6e8fbd]
/app/mysql/bin/mysqld(_ZN9sp_cursor5fetchEP3THDP4ListI11sp_variableE+0xd0)[0x6a6b70]
/app/mysql/bin/mysqld(_ZN15sp_instr_cfetch7executeEP3THDPj+0x34)[0x85c184]
/app/mysql/bin/mysqld(_ZN7sp_head7executeEP3THDb+0x4bd)[0x6a0f4d]
/app/mysql/bin/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x683)[0x6a1a93]
/app/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x44b5)[0x71a045]
/app/mysql/bin/mysqld(_ZN13sp_instr_stmt9exec_coreEP3THDPj+0x60)[0x85c2c0]
/app/mysql/bin/mysqld(_ZN12sp_lex_instr23reset_lex_and_exec_coreEP3THDPjb+0x234)[0x85c874]
/app/mysql/bin/mysqld(_ZN12sp_lex_instr29validate_lex_and_execute_coreEP3THDPjb+0x99)[0x85e0c9]
/app/mysql/bin/mysqld(_ZN13sp_instr_stmt7executeEP3THDPj+0x182)[0x85e3f2]
/app/mysql/bin/mysqld(_ZN7sp_head7executeEP3THDb+0x4bd)[0x6a0f4d]
/app/mysql/bin/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x683)[0x6a1a93]
/app/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x44b5)[0x71a045]
/app/mysql/bin/mysqld(_ZN13sp_instr_stmt9exec_coreEP3THDPj+0x60)[0x85c2c0]
/app/mysql/bin/mysqld(_ZN12sp_lex_instr23reset_lex_and_exec_coreEP3THDPjb+0x234)[0x85c874]
/app/mysql/bin/mysqld(_ZN12sp_lex_instr29validate_lex_and_execute_coreEP3THDPjb+0x99)[0x85e0c9]
/app/mysql/bin/mysqld(_ZN13sp_instr_stmt7executeEP3THDPj+0x182)[0x85e3f2]
/app/mysql/bin/mysqld(_ZN7sp_head7executeEP3THDb+0x4bd)[0x6a0f4d]
/app/mysql/bin/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x683)[0x6a1a93]
/app/mysql/bin/mysqld(_ZN14Event_job_data7executeEP3THDb+0x5cc)[0x7c254c]
/app/mysql/bin/mysqld(_ZN19Event_worker_thread3runEP3THDP28Event_queue_element_for_exec+0xe1)[0x8ac111]
/app/mysql/bin/mysqld(event_worker_thread+0x54)[0x8ac1d4]
/app/mysql/bin/mysqld(pfs_spawn_thread+0x13b)[0xae995b]
/lib64/libpthread.so.0[0x3db5607851]
/lib64/libc.so.6(clone+0x6d)[0x3db52e767d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (d15f6010): CALL scop_pm.PPM_HDLR_05_DATA(DATE_FORMAT(DATE_SUB(_wrk_dt, INTERVAL 5 MINUTE), '%Y%m%d%H%i%s'),_evnt_id,'2')
Connection ID (thread ID): 10322207
Status: NOT_KILLED
에러 발생 원인 query
51. 51
- Internal Use Only -
MySQL 백업 및 복구
Backup 방법
1.전통적인 dump backup 방법
2.Hot backup (상용 버전)
3.Xtrabackup tool backup 방법 (무료 버전)
4.상용 솔루션 backup 방법
논리백업
물리 백업
물리 백업
52. 52
- Internal Use Only -
MySQL 백업 및 복구
1.Full backup Full 백업은 백업할 자료를 처음부터 끝까지 다 기록하는 것이며, Full 백업 시 완전히 데이터를 백업할 수 있지만 시간이 많이 걸리고, 시스템에 부하를 초래할 수 있음
2.Incremental 백업 Incremental 백업은 이전의 데이터와 비교해서 새로 추가된 내용만 백업하는 방법, 빠른 시간 내에 백업을 할 수 있지만, 백업하는 시간에 따라 데이터가 완전히 백업되지 못할 경우도 있을 수 있다.
백업정책 결정요소
1.나의 복구 조건은 무엇인가?
2.운용중인 시스템의 데이터베이스 전체 사용 용량이 어떻게 되는가?
3.사용할 백업 장비와 종류, 백업할 대상이 어떤 부분인가?
4.데이터 손실에 대한 결함 허용하는가?
5.얼마나 자주 백업을 수행해야 하는가?
6.시점 복구가 필요한가? 다운 타임에 대한 결함 허용 산정 : 문제확인+복구계획+시스템복구
7.백업 보전 정책 결정 online, offline, 물리적 장기보존
백업 전략
53. 53
- Internal Use Only -
MySQL 백업 및 복구
MySQL dump backup
서버에 있는 모든 것의 논리 백업 생성
# mysqldump -u[userId] -p[password] --databases [DB명] > dump.sql # mysqldump -u[userId] -p[password] [DB명] [테이블명]
# mysqldump -u[userId] -p[password] --all-databases > dump.sql
특정 데이터베이스만의 논리 백업 생성
54. 54
- Internal Use Only -
MySQL 백업 및 복구
MySQL dump backup
서버에 있는 모든 것의 논리 백업 생성 # mysqldump -u[userId] -p[password] --all-databases > dump.sql
기타 옵션 -A, --all-databases : 모든 DB 덤프 -B, --databases : 특정 DB를 덤프 --opt : 버퍼링을 비활성화, 많은 데이터를 덤프에 있는 소량의 SQL구문에 기록해 더 효율적으로 동작하도록 한다. --allow-keywords, --quote-names : 예약어를 사용하는 테이블을 덤프/복원할 수 있게 한다. --lock-alltables : 전역적으로 일관된 백업을 만들도록 "FLUSH TABLES WITH READ LOCK"을 사용한다. --tab : "SELECT INTO OUTFILE"로 파일을 덤프하여, 덤프 및 복원 속도가 매우 빠르다. -d, --no-data : 데이터는 제외하고 스키마만 덤프 하도록 한다. -t, --no-create-info : 스키마는 제외 하도록 한다.
55. 55
- Internal Use Only -
MySQL 백업 및 복구
MySQL dump restore
# mysql -u[userId] -p[password] [DB명] < dump.sql
백업된 dump file 을 이용
단점
Hot Backup
Cool Backup
56. 56
- Internal Use Only -
MySQL 백업 및 복구
MySQL Hot backup
MySQL Enterprise version 에서만 제공되는 툴
Hot backup / restore 제공
넌 블로킹(non-blocking) 백업을 수행
쿼리 또는 업데이트를 중단시키지 않고 온라인으로 수행
증분 백업은 이전 백업에서 변경된 데이터만 백업하도록 지원
필요한 특정 테이블/테이블스페이스만 백업되어야 하는 경우, 부분 백업이 지원
실제 데이터베이스 파일 사이즈에 비해 백업 사이즈를 평균적으로 70%에서 90% 이상까지 압축하여 스토리지 및 여타 비용을 절감할 수 있도록 지원
DUMP
replication
Hot backup
증분 백업
부분 백업
응용프로그램에 미치는 영향
손상 감지
백업 및 복구 속도
57. 57
- Internal Use Only -
MySQL 백업 및 복구
# mysqlbackup --defaults-file=/etc/my.cnf
-u${DBUSER} -p${USERPS}
--backup-dir=${TDIR}/${CURRDATE}/bkpimage
backup-and-apply-log > ${TDIR}/${CURRDATE}/log/mbackup.log 2>&1
58. 58
- Internal Use Only -
MySQL 백업 및 복구
MySQL xtrabackup
논 블로킹 (non-blocking)
MYISAM 지원
압축
부분 백업
증분 백업
개별 테이블을 가져 오기 / 내보내기
(2.0 이후 증분 스트리밍을 포함!) 스트리밍
병렬 복사 (innodb_file_per_table의 사용과)
InnoDB/
MyISAM
Impact
Warmth
Backup Time
Restore Time
Cold backup
very high
cold
very fast
fast
Mysql dump
medium
hot
medium
slow
snapshotting
high/medium
hot/warm
fast
fast
Mysql EB
low
hot
fast
fast
xtrabackup
low
hot
fast
fast
59. 59
- Internal Use Only -
MySQL 백업 및 복구
Xtrabackup working flow
60. 60
- Internal Use Only -
MySQL 백업 및 복구
Backing up
1. Copy datafiles while recording transaction log changes
2. FLUSH TABLES WITH READ LOCK;
3. Get binlog position?
4. Copy all .MYD, .MYI, .TRG, .TRN, ... files
5. Stop recording transaction log changes
6. UNLOCK TABLES;
Xtrabackup simple description
# innobackupex /path/to/your/backups # innobackupex --apply-log /path/to/your/backups/2012-06-21_13-45-00/ # innobackupex --copy-back /path/to/your/backups/2012-06-21_13-45-00/ # chown -R mysql:mysql /var/lib/mysql
Simple full backup and restore
Preparing/Restoring 7. Prepare backup by applying recorded tlog changes 8. Restoring files to original location
61. 61
- Internal Use Only -
MySQL 백업 및 복구
일반적인 파일단위 백업 서비스와는 달리 이미지백업 (Volume Snapshots 방식) 이면서 분 단위까지 백업을 받고 필요 시 특정 백업 시점으로 복원 할 수 있는 백업 서비스로서 Continuous Data Protection Back-Up 이라는 의미 입니다.
Continuous Data Protection Back-Up
62. 62
- Internal Use Only -
MySQL 백업 및 복구
저렴한 비용의 DR 구축 가장 기본적은 DR시스템 ( 실시간 백업 및 복원 ) 을 저렴한 비용으로 구축이 가능 합니다. OS, File, DB, Image. 동영상 등등을 지속적으로 백업하고 필요 시 특정 시점으로 복원 할 수 있습니다.
최소 분 단위의 백업 작업 가능 CDP백업은 최대 분 단위 까지 지속적인 백업을 할 수 있습니다. ( 1일 150회 이상 )
중복백업을 하지 않는 알고리즘 CDP백업은 분 단위까지 백업 작업을 수행 하지만 중복백업을 하지 않아 백업 저장공간을 최소화 할 수 있습니다.
복원 시 최대 문제발생 15분 전의 상태로 복구 가능 CDP백업은 일반 백업서버와 같이 문제발생시 하루 전으로 복원 하는 것이 아니라, 문제발생 15분 전 상태로 복구가 가능하여 Data Loss를 최소화 할 수 있습니다.
서버에 부담을 주지 않는 백업 서비스 CDP백업은 최초 백업을 제외 하고는 백업동작 시 서버에 부하를 주지 않는 특허 받은 알고리즘을 통해 최적의 백업 환경을 제공 합니다. 서버가 가장 바쁜 시간대에도 백업이 가능 합니다.
CDP Backup 의 특징
63. 63
- Internal Use Only -
MySQL 백업 및 복구
CDP Backup 의 장점
64. 64
- Internal Use Only -
MySQL 백업 및 복구
항목 / 구분
수동백업
이미지백업
CDP백업
백업을 위한 통합 콘솔 제공
No
Yes
Yes
스케줄 백업 지원
No
Yes
Yes
증분 백업 지원
No
Yes
Yes
백업 작업 시 시스템 부하 여부
심함
심함
거의없음
백업시점 및 복원시점 자동 관리
No
No
Yes
네트워크 백업 전문성
No
No
Yes
Bare Metal Restore ( OS백업 및 복구 )
No
Yes
Yes
백업 주기 관리
일
일,시간
일,시간,분
CDP 백업 방식 비교
65. 65
- Internal Use Only -
MySQL 백업 및 복구
CDP 백업 지원 가능 시스템 (for Agent)
CPU
Minimum: Pentium3 Recommended: Pentium4
Physical Memory
Minimum: 512 MB Recommended: 1 GB
NTFS
512 byte - 32KB cluster sizes
Free Disk Space
Disks and Volumes should be No More than 85% full to leave room for copy-on-write Volume Shadow Copy Service snapshot operations.
Supported File Systems
ext2, ext3, ext4 (CDP 2.20+), reiserfs, Linux Swap
32-Bit Windows
Windows XP SP2+, Windows Server 2003 SP2+, Windows Vista, Windows Server 2008, Windows Server 2008 R2, Windows 7
64-Bit Windows
Windows XP SP2+, Windows Server 2003 SP2+, Windows Vista, Windows Server 2008, Windows Server 2008 R2, Windows 7
32-Bit Linux
Most 2.4 & 2.6 Linux Kernels. See Supported Linux Distributions.
64-Bit Linux
Most 2.4 & 2.6 Linux Kernels. See Supported Linux Distributions.
OS 별
66. 66
- Internal Use Only -
MySQL 백업 및 복구
기존의 백업 솔루션과 달리 백업 용량이 최소화 됨.
백업 및 복원 시점을 최소 분 단위 까지 관리 가능.
시스템 부하가 거의 없어 서버의 서비스 성능을 유지 할 수 있음.
OS 및 Data, DB 까지 포함한 백업.
저렴한 비용으로 DR 구축 가능
CDP 백업 도입 효과
MySQL 실시간 백업
문제발생시 특정 테이블만 복원 가능. MySQL 무중단 백업 ! Transaction 무 손실 !
CDP백업- MySQL Special 백업
67. 67
- Internal Use Only -
MySQL 백업 및 복구
CDP 백업 서비스 구성도
CDP은 다음과 같은 고객님께 권장 합니다.
서버의 OS 및 파일에 대하여 백업이 필요한 경우.
매우 중요한 Data를 운용 하는 경우.
DB를 운영하여 문제 발생시 Data Loss를 최소화 하여야 하는 경우.
만약에 발생할 수 있는 실수로 인한 Data 유실 시 빠른 복원이 필요한 경우.
69. 69
- Internal Use Only -
…….
MySQL Upgrade
Upgrade utility
mysql_upgrade는 mysql 에서 기본 제공되는 유틸리티입니다
70. 70
- Internal Use Only -
MySQL Upgrade
Upgrade utility
prompt> mysql_upgrade --help
…
71. 71
- Internal Use Only -
MySQL Upgrade
Upgrade utility
prompt> mysql_upgrade -u user -p password --datadir=/user data directory...
MySQL System table User define table`s
72. 72
- Internal Use Only -
MySQL Upgrade
Upgrade utility
prompt> mysql_check --check-upgrade --all-database --auto-repair
각 테이블들에 대한 체크
73. 73
- Internal Use Only -
OPEN SHARE CONTRIBUTE ADOPT REUSE