미스터 역마살

[DAP / 모델링 문제] [고급] 녹색회관리

Mr. YeokMaSsal — Tue, 13 Sep 2022 21:28:14 +0900

문제

우리 지역의 녹색회는 200명이상 회원으로 늘어났다. 우리는 자원 봉사단체로 우리의 기록들은 정말로 엉망이다. 그래서 우리는 모든 행사를 관리할 수 있는 정보시스템을 필요로한다.

우리는 우리의 회원권 기록들을 자동화시키고 싶다. 각 회원을 위해서 회원명, 직위, 우편주소, 직장전화, 회원권의 종류(개인/단체), 그리고 그 회원이 현재 유효 기간내에 있는지를 알고자 한다. 우리는 1년에 한번 1월에 회비를 거두어 들인다. 회원의 회비 납부기록을 관리해야한다.

우리는 또한 한 회원이 어느 회사에 근무하는지 알고 싶지만 회원들이 자주 회사를 옮기기 때문에 이러한 정보를 관리하는 것은 정말 중요하다. 우리는 각 회원에 대해 한개의 소속회사만을 관리하려고 한다. 우리 회원들은 많은 다른 회사로 부터 온다. 그들 중 몇 명은 어느회사에도 소속되어 있지 않다. 각 회사에 대한 회사명, 주소, 업종 등을 관리하고자 한다.

우리는 1년동안 각종 행사를 치루어왔다. 우리는 이러한 행사에 대한 정보도 또한 관리하고 싶다. 년중 행사에는 9월 회의, 11월 회의, 1월의 연례교육, 4월 회의가 있다. 예를 들어 우리는 지난 5월 엔코아 정보컨설팅에서 온 홍길동씨를 모시고 특별강좌를 가졌고 주위의 도시에서 각종 행사들을 개최하였다. 우리는 각행사가 언제 개최되고 각 행사에 대한 설명, 예상참석자수, 개최지, 소요경비,설문 등의 정보를 관리하고 싶다.

어느 회원이 어느 행사에 참가했는지도 관리한다. 회원들 중 몇몇은 정말로 활발하게 활동하고 나머지는 간간히 참석 하거나 단지 초청장 받는 것을 즐기고 있다.

우리는 익명의 제보자로부터 오는 것처럼 설문들을 처리한다. 우리가 관리하는 설문의 종류는 약 20종류의 설문이 있으며, 20종류 중 하나의 설문을 선택하여 행사에 사용한다. 하나의 설문은 20문항으로 되어있으며, 모두 객관식으로 구성된다. 객관식은 4개의 보기로 구성되어 있다. 우리는 각 설문들을 취합하여 관리한다.

우리는 회원들이 어떠한 Computer Platform을 사용하는지 관리할 필요가 있고 각 Platform마다 3자리 숫자의 Code를 부여하여 관리하려고 한다. (001은 메인프레임, 002는 유닉스서버, 003은 윈도우서버 등) 회원들은 다양한 Computer Platform을 사용하고 있다. 어떤 회원은 IBM/MVS 하나만을 사용하지만, 어떠한 회원은 3가지 모두를 사용하는 회원도 있다. 각 플랫폼별 벤더사를 관리한다. IBM, SUN, HP, 등

우리는 각 회원이 관심을 가지고 있는 응용분야를 관리하고 싶다. 예를 들어 회계, 인사, 광업, 제약등. 이를 만족하는 응용프로그램은 이식성이 강해야 하며 어떠한 Platform이 되던지 상관치 않는다. 하나의 회원이 다양한 관심분야를 가지고 있을 수 있다. 관심분야는 계층구조를 관리한다.

엔터티 & 속성 도출

엔터티는 빨간색, 속성은 파란색, 관계나 주요 사항은 밑줄

우리는 우리의 회원권 기록들을 자동화시키고 싶다. 각 회원을 위해서 회원명, 직위, 우편주소, 직장전화, 회원권의 종류(개인/단체), 그리고 그 회원이 현재 유효 기간내에 있는지를 알고자 한다. 우리는 1년에 한번 1월에 회비를 거두어 들인다. 회원의 회비 납부기록을 관리해야한다.

우리는 또한 한 회원이 어느 회사에 근무하는지 알고 싶지만 회원들이 자주 회사를 옮기기 때문에 이러한 정보를 관리하는 것은 정말 중요하다. 우리는 각 회원에 대해 한개의 소속회사만을 관리하려고 한다. 우리 회원들은 많은 다른 회사로 부터 온다. 그들 중 몇 명은 어느회사에도 소속되어 있지 않다. 각 회사에 대한 회사명, 주소, 업종 등을 관리하고자 한다.

우리는 1년동안 각종 행사를 치루어왔다. 우리는 이러한 행사에 대한 정보도 또한 관리하고 싶다. 년중 행사에는 9월 회의, 11월 회의, 1월의 연례교육, 4월 회의가 있다. 예를 들어 우리는 지난 5월 엔코아 정보컨설팅에서 온 홍길동씨를 모시고 특별강좌를 가졌고 주위의 도시에서 각종 행사들을 개최하였다. 우리는 각행사가 언제 개최되고 각 행사에 대한 설명, 예상참석자수, 개최지, 소요경비,설문 등의 정보를 관리하고 싶다.

어느 회원이 어느 행사에 참가했는지도 관리한다. 회원들 중 몇몇은 정말로 활발하게 활동하고 나머지는 간간히 참석 하거나 단지 초청장 받는 것을 즐기고 있다.

우리는 회원들이 어떠한 Computer Platform을 사용하는지 관리할 필요가 있고 각 Platform마다 3자리 숫자의 Code를 부여하여 관리하려고 한다. (001은 메인프레임, 002는 유닉스서버, 003은 윈도우서버 등) 회원들은 다양한 Computer Platform을 사용하고 있다. 어떤 회원은 IBM/MVS 하나만을 사용하지만, 어떠한 회원은 3가지 모두를 사용하는 회원도 있다. 각 플랫폼별 벤더사를 관리한다. IBM, SUN, HP, 등

우리는 각 회원이 관심을 가지고 있는 응용분야를 관리하고 싶다. 예를 들어 회계, 인사, 광업, 제약등. 이를 만족하는 응용프로그램은 이식성이 강해야 하며 어떠한 Platform이 되던지 상관치 않는다. 하나의 회원이 다양한 관심분야를 가지고 있을 수 있다. 관심분야는 계층구조를 관리한다.

나의 답안

모범 답안

주요 Point

그 회원이 현재 유효 기간내에 있는지를 알고자 한다.

현재 시점의 정보를 알기 위해서는 상태정보를 관리할수 있는 선분이력 형태로 관리해야 적절하다고 판단 하였다. 따라서 회원 엔터티에 유효시작일자와 종료일자 속성으로 관리하여 조회조건에 SYSDATE를 BETWEEN 조건으로 조회하였을때 현재 유효한 회원만 조회할 수 있도록 하였다.

우리는 익명의 제보자로부터 오는 것처럼 설문들을 처리한다.

익명의 제보자 형태로 되어야 하기에 회원 엔터티와 관계를 가질수 없고 답변자에 대한 정보는 관리하면 안된다. 따라서 설문답변자순번 속성으로만 설문자를 구분하도록 하였다.

어떤 회원은 IBM/MVS 하나만을 사용하지만, 어떠한 회원은 3가지 모두를 사용하는 회원도 있다.

회원과 플랫폼 엔터티의 다대다 관계 엔터티를 생성하여야 한다.

[DAP / 모델링 공부] [중급] 주문배송관리

Mr. YeokMaSsal — Sat, 27 Aug 2022 20:25:32 +0900

문제

우리는 다양한 상품을 판매하는 쇼핑몰을 운영하고 있다. 우리의 고객은 개인과 법인으로 구분할 수 있으며, 대부분은 우리의 상품을 구매하는 구매 고객 이지만 법인 고객 중에는 우리에게 판매 할 상품을 납품하는 거래처도 포함되어 있다.

고객 등록은 주문 실적과 상관 없이 가능하지만, 납품 관련 거래처가 아니면서 등록일로부터 6개월 이상 단 한차례의 주문 실적도 없으면 6개월이 경과한 시점부터 1 개월간격으로 3회까지 탈퇴 권고 메일과 SMS 문자를 발송하고, 그 기간 동안에도 구매 주문이나 탈퇴 신청이 없으면 3회차의 메일 및 SMS 문자발송으로부터 1 개월 경과 시 임의로 탈퇴 처리한다. 이메일과 SMS는 같은 회차이나 다른 날 발송할 수 있다. 우리는 등록 고객에게 고객번호를 부여하여 식별하고, 개인은 이름과 연락전화번호, 주소를, 법인은 상호명과 사업자등록번호, 대표전화번호, 대표 주소를 관리한다. 탈퇴고 고객은 고객 정보를 삭제하지 않고 탈퇴일자를 등록하는 것으로 대신하며, 탈퇴 일자가 등록된 고객은 상품주문이 불가능하고, 탈퇴일자로부터 1년이 경과하면 삭제 처리한다.

고객은 주문을 위해 미리 여러 개의 배송지 정보를 저장하여 주문 시에 선택 할 수 있 는데, 고객 등록 시 입력했던 주소지를 최초의 기본 배송지로 설정하고, 기본 배송지가 변경되면 어느 시점에 어떤 배송지가 기본 배송지였는지 알수 있도록 변경이력을 관리 해야 한다. 배송지 목록은 배송지명과 주소, 기본 배송지 여부로 구성 되며, 고객은 자신의 배송지 목록을 자유롭게 편집 할 수 있고, 원하는 기준일자 시점의 배송지(기본 배송지 포함) 목록을 조회 할 수 있다.

우리는 관리 하는 상품은 고객이 쉽게 찾을 수 있도록 분류체계를 정의하여 분류하고 있으며, 상품의 분류 체계는 몇 개의 계층으로 세분화하여 관리 할 수 있다. 상품에대 해서는 상품명, 모델번호, 규격, 제조사, 단가 등을 관리하고, 상품번호를 부여하여 식별한다.

고객이 상품을 주문 하면 주문번호를 생성하여 주문일자와 함께 주문정보를 관리하는데,고객은 우리가 등록한 여러 상품을 하나의 주문으로 묶어 구매 할 수 있으며, 주문 상품의 총(주문)금액, 배송처를 주문 정보에서 관리 한다. 주문번호로 식별되는 하나의 주문은 신용카드, 포인트, 계좌이체 등과 같은 여러 개의 결제 수단을 복합적으로 사용하여 결제 할 수 있다. 주문 결제가 이루어지면 고객에게 주문금액에 따라 포인트를 지급하며 포인트의 누적과 사용이력을 관리하여 언제라도 고객이 자신의 현재 사용가능 한 포인트가 얼마인지 알 수 있어야 한다.

엔터티 & 속성 도출

엔터티는 빨간색, 속성은 파란색, 관계나 주요 사항은 밑줄

우리는 다양한 상품을 판매하는 쇼핑몰을 운영하고 있다. 우리의 고객은 개인과 법인으로 구분할 수 있으며, 대부분은 우리의 상품을 구매하는 구매 고객 이지만 법인 고객 중에는 우리에게 판매 할 상품을 납품하는 거래처도 포함되어 있다.

고객 등록은 주문 실적과 상관 없이 가능하지만, 납품 관련 거래처가 아니면서 등록일로부터 6개월 이상 단 한차례의 주문 실적도 없으면 6개월이 경과한 시점부터 1 개월간격으로 3회까지 탈퇴 권고 메일과 SMS 문자를 발송하고, 그 기간 동안에도 구매 주문이나 탈퇴 신청이 없으면 3회차의 메일 및 SMS 문자발송으로부터 1 개월 경과 시 임의로 탈퇴 처리한다. 이메일과 SMS는 같은 회차이나 다른 날 발송할 수 있다. 우리는 등록 고객에게 고객번호를 부여하여 식별하고, 개인은 이름과 연락전화번호, 주소를, 법인은 상호명과 사업자등록번호, 대표전화번호, 대표 주소를 관리한다. 탈퇴고 고객은 고객 정보를 삭제하지 않고 탈퇴일자를 등록하는 것으로 대신하며, 탈퇴 일자가 등록된 고객은 상품주문이 불가능하고, 탈퇴일자로부터 1년이 경과하면 삭제 처리한다.

고객은 주문을 위해 미리 여러 개의 배송지 정보를 저장하여 주문 시에 선택 할 수 있 는데, 고객 등록 시 입력했던 주소지를 최초의 기본 배송지로 설정하고, 기본 배송지가 변경되면 어느 시점에 어떤 배송지가 기본 배송지였는지 알수 있도록 변경이력을 관리 해야 한다. 배송지 목록은 배송지명과 주소, 기본 배송지 여부로 구성 되며, 고객은 자신의 배송지 목록을 자유롭게 편집 할 수 있고, 원하는 기준일자 시점의 배송지(기본 배송지 포함) 목록을 조회 할 수 있다.

우리는 관리 하는 상품은 고객이 쉽게 찾을 수 있도록 분류체계를 정의하여 분류하고 있으며, 상품의 분류 체계는 몇 개의 계층으로 세분화하여 관리 할 수 있다. 상품에대 해서는 상품명, 모델번호, 규격, 제조사, 단가 등을 관리하고, 상품번호를 부여하여 식별한다.

고객이 상품을 주문 하면 주문번호를 생성하여 주문일자와 함께 주문정보를 관리하는데,고객은 우리가 등록한 여러 상품을 하나의 주문으로 묶어 구매 할 수 있으며, 주문 상품의 총(주문)금액, 배송처를 주문 정보에서 관리 한다. 주문번호로 식별되는 하나의 주문은 신용카드, 포인트, 계좌이체 등과 같은 여러 개의 결제 수단을 복합적으로 사용하여 결제 할 수 있다. 주문 결제가 이루어지면 고객에게 주문금액에 따라 포인트를 지급하며 포인트의 누적과 사용이력을 관리하여 언제라도 고객이 자신의 현재 사용가능 한 포인트가 얼마인지 알 수 있어야 한다.

나의 답안

모범 답안

주요 Point

이메일과 SMS는 같은 회차이나 다른 날 발송할 수 있다.

이메일과 SMS의 발송일자를 별도로 관리해야한다는 의미로 해석했다. 모범답안에는 이메일, SMS 각가 별도로 발송일자를 관리하고 있지 않지만 문제에서 '다른날' 이라고 한 부분이 관리가 필요한듯 보인다.

기본 배송지가 변경되면 어느 시점에 어떤 배송지가 기본 배송지였는지 알수 있도록 변경이력을 관리 해야 한다..
원하는 기준일자 시점의 배송지(기본 배송지 포함) 목록을 조회 할 수 있다

어느시점에 어떤 배송지가 기본 배송지였는지와 원하는 기준일자 시점의 배송지 목록을 조회하기 위해서는 점이력 보다는 선분이력으로 관리하는것이 유용하다고 판단 하였고 그러기 위해 시작일자와 종료일자 속성을 생성하였다.

[DAP / 모델링 공부] [중급] 소송시스템 문제

Mr. YeokMaSsal — Sun, 21 Aug 2022 17:34:32 +0900

문제

나는 규모가 크고 다양한 업무를 취급하는 법률회사의 동업자이다. 우리 회사는 교통위반,국내분규,민사소송,살인 등 다양한 종류의 일들을 취급한다. 우리회사는 소송,살인,기타 부서로 이루어지며 관리 목적에 따라 각 사건마다 특정부서로 할당된다. 변호사는 특정부서에 소속되지만 그것은 단지 회계적인 목적이며 사건에 따라서 타부서에서 일할 수도 있다. 우리는 사건의 각종 진행사항에 대한 정보를 필요로 하며 각 사건은 발생된 EVENT에 대한 일자,개요와 함께 ID별로 관리되어야 한다. EVENT 들은 특수코드를 갖는데 예를 들면 시작은 1, 재판 중은 2, 종료는 3으로 구분하며 각 사건에 대한 EVENT 상태를 알 수 있어야 한다. 우리는 사건이 어느 부서에 배정되었고 이 사건에 대한 간단한 개요를 포함하는 중요한 정보를 관리하고 싶다. 한 사건이 종료된 후 그것은 추후에 다시 계속될 지도 모른다. 재개된 사건에 대해서는 새 사건ID를 부여하지만 이전 사건과 연결될 수 있어야 한다. 변호사들은 동시에 여러 개의 사건에 관여할 수 있으며 여러 사람들이 여러 사건에 관여될 수 있다. 예를 들어 홍길동은 한 개 사건에서는 재판장이면서 다른 사건에서는 목격자일 수 있다. 우리는 특정 사건에 있어 사람들이 어떠한 역할 및 관계를 가지고 있는지 관리하고자 한다. 소송관계인은 이름,생년월일과 유일한 번호에 의해 확인될 수 있어야 하며 사건에 관련된 사람은 판사, 목격자, 피고인, 변호사로 구분된다. 우리는 이 네 사람의 정보를 알아야 한다. 사람들은 다른 사건에서 다른 역할을 할 수 있으나 한 관계자는 하나의 사건에서 오직 하나의 역할만 할 수 있다.

엔터티 & 속성 도출

엔터티는 빨간색, 속성은 파란색, 관계나 주요 사항은 밑줄

나는 규모가 크고 다양한 업무를 취급하는 법률회사의 동업자이다. 우리 회사는 교통위반,국내분규,민사소송,살인 등 다양한 종류의 일들을 취급한다. 우리회사는 소송,살인,기타 부서로 이루어지며 관리 목적에 따라 각 사건마다 특정부서로 할당된다. 변호사는 특정부서에 소속되지만 그것은 단지 회계적인 목적이며 사건에 따라서 타부서에서 일할 수도 있다. 우리는 사건의 각종 진행사항에 대한 정보를 필요로 하며 각 사건은 발생된 EVENT에 대한 일자,개요와 함께 ID별로 관리되어야 한다. EVENT 들은 특수코드를 갖는데 예를 들면 시작은 1, 재판 중은 2, 종료는 3으로 구분하며 각 사건에 대한 EVENT 상태를 알 수 있어야 한다. 우리는 사건이 어느 부서에 배정되었고 이 사건에 대한 간단한 개요를 포함하는 중요한 정보를 관리하고 싶다. 한 사건이 종료된 후 그것은 추후에 다시 계속될 지도 모른다. 재개된 사건에 대해서는 새 사건ID를 부여하지만 이전 사건과 연결될 수 있어야 한다. 변호사들은 동시에 여러 개의 사건에 관여할 수 있으며 여러 사람들이 여러 사건에 관여될 수 있다. 예를 들어 홍길동은 한 개 사건에서는 재판장이면서 다른 사건에서는 목격자일 수 있다. 우리는 특정 사건에 있어 사람들이 어떠한 역할 및 관계를 가지고 있는지 관리하고자 한다. 소송관계인은 이름,생년월일과 유일한 번호에 의해 확인될 수 있어야 하며 사건에 관련된 사람은 판사, 목격자, 피고인, 변호사로 구분된다. 우리는 이 네 사람의 정보를 알아야 한다. 사람들은 다른 사건에서 다른 역할을 할 수 있으나 한 관계자는 하나의 사건에서 오직 하나의 역할만 할 수 있다.

나의 답안

모범 답안

주요 Point

변호사는 특정부서에 소속되지만 그것은 단지 회계적인 목적이며 사건에 따라서 타부서에서 일할 수도 있다. .

이부분을 보고 변호사 엔터티를 생성해야 한다고 판단 해서 해당 엔터티를 만들고 소속부서ID를를 통해 부서 엔터티와 관계 설정을 하였지만 모범답안을 보고 나니 해당 문구의 의미가 변호사 엔터티를 별도로 생성할 필요가 없다는것을 의미 한다는 것을 알게 되었다.

한 사건이 종료된 후 그것은 추후에 다시 계속될 지도 모른다. 재개된 사건에 대해서는 새 사건ID를 부여하지만 이전 사건과 연결될 수 있어야 한다.

사건, 사건 마다 사건ID가 생성이 되고 이전 사건ID가 현재 사건ID와 관계를 가지는 Recursive한 구조의 엔터티가 구성되어야 한다.

사람들은 다른 사건에서 다른 역할을 할 수 있으나 한 관계자는 하나의 사건에서 오직 하나의 역할만 할 수 있다..

이부분을 보고 많은 고민을 했다. 소송관계인 한명이 한 사건에 하나의 역할만 한다는 제약조건 같은것이 모델로 어떻게 표현해야 하나 했던것이다. 모범 답안을 확인 해보니 사건별관계인역할 엔터티를 생성했다. 내가 문제를 잘못 이해한 부분이 있었다. 나는 사건당 소송관계인이 발생하면 소송관계인번호를 채번한다고 생각을 했는데 모범 답안을 보니 소송관계인은 사람을 식별하는 식별값이었던 것이다. 애초에 문제에서 그런식으로 이해를 했더라면 나도 모범답안처럼 관계인역할 엔터티를 도출했을텐데 문제 이해능력이 떨어져서 좀 아쉽다.

[DAP / 모델링 문제] [중급] 도서관리시스템

Mr. YeokMaSsal — Sat, 20 Aug 2022 14:09:47 +0900

문제

우리 도서관은 많은 책을 보유하고 있으며, 책을 대여하는 시스템을 개발 중이다.

우리는 많은 회원을 관리하고 있어, 회원을 관리한다. 회원은 이름, 연락처, 주소를 관리한다. 대여한 책을 3회 이상 기한 내에 반납하지 않은 회원은 불량회원으로 등록하여, 1년동안 책을 대여해 주지 않는 패널티 조항이 있다. 따라서 회원의 불량 여부를 관리하며, 불량회원일 경우 최종 불량회원 등록일자를 관리한다.

우리는 많은 책을 보유하고 있다. 도서명, 출판사, 출판일자, 우리도서관 납품일자를 관리한다.

회원은 도서를 대여할 수 있으며, 한번에 여러 권을 대여할 수 있으며, 도서별로 반납예정일자가 다를 수 있다. 또한 회원의 실제 반납은 반납 예정일과 다를 수 있어 별도로 반납일자를 관리해야 한다. 도서대여일자, 대여시간을 관리해야 한다. 도서대여는 한번 대여할 때 마다 대여번호가 자동 채번된다.

우리는 도서관 운영비용을 회원의 회비와 도서대여료, 도서반납 연체료로 운영을 한다. 회원의 회비는 년간 1회 비용을 납입하며, 도서대여비는 대여할 때 일시불로 받는다. 그리고 도서반납연체료는 도서를 반납하는 시점에 받는다.

우리는 입금내역을 관리해야 한다. 입금번호, 입금일자, 금액을 관리한다.

입금내역은 어느 회원의 연회비인지 또는 어떤 대여비용인지, 어떤 도서의 연채료인지를 관리해야 한다.

엔터티 & 속성 도출

엔터티는 빨간색, 속성은 파란색, 관계나 주요 사항은 밑줄

우리 도서관은 많은 책을 보유하고 있으며, 책을 대여하는 시스템을 개발 중이다.

우리는 많은 회원을 관리하고 있어, 회원을 관리한다. 회원은 이름, 연락처, 주소를 관리한다. 대여한 책을 3회 이상 기한 내에 반납하지 않은 회원은 불량회원으로 등록하여, 1년동안 책을 대여해 주지 않는 패널티 조항이 있다. 따라서 회원의 불량 여부를 관리하며, 불량회원일 경우 최종 불량회원 등록일자를 관리한다.

우리는 많은 책을 보유하고 있다. 도서명, 출판사, 출판일자, 우리도서관 납품일자를 관리한다.

회원은 도서를 대여할 수 있으며, 한번에 여러 권을 대여할 수 있으며, 도서별로 반납예정일자가 다를 수 있다. 또한 회원의 실제 반납은 반납 예정일과 다를 수 있어 별도로 반납일자를 관리해야 한다. 도서대여일자, 대여시간을 관리해야 한다. 도서대여는 한번 대여할 때 마다 대여번호가 자동 채번된다.

우리는 도서관 운영비용을 회원의 회비와 도서대여료, 도서반납 연체료로 운영을 한다. 회원의 회비는 년간 1회 비용을 납입하며, 도서대여비는 대여할 때 일시불로 받는다. 그리고 도서반납연체료는 도서를 반납하는 시점에 받는다.

우리는 입금내역을 관리해야 한다. 입금번호, 입금일자, 금액을 관리한다.

입금내역은 어느 회원의 연회비인지 또는 어떤 대여비용인지, 어떤 도서의 연채료인지를 관리해야 한다.

나의 답안

모범 답안

주요 Point

도서대여는 한번 대여할 때 마다 대여번호가 자동 채번된다..
회원은 도서를 대여할 수 있으며, 한번에 여러 권을 대여할 수 있으며, 도서별로 반납예정일자가 다를 수 있다.

이 문구를 통해 도서대여 기본 엔터티와 도서대여에 따른 각각의 도서들을 구분하는 상세 엔터티를 구성해야한다는것을 알 수있다. 도서별로 반납예정일자가 다를수 있다는 부분을 통해 반납예정일자는 도서대여 엔터티가 아닌 상세 엔터티의 속성으로 관리되어야 함을 알 수 있다.

입금내역 엔터티 관련

모범답안을 보게 되면 입금 구분의 서브타입과 다른 엔터티들이 배타적관계를 가지고 있다. 문제를 풀면서 이런부분까지는 고려를 하지 못했다. 논리적으로 명확하게 하기 위해서는 모범답안과 같이 배타적 관계를 가져야만 한다. 문제에 대해 면밀하게 파악하지 않고 급하게 푸느라 이런부분을 놓친듯 하다. 다음에는 배타적 관계를 가질 상황에 대해 고려하며 모델링을 해야 겠다.

[DAP / 모델링 문제] [중급] 인사평가시스템

Mr. YeokMaSsal — Mon, 15 Aug 2022 22:35:02 +0900

문제

우리는 인사평가시스템을 만들고 있다. 인사 평가는 직원의 직속상관으로 3차 평가에 의해 이루어 진다. 예를 들어 팀원이면 팀장(1차평가) – 부장(2차평가) – 본부장(3차평가)을 팀장이면 부장(1차) – 본부장(2차) – 부사장(3차) 로 이루어 진다. 이는 예시이며, 꼭 팀이 부서 아래만 존재하지 않으며, 본부 또는 부사장 직속일 수 있다. 팀원이면 1차(50%), 2차(30%), 3차(20%) 이며, 팀장일 경우 1차(40%) – 2차(30%) – 3차(30%) 이다. 즉 팀원, 팀장, 부장, 본부장, 부사장의 평가 비율이 다르다. 평가년도별 평가 비율이 다를 수 있다.
우리는 사원을 관리한다. 사원은 사원번호, 이름, 연락처, 출신학교, 소속부서를 관리한다. 출신학교는 초등학교부터 최종 학교의 입학년도, 졸업년도, 출신학교명, 출신학교구분(초등~대학원)의 이력을 관리한다. 또한 직원은 인사별령으로 부서 및 직책이 바뀔 수 있으며, 이에 대한 이력을 관리한다. 우리는 조직을 관리한다. 조직은 부서코드, 부서명, 조직장(팀장,부장,본부장 등), 상위조직, 조직구분을 관리한다. 부서장은 한사람이 다수 조직의 장으로 겸직할 수 없다. 조직구분은 사장, 부사장, 본부, 부, 팀으로 구분된다.
우리는 평가를 관리한다. 피평가자, 평가자, 평가비율, 평가차수(1~3차), 평가점수, 평가등급(S, A, B, C, D), 최종 평가등급, 평가일자를 관리한다. 최종 평가 등급은 1~3차 값을 합산하여 등급을 평가하며 평가 등급은 평가점수가 95점 이상 S, 90점이상 A, 80점이상 B, 70점 이상 C, 70점 미만 D로 구분한다. 평가등급의 기준은 매년 변경될 수 있다. 평가는 매년 1회 실시하며, 매년 평가에 대한 전체 이력을 관리한다.

엔터티 & 속성 도출

엔터티는 빨간색, 속성은 파란색, 관계나 주요 사항은 밑줄

우리는 인사평가시스템을 만들고 있다. 인사 평가는 직원의 직속상관으로 3차 평가에 의해 이루어 진다. 예를 들어 팀원이면 팀장(1차평가) – 부장(2차평가) – 본부장(3차평가)을 팀장이면 부장(1차) – 본부장(2차) – 부사장(3차) 로 이루어 진다. 이는 예시이며, 꼭 팀이 부서 아래만 존재하지 않으며, 본부 또는 부사장 직속일 수 있다. 팀원이면 1차(50%), 2차(30%), 3차(20%) 이며, 팀장일 경우 1차(40%) – 2차(30%) – 3차(30%) 이다. 즉 팀원, 팀장, 부장, 본부장, 부사장의 평가 비율이 다르다. 평가년도별 평가 비율이 다를 수 있다.
우리는 사원을 관리한다. 사원은 사원번호, 이름, 연락처, 출신학교, 소속부서를 관리한다. 출신학교는 초등학교부터 최종 학교의 입학년도, 졸업년도, 출신학교명, 출신학교구분(초등~대학원)의 이력을 관리한다. 또한 직원은 인사별령으로 부서 및 직책이 바뀔 수 있으며, 이에 대한 이력을 관리한다. 우리는 조직을 관리한다. 조직은 부서코드, 부서명, 조직장(팀장,부장,본부장 등), 상위조직, 조직구분을 관리한다. 부서장은 한사람이 다수 조직의 장으로 겸직할 수 없다. 조직구분은 사장, 부사장, 본부, 부, 팀으로 구분된다.
우리는 평가를 관리한다. 피평가자, 평가자, 평가비율, 평가차수(1~3차), 평가점수, 평가등급(S, A, B, C, D), 최종 평가등급, 평가일자를 관리한다. 최종 평가 등급은 1~3차 값을 합산하여 등급을 평가하며 평가 등급은 평가점수가 95점 이상 S, 90점이상 A, 80점이상 B, 70점 이상 C, 70점 미만 D로 구분한다. 평가등급의 기준은 매년 변경될 수 있다. 평가는 매년 1회 실시하며, 매년 평가에 대한 전체 이력을 관리한다.

나의 답안

모범 답안

주요 Point

뭔가 나의 답안과 모범 답안이 비슷해 보이면서도 많이 다른듯 하다. 어떤 부분이 다른지도 함께 보자

팀원, 팀장, 부장, 본부장, 부사장의 평가 비율이 다르다. 평가년도별 평가 비율이 다를 수 있다.

이부분은 평가년도별로 평가비율을 별도 테이블로 관리를 해야 하며 피 평가자의 직책, 평가 차수에 따라 비율이 달라지기 때문에 PK 구성을 평가년도, 피평가자직책, 평가차수 로 구성해야 한다는것을 의미 한다. 평가 관련된 부분의 엔터티 구성이 사실 좀 어려웠다. 따라서 모범답안에는 없지만 나의 답안에는 평가라는 엔터티를 만든걸 볼수있다. 뭔가 평가의 마스터 엔터티가 필요하다고 판단되서 그렇게 만든건데 모범답안을 보고 나니 굳이 만들 필요는 없겠다는 생각도 들었다.

출신학교는 초등학교부터 최종 학교의 입학년도, 졸업년도, 출신학교명, 출신학교구분(초등~대학원)의 이력을 관리한다

출신학교 엔터티 구성에서 PK를 어떻게 해야 하나 고민을 많이 했다. 모범 답안처럼 사원번호, 입학년도, 졸업년도로 PK를 구성하는걸 첫번째로 생각했지만 현재 사원이 대학원에 진학중이거나 졸업을 못한 경우라면 졸업년도 속성에는 데이터가 NULL이 들어갈 것이라 판단했기에 그렇게 하지는 않았다. 그래서 사원번호, 이력순번으로 PK 구성을 하였는데 이부분은 차라리 순번이 아닌 입학년도를 PK구성에 포함하던지 하는게 좀 더 명확해 보인다.

부서장은 한사람이 다수 조직의 장으로 겸직할 수 없다.

이부분은 사원 엔터티와 부서의 조직장 속성과의 1:1 관계를 가진다는 것을 의미한다. 엔터티 구성에서 1:1 관계는 잘 나오지 않지만 이렇게 한번씩 문제에 나올때 잘 익혀두는것이 중요할 것 같다.

[DAP/모델링 공부] [중급]차량 렌트 회사

Mr. YeokMaSsal — Sun, 14 Aug 2022 10:15:50 +0900

문제

아래는 가상화된 어느 차량렌트회사에 대한 시스템을 구축하고자 한다.

“바른길” 렌탈 트럭회사는 지역 또는 편도 사용을 위한 소형 트럭과 트레일러를 빌려준다. 우리는 347개의 렌탈 사무소를 가지고 있으며 5,780개 다양한 종류의 차량을 구비하고 있다.

우리는 렌탈 계약서를 관리할 시스템을 설치 운용하려고 한다. 각 렌탈 사무소는 바로 고객에게 대여될 수 있는 차량을 빌려 준다. 우리는 예약을 받지 않는다. 고객은 렌탈한 사무소와 반납할 사무소가 다를 수 있다. 대여 시 반납예정일자와 반납사무소를 지정한다. 대여일자와 반납일자가 다를 수 있다. 계약 시 시스템에서 계약번호를 자동으로 채번한다. 실제 반납되었을 경우 실제반납일자를 관리한다.

각 렌탈 사무소는 “대전중부지점”과 같이 자체 사무소명을 갖고 있다. 각 사무소는 또한 사무소별로 유일한 3자리 숫자의 사무소 번호를 갖는다. 우리는 또한 사무소의 주소를 관리한다. 각 차량은 차량번호, 등록상태와 면허번호판 등록번호를 가지고 있다. 우리는 5가지의 차량을 갖고있다 36t트럭, 24t트럭, 10t트럭, 8t덮개 트레일러, 6t무덥게 트레일러. 이를 분류하기 위해 차량종류코드를 가지고 있다. 우리의 모든 차량을 위하여 우리는 마지막 정비일자, 등록 말소일을 관리할 필요가 있다.

우리의 트럭을 위해서는 기름탱크의 용량, 리디오가 작동여부를 알 필요가 있다. 장거리 주행의 경우 고객들은 라디오를 선호한다. 우리는 트럭을 빌려주기 전 현재 몇 Km를 주행했는지 기록하고 트럭이 반납된 후 다시 이를 기록한다.

한 번의 렌탈계약은 한대의 차량만을 렌탈 가능하다. 대부분의 렌탈 계약은 개인 고객과 맺지만 법인과도 맺을 수 있다. 각 계약은 계약 시 렌탈계약번호가 자동으로 채번된다. 우리는 각 법인별로 법인번호를 부여하고 법인명과 주소를 관린한다. 우리는 법인과 개인 정보를 별도로 관리하고 있다.

각 개인고객들에 대해서는 고객명, 자택전화, 주소, 운전면허발급시도, 면허번호, 적성검사일을 기록한다.

렌탈 사무소는 중앙사무소 지방사무소가 있으며, 각 렌탈사무소는 차량을 보유하고 있다. 중앙사무소는 특정 사무소에 너무 많은 차량이 몰리지 않도록 차량을 조정하는 역할도을 한다.

엔터티 & 속성 도출

엔터티는 빨간색, 속성은 파란색, 관계나 주요 사항은 밑줄

아래는 가상화된 어느 차량렌트회사에 대한 시스템을 구축하고자 한다.

우리는 렌탈 계약서를 관리할 시스템을 설치 운용하려고 한다. 각 렌탈 사무소는 바로 고객에게 대여될 수 있는 차량을 빌려 준다. 우리는 예약을 받지 않는다. 고객은 렌탈한 사무소와 반납할 사무소가 다를 수 있다. 대여 시 반납예정일자와 반납사무소를 지정한다. 대여일자와 반납일자가 다를 수 있다. 계약 시 시스템에서 계약번호를 자동으로 채번한다. 실제 반납되었을 경우 실제반납일자를 관리한다.

각 렌탈 사무소는 “대전중부지점”과 같이 자체 사무소명을 갖고 있다. 각 사무소는 또한 사무소별로 유일한 3자리 숫자의 사무소 번호를 갖는다. 우리는 또한 사무소의 주소를 관리한다. 각 차량은 차량번호, 등록상태와 면허번호판 등록번호를 가지고 있다. 우리는 5가지의 차량을 갖고있다 36t트럭, 24t트럭, 10t트럭, 8t덮개 트레일러, 6t무덥게 트레일러. 이를 분류하기 위해 차량종류코드를 가지고 있다. 우리의 모든 차량을 위하여 우리는 마지막 정비일자, 등록 말소일을 관리할 필요가 있다.

우리의 트럭을 위해서는 기름탱크의 용량, 리디오가 작동여부를 알 필요가 있다. 장거리 주행의 경우 고객들은 라디오를 선호한다. 우리는 트럭을 빌려주기 전 현재 몇 Km를 주행했는지 기록하고 트럭이 반납된 후 다시 이를 기록한다.

한 번의 렌탈계약은 한대의 차량만을 렌탈 가능하다. 대부분의 렌탈 계약은 개인 고객과 맺지만 법인과도 맺을 수 있다. 각 계약은 계약 시 렌탈계약번호가 자동으로 채번된다. 우리는 각 법인별로 법인번호를 부여하고 법인명과 주소를 관린한다. 우리는 법인과 개인 정보를 별도로 관리하고 있다.

각 개인고객들에 대해서는 고객명, 자택전화, 주소, 운전면허발급시도, 면허번호, 적성검사일을 기록한다.

나의 답안

모범 답안

주요 Point

트럭을 빌려주기 전 현재 몇 Km를 주행했는지 기록하고 트럭이 반납된 후 다시 이를 기록 한다.

이부분은 크게 신경쓰지 않았던 부분이다. 하지만 모법 답안을 보고나니 트럭에 한해서 주행기록을 관리한다는걸 알아 차렸고 문제를 꼼꼬히 읽어야 겠다고 다시금 깨닫게 되는 순간 이었다. 차량렌탈계약 엔터티에서 트럭일 경우에만 주행거리를 관리하기 위해서는 렌탈계약 엔터티에서 서브타입으로 관리 하는것이 적절해 보인다. 차량 구분을 통해 트럭과 트럭이 아닌것으로 나눈 후 트럭일 경우만 주행거리 속성을 추가하게 되면 문제에서 요구하는 요구사항에 부합되게 된다.

한 번의 렌탈계약은 한대의 차량만을 렌탈 가능하다.

이부분은 결국 렌탈계약 엔터티에 대해서 상세 엔터티는 만들 필요가 없다는것을 의미 한다. 한번의 계약에서 2개이상이 가능하다고 한다면 렌탈계약상세라는 엔터티를 추가적으로 만들어 렌탈계약번호에 추가로 순번이나 차량번호를 포함한 결합속성 PK를 구성해야 했을 것이다. 하지만 하나의 계약은 한대의 차량만 계약이 가능하다는건 계약 엔터티에서 차량 정보도 입력할 수 있다는것을 의미하기 때문에 추가적으로 엔터티를 도출할 필요가 없다.

우리는 법인과 개인 정보를 별도로 관리하고 있다

이부분은 법인과 개인 엔터티를 분리해서 만들어야 한다는것을 의미한다. 그리고 '대부분의 렌탈 계약은 개인 고객과 맺지만 법인과도 맺을 수 있다' 이 문구에서 알수 있듯이 계약은 법인, 개인이 동시에 될수 없는 배타적 관계라는것을 의미한다. 따라서 계약엔터티와 관계를 가지되, 배타관계로 관계설정을 해주어야 한다.

사무소는 차량을 보유하고 있다. 중앙사무소는 특정 사무소에 너무 많은 차량이 몰리지 않도록 차량을 조정하는 역할도을 한다.

이부분은 차량과 사무소와 관계가 있다는 것을 의미하며, 차량 엔터티에 소속사무소번호를 FK로 가지고 있게되면 사무소별 차량 보유 수를 알수 있고 '중앙사무소는 특정 사무소에 너무 많은 차량이 몰리지 않도록 차량을 조정하는 역할도을 한다' 이 문구도 해결 할 수있게 된다.

차량종류코드 서브 타입.

라디오작동여부, 기름탱크용량, 주행거리 등은 트럭인 경우에만 관리 해야 한다고 하고 차량종류코드는 3가지의 트럭을 관리하고 있어 이것을 어떻게 해결해야 할지 고민이 되었다. 모범답안 처럼 처리하는것이 정답이겠지만 내가 제시한 답안 처럼 해도 물리모델로 변경했을 경우 속성의 중복은 발생하지 않는다.

Mysql File Table에 Insert

Mr. YeokMaSsal — Sat, 13 Aug 2022 12:35:16 +0900

/*=======================================================
 * 		01. DATABASE 생성 
 *======================================================= */
CREATE DATABASE O2JOB_DB;


/*=======================================================
 * 		02. 해당 DATABASE에서 테이블 생성
 *======================================================= */
DROP TABLE TEST_TB_01;
CREATE TABLE TEST_TB_01
(
	COUNT_DATA INT
	, DO_DATA INT
	, TDS_dATA INT
	, ORP_DATA  INT
	, PH_DATA       INT
	, TURBIDITY_DATA INT
	
);


/*=======================================================
 * 		03. 파라미터 값 확인
 *======================================================= */

/*	아래의 쿼리 결과가 NULL 값이 아니라면 my.ini 파일 or my.cnf 파일에 아래 문구 추가 및 수정
 *   
 *  [mysqld]
	secure-file-priv = ""
 	
 	그런 다음 mysql 재시작
 * * */
-- 
-- 
SHOW VARIABLES LIKE '%infile%';

/*=======================================================
 * 		04. 파일 업로드 테스트
 *======================================================= */
TRUNCATE TABLE TEST_TB_01;
LOAD DATA INFILE 'D:/TEST.txt' INTO TABLE TEST_TB_01 FIELDS TERMINATED BY ' ' LINES TERMINATED BY '\n'
(COUNT_DATA, DO_DATA, TDS_dATA, ORP_DATA, PH_DATA, TURBIDITY_DATA );


SELECT * FROM TEST_TB_01;

Mysql 일단위 백업 자동화

Mr. YeokMaSsal — Sat, 13 Aug 2022 12:33:00 +0900

1.백업 스크립트 쉘 생성

#!/bin/bash
echo " "
echo "## Backup Start"
echo " "
datetime=$(date +%Y_%m_%d)
echo "## 2일전 백업 삭제 하기"
echo " "
sudo find /home/ec2-user/backup/*.tar.gz -ctime +2 -exec rm -f {} \;

echo "## DB 백업"
echo " "
mysqldump -u root -p'[패스워드]' --all-databases > /home/ec2-user/backup/mysql_bak_$datetime.sql
tar -zcvf /home/ec2-user/backup/mysql_bk_$datetime.tar.gz /home/ec2-user/backup/mysql_bak_$datetime.sql
rm -rf *.sql

echo "## Backup finish"
echo " "

2.쉘 권한 변경

chmod +x backup.sh

3.Crontab 등록

# 크론탭 수정
crontab -e

# 등록 (매일 0시0분에 돌아감)
0 0 * * * /home/ec2-user/backup/backup.sh

백업 및 복원 [feat - mysqldump]

Mr. YeokMaSsal — Fri, 12 Aug 2022 23:23:16 +0900

백업

모든 DB 백업

-- all-databases 옵션을 사용한다.

mysqldump -u아이디 -p --all-databases > 저장할파일명.sql 
ex) mysqldump -uroot -p --all-databases > all.sql

# 데이터베이스를 미리 생성해서 작업하기
mysql -u root -p -e "create database database_name";
mysql -u root -p database_name < database_name.sql

# 압축된 데이터베이스 백업
mysqldump database_name | gzip > database_name.sql.gz

타임스탬프를 이용하여 백업 생성

둘 이상의 백업을 동일한 위치에 유지하려면 백업 파일 이름에 현재 날짜를 추가할 수 있다.

mysqldump  database_name > database_name-$(date +%Y%m%d).sql

특정 DB 백업

# 단일 DB 백업
mysqldump -u root -p database_name > database_name.sql

# 다수의 DB 백업 (띄어쓰기로 구분한다)
mysqldump -u root -p database_name1 database_name1 > database_name.sql

특정 DB의 특정 테이블 백업

mysqldump -u아이디  -p비밀번호 dbname t1 t2 > D:\>backup\table.sql

특정 테이블만 제외하고 백업

mysqldump -u아이디  -p비밀번호 dbname --ignore-table=dbname.t1 --ignore-table=dbname.t2 > D:\>backup\table.sql

다른 db에 호환되게 백업

—compatible 옵션은 mysql 4.1 버전부터 사용할수 있다. 아래의 명령을 이전 버전인 4.0으로 다운그레이드 할 때 사용할 수 있는 옵션이다.

그외 사용할 수 있는 옵션은 아래와 같다

ansi, mysql323, mysql40, postgresql, oracle, mssql, db2, maxdb, no_key_options, no_table_options, no_field_options

mysqldump -u아이디 -p비밀번호 dbname --compatible=mysql40 > dbname.sql

테이블 스키마만 백업

insert 문을 제외하고 생성 스크립트만 백업 한다.

mysqldump -u아이디 -p비밀번호 --no-data dbname > D:\>backup\dbname.sql

mysqldump -u아이디 -p비밀번호 -d dbname > D:\>backup\dbname.sql

복구

전체 복구

mysqldump -u아이디 -p < 백업파일명.sql

특정 db만 복구

mysql --one-database database_name < all_databases.sql

단일 명령으로 데이터베이스 내보내고 가져오기

한 데이터베이스에서 덤프 파일을 만든 다음 백업을 다른 MySQL 데이터베이스로 가져오는 대신 아래와 같이 한방에 처리할 수 있다.

mysqldump -u root -p database_name | mysql -h remote_host -u root -p remote_database_name

백업 파일 신규 db에 복구시키기

# 신규 db를 미리 생성 해놔야 한다.
mysql -u root -p new_database < bakup.sql

# 덤프 파일 생성시 --no-create-db 옵션 추가
mysqldump -u root -p --opt --routine --triggers --no-create-db DB1 > BACKUP_DB1.sql

# 복구시(mysql 접속하여 원하는 db로 접속)
mysql> CREATE DATABASE DB_NEW;
mysql> USE DB_NEW;
mysql> SOURCE BACKUP_DB1.sql

DB의 테이블 생성 DDL만 덤프

아래와 같이 실행하면 AUTO_INCREMENT 값이 1부터 설정되지 않고 개발용 MYSQL에서 사용되던 마지막 자동 증가값이 명시되어 덤프된다. 그래서 DDL을 덤프 받아서 생성할때는 반드시 AUTO_INCREMENT 값을 1로 모두 초기화 하거나 CREATE TABLE 문에 'AUTO_INCREMENT=xxx' 옵션을 제거하고 사용하는것이 좋다.

mysqldump -u root -p --opt --routines --triggers --database DB1 DB2 > schema.sql

mysqldump 옵션

https://puham.tistory.com/56

mysqldump 옵션 설명

mysqldump 의 사용법 백업뿐만 아니라, 데이터의 이관이나 복제등과 같이 어떤 MySQL 서버에서 다른 서버로 데이터를 옮기는 경우 MySQL 패키지에 기본적으로 포함되어 있는 mysqldump라는 도구를 자주

puham.tistory.com

Replication

Mr. YeokMaSsal — Thu, 11 Aug 2022 23:41:25 +0900

Replication 이란?

리플리케이션(Replication)은 복제를 뜻하며 2대 이상의 DBMS를 나눠서 데이터를 저장하는 방식이며, 사용하기 위한 최소 구성은 Master / Slave 구성해야 한다.

Master DB
웹서버로 부터 데이터 등록/수정/삭제 요청시 바이너리로그(Binarylog)를 생성하여 Slave 서버로 전달하게 됩니다 (웹서버로 부터 요청한 데이터 등록/수정/삭제 기능을 하는 DBMS로 많이 사용됩니다)
Slave DB
Master DBMS로 부터 전달받은 바이너리로그(Binarylog)를 데이터로 반영하게 된다. (웹서버로 부터 요청을 통해 데이터를 불러오는 DBMS로 많이 사용된다.)

Replication의 목적

데이터 백업
Master 서버에 DBMS의 등록/수정/업데이터가 생기는 즉시 Slave 서버의 변경된 데이터를 전달하게 된다 이러한 과정으로 데이터의 백업을 할수 있으며, 또한 Master 서버의 장애가 생겼을 경우 Slave 서버로 변경하여 사용할수 있다.

DBMS 부하 분산
사용자의 폭주로 인해 1대의 DB서버로 감당할수 없을때, MySQL 리플리케이션(Replication)을 이용하여 같은 DB 데이터를 여러대를 만들수 있기에 부하를 분산하수 있다.

Replication 주의 사항

1. 호환성을 위해 Replication Mysql 버전을 동일하게 맞추는것이 좋다.

2. 서로 버전이 다른 경우 Slave 서버 버전이 상위 버전이여야 한다.

3. Replication 가동시 Master, Slave 순으로 가동시켜야 한다.

Replication 구성 절차

[Master] 서버 접속 후 유저 생성 및 권한 부여

/* 유저 생성 */
create user 'replication_user'@'%' identified by 'dusqhd10djr!!QQ';

/* 권한 생성 */
GRANT REPLICATION SLAVE ON *.* to 'replication_user'@'%';
flush privileges;

[Master] database 및 테이블 생성

/* DB 생성 */
create database replica_db;
use replica_db;

/* TABLE 생성 */
create table replication_tb(id INT AUTO_INCREMENT Primary key,name VARCHAR(30));

[Master] my.cnf 파일 설정

# 아래 설정 확인 및 추가
log-bin=mysql_bin
server-id=1
binlog-do-db=replica_db
log-slave-updates

[Master] mysql restart

service mysqld restart

[Master] 덤프 생성

mysqldump -u replication_user -p --single-transaction --master-data=2 --routines --triggers  replica_db > replica_ec2_dump.sql

## 파일 확인
ls -al

[Master] binlog와 포지션 확인하기

less replica_ec2_dump.sql


-- MySQL dump 10.13  Distrib 5.7.35, for Linux (x86_64)
--
-- Host: localhost    Database: MIG_TEST_DB
-- ------------------------------------------------------
-- Server version       5.7.35-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Position to start replication or point-in-time recovery from
--

## -------------------------------------------------------------------
#  아래의 파일명과 포지션 복사해놓기		
## -------------------------------------------------------------------
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql_bin.000001', MASTER_LOG_POS=1285;

--
-- Current Database: `MIG_TEST_DB`
--

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `MIG_TEST_DB` /*!40100 DEFAULT CHARACTER SET latin1 */;

USE `MIG_TEST_DB`;

[Slave] my.cnf 파일 설정

log-bin=mysql_bin
server-id=2
read_only=1

[Slave] restart 하기

service mysqld restart

[Slave] Master db 정보 입력

CHANGE MASTER TO MASTER_HOST='3.36.58.83'
     , MASTER_PORT=3306
	 , MASTER_USER='replication_user'
	 , MASTER_PASSWORD='dusqhd10djr!!QQ'
	 , MASTER_LOG_FILE='mysql_bin.000007'
	 , MASTER_LOG_POS=150 ;

[Slave] start slave하기

start slave

[Slave] 결과 확인

show slave status \G;
*************************** 1. row ***************************

..생략...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes


..생략...



# 둘다 YES가 나오면 성공이다.

예외 상황

만약 둘중 하나라도 NO가 나온 경우

Last_IO_Error: Fatal error: The SLAVE I/O thread stops because MASTER AND SLAVE have equal MySQL SERVER UUIDs; these UUIDs must be different FOR REPLICATION TO work.

해당 에러는 Slave DB 서버의 auto.cnf 파일에 현재 서버의 UUID가 적혀있는데, 이 파일까지 Master DB 서버에서 함께 가져와서 발생하는 에러다.

다음 명령어 들로 해결해보자

systemctl stop mysqld
rm -rf /var/lib/mysql/auto.cnf
systemctl start mysqld

이후 다시 slave를 start하고 확인해보면 적용이 되어 있을 것이다.

Duplicate 이슈

Last_Error: Error 'Duplicate key name 'oauth_users_name_domain'' on query. Default database: 'cyauth'. Query: 'create index oauth_users_name_domain on oauth_users( username , domain , userid )'

이런 경우 slave stop을 하고 아래와 같이 해주면 된다.

SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;

/*
여기선 중복 에러 나는 것이 1개 이므로, 여러 개 일 경우 숫자를 크게
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=100 ;

또는 위에 에러 번호가 1061 이였으므로, my.cnf 파일에 다음과 같이 설정 가능
my.cnf
slave-skip-errors = 1061,1062,1063    등등 스킵하고 싶은 에러번호 나열
*/

AWS RDS 경우

AWS RDS의 EC2로 진행하는 경우 보안그룹에 각각의 Public ip를 열어 줘야 한다.

less replica_dump.sql

-- MySQL dump 10.13  Distrib 5.7.35, for Linux (x86_64)
--
-- Host: localhost    Database: MIG_TEST_DB
-- ------------------------------------------------------
-- Server version       5.7.35-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Position to start replication or point-in-time recovery from
--

## -------------------------------------------------------------------
#  아래의 파일명과 포지션 복사해놓기		
## -------------------------------------------------------------------
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql_bin.000001', MASTER_LOG_POS=1285;

--
-- Current Database: `MIG_TEST_DB`
--

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `MIG_TEST_DB` /*!40100 DEFAULT CHARACTER SET latin1 */;

USE `MIG_TEST_DB`;

binlog 와 redo log 차이

Mr. YeokMaSsal — Thu, 11 Aug 2022 23:28:00 +0900

binlog

Mysql 서버에서 CREATE, DROP, ALTER와 같은 DDL과 DML을 통해 DB에 변경사항이 생길때 그 변화된 이벤트를 기록하는 이진 파일이 있는데 이것이 바로 바이너리 로그(binlog)라고 한다. slow나 select등 조회 문법은 제외되며 binlog는 2가지의 중요한 용도가 있다.

주로 binlog는 replication 구성이나 HA 구성시에 활용되는 로그이며, 또한 특정시점 복구(Point in time)에 주로 사용된다.

redolog

하드웨어나 소프트웨어 등 여러가지 문제점으로 인해 mysql 서버가 비정상 적으로 종료 됐을때 데이터 파일에 기록되지 못한 데이터를 잃지 않게 해주는 안정 장치 역할으 하는 로그이다.

데이터가 변경되는 경우 데이터파일에 쓰려면 많은 비용이 들어간다. 그로인한 성능저하를 막기 위해 redolog에 해당 내용을 가지고 있으며 서버가 다운되면 커밋됐지만 데이터 파일에 기록되지 않은 데이터는 redolog를 통해 복구 할 수 있다.

차이점

redolog는 innodb에만 해당하는 로그이며 binlog는 mysql 서버계층에 구현되어 있다.
redolog는 innodb 엔진 레벨의 물리적 로그 이며 binlog는 SQL Statement에 상응하는 논리적 로그이다. 즉 리두 로그는 데이터 페이지의 변경 사항을 기록하는 물리적 로그이며. binlog는 명령문의 원래 논리를 기록하는 논리 로그란 소리다.
redolog는 복수의 고정 사이즈의 파일로 이루어져 있으며 binlog는 일련번호로 파일이 생성된다.
바이너리 로그는 트랜잭션 커밋이 완료된 후 한 번만 기록되며, InnoDB 스토리지 엔진의 redo 로그는 트랜잭션에 지속적으로 기록된다.

[DAP/모델링 공부][중급] PC제조 및 판매

Mr. YeokMaSsal — Wed, 10 Aug 2022 22:02:07 +0900

문제

우리 회사는 PC를 조립하여 판매하는 회사이다. 나는 재고관리부터 생산, 판매관리의 전 과정을 관리하는 시스템을 만드는 중이다.

우리는 PC를 조립하기 위하여 다양한 업체로 부터 부품을 공급받는다. 부품은 외장 케이스, 마더보드, 비디오카드, 하드 디스크등 다양하게 존재한다. 부품번호, 부품명, 재고수량을 관리한다. 각 부품은 다양한 업체에서 납품을 한다. 우리는 납품업체를 업체번호, 업체명, 연락처를 관리한다. 동일한 부품을 두 개 이상의 업체에서 납품하기도 한다. 또한 각 업체별로 납품한 부품, 납품일자, 납품수량을 관리한다. 한 업체에서는 동일한 부품을 하루에 한번만 납품하며, 2번이상 납품하지 않는다.

공장은 생산라인이 다양하게 존재하며, 이를 관리한다. 생산라인번호, 라인구축일자를 관리한다. 사원은 사원번호, 이름, 연락처를 관리한다. 각 부서는 별도 부서로 관리하지는 않으나, 생산직과 관리직을 구분하고, 생산직일 경우 어느 생산라인에 소속되어 있는지 관리한다.

각 생산 라인별 매일 사용한 부품의 사용개수를 관리한다.

PC는 다양한 모델별로 구분된다. 모델별 각 부품이 몇 개씩 소요되는지 관리한다. 또한 공장에서 생산 완료한 PC를 관리한다. 또한 생산완료한 PC는 제조일련번호, 제조단가, 제조일자, 모델번호,모델명을 관리하며, 또한 어느 생산라인에서 생산된 PC인지를 관리해야 한다.

우리는 다양한 매장을 보유하고 있다. 매장은 매장주소, 연락처를 관리한다.각 제품별로 어느 매장으로 할당 되었는지 관리한다.PC가 최초 생산되어 매장에할당 되지 않았을 경우 본사에 위치한 매장에 할당된 것으로 처리한다.PC는 각 매장 간 이동 배치할 수 있으나,이력은 관리하지 않는다.

엔터티, 속성 정보 추출

문제를 읽고 엔터티로 추출할건 빨간색, 속성으로 추출할건 파란색, 관계선과 관련이 있거나 주요하게 봐야 하는건 밑줄을 긋는다.

우리 회사는 PC를 조립하여 판매하는 회사이다. 나는 재고관리부터 생산, 판매관리의 전 과정을 관리하는 시스템을 만드는 중이다.

각 생산 라인별 매일 사용한 부품의 사용개수를 관리한다.

나의 답안

모범 답안

Point

한 업체에서는 동일한 부품을 하루에 한번만 납품하며, 2번이상 납품하지 않는다

하루에 한번만 납품을 한다는 의미는 곧 납품일자를 PK로 생성 해야 한다는것을 의미 한다.

부서는 별도 부서로 관리하지는 않으나, 생산직과 관리직을 구분하고, 생산직일 경우 어느 생산라인에 소속되어 있는지 관리

부서는 별도로 관리 하지 않는다. → 부서 엔터티는 만들지 않는다.
생산직과 관리직을 구분하고, 생산직일 경우 어느 생산라인에 소속되어 있는지 관리 한다. → 사원 엔터티에서 속성으로 관리 하며 생산직 부서일 경우 공장 엔터티와 관계를 가진다.

PC가 최초 생산되어 매장에 할당 되지 않았을 경우 본사에 위치한 매장에 할당된 것으로 처리한다

본사와 본사가 아닌 경우를 구분해야 한다. 즉 매장 구분을 두어야 한다는 의미다.
완료PC 엔터티에서 매장 할당 여부를 관리 하여

binlog

Mr. YeokMaSsal — Wed, 10 Aug 2022 21:10:11 +0900

binlog란?

binlog용도

1. 복제 구성에 사용

Mysql에서는 Replication이라는 부하분산 기능을 제공하는데 이때 binlog를 사용한다. binlog는 master-slave구조에서 master db에 생성이 되고 slave db는 master db의 binlog를 읽어들여 똑같이 이벤트를 발생시켜 master와 동일한 구조로 만들게 된다.

Replication 순서

Master db가 트랜잭션이 커밋되는 순간 binlog에 이벤트를 생성하여 기록을한다.
슬레이브는 IO Thread를 통해서 마스터에 이벤트를 요청하고 받는다.
마스터는 이벤트를 요청 받으면 binlog dump thread를 통해서 클라이언트에게 이벤트를 전송한다.
IO Thread는 전송받은 dump log를 이용하여 relay log를 만든다
SQL Thread는 relay log를 읽어서 이벤트를 다시 실행하여 slave에 데이터를 복사한다.

2. 특정시점에 복구에 사용

db를 사용하다 보면 데이터 삭제나 db가 어떤 이유로 장애나 crash가 발생할 시 복구를 해야할 때가 있다. 이때 특정 시점으로 돌아가야 하는데 특정 시점 시간으로 돌아갈때 binlog를 사용한다.

binlog 활성화 방법

binlog 활성화 방법은 2가지 있다.

1. 서버구동시 설정 방법

mysql 구동시에 binlog를 활성화 시키는 방법인데 이 방법은 mysql을 재시작하는 경우는 적용이 다시 안되기 때문에 추천하지 않는 방법 이다.

[root@localhost]# mysqld_safe --log-bin=systemv-bin-log &

## --log-bin=VALUE 과 같은 형식으로 사용할수 있는데 VALUE에는 파일경로/파일명을 쓸수 있다.
## VALUE값을 생략하면 data_dir 디렉토리에 hostname-bin 이라는 이름으로 생성된다.
## (라고 모든 MySQL 공식 도큐먼테이션에서 밝히지만 5.5버전 이후에서 테스트 했을시 mysqld-bin 으로 생성되더라.
## hostname 변경시 발생될 수 있는 변수 상황을 피하기 위함이라 생각한다.)

2. my.cnf 설정

my.cnf 파일에다가 binlog를 설정하는 방법이다. binlog는 정적 파라미터 이기 때문에 서버 restart를 해야 적용이 된다.

[mysqld]
# 절대 경로를 지정해 줄수도 있고 log-bin만 설정 해도 된다.
# 경로지정을 생략하면 data_dir 디렉토리에 hostname-bin 이라는 이름으로 생성된다.
log-bin=/var/log/mysql_bin 
server-id=1
binlog_format=ROW
expire_logs_days=7
binlog_checksum=NONE
binlog_row_image=FULL

my.cnf 설정 옵션

log-bin
binlog를 활성화 하기 위한 옵션으로 binlog 파일이 저장될 경로나 파일 이름을 설정 할수 있다. 경로나 파일명 없이 log-bin만 적을 경우나 파일명만 적을 경우default로 /var/lib/mysql 경로에 생성 된다.
server-id
master와 slave의 서버는 다르면 되며 아무 숫자나 사용이 가능하다.
binlog_format
binlog에 저장되는 포맷을 설정하는 값으로써 ROW, STATEMENT, MIXED 3가지의 설정 값이 있다.
Mysql 5.7.6 까지는 기본값이 STATEMENT이고 그 이후 버전은 ROW가 기본값이다.(클러스터는 예외로 MIXED)
1. ROW : 행기반 방식이다. STATEMENT방식과는 좀 다르게 개별 테이블 행이 어떻게 영향을 받는지를 나타내는 이벤트를 binlog에 쓴다. SQL 문법이 아니라 결과값을 binlog에 저장하게 된다. 따라서 테이블은 항상 pk를 사용하여 행을 효율적으로 식별 할 수 있도록 하는것이 중요하다.
2. STATEMENT : 가장 전통적인 방식이며 마스터에서 실행한 SQL을 그대로 바이너리 로그에 작성하고 그 로그를 슬레이브로 전송하여 슬레이브에도 실행하게 하는 방식이다.
3. MIXED : 혼합로깅 방식이며 기본적으로 STATEMENT방식로깅이 사용되지만 특정 로깅의 경우 ROW 방식의 로깅으로 전환된다.
※ 주의할점그렇기 때문에 read-committed에서는 row방식이나 이런 상황에서 자동으로 row형태로 변경해주는 mixed방식을 사용해야 한다.
isolation level이 read-committed일 경우 현재 트랜잭션이 종료되지 않았더라도 다른 트랙잭션에서 동일한 데이터의 commit이 일어나면 현재 트랜잭션에서도 변경된 값이 보이게 된다.이런 환경에서 statement방식을 사용하게 되면 트랜잭션 단위로 순서대로 로깅하기 때문에 복구나 슬레이브동기화시 원하는 바와 달리 다른 결과가 나타날 수 있다.
binlog에 저장되는 포맷을 설정하는 값으로써 ROW, STATEMENT, MIXED 3가지의 설정 값이 있다.
expire_logs_days
binlog 파일 보관 기간(일 단위), default 0, 즉 binlog를 삭제하지 않음
binlog_cache_size
트랜잭션을 처리하는 스레드가 시작되면 binlog_cache_size라는 옵션에 설정되어 있는 크기만큼 버퍼를 할당 한다. 그리고 명령문을 이곳에 저장하게 된다.
크기가 큰 트랜잭션을 자주 사용하는 db의 경우 binlog_cache_size에 저장하지 못해 disk에 쓰게 되는데 이런경우 binlog_cache_size를 늘려주어 성능을 향상 시킬 수 있다. default값은 32kb이다.
max_binlog_size
binlog 파일의 최대 크기 지정(단위 G,M,K,bytes), default 1G, MAX도 1G
binlog_checksum
Replication 구조에서 binlog event가 문제없이 전달되고 있음을 보장하기 위한 수단에서 도입된것으로 5.6 부터 도입이 됨
문제란?
- 하드웨어 문제 : 메모리 fault, 디스크 깨짐
- 소프트웨어 문제 : I/O thread 버그 등
- 네트워크 문제 : 네트워크 중단 등
binlog에 쓰여지는 각 event 마다 binlog checksum 을 같이 기록함으로써 binlog를 기록할 때 뿐 아니라 슬레이브가 binlog 를 가져갈 때도 체크함으로써 전체 Replication 구조에서 모두 문제가 없음을 보장 받게 된다. 이 때 iso-3309에 제시된 CRC32 checksum 알고리즘을 사용하여 체크한다. NONE값을 사용하게 되면 이 checksum을 하지 않겠다는 뜻이다.
binlog_row_image-
binlog_format을 row로 했을때 로깅한 컬럼 set을 설정할수 있다 (FULL, MINIMAL, NOBLOB)
- FULL : 변경 전/후 이미지를 전체 binlog에 기록(Default)
- MINIMAL : 최소한의 값만 로깅, 변경된 행을 식별하는 데 필요한 이전 이미지의 열만 기록
- NOBLOB : BLOB, TEXT와 같이 사이즈가 큰값을 제외하고 로깅

binlog 설정에 대해 더 자세한 내용은 아래 링크 참조

https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html

MySQL :: MySQL 5.7 Reference Manual :: 16.1.6.4 Binary Logging Options and Variables

16.1.6.4 Binary Logging Options and Variables You can use the mysqld options and system variables that are described in this section to affect the operation of the binary log as well as to control which statements are written to the binary log. For additi

dev.mysql.com

binlog 읽기 위한 권한

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO  {ID}@'{IP}'  IDENTIFIED BY '{PWD}';

binlog 삭제 방법

purge master logs to ‘mysql-bin.000020’;

binlog를 SQL로 변환

1. binlog 저장 경로 찾기

2. mysqlbinlog 를 이용하여 파일 변환 하기

mysqlbinlog /var/lib/mysql/mysql_bin.000002 > binlog.sql

3. 변환 파일 확인

cat binlog.sql

mysqlbinlog 옵션

일반적으로 볼때

## 일반적으로 볼때

mysqlbinlog log_file
...
# at 218
#080828 15:03:08 server id 1  end_log_pos 258   Write_rows: table id 17 flags: STMT_END_F

BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ==
'/*!*/;
...
# at 302
#080828 15:03:08 server id 1  end_log_pos 356   Update_rows: table id 17 flags: STMT_END_F

BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/*!*/;
...
# at 400
#080828 15:03:08 server id 1  end_log_pos 442   Delete_rows: table id 17 flags: STMT_END_F

BINLOG '
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP

-v옵션 : SQL 형식으로 보여줌

## -v 옵션을 사용하면 사람이 읽을 수 있는 SQL로 출력된다.

$> mysqlbinlog -v log_file
...
# at 218
#080828 15:03:08 server id 1  end_log_pos 258   Write_rows: table id 17 flags: STMT_END_F

BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ==
'/*!*/;
### INSERT INTO test.t
### SET
###   @1=1
###   @2='apple'
###   @3=NULL
...
# at 302
#080828 15:03:08 server id 1  end_log_pos 356   Update_rows: table id 17 flags: STMT_END_F

BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/*!*/;
### UPDATE test.t
### WHERE
###   @1=1
###   @2='apple'
###   @3=NULL
### SET
###   @1=1
###   @2='pear'
###   @3='2009:01:01'
...
# at 400
#080828 15:03:08 server id 1  end_log_pos 442   Delete_rows: table id 17 flags: STMT_END_F

BINLOG '
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP
'/*!*/;
### DELETE FROM test.t
### WHERE
###   @1=1
###   @2='pear'
###   @3='2009:01:01'

-vv 옵션 :SQL에 컬럼 메타정보도 함께 보여줌

## -vv 옵션은 컬럼의 메타정보도 함께 출력된다.

$> mysqlbinlog -vv log_file
...
# at 218
#080828 15:03:08 server id 1  end_log_pos 258   Write_rows: table id 17 flags: STMT_END_F

BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ==
'/*!*/;
### INSERT INTO test.t
### SET
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='apple' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
###   @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
...
# at 302
#080828 15:03:08 server id 1  end_log_pos 356   Update_rows: table id 17 flags: STMT_END_F

BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/*!*/;
### UPDATE test.t
### WHERE
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='apple' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
###   @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
### SET
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='pear' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
###   @3='2009:01:01' /* DATE meta=0 nullable=1 is_null=0 */
...
# at 400
#080828 15:03:08 server id 1  end_log_pos 442   Delete_rows: table id 17 flags: STMT_END_F

BINLOG '
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP
'/*!*/;
### DELETE FROM test.t
### WHERE
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='pear' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
###   @3='2009:01:01' /* DATE meta=0 nullable=1 is_null=0 */

-base64-output=DECODE-ROWS 와 --verbose 옵션의 조합 : binary 값도 없애고 보여줌

shell> mysqlbinlog -v --base64-output=DECODE-ROWS log_file

...

# at 218

#080828 15:03:08 server id 1  end_log_pos 258   Write_rows: table id 17 flags: STMT_END_F

### INSERT INTO test.t

### SET

###   @1=1

###   @2='apple'

###   @3=NULL

...

# at 302

#080828 15:03:08 server id 1  end_log_pos 356   Update_rows: table id 17 flags: STMT_END_F

### UPDATE test.t

### WHERE

###   @1=1

###   @2='apple'

###   @3=NULL

### SET

###   @1=1

###   @2='pear'

###   @3='2009:01:01'

...

# at 400

#080828 15:03:08 server id 1  end_log_pos 442   Delete_rows: table id 17 flags: STMT_END_F

### DELETE FROM test.t

### WHERE

###   @1=1

###   @2='pear'

###   @3='2009:01:01'

자세한 내용은 아래 링크 참조

MySQL :: MySQL 5.7 Reference Manual :: 4.6.7.2 mysqlbinlog Row Event Display

4.6.7.2 mysqlbinlog Row Event Display The following examples illustrate how mysqlbinlog displays row events that specify data modifications. These correspond to events with the WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT, and DELETE_ROWS_EVENT type codes. The --b

dev.mysql.com

binlog를 이용하여 특정 테이블 시점 복구하기

1. 테스트 db & 테이블 생성

CREATE DATABASE db_test;
USE DATABASE db_test;

/* TABLE 생성 및 데이터 입력*/
create table binlogtest (name varchar(10));

insert into binlogtest values ('1');
insert into binlogtest values ('2');
insert into binlogtest values ('3');
insert into binlogtest values ('4');
insert into binlogtest values ('5');
insert into binlogtest values ('6');
commit;

select * from binlogtest;
+------+
| name |
+------+
| 1    |
| 2    |
| 3    |
| 4    |
| 5    |
| 6    |
+------+

2. mysqldump를 이용한 백업

 mysqldump --single_transaction --databases db_test --flush_logs -u root -p > db_test_dump.sql

3. 데이터 추가 삽입

insert into binlogtest values ('7'),('8'),('9'),('10');
commit;

select * From binlogtest;
+------+
| name |
+------+
| 1    |
| 2    |
| 3    |
| 4    |
| 5    |
| 6    |
| 7    |
| 8    |
| 9    |
| 10   |
+------+

4. database drop 시키기

DROP DATABASE db_test;

5.binlog 파일 .sql 파일로 변환

## 현재 mysql_bin.000001 ~ mysql_bin.000004 까지 총 4개의 binlog 파일이 존재함
[root@ip-10-0-1-201 mysql]# ll
total 122984
....
-rw-r----- 1 mysql mysql     1509 Sep 17 13:17 mysql_bin.000001
-rw-r----- 1 mysql mysql     7381 Sep 18 14:23 mysql_bin.000002
-rw-r----- 1 mysql mysql     3338 Sep 18 14:52 mysql_bin.000003
-rw-r----- 1 mysql mysql     2429 Sep 18 16:14 mysql_bin.000004
-rw-r----- 1 mysql mysql     1912 Sep 18 16:16 mysql_bin.000005
-rw-r----- 1 mysql mysql       95 Sep 18 16:14 mysql_bin.index
....


## 마지막 binlog 파일에서 drop database 전까지 찾아서 그 부분에서 stop-position을 해야함
mysqlbinlog --verbose -d db_test ../mysql_bin.000001 > data_backup_bin_01.sql
mysqlbinlog --verbose -d db_test ../mysql_bin.000001 > data_backup_bin_02.sql
mysqlbinlog --verbose -d db_test ../mysql_bin.000001 > data_backup_bin_03.sql
mysqlbinlog --stop-position="468" --verbose -d db_test ../mysql_bin.000004 > data_backup_bin_04.sql

6. mysqldump를 이용한 복구 진행

mysql -u root -p < db_test_dump.sql

7. 확인

show databases;
+--------------------+
| Database           |
+--------------------+
| classicmodels      |
| db_test            |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test               |
+--------------------+

/* 추가입력 전 까지 복구 완료 */
select * from db_test.binlogtest;
+------+
| name |
+------+
| 1    |
| 2    |
| 3    |
| 4    |
| 5    |
| 6    |
+------+

8. 백업 이후 추가입력건 까지 복구 시키기(binlog)

mysql -u root -p < data_backup_bin_01.sql
mysql -u root -p < data_backup_bin_02.sql
mysql -u root -p < data_backup_bin_03.sql
mysql -u root -p < data_backup_bin_04.sql

9. 확인

/* 복구완료 */
select * from db_test.binlogtest;
+------+
| name |
+------+
| 1    |
| 2    |
| 3    |
| 4    |
| 5    |
| 6    |
| 7    |
| 8    |
| 9    |
| 10   |
+------+

참고 페이지

binlog를 이용한 백업&복구

Binlog를 사용하여 백업&복구에 사용할 수 있습니다. 시점복구(PIT)가 가능합니다. 즉, 특정 시점의 binlog파일을 이용하여 특정시점이후의 데이터가 복구가 가능하다는 것입니다. 이론적으로, mysqldu

bae9086.tistory.com

MySQL 특정 테이블만 시점복구 하기

MySQL 특정 테이블만 시점복구 하기 얼마 전 서비스 로직 이슈로 특정 데이터들이 CASCADE 삭제되어 데이터가 유실되는 일이 발생했습니다. 영향 받은 테이블들은 전체 테이블들 중 두개였고 전체

kimdubi.github.io

binlog 일단위로 파일 만들기

#!/bin/bash

# LOG Backup date
LogDate=$(date + '%Y%m%d' -d '1 day ago');

# Date Home Path
DatePath="/SSP_DEV_DATA/data01/";

# Log Home Path
DataLogPath=$DataPath."/log/slow";

# Mysql Home Path
mysqlPath="/SSP_DEV/mysql5/bin/";

echo $LogDate
echo $DataPath

cd $DataLogPath;

mv mysql-slow.log mysql-slow-$LogDate.log

cd $mysqlPath

./mysqladmin -uroot -pssp_bespin456 --sockect=/[mysqld경로]/mysqld.sock flush-logs;

Mysql Slow Query Log

Mr. YeokMaSsal — Tue, 9 Aug 2022 20:54:47 +0900

Slow Query Log 확인 절차

1. 현재 설정 확인

mysql> SHOW VARIABLES LIKE 'slow_query_%';
+---------------------+---------------------------------------+
| Variable_name       | Value                                 |
+---------------------+---------------------------------------+
| slow_query_log      | OFF                                   |
| slow_query_log_file | /var/lib/mysql/ip-10-0-1-175-slow.log |
+---------------------+---------------------------------------+
2 rows in set (0.00 sec)

2. my.cnf 설정파일 변경

# my.cnf 파일 변경
sudo vi /etc/my.cnf


# 설정 값 입력
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/lib/mysql/mysql-slow.log
long_query_time = 3

3. mysql 재시작

service mysqld restart

4. mysql 접속 후 slow 쿼리 만들기

SELECT SLEEP(10);

5. 로그 확인

[root@ip-10-0-1-175 mysql]# cat /var/lib/mysql/mysql-slow.log
/usr/sbin/mysqld, Version: 5.7.35-log (MySQL Community Server (GPL)). started with:
Tcp port: 0  Unix socket: /var/lib/mysql/mysql.sock
Time                 Id Command    Argument
# Time: 2021-09-29T06:16:05.653863Z
# User@Host: root[root] @ localhost []  Id:     2
# Query_time: 10.000297  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
SET timestamp=1632896165;
select sleep(10);

mysqldumpslow

mysql에는 slow쿼리를 통계내줄수 있는 mysqldumpslow가 있다. 이를 통해 slow 쿼리의 실행 횟수등에 대한 통계를 알 수 있으며 빈번하게 수행된 쿼리 순서로도 확인 할 수 있다.

mysqldumpslow -s c /var/lib/mysql/mysql-slow.log > slow_rersult.log

주요 옵션

쿼리 실행 횟수
mysqldumpslow -s c 옵션을 사용하면 쿼리가 많이 실행된 순서대로 슬로우 쿼리를 분석해서 결과를 출력한다.
쿼리 잠금 시간
mysqldumpslow -s l 옵션을 사용하면 쿼리가 실행되면서 오랜시간 동안 잠금을 가지고 있었던 순서대로 슬로우 쿼리를 분석해서 결과를 출력한다. 잠금 시간은 잠금을 획득하기 위해 기다린 시간이 아니라 쿼리가 실행되면서 잠금을 획득해서 가지고 있었던 ㅅ ㅣ간을 의미한다. 테이블 수준의 잠금만 해당 하므로 InnoDB테이블의 레코드 잠금은 해당되지 않는다.
쿼리로 조회한 레코드(row sent)
mysqldumpslow -s r 옵션은 쿼리가 실행된 후 클라이언트로 결과 레코드를 많이 보내 준 순서대로 정렬해서 출력한다.

옵션 설명

-n : 몇개까지 출력할지 보여줌 Top 10개의 쿼리만 출력하고 싶다면 10을 입력하면 됨
-g : 리눅스나 유닉스의 grep 패턴, 즉 특정단어가 포함된 결과만 출력한다. 원하는 쿼리나 특정 테이블 명만 알고 있을때 이용하면 편리하다.
-r : 정렬순서를 역순으로 정리한다. 기본값은 내림차순임
-s : 출력시 정렬방법 정의

효율적 활용

일반적으로 어떤 쿼리가 얼만큼 들어오는지 확인하지 위해 여러 방법이 있을수 있다. WAS에서 확인할 수도 있고 general log를 내려 모든 쿼리를 확인 할 수 있다. 하지만 쿼리의 통계를 내는 프로그램은 없어 mysqldumpslow 을 활용하면 쉽게 할 수 있다.

간단하게 특정 시간동안 long_query_time을 0으로 세팅하여 모든 쿼리를 slow_query로 남긴 후 mysqldumpslow 을 통해 분석해 낼 수 있다.

mysql> set global long_query_time=0;
shell# mysqldumpslow -s c slow-queries.log > static.sql

Mysql 쿼리 힌트

Mr. YeokMaSsal — Tue, 9 Aug 2022 20:31:40 +0900

쿼리 힌트

Mysql 서버에서 사용 가능한 쿼리 힌트는 2가지로 구분 할수 있다

인덱스 힌트
옵티마이저 힌트

참고로 Mysql 5.7 버전까지는 힌트를 쓰더라도 옵티마이저가 힌트 외의 실행계획을 평가 하기 때문에 실행계회을 세우는 오버로드를 줄여 주지는 못한다. 다만 옵티마이저의 잘못된 실행계획을 방지할 순 있다. 8.0 부터는 힌트 작성시 옵티마이저가 실행계획을 만들지 않기 때문에 오버로드 측면에서는 도움이 된다.

인덱스 힌트

인덱스 힌트는 Mysql 5.6 이전까지 사용했었고 그 이후부터는 옵티마이저 힌트가 추가됨에 따라 옵티마이저 힌트 사용을 권고하고 있다. 인덱스 힌트를 사용하게 되면 ANSI SQL문법에 위배되며 Mysql 이 아닌 타 DBMS에서는 에러가 발생한다. 하지만 옵티마이저 힌트는 타 DBMS에서는 주석으로 처리되기 때문에 옵티마이저 힌트 사용을 추천하게 된것이다.

STRAIGHT_JOIN

STARIGHT_JOIN은 SELECT, UPDATE, DELETE 쿼리에서 여러개의 테이블이 조인되는 경우 조인 순서를 고정하는 역할을 한다. STARIGHT_JOIN은 SELECT 키워드 뒤에 위치한다.아래의 쿼리는 조인 순서를 FROM절에 명시한대로 EMPLOYEE → DEPARTMENT 순으로 읽게 된다.

SELECT STRAIGHT_JOIN
       e.first_name, d.dept_name
  FROM EMPLOYEE e, DEPARTMENT d
 WHERE e.dept_no = d.dept_no


SELECT /*! STRAIGHT_JOIN */
       e.first_name, d.dept_name
  FROM EMPLOYEE e, DEPARTMENT d
 WHERE e.dept_no = d.dept_no

STARIGHT_JOIN 과 비슷한 역할을 하는 옵티마이저 힌트는 아래와 같은 것들이 있다.

JOIN_FIXED_ORDER : STARIGHT_JOIN와 동일함
JOIN_ORDER
JOIN_PREFIX
JOIN_SUFFIX

USE INDEX / FORCE INDEX / IGNORE INDEX

인덱스 힌트들은 STARIGHT_JOIN과 달리 힌트를 테이블 뒤에 명시해야 한다. 대체로 옵티마이저가 인데스를 잘 사용하면 편인데 3~4개 이상의 컬럼을 포함하는 비슷한 인덱스가 여러개 존재하는 경우에는 가끔 옵티마이저가 실수를 하는데 이런 경우에는 강제로 특정 인덱스를 사용하도록 힌트를 추가해야 한다.

인덱스 힌트 사용시 해당 인덱스가 없거나 괄호안에 아무것도 존재하지 않으면 쿼리의 문법 오류로 처리된다.

USE INDEX
가장 자주 사용되는 인덱스 힌트로 MYSQL 옵티마이저에게 특정 테이블의 인덱스를 사용하도록 권장하는 힌트 정도로 생각하면 된다. 대부분의 경우 인덱스 힌트가 주어지면 옵티ㅏ이저는 사용자의 힌트를 채택하지만 항상 그 인덱스를 사용하는 것은 아니다.
FORCE INDEX
INDEX와 비교해서 다른 점은 없으며, USE_INDEX보다 옵티마이저에게 미치는 영향이 더 강한 힌트로 생각하면 된다. USE_INDEX 사용만으로도 충분해 보이지만 이게 안되면 FORCE_INDEX를 쓰면된다.
IGNORE INDEX
특정 인덱스를 사용하지 못하게 하는 용도로 사용하는 힌트다. 때로는 옵티마이저가 풀 테이블 스캔을 사용하도록 유도하기 위해 IGNORE_INDEX 힌트를 사용할 수도 있다.

위의 인덱스는 인덱스의 용도를 설정 해줄 수 있다.

USE INDEX FOR JOIN
여기서 JOIN이라는 키워드는 테이블간의 조인뿐만 아니라 레코드를 검색하기 위한 용도까지 포함하는 용어다. MYSQL 서버에서는 하나의 테이블로부터 데이터를 검색하는 작업도 JOIN이라는 용어를 사용한다.
USE INDEX FOR ORDER
명시된 인덱스를 ORDER BY 용도로만 사용할 수 있게 제한 한다.
USE INDEX FOR GROUP
명시된 인덱스를 GROUP BY 용도로만 사용할 수 있게 제한 한다.

SELECT * FROM EMPLOYEE WHERE EMP_NO = 1000;

SELECT * FROM EMPLOYEE FORCE INDEX(primary) WHERE EMP_NO = 1000;

SELECT * FROM EMPLOYEE USE INDEX(primary) WHERE EMP_NO = 1000;

SELECT * FROM EMPLOYEE IGNORE INDEX(primary) WHERE EMP_NO = 1000;

SELECT * FROM EMPLOYEE FORCE INDEX(ix_firstname) WHERE EMP_NO = 1000;

SQL_CALC_FOUND_ROWS

mysql의 limit을 사용하는 경우 조건을 만족하는 레코드가 limit에 명시된 수 보다 더 많다고 하더라도 limit에 명시된 수만큼 만족하는 레코드를 찾으면 즉시 검색 작업을 멈춘다.

하지만 해당 힌트를 사용하면 limit을 만족하는 수만큼 레코드를 찾았다고 하더라도 끝까지 검색을 수행한다. 주로 웹 프로그램에서 페이징 기능을 이용하기 위해 사용하는 경우가 간혹 있을수 있다.

SELECT SQL_CALC_FOUND_ROWS * 
  FROM EMPLOYEE E
 WHERE E.FIRST_NAME = 'AAA'
 LIMIT 0, 20

SQL_CALC_FOUND_ROWS 힌트는 사실상 장점보다는 단점이 더 많은 힌트기 때문에 해당 힌트는 사용하지 않는것을 추천한다.

https://dev.mysql.com/doc/refman/5.7/en/index-hints.html

MySQL :: MySQL 5.7 Reference Manual :: 8.9.4 Index Hints

Index hints give the optimizer information about how to choose indexes during query processing. Index hints, described here, differ from optimizer hints, described in Section 8.9.3, “Optimizer Hints”. Index and optimizer hints may be used separately o

dev.mysql.com

옵티마이저 힌트

옵티마이저 힌트는 다음 범위 레벨에서 적용 된다.

GLOBAL : 전체 쿼리 블록에 영향을 미치는 힌트
QUERY BLOCK : 특정 쿼리 블록에 사용할 수 있는 힌트로서 특정 쿼리 블록의 이름을 명시하는 것이 아니라 힌트가 명시된 쿼리 블록에 대해서만 영향을 미치는 힌트
TABLE-LEVEL : 특정 테이블의 이름을 사용할 수 있는 힌트
INDEX-LEVEL : 특정 인덱스의 이름을 사용할 수 있는 힌트

Mysql 5.7 버전의 힌트

Mysql 6.0 버전의 힌트

옵티마이저 힌트 작성 법

옵티마이저 힌트구문은 오라클에서 쓰던것 처럼 쓰면 될듯하다.

/*+ BKA(t1) */
/*+ BNL(t1, t2) */
/*+ NO_RANGE_OPTIMIZATION(t4 PRIMARY) */
/*+ QB_NAME(qb2) */


-- 쿼리 시작 부분
SELECT /*+ ... */ ...
INSERT /*+ ... */ ...
REPLACE /*+ ... */ ...
UPDATE /*+ ... */ ...
DELETE /*+ ... */ ...


-- 쿼리 블록 부분
(SELECT /*+ ... */ ... )
(SELECT ... ) UNION (SELECT /*+ ... */ ... )
(SELECT /*+ ... */ ... ) UNION (SELECT /*+ ... */ ... )
UPDATE ... WHERE x IN (SELECT /*+ ... */ ...)
INSERT ... SELECT /*+ ... */ ...

NO_ICP

인덱스 컨디션 푸시다운(Idex Condition Pushdown) 최적화는 사용 가능하다면 항상 성능 향상에 도움이 되므로 Mysql 옵티마이저는 최대한 ICP를 사용하는 방향으로 실행계획을 수립한다.

따라서 ICP힌트는 제공하지 않는다. 하지만 ICP를 통해 실행꼐획의 비용계산이 잘못 된다면 결과적으로 잘못된 실행계획을 수립하게 될 수도 있다.

SELECT /*+ NO_ICP(E IX_LAST_NAME) */ *
  FROM EMPLOYEE E
 WHERE LAST_NAME = 'AAA'

BNL, NO_BNL

블록 네스티드 루프 조인을 사용하게 하는 힌트

SELECT /*+ BNL(E, D) */ *
  FROM EMPLOYEES E
 INNER JOIN DEPT_EMP D 
 ON D.DEPT_NO = E.DEPT_NO

SEMIJOIN, NO_SEMIJOIN

세미조인의 최적화는 여러가지 세부 전략이 있다.

Duplicate Weed-out : SEMIJOIN(DUPSWEDOUT)
First Match : SEMIJOIN(FIRSTMATCH)
Loose Scan : SEMIJOIN(LOOSESCAN)
Materialization : SEMIJOIN(MATERIALIZATION)
Table Pull-out : 없음

SELECT *
  FROM DEPARTMENT D
 WHERE D.DEPT_NO IN (
                      SELECT /*+ SEMIJOIN(MATERIALIZATION) */SQ.DEPT_NO
                        FROM DEPT_EMP SQ
                    )
;

SELECT /*+ SEMIJOIN(@subq1 MATERIALIZATION) */
       *
  FROM DEPARTMENT D
 WHERE D.DEPT_NO IN (
                      SELECT /*+ QB_NAME(subq1) */SQ.DEPT_NO
                        FROM DEPT_EMP SQ
                    )
;

특정 세미조인을 사용하지 않기 위해서는 NO_SEMIJOIN 힌트를 사용할 수 있다.

SELECT *
  FROM DEPARTMENT D
 WHERE D.DEPT_NO IN (
                      SELECT /*+ NO_SEMIJOIN(DUPSWEEDOUTR, FRISTMATCH) */SQ.DEPT_NO
                        FROM DEPT_EMP SQ
                    )
;

MAX_EXCUTION_TIME

옵티마이저 힌트 중 유일하게 쿼리 실행 계획에 영향을 미치지 않는 힌트이며 단순히 쿼리의 최대 실행 시간을 설정하는 힌트이다. 밀리초 단위의 시간을 설정하는데 쿼리가 지정된 시간을 초과하면 쿼리는 실패하게 된다.

SELECT /*+ MAX_EXCUTION_TIME(100) */ *
  FROM EMPLOYEE E
ORDER BY LAST_NAME 
 LIMIT 1

SUBQUERY

서브쿼리 최적화는 세미조인 최적화가 사용되지 못할때 사용하는 최적화 방법으로 서브쿼리는 다음 2가지 형태로 최적화 할 수 있다.

IN-to-EXISTS : SUBQUERY(INTOEXISTS)
Materialization : SUBQUERY(MATERIALIZATION)

서브쿼리 최적화는 사용할 기회가 그다지 많지 않다.

옵티마이저 힌트 참고 자료

https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html

MySQL :: MySQL 5.7 Reference Manual :: 8.9.3 Optimizer Hints

One means of control over optimizer strategies is to set the optimizer_switch system variable (see Section 8.9.2, “Switchable Optimizations”). Changes to this variable affect execution of all subsequent queries; to affect one query differently from an

dev.mysql.com

Mysql 프로파일링

Mr. YeokMaSsal — Mon, 8 Aug 2022 20:47:45 +0900

Mysql 프로파일링

mysql은 기본적으로 비활성화(OFF)되어 있으므로 프로파일링을 진행하기 위해서는 활성화 작업을 해야함

show variables like 'profiling%';

* 결과
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| profiling              | OFF   |
| profiling_history_size | 15    |
+------------------------+-------+

set profiling = 'ON';

프로파일링 수행할 SQL 출력

SELECT 사원번호
FROM 사원
WHERE 사원번호 = 100000;

* 결과
+----------+
| 사원번호 |
+----------+
|   100000 |
+----------+
1 row in set (0.00 sec)

show profiles;

* 결과
+----------+------------+---------------------------------------------------------+
| Query_ID | Duration   | Query	                                                  |
+----------+------------+---------------------------------------------------------+
|        1 | 0.00055779 | SELECT 사원번호 FROM 사원 WHERE 사원번호 = 100000       |
+----------+------------+---------------------------------------------------------+
1 rows in set (0.000 sec)

특정 쿼리 ID에 대해서만 프로파일링 된 상세내용을 확인하고자 한다면 쿼리 ID를 입력하여 다음과 같은 문법으로 결과를 확인함

show profile for query 1;

* 결과
+------------------------+----------+
| Status                 | Duration |
+------------------------+----------+
| Starting               | 0.000116 |
| checking permissions   | 0.000009 |
| Opening tables         | 0.000039 |
| After opening tables   | 0.000008 |
| System lock            | 0.000008 |
| table lock             | 0.000022 |
| init                   | 0.000037 |
| Optimizing             | 0.000029 |
| Statistics             | 0.000096 |
| Preparing              | 0.000006 |
| Unlocking tables       | 0.000020 |
| Preparing              | 0.000024 |
| Executing              | 0.000006 |
| Sending data           | 0.000020 |
| End of update loop     | 0.000013 |
| Query end              | 0.000005 |
| Commit                 | 0.000006 |
| closing tables         | 0.000004 |
| Unlocking tables       | 0.000003 |
| closing tables         | 0.000008 |
| Starting cleanup       | 0.000003 |
| Freeing items          | 0.000007 |
| Updating status        | 0.000064 |
| Reset for next command | 0.000006 |
+------------------------+----------+
24 rows in set (0.005 sec)

프로파일링 선택 가능한 출력정보

show profile all for query 1;

* 결과
+--------------------------------+----------+----------+------------+-------------------+---------------------+--------------+---------------+---------------+-------------------+-------------------+-------------------+-------+--------------------------------+----------------------+-------------+
| Status                         | Duration | CPU_user | CPU_system | Context_voluntary | Context_involuntary | Block_ops_in | Block_ops_out | Messages_sent | Messages_received | Page_faults_major | Page_faults_minor | Swaps | Source_function                | Source_file          | Source_line |
+--------------------------------+----------+----------+------------+-------------------+---------------------+--------------+---------------+---------------+-------------------+-------------------+-------------------+-------+--------------------------------+----------------------+-------------+
| starting                       | 0.000093 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | NULL                           | NULL                 |        NULL |
| Executing hook on transaction  | 0.000003 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | launch_hook_trans_begin        | rpl_handler.cc       |        1122 |
| starting                       | 0.000010 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | launch_hook_trans_begin        | rpl_handler.cc       |        1124 |
| checking permissions           | 0.000007 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | check_access                   | sql_authorization.cc |        2207 |
| Opening tables                 | 0.000052 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | open_tables                    | sql_base.cc          |        5605 |
| init                           | 0.000011 | 0.015625 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | Sql_cmd_dml::execute           | sql_select.cc        |         684 |
| System lock                    | 0.000025 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | mysql_lock_tables              | lock.cc              |         329 |
| optimizing                     | 0.000018 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | JOIN::optimize                 | sql_optimizer.cc     |         282 |
| statistics                     | 0.000118 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | JOIN::optimize                 | sql_optimizer.cc     |         504 |
| preparing                      | 0.000015 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | JOIN::optimize                 | sql_optimizer.cc     |         588 |
| executing                      | 0.000013 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | SELECT_LEX_UNIT::ExecuteIterat | sql_union.cc         |        1084 |
| end                            | 0.000003 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | Sql_cmd_dml::execute           | sql_select.cc        |         737 |
| query end                      | 0.000002 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | mysql_execute_command          | sql_parse.cc         |        4703 |
| waiting for handler commit     | 0.000009 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | ha_commit_trans                | handler.cc           |        1589 |
| closing tables                 | 0.000008 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | mysql_execute_command          | sql_parse.cc         |        4754 |
| freeing items                  | 0.000064 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | mysql_parse                    | sql_parse.cc         |        5435 |
| cleaning up                    | 0.000018 | 0.000000 |   0.000000 |              NULL |                NULL |         NULL |          NULL |          NULL |              NULL |              NULL |              NULL |  NULL | dispatch_command               | sql_parse.cc         |        2217 |
+--------------------------------+----------+----------+------------+-------------------+---------------------+--------------+---------------+---------------+-------------------+-------------------+-------------------+-------+--------------------------------+----------------------+-------------+
17 rows in set, 1 warning (0.00 sec)
====================================================================================
* SQL
show profile cpu for query 1;
* 결과
+--------------------------------+----------+----------+------------+
| Status                         | Duration | CPU_user | CPU_system |
+--------------------------------+----------+----------+------------+
| starting                       | 0.000093 | 0.000000 |   0.000000 |
| Executing hook on transaction  | 0.000003 | 0.000000 |   0.000000 |
| starting                       | 0.000010 | 0.000000 |   0.000000 |
| checking permissions           | 0.000007 | 0.000000 |   0.000000 |
| Opening tables                 | 0.000052 | 0.000000 |   0.000000 |
| init                           | 0.000011 | 0.015625 |   0.000000 |
| System lock                    | 0.000025 | 0.000000 |   0.000000 |
| optimizing                     | 0.000018 | 0.000000 |   0.000000 |
| statistics                     | 0.000118 | 0.000000 |   0.000000 |
| preparing                      | 0.000015 | 0.000000 |   0.000000 |
| executing                      | 0.000013 | 0.000000 |   0.000000 |
| end                            | 0.000003 | 0.000000 |   0.000000 |
| query end                      | 0.000002 | 0.000000 |   0.000000 |
| waiting for handler commit     | 0.000009 | 0.000000 |   0.000000 |
| closing tables                 | 0.000008 | 0.000000 |   0.000000 |
| freeing items                  | 0.000064 | 0.000000 |   0.000000 |
| cleaning up                    | 0.000018 | 0.000000 |   0.000000 |
+--------------------------------+----------+----------+------------+
17 rows in set, 1 warning (0.00 sec)
====================================================================================
* SQL
show profile block io for query 1;

* 결과
+--------------------------------+----------+--------------+---------------+
| Status                         | Duration | Block_ops_in | Block_ops_out |
+--------------------------------+----------+--------------+---------------+
| starting                       | 0.000093 |         NULL |          NULL |
| Executing hook on transaction  | 0.000003 |         NULL |          NULL |
| starting                       | 0.000010 |         NULL |          NULL |
| checking permissions           | 0.000007 |         NULL |          NULL |
| Opening tables                 | 0.000052 |         NULL |          NULL |
| init                           | 0.000011 |         NULL |          NULL |
| System lock                    | 0.000025 |         NULL |          NULL |
| optimizing                     | 0.000018 |         NULL |          NULL |
| statistics                     | 0.000118 |         NULL |          NULL |
| preparing                      | 0.000015 |         NULL |          NULL |
| executing                      | 0.000013 |         NULL |          NULL |
| end                            | 0.000003 |         NULL |          NULL |
| query end                      | 0.000002 |         NULL |          NULL |
| waiting for handler commit     | 0.000009 |         NULL |          NULL |
| closing tables                 | 0.000008 |         NULL |          NULL |
| freeing items                  | 0.000064 |         NULL |          NULL |
| cleaning up                    | 0.000018 |         NULL |          NULL |
+--------------------------------+----------+--------------+---------------+
17 rows in set, 1 warning (0.00 sec)

My sql 실행 계획 (2/2)

Mr. YeokMaSsal — Mon, 8 Aug 2022 20:44:33 +0900

확장된 실행 계획

다음은 확장된 실행계획을 알아보자

EXPLAIN FORMAT = TRADITIONAL

기본적인 실행계획은 EXPLAIN 키워드로 입력하며 기본 포맷은 TRADITIONAL이다. 따라서 명시하지 않아도 다음과 같이 기본적인 실행계획 정보가 출력됨

EXPLAIN FORMAT = TRADITIONAL
SELECT *
FROM 사원
WHERE 사원번호 BETWEEN 100001 AND 200000;

* 결과
+----+-------------+-------+------------+-------+---------------+---------+---------+------+-------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows  | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+-------+----------+-------------+
|  1 | SIMPLE      | 사원  | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL | 20080 |   100.00 | Using where |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+-------+----------+-------------+
1 row in set, 1 warning (0.01 sec)

EXPLAIN FORMAT = TREE

트리 형태로 보여줌

EXPLAIN FORMAT = TREE
SELECT *
FROM 사원
WHERE 사원번호 BETWEEN 100001 AND 200000;

* 결과
+---------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                                       |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Filter: (`사원`.`사원번호` between 100001 and 200000)  (cost=4036.17 rows=20080)                                                                           |
|   -> Index range scan on 사원 using PRIMARY  (cost=4036.17 rows=20080)                                                                                        |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

EXPLAIN FORMAT = JSON

형식값에 JSON 옵션을 입력하면 JSON 형태로 추가된 실행계획 항목을 확인 할 수 있음

EXPLAIN FORMAT = JSON
SELECT *
FROM 사원
WHERE 사원번호 BETWEEN 100001 AND 200000;

{
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "4036.54"
    },
    "table": {
      "table_name": "사원",
      "access_type": "range",
      "possible_keys": [
        "PRIMARY"
      ],
      "key": "PRIMARY",
      "used_key_parts": [
        "사원번호"
      ],
      "key_length": "4",
      "rows_examined_per_scan": 20080,
      "rows_produced_per_join": 20080,
      "filtered": "100.00",
      "cost_info": {
        "read_cost": "2028.54",
        "eval_cost": "2008.00",
        "prefix_cost": "4036.54",
        "data_read_per_join": "1M"
      },
      "used_columns": [
        "사원번호",
        "생년월일",
        "이름",
        "성",
        "성별",
        "입사일자"
      ],
      "attached_condition": "(`tuning`.`사원`.`사원번호` between 100001 and 200000)"
    }
  }

EXPLAIN ANALYZE

그동안 출력된 실행계획은 예측된 값이며 실제 측정한 실행계획은 ANALYZE 키워드를 사용하면 됨
실제 수행된 소요시간과 비용을 측정하여 실측 실행 계획과 예측 실행 계획을 모두 확인 하려면 EXPLAIN ANALYZE키워드를 활용하면됨
Mysql 8.0.18 이상 버전에서 사용 가능함

EXPLAIN ANALYZE 
SELECT * 
FROM 사원 
WHERE 사원번호 BETWEEN 100001 AND 200000; 

* 결과
+-------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                             |
+-------------------------------------------------------------------------------------------------------------------------------------+
| -> Filter: (`사원`.`사원번호` between 100001 and 200000)  (cost=4036.54 rows=20080) (actual time=0.082..8.311 rows=10025 loops=1)
    -> Index range scan on 사원 using PRIMARY  (cost=4036.54 rows=20080) (actual time=0.079..7.389 rows=10025 loops=1)                |
+-------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

My SQL 실행 계획 (1/2)

Mr. YeokMaSsal — Mon, 8 Aug 2022 20:41:38 +0900

실행 계획 확인하는 방법

실행계획을 확인 하는 키워드로는 EXPLAIN, DESCRIBE, DESC가 있다. 3가지 중 어떤 키워드를 사용해도 실행계획의 결과는 같다.

EXPLAIN [SQL문];
DESCRIBE [SQL문];
DESC [SQL문];

위와 같은 실행 계획에서 이를 해석하는 방법에 대해서 알아보자

실행 계획 각 항목별 해석 방법은 아래와 같다.

id

실행 계획을 순서를 표시하는 숫자 id 값이 같은 경우 위에서 아래의 순서로 테이블을 읽으며 조인이 이루어짐
id순서가 따라서 테이블 접근을 의미하지는 않음( 예를 들어 id 1,2,3,4 가 있을 경우 1,2,3,4 순서로 테이블 접근은 아니라는 의미)
아래의 경우 첫번째 행과 두번째 행의 ID값이 같으므로 처음 조인이 발생했다고 해석할 수 있음

EXPLAIN
SELECT 사원.사원번호, 사원.이름, 사원.성, 급여.연봉,
       (SELECT MAX(부서번호) 
        FROM 부서사원_매핑 as 매핑 WHERE 매핑.사원번호 = 사원.사원번호) 카운트
FROM 사원, 급여
WHERE 사원.사원번호 = 10001
AND 사원.사원번호 = 급여.사원번호;

* 결과
+----+--------------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+------------------------------+
| id | select_type        | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra                        |
+----+--------------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+------------------------------+
|  1 | PRIMARY            | 사원  | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL                         |
|  1 | PRIMARY            | 급여  | NULL       | ref   | PRIMARY       | PRIMARY | 4       | const |   17 |   100.00 | NULL                         |
|  2 | DEPENDENT SUBQUERY | NULL  | NULL       | NULL  | NULL          | NULL    | NULL    | NULL  | NULL |     NULL | Select tables optimized away |
+----+--------------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+------------------------------+
3 rows in set, 2 warnings (0.01 sec)

select_type

SQL을 구성하는 SELECT 문의 유형을 출력하는 항목
SELECT 문이 단순히 FROM절에 위치한것인지, 서브쿼리인지, UNION절로 묶인 SELECT인지의 정보를 제공함
자주 출력되는 select_type은 아래와 같음

SIMPLE

UNION이나 내부쿼리가 없는 SELECT문이라는걸 의미하는 유형으로 단순한 SELECT구문으로만 작성된 경우를 가리킴

EXPLAIN 
SELECT * FROM 사원 WHERE 사원번호 = 100000;

* 결과
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | 사원  | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
1 row in set (0.00 sec)

PRIMARY

서브쿼리가 포함된 SQL이 있을때 첫번째 SELECT문에 해당하는 구문에 표시되는 유형
서브쿼리를 감싸는 외부 쿼리이거나 UNION이 포함된 SQL문에서 가장 바깥쪽에 있는 단위 쿼리
예를 들어 다음과 같이 부서사원_매핑 테이블이 포함된 스칼라 서브쿼리가 있을때 외부 쿼리의 사원 테이블에 우선적으로 접근한다는 의미로 PRIMARY가 출력된다.

EXPLAIN
SELECT 사원.사원번호, 사원.이름, 사원.성,
       (SELECT MAX(부서번호) 
        FROM 부서사원_매핑 as 매핑 WHERE 매핑.사원번호 = 사원.사원번호) 카운트
FROM 사원
WHERE 사원.사원번호 = 100001;

* 결과
+----+--------------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+------------------------------+
| id | select_type        | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra                        |
+----+--------------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+------------------------------+
|  1 | PRIMARY            | 사원  | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL                         |
|  2 | DEPENDENT SUBQUERY | NULL  | NULL       | NULL  | NULL          | NULL    | NULL    | NULL  | NULL |     NULL | Select tables optimized away |
+----+--------------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+------------------------------+
2 rows in set, 2 warnings (0.00 sec)

또는 다음과 같이 UNION ALL 구문으로 통합된 SQL문에서 처음 SELECT 구문이 작성된 쿼리가 먼저 접근하다는 의미로 PRIMARY가 출력됨

EXPLAIN
SELECT 사원1.사원번호, 사원1.이름, 사원1.성
FROM 사원 as 사원1
WHERE 사원1.사원번호 = 100001

UNION ALL

SELECT 사원2.사원번호, 사원2.이름, 사원2.성
FROM 사원 as 사원2
WHERE 사원2.사원번호 = 100002;

* 결과
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
|  1 | PRIMARY     | 사원1 | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL  |
|  2 | UNION       | 사원2 | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
2 rows in set, 1 warning (0.00 sec)

SUBQUERY

독립적으로 수행되는 서브쿼리를 의미함
스칼라서브쿼리인 경우나 where 절에 중첩 서브쿼리 인경우 해당함

EXPLAIN
SELECT (SELECT COUNT(*)
        FROM 부서사원_매핑 as 매핑
        ) as 카운트,
       (SELECT MAX(연봉)
        FROM 급여
        ) as 급여;

* 결과
+----+-------------+-------+------------+-------+---------------+------------+---------+------+---------+----------+----------------+
| id | select_type | table | partitions | type  | possible_keys | key        | key_len | ref  | rows    | filtered | Extra          |
+----+-------------+-------+------------+-------+---------------+------------+---------+------+---------+----------+----------------+
|  1 | PRIMARY     | NULL  | NULL       | NULL  | NULL          | NULL       | NULL    | NULL |    NULL |     NULL | No tables used |
|  3 | SUBQUERY    | 급여  | NULL       | ALL   | NULL          | NULL       | NULL    | NULL | 2838731 |   100.00 | NULL           |
|  2 | SUBQUERY    | 매핑  | NULL       | index | NULL          | I_부서번호 | 12      | NULL |  331143 |   100.00 | Using index    |
+----+-------------+-------+------------+-------+---------------+------------+---------+------+---------+----------+----------------+
3 rows in set, 1 warning (0.00 sec)

DERIVED

FROM절에 작성된 인라인뷰를 의미함
DERIVED는 단위 SELECT 쿼리의 실행결과로 메모리나 디스크에 임시테이블을 생성하는 것을 의미함
쿼리 튜닝시 실행계획에 DERIVED인것을 먼저 확인해서 인라인뷰로 된것은 인라인뷰를 풀수있게 작성하는 것이 필요함

EXPLAIN
SELECT 사원.사원번호, 급여.연봉
FROM 사원,
       (SELECT 사원번호, MAX(연봉) as 연봉
        FROM 급여
        WHERE 사원번호 BETWEEN 10001 AND 20000 ) as 급여
WHERE 사원.사원번호 = 급여.사원번호;

* 결과
+----+-------------+------------+------------+--------+---------------+---------+---------+-------+--------+----------+-------------+
| id | select_type | table      | partitions | type   | possible_keys | key     | key_len | ref   | rows   | filtered | Extra       |
+----+-------------+------------+------------+--------+---------------+---------+---------+-------+--------+----------+-------------+
|  1 | PRIMARY     | <derived2> | NULL       | system | NULL          | NULL    | NULL    | NULL  |      1 |   100.00 | NULL        |
|  1 | PRIMARY     | 사원       | NULL       | const  | PRIMARY       | PRIMARY | 4       | const |      1 |   100.00 | Using index |
|  2 | DERIVED     | 급여       | NULL       | range  | PRIMARY       | PRIMARY | 4       | NULL  | 184756 |   100.00 | Using where |
+----+-------------+------------+------------+--------+---------------+---------+---------+-------+--------+----------+-------------+
3 rows in set, 1 warning (0.05 sec)

UNION

UNION 및 UNION ALL 구문으로 합쳐진 SELECT문에서 첫번째 SELECT 구문을 제외한 이후ㅡ이 SELECT 구문에 해당함
첫번째 SELECT는 PRIMARY로 나타냄

EXPLAIN
SELECT 'M' as 성별, MAX(입사일자) as 입사일자
FROM 사원 as 사원1
WHERE 성별 = 'M'

UNION ALL

SELECT 'F' as 성별, MIN(입사일자) as 입사일자
FROM 사원 as 사원2
WHERE 성별 = 'F';

* 결과
+----+-------------+-------+------------+------+---------------+-----------+---------+-------+--------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key       | key_len | ref   | rows   | filtered | Extra |
+----+-------------+-------+------------+------+---------------+-----------+---------+-------+--------+----------+-------+
|  1 | PRIMARY     | 사원1 | NULL       | ref  | I_성별_성     | I_성별_성 | 1       | const | 149578 |   100.00 | NULL  |
|  2 | UNION       | 사원2 | NULL       | ref  | I_성별_성     | I_성별_성 | 1       | const | 149578 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+-----------+---------+-------+--------+----------+-------+
2 rows in set, 1 warning (0.01 sec)

UNION RESULT

UNION ALL이 아닌 UNION 구문으로 SELECT 절을 결합했을때 출력됨
UNION RESULT는 중복을 제거하기 위해 별도의 메모리 또는 디스크에 임시 테이블을 만들어 중복을 제거하겠다는 의미로 해석 할 수 있음

EXPLAIN
SELECT 사원_통합.* 
FROM ( 
      SELECT MAX(입사일자) as 입사일자
      FROM 사원 as 사원1
      WHERE 성별 = 'M' 
	  UNION 
      SELECT MIN(입사일자) as 입사일자
      FROM 사원 as 사원2
      WHERE 성별 = 'M' 
    ) as 사원_통합; 

* 결과
+------+--------------+------------+------------+------+---------------+-----------+---------+-------+--------+----------+-----------------+
| id   | select_type  | table      | partitions | type | possible_keys | key       | key_len | ref   | rows   | filtered | Extra           |
+------+--------------+------------+------------+------+---------------+-----------+---------+-------+--------+----------+-----------------+
|  1   | PRIMARY      | <derived2> | NULL       | ALL  | NULL          | NULL      | NULL    | NULL  |      2 |   100.00 | NULL            |
|  2   | DERIVED      | 사원1      | NULL       | ref  | I_성별_성     | I_성별_성 | 1       | const | 149578 |   100.00 | NULL            |
|  3   | UNION        | 사원2      | NULL       | ref  | I_성별_성     | I_성별_성 | 1       | const | 149578 |   100.00 | NULL            |
| NULL | UNION RESULT | <union2,3> | NULL       | ALL  | NULL          | NULL      | NULL    | NULL  |   NULL |     NULL | Using temporary |
+------+--------------+------------+------------+------+---------------+-----------+---------+-------+--------+----------+-----------------+
4 rows in set, 1 warning (0.00 sec)

DEFENDENT SUBQUERY

UNION또는 UNION ALL을 사용하는 서브쿼리가 메인 쿼리 테이블에 영향을 받는 경우로 UNION 으로 연결된 단위 쿼리들 중에서처음으로 작성한 단위 쿼리에 해당되는 경우임
UNION으로 연결되는 첫번째 단위 쿼리가 독립적으로 수행하지 못하고 메인 테이블로 부터 값을 하나씩 공급받는 구조이므로 성능적으로 불리하여 SQL문의 튜닝 대상이 됨

EXPLAIN
SELECT 관리자.부서번호,
       ( SELECT 사원1.이름
         FROM 사원 AS 사원1
         WHERE 성별= 'F'
         AND 사원1.사원번호 = 관리자.사원번호

         UNION ALL
 
         SELECT 사원2.이름
         FROM 사원 AS 사원2
         WHERE 성별= 'M'
         AND 사원2.사원번호 = 관리자.사원번호
       ) AS 이름
FROM 부서관리자 AS 관리자;

* 결과
+----+--------------------+--------+------------+--------+-------------------+------------+---------+------------------------+------+----------+-------------+
| id | select_type        | table  | partitions | type   | possible_keys     | key        | key_len | ref                    | rows | filtered | Extra       |
+----+--------------------+--------+------------+--------+-------------------+------------+---------+------------------------+------+----------+-------------+
|  1 | PRIMARY            | 관리자 | NULL       | index  | NULL              | I_부서번호 | 12      | NULL                   |   24 |   100.00 | Using index |
|  2 | DEPENDENT SUBQUERY | 사원1  | NULL       | eq_ref | PRIMARY,I_성별_성 | PRIMARY    | 4       | tuning.관리자.사원번호 |    1 |    50.00 | Using where |
|  3 | DEPENDENT UNION    | 사원2  | NULL       | eq_ref | PRIMARY,I_성별_성 | PRIMARY    | 4       | tuning.관리자.사원번호 |    1 |    50.00 | Using where |
+----+--------------------+--------+------------+--------+-------------------+------------+---------+------------------------+------+----------+-------------+
3 rows in set, 3 warnings (0.01 sec)

DEFENDENT UNION

UNION 또는 UNION ALL을 사용하는 서브쿼리가 메인 테이블의 영향을 받는 경우로 UNION으로 연결된 단위 쿼리 중 첫번째 단위쿼리를 제외하고 두번째 단위 쿼리에 해당하는 경우임
DEFENDENT SUBQUERY와 같이 독립적으로 수행하지 못하고 메인 테이블로 부터 값을 하나씩 공급받는 구조이므로 성능적으로 불리하여 SQL문의 튜닝 대상이 됨

EXPLAIN
SELECT 관리자.부서번호,
       ( SELECT 사원1.이름
         FROM 사원 AS 사원1
         WHERE 성별= 'F'
         AND 사원1.사원번호 = 관리자.사원번호

         UNION ALL

         SELECT 사원2.이름
         FROM 사원 AS 사원2
         WHERE 성별= 'M'
         AND 사원2.사원번호 = 관리자.사원번호
       ) AS 이름
FROM 부서관리자 AS 관리자;

* 결과
+----+--------------------+--------+------------+--------+-------------------+------------+---------+------------------------+------+----------+-------------+
| id | select_type        | table  | partitions | type   | possible_keys     | key        | key_len | ref                    | rows | filtered | Extra       |
+----+--------------------+--------+------------+--------+-------------------+------------+---------+------------------------+------+----------+-------------+
|  1 | PRIMARY            | 관리자 | NULL       | index  | NULL              | I_부서번호 | 12      | NULL                   |   24 |   100.00 | Using index |
|  2 | DEPENDENT SUBQUERY | 사원1  | NULL       | eq_ref | PRIMARY,I_성별_성 | PRIMARY    | 4       | tuning.관리자.사원번호 |    1 |    50.00 | Using where |
|  3 | DEPENDENT UNION    | 사원2  | NULL       | eq_ref | PRIMARY,I_성별_성 | PRIMARY    | 4       | tuning.관리자.사원번호 |    1 |    50.00 | Using where |
+----+--------------------+--------+------------+--------+-------------------+------------+---------+------------------------+------+----------+-------------+
3 rows in set, 3 warnings (0.00 sec)

UNCACEABLE SUBQUERY

메모리에 상주하여 재활용되어야 할 서브쿼리가 재사용되지 못할때 출력되는 유형임
이러한 유형은

해당 서브쿼리 안에 사용자 정의 함수나 사용자 변수가 포함되어 있거나
RAND, UUID() 함수 등을 사용하여 매번 조회시 마다 결과가 달라지는 경우에 해당됨

만약 자주 호출되는 SQL이라면 메모리에 서브쿼리 결과가 상주할 수 있도록 변경하는 방향으로 SQL튜닝을 검토해 볼 수 있음

EXPLAIN
SELECT *
FROM 사원
WHERE 사원번호 = (SELECT ROUND(RAND()*1000000));

* 결과
+----+----------------------+-------+------------+------+---------------+------+---------+------+--------+----------+----------------+
| id | select_type          | table | partitions | type | possible_keys | key  | key_len | ref  | rows   | filtered | Extra          |
+----+----------------------+-------+------------+------+---------------+------+---------+------+--------+----------+----------------+
|  1 | PRIMARY              | 사원  | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 299157 |   100.00 | Using where    |
|  2 | UNCACHEABLE SUBQUERY | NULL  | NULL       | NULL | NULL          | NULL | NULL    | NULL |   NULL |     NULL | No tables used |
+----+----------------------+-------+------------+------+---------------+------+---------+------+--------+----------+----------------+
2 rows in set, 1 warning (0.00 sec)

MATERIALIZED

IN 절 구문에 연결된 서브쿼리가 임시 테이블을 생성한뒤 조인이나 가공 작업을 수행할때 출력되는 유형
즉 IN 절의 서브쿼리를 임시 테이블로 만들어서 조인자겅블 수행하는 것

EXPLAIN
SELECT *
FROM 사원
WHERE 사원번호 IN (SELECT 사원번호 FROM 급여 WHERE 시작일자>'2020-01-01' );

* 결과
+----+--------------+-------------+------------+--------+---------------------+---------------------+---------+----------------------+---------+----------+--------------------------+
| id | select_type  | table       | partitions | type   | possible_keys       |key                 | key_len | ref                  | rows    | filtered | Extra                    |
+----+--------------+-------------+------------+--------+---------------------+---------------------+---------+----------------------+---------+----------+--------------------------+
|  1 | SIMPLE       | 사원        | NULL       | ALL    | PRIMARY             |NULL                | NULL    | NULL                 |  299157 |   100.00 | Using where              |
|  1 | SIMPLE       | <subquery2> | NULL       | eq_ref | <auto_distinct_key> |<auto_distinct_key> | 4       | tuning.사원.사원번호 |       1 |   100.00 | NULL                     |
|  2 | MATERIALIZED | 급여        | NULL       | index  | PRIMARY             |I_사용여부          | 4       | NULL                 | 2838731 |    33.33 | Using where; Using index |
+----+--------------+-------------+------------+--------+---------------------+---------------------+---------+----------------------+---------+----------+--------------------------+
3 rows in set, 1 warning (0.00 sec)

table

말그대로 테이블명을 표시하는 항목
실행계획 정보에서 테이블 명이나 테이블 별칭을 출력하여 서브쿼리나 임시 테이블을 만들어서 별도의 작업을 수행할때 <subquery#>나 <derived#>라고 출력됨
아래는 첫번째 행의 table 열에는 <derived2>라고 출력되었고 ID값은 1임
두번째 행의 ID값 역시 마찬가지로 1인거승로 보아 첫번째 행의 <derived2>테이블과 두번째 행의 사원 테이블이 조인 했으리라 해석할 수 있음
여기서 <derived2>는 id가 2인 테이블이라는 뜻으로 사실상 급여 테이블을 의미함
즉 FROM 절의 섭크뤄 구문으로 작성된 급여테이블과 사원테이블이 조인을 했다고 생각하면됨

EXPLAIN
SELECT 사원.사원번호, 급여.연봉
FROM 사원,
      (SELECT 사원번호, MAX(연봉) as 연봉
       FROM 급여
       WHERE 사원번호 BETWEEN 10001 AND 20000 ) as 급여
WHERE 사원.사원번호 = 급여.사원번호;

* 결과
+----+-------------+------------+------------+--------+---------------+---------+---------+-------+--------+----------+-------------+
| id | select_type | table      | partitions | type   | possible_keys | key     | key_len | ref   | rows   | filtered | Extra       |
+----+-------------+------------+------------+--------+---------------+---------+---------+-------+--------+----------+-------------+
|  1 | PRIMARY     | <derived2> | NULL       | system | NULL          | NULL    | NULL    | NULL  |      1 |   100.00 | NULL        |
|  1 | PRIMARY     | 사원       | NULL       | const  | PRIMARY       | PRIMARY | 4       | const |      1 |   100.00 | Using index |
|  2 | DERIVED     | 급여       | NULL       | range  | PRIMARY       | PRIMARY | 4       | NULL  | 184756 |   100.00 | Using where |
+----+-------------+------------+------------+--------+---------------+---------+---------+-------+--------+----------+-------------+
3 rows in set, 1 warning (0.03 sec)

partition

실행계획의 부가정보로 데이터가 저장된 논리적인 영역을 표시하는 항목

type

테이블의 데이터를 어떻게 찾을지에 관한 정보를 제공하는 항목
테이블을 처음부터 끝까지 전부 확인할지 아니면 인덱스를 활용하여 바로데이터를 찾아갈지 등을 해석할 수 있음

system

테이블에 데이터가 없거나 한개만 있는 경우로 성능상 최상의 type이라고 할 수 있음

EXPLAIN
SELECT * FROM myisam_테이블;

* 결과
+----+-------------+---------------+------------+--------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table         | partitions | type   | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+---------------+------------+--------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | myisam_테이블 | NULL       | system | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL  |
+----+-------------+---------------+------------+--------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

const

조회되는 데이터가 1건일때 출력되는 유형으로 성능상 매우 유리한 방식
고유 인덱스나 기본키를 사용하여 단 1건의 데이터에만 접근하면 되므로 속도나 리소스 사용 측면에서 지향해야 할 타입

EXPLAIN
SELECT *
FROM 사원
WHERE 사원번호 = 10001;

* 결과
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | 사원  | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

eq_ref

조인이 수행될 때 드리븐 테이블의 데이터에 접근하며 고유 인덱스 또는 기본키로 단 1건의 데이터를 조회하는 방식
드라이빙 테이블과의 조인키가 드리븐 테이블에 유일하므로 조인이 수핼될 때 성능상 가장 유리함
아래의 실행 계획은 첫번째 와 두번째 id가 1로 동일한 것으로 보아 부서사원_매핑 테이블과 부서 테이블의 조인을 수행한다는걸 알수있음
먼저 작성된 첫번째 행의 부서사원_매핑 테이블이 드라이빙 테이블이고 이후 출력되는 두번째 행의 부서테이블이 드리븐 테이블인것으로 해석되며 여기서 type 유형이 eq_ref로 출력되었으므로 조인 수행시 기본키나 고유 인덱스를 활용하여 1건의 데이터씩만 검색되는 과정을 미리 확인 할 수 있음

EXPLAIN
SELECT 매핑.사원번호, 부서.부서번호, 부서.부서명
FROM 부서사원_매핑 as 매핑,
     부서
WHERE 매핑.부서번호 = 부서.부서번호
AND 매핑.사원번호 BETWEEN 100001 AND 100010;

* 결과
+----+-------------+-------+------------+--------+--------------------+---------+---------+----------------------+------+----------+--------------------------+
| id | select_type | table | partitions | type   | possible_keys      | key     | key_len | ref                  | rows | filtered | Extra                    |
+----+-------------+-------+------------+--------+--------------------+---------+---------+----------------------+------+----------+--------------------------+
|  1 | SIMPLE      | 매핑  | NULL       | range  | PRIMARY,I_부서번호 | PRIMARY | 4       | NULL                 |   12 |   100.00 | Using where; Using index |
|  1 | SIMPLE      | 부서  | NULL       | eq_ref | PRIMARY            | PRIMARY | 12      | tuning.매핑.부서번호 |    1 |   100.00 | NULL                     |
+----+-------------+-------+------------+--------+--------------------+---------+---------+----------------------+------+----------+--------------------------+
2 rows in set, 1 warning (0.01 sec)

ref

앞에서 설명한 eq_ref 유형과 유사한 방식으로 조인을 수행할 때 드리븐 테이블의 데이터 접근 범위가 2개이상일 경우를 의미함
즉 드라이빙 테이블과 드리븐 테이블이 조인을 수행하면 일대다 관계가 되므로 드라이빙 테이블의 1개값이 드리븐 테이블에서는 2개이상의 데이터로 존재함
이때 기본키나 고유 인덱스를 활용하면 2개의상의 데이터가 검색되거나 유일성이 없는 비고유 인덱스를 사용하게 됨
드리븐 테이블의 데이터 양이 많지 않을때는 성능 저하를 크게 우려하지 않아도 되지만 데이터 양이 많다면 접근해야 할 데이터 범위가 넓어져 성능 저하의 원인이 되는지 확인해야 함
한편으로는 =, <, > 등의 연산자를 인덱스를 사용해 비교할때도 출력됨

EXPLAIN
SELECT 사원.사원번호, 직급.직급명
FROM 사원, 직급
WHERE 사원.사원번호 = 직급.사원번호
AND 사원.사원번호 BETWEEN 10001 AND 10100;

* 결과
+----+-------------+-------+------------+-------+---------------+---------+---------+----------------------+------+----------+--------------------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref                  | rows | filtered | Extra                    |
+----+-------------+-------+------------+-------+---------------+---------+---------+----------------------+------+----------+--------------------------+
|  1 | SIMPLE      | 사원  | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL                 |  100 |   100.00 | Using where; Using index |
|  1 | SIMPLE      | 직급  | NULL       | ref   | PRIMARY       | PRIMARY | 4       | tuning.사원.사원번호 |    1 |   100.00 | Using index              |
+----+-------------+-------+------------+-------+---------------+---------+---------+----------------------+------+----------+--------------------------+
2 rows in set, 1 warning (0.00 sec)

EXPLAIN
SELECT *
FROM 사원
WHERE 입사일자 = '1985-11-21';

* 결과
+----+-------------+-------+------------+------+---------------+------------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key        | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | 사원  | NULL       | ref  | I_입사일자    | I_입사일자 | 3       | const |  119 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

ref_or_null

ref 유형과 유사하지만 IS NULL 구문에 대해 인덱스를 활용하도록 최적화된 방식임
Mysql은 NULL에 대해서도 인덱스를 활용하여 검색할 수 있으며 이때 NULL은 가장 앞쪽에 정렬됨
테이블에서 검색할 때 NULL 데이터 양이 적다면 ref_of_null 방식을 활용했을때 효율적인 SQL문이 될것이나, 검색할 NULL 데이터 양이 많다면 SQL 튜닝의 대상이 될 것

EXPLAIN
SELECT *
FROM 사원출입기록
WHERE 출입문 IS NULL
OR 출입문 = 'A';

* 결과
+----+-------------+--------------+------------+-------------+---------------+----------+---------+-------+--------+----------+-----------------------+
| id | select_type | table        | partitions | type        | possible_keys | key      | key_len | ref   | rows   | filtered | Extra                 |
+----+-------------+--------------+------------+-------------+---------------+----------+---------+-------+--------+----------+-----------------------+
|  1 | SIMPLE      | 사원출입기록 | NULL       | ref_or_null | I_출입문      | I_출입문 | 4       | const | 329468 |   100.00 | Using index condition |
+----+-------------+--------------+------------+-------------+---------------+----------+---------+-------+--------+----------+-----------------------+
1 row in set, 1 warning (0.01 sec)

range

테이블 내의 연속된 데이터 범위를 조회하는 유형으로 =, <, >, ≤, ≥ , IS NULL, ≤>, BETWEEN, IN 연산을 통해 범위 스캔을 수행하는 방식
주어진 데이터 범위 내에서 행단위로 스캔하지만 스캔할 범위가 넓으면 성능 저하의 요인이 될 수 있으므로 SQL 튜닝 검토 대상이 됨

EXPLAIN
SELECT *
FROM 사원
WHERE 사원번호 BETWEEN 10001 AND 100000;

* 결과
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows   | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
|  1 | SIMPLE      | 사원  | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL | 149578 |   100.00 | Using where |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
1 row in set, 1 warning (0.01 sec)

fulltext

텍스트 검색을 빠르게 처리하기 위해 전문 인덱스(full texxt index)를 사용하여 데이터에 접근하는 방식

index_merge

결합된 인덱스들이 동시에 사용되는 유형
특정 테이블에 생성된 두개이상의 인덱스가 병합되어 동시에 적용됨(전문 인덱스는 제외)
아래의 옞제는 사원 테이블의 입사일자 열에 대한 인덱스_입사일자 인덱스와 사원번호열로 구성된 기본키 모두를 통합해서 사용하리라 예측됨

EXPLAIN
SELECT * 
FROM 사원 
WHERE 사원번호 BETWEEN 10001 AND 100000 
AND 입사일자 = '1985-11-21'; 

* 결과
+----+-------------+-------+------------+-------------+--------------------+--------------------+---------+------+------+----------+--------------------------------------------------+
| id | select_type | table | partitions | type        | possible_keys      | key                | key_len | ref  | rows | filtered | Extra                                            |
+----+-------------+-------+------------+-------------+--------------------+--------------------+---------+------+------+----------+--------------------------------------------------+
|  1 | SIMPLE      | 사원  | NULL       | index_merge | PRIMARY,I_입사일자 | I_입사일자,PRIMARY | 7,4     | NULL |   15 |   100.00 | Using intersect(I_입사일자,PRIMARY); Using where |
+----+-------------+-------+------------+-------------+--------------------+--------------------+---------+------+------+----------+--------------------------------------------------+
1 row in set, 1 warning (0.00 sec)

index

type항목의 index 유형은 인덱스 풀 스캔을 의미함
물리적인 인덱스 블록을 처음 부터 끝까지 훓는 방식

EXPLAIN
SELECT 사원번호
FROM 직급
WHERE 직급명 = 'Manager';

* 결과
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows   | filtered | Extra                    |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
|  1 | SIMPLE      | 직급  | NULL       | index | PRIMARY       | PRIMARY | 159     | NULL | 442961 |    10.00 | Using where; Using index |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
1 row in set, 1 warning (0.00 sec)

ALL

테이블 풀 스캔 방식
활용할 수 있는 인덱스가 없거나 인덱스를 활용하는게 오히려 비효율적이라고 옵티마이저가 판단했을때 선택 됨
ALL 유형일때는 인덱스를 새로 추가하거나 기존 인덱스를 변경하여 인덱스를 활용하는 방식으로 SQL튜닝을 할 수 있으나 전체 테이블 중 10~20% 이상의 분량의 데이터를 조회할때는 ALL 유형이 오히려 성능상 유리할 수 있음

EXPLAIN 
SELECT * FROM 사원;

* 결과
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows   | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+-------+
|  1 | SIMPLE      | 사원  | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 299157 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+-------+
1 row in set, 1 warning (0.00 sec)

possible_keys

옵티마이저가 SQL을 최적화 하고자 사용할 수 있는 인덱스 목록을 출력하게 되는데 이 경우 실제 사용한 인덱스가 아닌 사용할 수 있는 후보군의 기본키와 인덱스 목록만 보여주므로 SQL 튜닝의 효용성은 없음

key

옵티 마이저가 SQL을 최적화 하고자 사용한 기본키(PK)똔느 인덱스 명을 의미함
어느 인덱스로 데이터를 검색했는지 확인 할 수 있으므로 비효율적인 인덱스를 사용했거나 인덱스 자체를 사용하지 않았다면 SQL 튜닝의 대상이 됨

EXPLAIN
SELECT 사원번호
FROM 직급
WHERE 직급명 = 'Manager';

* 결과
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows   | filtered | Extra                    |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
|  1 | SIMPLE      | 직급  | NULL       | index | PRIMARY       | PRIMARY | 159     | NULL | 442961 |    10.00 | Using where; Using index |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
1 row in set, 1 warning (0.00 sec)

아래의 SQL의 key열을 확인해보면 그 값이 null으로 확인되며 이는 기본키와 인덱스를 전혀 사용하지 않았다는걸 의미함

EXPLAIN
SELECT * FROM 사원;

* 결과
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows   | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+-------+
|  1 | SIMPLE      | 사원  | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 299157 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+-------+
1 row in set, 1 warning (0.00 sec)

key_len

인덱스를 사용한 바이트(byte)수를 의미함
UTF-8 기준으로
- INTEGER : 4yte
- VARCHAR : 단위당 3byte
- CHAR : 단위당 4byte
- DATE : 3byte
NOT NULL이 아닌 컬럼에서는 컬럼의 값이 NULL인지 아닌지 저장하기 위해 1바이트를 추가로 더 사용함
아래의 SQL은 직급 테이블의 데이터에 접근할 때 사원번호와 직급명, 시작일자 열을 결합한 기본키를 사용함
key열 확인 결과 PRIMARY로 확인 되며 key_lent은 159byte로 확인됨
PK는 사원번호 + 직급명 + 시작일자 로 구성된 결합 인덱스이며 사원번호는 INT로 4byte 이고 직급명은 VARCHAR(50) 으로 (50+1) x 3byte = 155byte
즉 PK에서 사원번호의 4byte와 직급명의 155byte만 사용해서 key_len이 159byte로 출력됨을 알수있음

desc 직급;

* 결과
+----------+-------------+------+-----+---------+-------+
| Field    | Type        | Null | Key | Default | Extra |
+----------+-------------+------+-----+---------+-------+
| 사원번호 | int         | NO   | PRI | NULL    |       |
| 직급명   | varchar(50) | NO   | PRI | NULL    |       |
| 시작일자 | date        | NO   | PRI | NULL    |       |
| 종료일자 | date        | YES  |     | NULL    |       |
+----------+-------------+------+-----+---------+-------+
4 rows in set (0.01 sec)


EXPLAIN
SELECT 사원번호
FROM 직급
WHERE 직급명 = 'Manager';

* 결과
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows   | filtered | Extra                    |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
|  1 | SIMPLE      | 직급  | NULL       | index | PRIMARY       | PRIMARY | 159     | NULL | 442961 |    10.00 | Using where; Using index |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
1 row in set, 1 warning (0.00 sec)

ref

reference의 약자로 테이블 조인을 수핼할때 어떤 조건으로 해당테이블에 액세스 되었는지 알려줌
아래 SQL의 결과 2개의 행의 ID가 똑같이 1로 출력되어으므로 사원테이블과 직급테이블의 조인을 수행했음을 알수있음
드리븐 테이블인 직급 테이블의 데이터에 접근하면 사원번호로 데이터를 검색한다는걸 확인 할 수 있음
WHERE 절의 사원.사원번호 = 직급.사원번호를 통해서도 알수있는 부분임

EXPLAIN
SELECT 사원.사원번호, 직급.직급명
FROM 사원, 직급
WHERE 사원.사원번호 = 직급.사원번호
AND 사원.사원번호 BETWEEN 10001 AND 10100;

* 길이
+----+-------------+-------+------------+-------+---------------+---------+---------+----------------------+------+----------+--------------------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref                  | rows | filtered | Extra                    |
+----+-------------+-------+------------+-------+---------------+---------+---------+----------------------+------+----------+--------------------------+
|  1 | SIMPLE      | 사원  | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL                 |  100 |   100.00 | Using where; Using index |
|  1 | SIMPLE      | 직급  | NULL       | ref   | PRIMARY       | PRIMARY | 4       | tuning.사원.사원번호 |    1 |   100.00 | Using index              |
+----+-------------+-------+------------+-------+---------------+---------+---------+----------------------+------+----------+--------------------------+
2 rows in set, 1 warning (0.00 sec)

rows

SQL을 수행하고자 정ㅂ근하는 데이터의 모든 행수를 예측하는 항목
디스크에서 데이터 파일을 읽고 메모리에서 처리해야 할 행수를 예상하는 값이고 수시로 변동되는 mysql 통계정보를 참고하여 산출하는 값이므로 수치가 정확하진 않음
최종 출력될 행 수가 아니라는 점에 유의해야함
SQL문의 최종 결과 건수와 비교해 row수가 크게 차이 날때는 불필요하게 mysql엔진까지 데이터를 많이 가져왔다는 뜻이므로 SQL 튜닝의 대상이 될 수 있음

filtered

SQL을 통해 DB엔진으로 가져온 데이터 대상으로 필터 조건에 따라 어느정도의 비율로 데이터를 제거했는지를 의미하는 항목
예를 들어 DB엔진으로 100건의 데이터를 가져왔다고 가졍한다면 이후 WHERE 절의 사원번호 BETWEEN 1 AND 10 조건으로 100건의 데이터가 10건으로 필터링 됨
100건 10건으로 필터링 되었으므로 filtered에는 10이라는 정보가 출력됨, 단위는 % 임

extra

SQL문을 어떻게 수행할 것인지에 관한 추가정볼르 보여주는 항목
30여가지의 항목으로 나타날 수 있음

Distinct

중복이 제거되어 유일한 값을 찾을때 출력되는 정보로써 중복제거가 포함된느 distinct 키워드나 union 구문이 포함된 경우 출력됨

Using where

실행계획에서 자주 볼 수 있는 extra 정보로써 WHERE 절의 필터 조건을 사용해 Mysql 엔진으로 가져온 데이터를 추출할 것이라는 의미임

Using temporary

데이터의 중간 결과를 저장하고자 임시 테이블을 생성하겠다는 의미로써 데이터를 가져와 저장한뒤에 정렬작업을 수행하거나 중복을 제거하는 작업등을 수행함
보통 DISTINCT, GROUP BY, ORDER BY 구문이 포함된 경우 Using temporary 정보가 출력됨
임시 테이블을 메모리에 생성하거나 메모리 영역을 초과하여 디스크에 임시테이블을 생성하면 Using temporary는 성능 저하의 원인이 될 수 있음
따라서 이 항목의 정보가 출력되면 SQL 튜닝 대상이 될 수 있음

Using index

물리적인 데이터 파일을 읽지 않고 인덱스만을 읽어서 SQL문의 요청사항을 처리할 수 있는 경우를 의미함
일명 커버링 인덱스 방식이라고 부르며 인덱스로 구성된 열만 SQL에서 사용할 경우 이 방식을 이용하게됨

EXPLAIN
SELECT 사원번호
FROM 직급
WHERE 직급명 = 'Manager';

* 결과
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows   | filtered | Extra                    |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
|  1 | SIMPLE      | 직급  | NULL       | index | PRIMARY       | PRIMARY | 159     | NULL | 442961 |    10.00 | Using where; Using index |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+--------+----------+--------------------------+
1 row in set, 1 warning (0.00 sec)

Using filesort

정렬이 필요한 데이터를 메모리에 올리고 정렬 작업을 수행한다는 의미
이미 정렬된 인덱스를 사용하면 추가적인 정렬 작업이 필요없지만 인덱스를 사용하지 못할때는 정렬을 위해 메모리 영역에 데이터를 올리게 되는데 Using fileosrt는 추가적인 정렬 작업이므로 인덱스를 활용하도록 SQL 튜닝 대상이 될 수 있음

Using join buffer

조인을 수행하기 위해 중간 데이터 결과를 저장하는 조인버퍼를 사용한다는 의미

Using union / Using intersect / Using sort_union

2개 이상의 인덱스가 병합되어 사용 될 경우 index_merge로 나타나며 extra 정보에 어떻게 병합되었는지 나타남

Using union
인덱스를 합집합 처럼 모두 결합하여 데이터에 접근한다는 뜻으로써 보통 SQL문에 OR 구문으로 작성된 경우 해당됨
Using intersect
인덱스들을 교집합 처럼 추출하는 방식으로 SQL문이 AND 구문으로 작성된 경우 확인 할 수 있음
Using sort_union
Using union과 비슷하지만 WHERE 절의 OR 구문이 동등 조건이 아닐때 확인 할 수 있는 정보

Using index condition

Mysql엔진에서 인덱스로 생성된 열의 필터조건에 따라 요청된 데이터만 필터링하는 Using where 방식과 달리 필터조건을 스토리지 엔진으로 전달하여 필터링 작업에 대한 Mysql엔진의 부하를 줄이는 방식
이는 스토리지 엔진의 데이터 결과를 Mysql엔진으로 전송하는 데이터 양을 줄여 성능 효율을 높일 수 있는 옵티마이저의 최적화 방식임

Using index condition(BKA)

type 정보의 Using index condition 유형과 비슷하나 데이터를 검색하기 위해 배치 키 엑세스를 사용하는 방식

Using index for group by

SQL에서 group by 구문이나 DISTINCT 구문이 포함될때는 인덱스를 정렬 작업을 수행하여 최적화 하는데 이때 Using index for group by는 인덱스로 정렬 작업을 수행하는 인덱스 루스 스캔일때 출력되는 정보임

Not exists

하나의 일치하는 행을 찾으면 추가로 행을 더 검색하지 않아도 될때 출려되는 유형
해당 매커니즘은 left outer join이나 righter outer join에서 테이블에 존재하지 않는 데이터를 명시적으로 검색할 때 발생 함

extra 정보에 관한 추가항목

https://docs.oracle.com/cd/E17952_01/mysql-5.7-en/explain-output.html

8.8.2 EXPLAIN Output Format

EXPLAIN Extra Information The Extra column of EXPLAIN output contains additional information about how MySQL resolves the query. The following list explains the values that can appear in this column. Each item also indicates for JSON-formatted output which

docs.oracle.com

좋고 나쁨을 판단 하는 기준

select_type

type

extra

Mysql Audit Log

Mr. YeokMaSsal — Wed, 3 Aug 2022 18:05:38 +0900

Audit Log란?

Audit(감사) Log란 보안상 특정 이슈로 어떤 사용자의 행위를 확인하고 싶을때 설정하는 로그로써 접속, 쿼리 등 모든 정보를 로깅할 수 있다.

Mysql Enterprise 버전에는 기본으로 Audit Plugin이 들어있어 설치이후 로깅을 시작하면 되고, Community버전은 Mariadb의 audit plugin을 받아 설치하여야 한다.

Audit Log 설정

AUDIT 설치

/*================================================================================
 * Audit Plugin이 설치 되어있는지 확인
 *================================================================================ */
SELECT PLUGIN_NAME
     , PLUGIN_STATUS
  FROM information_schema.PLUGINS 
 WHERE PLUGIN_NAME LIKE '%audit%'
 ;
 
show variables like '%audit%';




/*================================================================================
 * Audit Plugin 설치 (터미널에서 할것)
 *================================================================================ */
-- Percona
Install PLUGIN audit_log SONAME ='audit_log.so';

-- Maria db
Install PLUGIN audit_log SONAME = 'server_audit.so';


-- 설치후 확인
show variables like '%audit%';

Audit 설정

/*================================================================================
 * audit_log_connection_policy 옵션
 * -> 접속정보 감사
 *  - ALL : 모든 접속정보 기록
 *  - ERRORS : 접속에러 사항만 기록
 *  - NONE : 기록하지 않음
 *================================================================================ */
SET GLOBAL audit_log_connection_policy=ALL;



/*================================================================================
 * audit_log_exclude_accounts 옵션
 * -> 로그 정보를 남기지 않을 유저 설정 (설정 이후 생긴 Connection에만 유효함)
 *================================================================================ */
-- Mysql 
SET GLOBAL audit_log_exclude_accounts='ssp_isp@112.106.111.11';

-- Mariadb
-- Mariadb는 IP정보까지 입력할수 없음
SET GLOBAL server_audit_excl_users=admin,test;



/*================================================================================
 * audit_log_statement_policy 옵션
 * -> 쿼리 정보 감사
 *  - ALL : 모든 명령문 기록
 *  - ERRORS : 에러 명령문 기록
 *  - NONE : 기록하지 않음
 *================================================================================ */
SET GLOBAL audit_log_statement_policy=NONE;

Audit Log my.cnf 파일 설정

audit-log=FORCE_PLUS_PERMANENT
audit_log_format=NEW
audit_log_policy=ALL
audit_log_statement_policy=ALL
audit_log_exclude_accounts='[계정]'

Audit 삭제

UNINSTALL PLUGIN audit_log;

Audit Log 정보 테이블에 insert

Audit Log 테이블 생성 및 SQL 파일 작성

/*================================================================================
 * 테이블 생성
 *================================================================================ */
CREATE TABLE AUDIT_LOG_TEST
(
	  AUDIT_LOG_SN BIGINT NOT NULL AUTO_INCREMENT COMMENT 'AUDIT로그순번'
  , TIMESTAMP    TIMESTAMP NOT NULL             COMMENT '로그생성일시'
  , RECORD_ID    VARCHAR(64) NOT NULL           COMMENT '레코드ID'
  , NAME         VARCHAR(100)                   COMMENT 'AUDIT유형명'
  , CONNECTION_ID BIGINT                        COMMENT 'CONNECTION아이디'
  , USER          VARCHAR(50)                   COMMENT '사용자명'
  , HOST          VARCHAR(50)                   COMMENT 'HOST명'
  , IP            VARCHAR(25)                   COMMENT 'IP주소'
  , COMMAND_CLASS VARCHAR(50)                   COMMENT '명령어'
  , COMMAND_TYPE  VARCHAR(50)                   COMMENT '명령어유형'
  , DB            VARCHAR(50)                   COMMENT 'DB명'
  , REGISTER      VARCHAR(50) DEFAULT "SYSTEM"  COMMENT '등록자'
  , REGIST_DT     DATETIME    DEFAULT CURRENT_TIMESTAMP COMMENT '등록일시'
  , UPDUSR        VARCHAR(30) DEFAULT "SYSTEM"  COMMENT '수정자'
  , UPDT_DT       DATETIME    DEFAULT CURRENT_TIMESTAMP COMMENT '수정일시'
  , PRIMARY KEY(AUDIT_LOG_SN)
  , UNIQUE U_RECORD_ID (RECORD_ID)
)ENGINE=InnoDB DEFAULT CHASET=utf8mb4 COMMENT='AUDIT_LOG_테이블'
;


/*================================================================================
 * SQL파일 생성
 *================================================================================ */
use test_database;
LOAD XML LOCAL INFILE "/data/data01/log/audit/...." INTO TABLE AUDIT_LOG_TEST ROWS IDENTIFIED BY '<AUDIT_RECORD>'
(@TIMESTAMP, RECORD_ID, NAME , CONNECTION_ID , USER , HOST ,IP, COMMAND_CLASS, COMMAND_TYPE , DB)
SET TIMESTAMP = CONVERT_TZ(STR_TO_DATE(@TIMESTAMP, '%Y-%m-%dT%H:%i:%s UTC'), 'UTC', '+9:00');

서버 Crontab 등록

#!/bin/bash

# audit log backup
cp /[audit경로]/audit.log /SSP_DEV_DATA/audit/bak/

# audit log table insert
/mysql5/bin/mysql -uroot -p1234 --socket=/SSP_DEV_DATA/data01/mysqld.sock < insert_table.sql

# backup file delete
rm -f /audit/bak/audit.log

참고자료

Maria db

https://mariadb.com/kb/en/mariadb-audit-plugin-options-and-system-variables/#server_audit_excl_users

MariaDB Audit Plugin Options and System Variables

Description of Server_Audit plugin options and system variables.

mariadb.com

Mysql

https://dev.mysql.com/doc/refman/5.7/en/audit-log.html

MySQL :: MySQL 5.7 Reference Manual :: 6.4.5 MySQL Enterprise Audit

6.4.5 MySQL Enterprise Audit Note MySQL Enterprise Audit is an extension included in MySQL Enterprise Edition, a commercial product. To learn more about commercial products, see https://www.mysql.com/products/. MySQL Enterprise Edition includes MySQL Ente

dev.mysql.com

AWS RDS 적용

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html

MariaDB 감사 플러그인 지원 - Amazon Relational Database Service

MariaDB 감사 플러그인 지원 Amazon RDS는 MySQL 데이터베이스 인스턴스에서의 MariaDB 감사 플러그인 사용을 지원합니다. MariaDB 감사 플러그인은 사용자의 데이터베이스 로그온, 데이터베이스에 대해

docs.aws.amazon.com

Mysql 모니터링 스크립트

Mr. YeokMaSsal — Mon, 1 Aug 2022 17:59:42 +0900

Mysql 모니터링 스크립트

아래 스크립트는 S전자 보안포털 운영 프로젝트에서 모니터링 업체가 Mysql 모니터링시 사용하는 스크립트 이다.

OS Disk Usage - 기준값 : 80% 이하

OS Disk Usage - 기준값 : 80% 이하

Mysql Data Size

SELECT ROUND(SUM(A.DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024 / 1024, 2 ) AS SIZE_GB
  FROM information_schema.tables A

Memory Usage

# Mysql Total Memory (현재 Mysql에서 사용하는 메모리 사용률)
ps awxuf | grep mysqld | grep -v grep | grep -v sage | awk '{print $4}'

# Innodb buffer pool size 
mysql> show global variables like 'innodb_buffer_pool_size';

Innodb_buffer pool hit rate - 기준값 : 99% 이상

-- 수식 : innodb buffer pool hit ratio = Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads)

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%';

Max connections

/* Connection 될수 있는 최대 값 */
show global variables like '%max_connections%';

/* 최대 접속된 클라이언트 수 */
show global status like '%max_used_connections%';

Created Tmp - 기준값 : 10%미만

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

Innodb engine 사용중 발생되는 last dead lock, Fk error, lock 발생 Issue 확인

show engine innodb status \G

Replication 구조일 경우 Slave 현재 상태 확인

show slave status\G

Mysql 파티셔닝

Mr. YeokMaSsal — Mon, 1 Aug 2022 12:50:11 +0900

파티션 생성시 주의사항

스토어드루틴이나 UDF, 사용자 변수등을 파티션 표현식에 사용할 수 없다.
파티션 표현식은 일반적으로 칼럼 그 자체 또는 mysql 내장 함수를 사용할 수 있는데, 여기서 일부 함수들은 파티션 생성은 가능하지만 파티션 프루닝은 지원하지 않을 수 있다.
- ABS(), CEILING(), EXTRACT(), FLOOR(), MOD(), DATEDIFF(), DAY(), DAYOFMONTH(), DAYOFWEEK(), DAYOFYEAR(), HOUR(), MICROSECOND(), MINUTE(), MONTH(), QUARTER(), SECOND(), TIME_TO_SEC(), TO_DAYS(), TO_SECONDS(), UNIX_TIMESTAMP(), WEEKDAY(), YEAR(), YEARWEEK()
파티션 프루닝을 지원하는 내장 함수
프라이머리 키를 포함해서 테이블의 모든 유니크 인덱스는 파티션 키 컬럼을 포함해야 한다.
파티션된 테이블의 인덱스는 모두 로컬 인덱스이며 동일 테이블에 소속된 모든 파티션은 같은 구조의 인덱스만 가질 수 있다. 또한 파티션 개별로 인덱스를 변경하거나 추가할 수 없다.
동일 테이블에 속한 모든 파티션은 동일 스토리지 엔진만 가질 수 있다.
최대(서브 파티션까지) 파티션 개수는 8192개이다.
파티션 생성 이후 mysql 서버의 sql_mode 시스템 변수 변경은 데이터 파티션의 일관성을 깨뜨릴 수 있다.
파티션 테이블에서는 외래키를 사용할 수 없다.
파티션 테이블은전문 검색 인덱스 생성이나 전문검색 쿼리를 사용할 수 없다.
공간 데이터 저장 하는 컬럼 타입(POINT, GEOMETRY..)은 파티션 테이블에서 사용할 수 없다.
임시 테이블은 파티션 기능 사용할 수 없다.

파티션과 open_files_limit 시스템 변수 설정

Mysql에서는 일반적으로 테이블은 파일단위로 관리하기 때문에 Mysql에서 동시에 오픈된 파일의 개수가 상당히 많아 질 수 있다. 이를 제한하기 위해 open_files_limit 시스템 변수에 동시에 오픈할 수 있는 적절한 파일의 개수를 설정 할 수 있다. 파티션 되지않은 일반 테이블은 테이블 1개당 오픈된 파일의 개수가 2~3개 수준이지만 파티션 (테이블에서는 파티션 개수 x 2~3) 개가 된다.

에를 들어 1024개의 파티션 가운데 2개의 파티션만 접근해도 된다고 하더라도 일단 동시에 모든 파티션의 데이터 파일을 오픈해야 한다.

그래서 파티션을 많이 사용하는 경우에는 open_files_limit 시스템 변수를 적절히 높은 값으로 다시 설정 해줄 필요가 있다.

파티셔닝 테스트 쿼리

Mysql에서는 일반적으로 테이블은 파일단위로 관리하기 때문에 Mysql에서 동시에 오픈된 파일의 개수가 상당히 많아 질 수 있다. 이를 제한하기 위해 open_files_limit 시스템 변수에 동시에 오픈

/*--------------------------------------------------------------
 * 	파티셔닝 테스트
 *-------------------------------------------------------------- */

/*----------------------- 
 *  01. 사전 준비
 *----------------------- */
-- 년도별 건수 확인
SELECT YEAR(A.HIST_DT)
     , COUNT(*) AS CNT
  FROM DUMMY_TEST_TB A
 GROUP BY YEAR(A.HIST_DT)
 ;
 

-- 데이터 분산 하기
UPDATE DUMMY_TEST_TB A
   SET A.HIST_DT = STR_TO_DATE(concat('2018',substring(date_format(A.HIST_DT,'%Y%m%d%H%i%s'),5)),'%Y%m%d%H%i%s')
 WHERE YEAR(A.HIST_DT) = 2021
   AND MOD(HOUR(A.HIST_DT),2) >= 1
  LIMIT 900000
;

/*--------------------------------- 
 *  02. 파티션 테이블 생성
 *--------------------------------- */
DROP TABLE partition_dummy_test_tb ;
CREATE TABLE PARTITION_DUMMY_TEST_TB
(
	  HIST_SN INT(11) NOT NULL AUTO_INCREMENT 
	, HIST_DT DATETIME
	, CRUD_TY VARCHAR(1)
	, SCRIN_SN INT(11)
	, SCRIN_ID1 VARCHAR(100)
	, SCRIN_ID2 VARCHAR(100)
	, SCRIN_ID3 VARCHAR(100)
	, SCRIN_ID4 VARCHAR(100)
	, SCRIN_ID5 VARCHAR(100)
	, SCRIN_ID6 VARCHAR(100)
	, SCRIN_ID7 VARCHAR(100)
	, SCRIN_ID8 VARCHAR(100)
	, SCRIN_ID9 VARCHAR(100)
	, SCRIN_ID10 VARCHAR(100)
    , PRIMARY KEY(HIST_SN, HIST_DT)
)PARTITION BY RANGE(YEAR(HIST_DT))(
	  PARTITION p_2018 VALUES LESS THAN (2018)
	, PARTITION p_2019 VALUES LESS THAN (2019)
	, PARTITION p_2020 VALUES LESS THAN (2020)
	, PARTITION p_2021 VALUES LESS THAN (2021)
	, PARTITION p_2022 VALUES LESS THAN (2022)
	, PARTITION p_2023 VALUES LESS THAN (2023)
	, PARTITION p_2024 VALUES LESS THAN (2024)
	, PARTITION p_2025 VALUES LESS THAN (2025)
	, PARTITION p_2026 VALUES LESS THAN (2026)
	, PARTITION p_2027 VALUES LESS THAN (2027)
	, PARTITION p_max  VALUES LESS THAN MAXVALUE
);


/*--------------------------------- 
 *  03. 데이터 INSERT
 *--------------------------------- */
-- 테이블 사이즈 확인
SELECT TABLE_NAME 
     , ROUND(((DATA_LENGTH + INDEX_LENGTH) / 1024 /1024 / 1024),3) AS SIZE_GB
     , TABLE_ROWS 
  FROM information_schema.TABLES A
 WHERE A.TABLE_SCHEMA  = 'testdb'
 ;

/*
dummy_test_tb	2.426	10986122
partition_dummy_test_tb	0.000	0
*/


-- 데이터 입력 및 시간체크
SELECT SYSDATE();
-- 2021-10-03 16:48:58


INSERT INTO PARTITION_DUMMY_TEST_TB
SELECT * FROM DUMMY_TEST_TB;

COMMIT;

SELECT SYSDATE();
-- 2021-10-03 16:49:33
-- 2.4GB 데이터 INSERT시 1분 소요




/*--------------------------------- 
 *  04. 데이터 검증
 *--------------------------------- */
SELECT COUNT(1) AS "PARTITION_DUMMY_TEST_TB" FROM PARTITION_DUMMY_TEST_TB
UNION ALL 
SELECT COUNT(1) AS "DUMMY_TEST_TB" FROM DUMMY_TEST_TB
;


-- 파티션 정보 확인
SELECT A.TABLE_SCHEMA 
     , A.TABLE_NAME
     , A.PARTITION_NAME 
     , A.PARTITION_ORDINAL_POSITION 
     , A.TABLE_ROWS 
  FROM information_schema.PARTITIONS A
 WHERE A.TABLE_SCHEMA = 'testdb'
 ;




/*--------------------------------- 
 *  05. 테이블 이름 변경
 *--------------------------------- */
RENAME TABLE DUMMY_TEST_TB TO DUMMY_TEST_TB_OLD,
             PARTITION_DUMMY_TEST_TB TO DUMMY_TEST_TB
;




/*--------------------------------- 
 *  06. 쿼리 테스트
 *--------------------------------- */
-- SHOW TABLE STATUS LIKE 'DUMMY_TEST_TB';

-- 파티션 테이블 실행게획
EXPLAIN  
SELECT A.*
  FROM DUMMY_TEST_TB A
 WHERE 1=1
   -- AND A.HIST_DT BETWEEN STR_TO_DATE('20210101','%Y%m%d') AND STR_TO_DATE('20211231','%Y%m%d')
  -- AND A.HIST_DT BETWEEN '2021-01-01' AND '2021-12-31'
   AND A.SCRIN_ID1 = 'SCRIN_ID1-4220751'
;

id|select_type|table|partitions|type|possible_keys|key|key_len|ref|rows   |filtered|Extra      |
--+-----------+-----+----------+----+-------------+---+-------+---+-------+--------+-----------+
 1|SIMPLE     |A    |p_2022    |ALL |             |   |       |   |4362654|   11.11|Using where|
 
 ;

-- 일반 테이블 실행게획
EXPLAIN  
SELECT A.*
  FROM DUMMY_TEST_TB_OLD A
 WHERE A.HIST_DT BETWEEN STR_TO_DATE('20210101','%Y%m%d') AND STR_TO_DATE('20211231','%Y%m%d')
;

id|select_type|table|partitions|type|possible_keys|key|key_len|ref|rows    |filtered|Extra      |
--+-----------+-----+----------+----+-------------+---+-------+---+--------+--------+-----------+
 1|SIMPLE     |A    |          |ALL |             |   |       |   |10986122|   11.11|Using where|
 ;

Mysql DBA 업무 SQL

Mr. YeokMaSsal — Mon, 1 Aug 2022 12:38:44 +0900

Mysql DBA 업무 SQL

Mysql DBA 업무를 수행하면서 필요했던 SQL 모음이다.

계정 및 권한 관리

계정 리스트 확인 하기

use mysql;
select * from user;

계정 생성

/* 계정 생성 */
CREATE USER create user test3@123.123.123.123 identified by '[패스워드]';
-- 계정 생성하면서 권한 주기
GRANT ALL ON *.* TO test@localhost IDENTIFIED BY "[패스워드]";
GRANT Select, Insert, Delete On test_db.test 'test_user'@'192.168.0.20' IDENTIFIED BY '[패스워드]'
FLUSH privileges;

권한 추가

GRANT ALL ON *.* TO test@localhost ;
FLUSH privileges;

권한 삭제

revoke 각종 권한들 on 디비이름.테이블 from 사용자ID@접속호스트
flush privileges

계정 패스워드 변경

set password for testuser@localhost = password('[변경 패스워드]');

현재 접속된 내 계정 권한 확인

SHOW GRANTS FOR CURRENT_USER;

권한 확인

SHOW GRANTS FOR 'test_user'@'%';

test_A의 역할을 test_B 에서 부여

GRANT test_A@'%' TO test_B@'%' ;

사용자 암호 변경

ALTER USER 'user-name'@'localhost' IDENTIFIED BY 'NEW_USER_PASSWORD';
FLUSH PRIVILEGES;

사용자 암호 변경시 ALTER문이 안되는 경우

UPDATE mysql.user SET authentication_string = PASSWORD('NEW_USER_PASSWORD')
WHERE User = 'user-name' AND Host = 'localhost';
FLUSH PRIVILEGES;

Lock 관리 쿼리

잠금으로 인해 트랜잭션이 차단된 쿼리

SELECT 
    pl.id
    ,pl.user
    ,pl.state
    ,it.trx_id 
    ,it.trx_mysql_thread_id 
    ,it.trx_query AS query
    ,it.trx_id AS blocking_trx_id
    ,it.trx_mysql_thread_id AS blocking_thread
    ,it.trx_query AS blocking_query
FROM information_schema.processlist AS pl 
INNER JOIN information_schema.innodb_trx AS it
	ON pl.id = it.trx_mysql_thread_id
INNER JOIN information_schema.innodb_lock_waits AS ilw
	ON it.trx_id = ilw.requesting_trx_id 
        AND it.trx_id = ilw.blocking_trx_id
  ;

트랜잭션이 활성 상태인 커넥션에서 실행한 쿼리 내역

SELECT A.PROCESSLIST_ID 
     , C.THREAD_ID 
     , CONCAT(A.PROCESSLIST_USER,'@',A.PROCESSLIST_HOST) AS DB_ACCOUNT
     , C.EVENT_NAME 
     , C.SQL_TEXT 
     , sys.format_time(C.TIMER_WAIT) AS DURATION
     , DATE_SUB(NOW(), INTERVAL (
     							  SELECT VARIABLE_VALUE 
     							    FROM performance_schema.global_status SQ 
     							   WHERE SQ.VARIABLE_NAME ='UPTIME'
     							) -C.TIMER_START *10e-13 SECOND ) AS START_TIME
     , DATE_SUB(NOW(), INTERVAL (
     							  SELECT VARIABLE_VALUE 
     							    FROM performance_schema.global_status SQ 
     							   WHERE SQ.VARIABLE_NAME ='UPTIME'
     							) -C.TIMER_END *10e-13 SECOND ) AS END_TIME						
  FROM performance_schema.threads A
 INNER JOIN performance_schema.events_transactions_current B 
 		 ON B.THREAD_ID=A.THREAD_ID 
 INNER JOIN performance_schema.events_statements_history C
         ON C.NESTING_EVENT_ID = B.EVENT_ID 
 WHERE B.STATE = 'ACTIVE'
   AND C.MYSQL_ERRNO = 0
 ORDER BY A.PROCESSLIST_ID , B.TIMER_START

데이터 락 대기 확인

 SELECT * 
   FROM sys.innodb_lock_waits

메타데이터 락 확인

SELECT *
  FROM performance_schema.metadata_locks

시스템 관리 쿼리

디폴트 캐릭터 셋 확인

-- 데이터베이스
SELECT 
	default_character_set_name 
FROM information_schema.SCHEMATA
;

-- 테이블
SELECT 
	CCSA.character_set_name 
FROM information_schema.TABLES AS T
INNER JOIN information_schema.COLLATION_CHARACTER_SET_APPLICABILITY AS CCSA
	ON CCSA.collation_name = T.table_collation
WHERE T.table_schema = 'Database_Name'
  AND T.table_name = 'Table_Name';
WHERE schema_name = 'Database_Name';

-- 컬럼
SELECT 
	character_set_name 
FROM information_schema.COLUMNS 
WHERE table_schema = 'Database_Name'
  AND table_name = 'Table_Name'
  AND column_name = 'Column_Name';

id로 끝나는 컬럼인데 인덱스가 설정 안된 테이블 및 컬럼

SELECT 
	t.TABLE_SCHEMA
	,t.TABLE_NAME
	,c.COLUMN_NAME
	,IFNULL(kcu.CONSTRAINT_NAME, 'Not indexed') AS Indexed
FROM information_schema.TABLES as t
INNER JOIN information_schema.COLUMNS as c
	ON c.TABLE_SCHEMA = t.TABLE_SCHEMA
		AND c.TABLE_NAME = t.TABLE_NAME
		AND c.COLUMN_NAME LIKE '%_id'
LEFT JOIN information_schema.KEY_COLUMN_USAGE as kcu
	ON kcu.TABLE_SCHEMA = t.TABLE_SCHEMA
		AND kcu.TABLE_NAME = t.TABLE_NAME
		AND kcu.COLUMN_NAME = c.COLUMN_NAME
		AND kcu.ORDINAL_POSITION = 1
WHERE kcu.TABLE_SCHEMA IS NULL
AND t.TABLE_SCHEMA NOT IN ('information_schema', 'performance_schema', 'mysql','sys');
;

TABLE SIZE 체크

SELECT table_name AS TableName
	 , ROUND(((data_length + index_length) / 1024 / 1024), 2) AS SizeInMB
  FROM information_schema.TABLES
 WHERE table_schema = 'testdb'
--  AND table_name = 'Table_Name'

DATABASE SIZE 체크

SELECT table_schema AS Database_Name
  	 , ROUND(SUM(data_length + index_length) / 1024 / 1024, 1) AS SizeInMB
  FROM information_schema.tables
 GROUP BY table_schema

PK없는 테이블 확인

select 
	table_schema
	,table_name
from information_schema.columns
where table_schema = 'SCHEMA_NAME'
group by 
	table_schema
	,table_name
having sum(if (column_key in ('PRI', 'UNI'), 1, 0)) = 0

MySQL 총 메모리 사용량

SELECT A.*
  FROM sys.memory_global_total A

미사용 인덱스 확인

SELECT *
  FROM sys.schema_unused_indexes

중복된 인덱스 확인

SELECT *
  FROM sys.schema_redundant_indexes sri

변경이 없는 테이블 목록

SELECT T.TABLE_SCHEMA
     , T.TABLE_NAME
     , T.TABLE_ROWS 
     , TIO.COUNT_READ
     , TIO.COUNT_WRITE
  FROM information_schema.TABLES T 
  JOIN performance_schema.table_io_waits_summary_by_table TIO
    ON TIO.OBJECT_SCHEMA = T.TABLE_SCHEMA AND TIO.OBJECT_NAME = T.TABLE_NAME 
 WHERE T.TABLE_SCHEMA NOT IN ('mysql','performance_schema','sys')
   AND TIO.COUNT_WRITE = 0
 ORDER BY T.TABLE_SCHEMA 
        , T.TABLE_NAME

SERVER에서 사이즈가 큰 데이터베이스 찾기

SELECT
	COUNT(*) AS TotalTableCount
	,table_schema
	,CONCAT(ROUND(SUM(table_rows)/1000000,2),'M') AS TotalRowCount
	,CONCAT(ROUND(SUM(data_length)/(1024*1024*1024),2),'G') AS TotalTableSize
	,CONCAT(ROUND(SUM(index_length)/(1024*1024*1024),2),'G') AS TotalTableIndex
	,CONCAT(ROUND(SUM(data_length+index_length)/(1024*1024*1024),2),'G') TotalSize	
FROM information_schema.TABLES
WHERE table_schema NOT IN('information_schema', 'performance_schema', 'mysql','sys')
GROUP BY table_schema
ORDER BY SUM(data_length+index_length) 
DESC LIMIT 10

최근 업데이트를 언제 했는지 확인

SELECT UPDATE_TIME
FROM information_schema.tables
WHERE TABLE_SCHEMA = 'Database_Name'
   AND TABLE_NAME = 'Table_Name'

튜닝 관련 쿼리

I/O요청이 많은 테이블 목록 확인

SELECT * 
  FROM sys.io_global_by_file_by_bytes 
 WHERE file LIKE '%ibd'

테이블별 작업량 통게 확인

SELECT TABLE_SCHEMA
     , TABLE_NAME
     , rows_fetched 
     , rows_inserted 
     , rows_updated 
     , rows_deleted 
     , io_read 
     , io_write 
  FROM sys.schema_table_statistics A 
 WHERE A.table_schema  NOT IN ('mysql','performance_schema','sys')

풀 테이블 스캔 쿼리 확인

SELECT A.db 
     , A.query 
     , A.exec_count 
     , sys.format_time(A.total_latency) AS FORMATTED_TOTAL_LATENCY
     , rows_sent_avg 
     , rows_examined_avg 
     , last_seen 
  FROM sys.`x$statements_with_full_table_scans` A
 ORDER BY A.total_latency DESC

자주 실행되는 쿼리 목록 확인

SELECT A.db 
     , A.exec_count 
     , A.query 
  FROM sys.statement_analysis A 
 ORDER BY A.exec_count DESC

실행시간이 긴 쿼리 확인

SELECT A.query 
     , A.exec_count 
     , sys.format_time(A.avg_latency) AS avg_latency
     , rows_sent_avg 
     , rows_examined_avg 
     , last_seen 
  FROM sys.`x$statement_analysis` A 
 ORDER BY A.avg_latency DESC, A.exec_count DESC

정렬작업을 수행한 쿼리 목록 확인

SELECT A.*
  FROM sys.statements_with_sorting A
 ORDER BY A.last_seen DESC

임시테이블을 생성하는 쿼리 목록 확인

SELECT A.*
  FROM sys.statements_with_temp_tables A

오래걸린 쿼리와 트랜잭션 찾기

SELECT trx.trx_id
	,trx.trx_started
	,trx.trx_mysql_thread_id
FROM INFORMATION_SCHEMA.INNODB_TRX AS trx
INNER JOIN INFORMATION_SCHEMA.PROCESSLIST AS pl 
	ON trx.trx_mysql_thread_id = pl.id
WHERE trx.trx_started < CURRENT_TIMESTAMP - INTERVAL 59 SECOND
  AND pl.user <> 'system_user'
  ;
  
   
 SELECT 
	pl.id 'PROCESS ID'
	,trx.trx_started
	,esh.event_name 'EVENT NAME'
	,esh.sql_text 'SQL'
FROM information_schema.innodb_trx AS trx
INNER JOIN information_schema.processlist pl 
	ON trx.trx_mysql_thread_id = pl.id
INNER JOIN performance_schema.threads th 
	ON th.processlist_id = trx.trx_mysql_thread_id
INNER JOIN performance_schema.events_statements_history esh 
	ON esh.thread_id = th.thread_id
WHERE trx.trx_started < CURRENT_TIME - INTERVAL 59 SECOND
  AND pl.user <> 'system_user'
ORDER BY esh.EVENT_ID
;

인덱스 사용량에 대한 통계

SELECT 
    TABLE_NAME
    ,INDEX_NAME
    ,SEQ_IN_INDEX
    ,COLUMN_NAME
    ,CARDINALITY
    ,INDEX_TYPE    
FROM INFORMATION_SCHEMA.STATISTICS 
WHERE table_schema = 'DatabaseName'

SQL Server 백업 및 복구

Mr. YeokMaSsal — Sun, 31 Jul 2022 18:59:31 +0900

백업

SQL Server의 백업 종류 및 백업 전략은 아래와 같다.

SQL Server 백업 종류

전체 백업
차등 백업
트랜잭션 로그 백업

백업 전략

전체 백업
전체 백업 + 차등 백업
전체 백업 + 트랜잭션 로그 백업
전체 백업 + 차등 백업 + 트랜잭션 로그 백업

트랜잭션 로그

SQL Server에서는 쿼리르 실행하고 Commit이 일어날때 까지의 동작 작위를 트랜잭션이라고 한다. 각 트랜잭션에 의해 적용된 모든 트랜잭션 및 데이터베이스 수정 내용을 기록하는 것이 트랜잭션 로그의 역할이다. 이것은 데이터베이스에서 아주 중요한 구성요소이며, 복제와 미러링 등에서도 주 데이터베이스와 복제 또는 미러 데이터베이스의 동기화를 위해 사용되며 시스템 오류가 발생 할 경우 데이터베이스를 다시 일관된 상태로 만들기 위해 사용 된다.

트랜잭션 로그는 DB에서 별도의 파일 또는 파일 집합으로 구현된다. SQL Server 에서는 ldf형식의 파일에 저장된다. 로그 캐시는 데이터 페이지의 버퍼 캐시와는 별도로 관리 되므로 DB엔진에 단순하고 빠르고 강력한 코드를 구현할 수 있다.

트랜잭션 로그는 데이터 파일과 같이 여러 파일에 구현할 수 있으며 트랜잭션 로그에 FILEGROUTH 값을 설정 하여 자동으로 확장되도록 파일을 정의 할 수 있다. 이를 통해 트랜잭션 로그에서 공간이 부족해질 확률이 줄어들며 관리 오버헤드를 줄일 수 있다.

백업의 종류

전체 백업

가장 기본적인 백업이다. DB를 구성하는 모든 데이터 파일과 백업이 진행되는 동안 발생한 트랜잭션에 대한 로그를 백업한다. 모든 DB 복원의 베이스가 때문에, 복원을 위해서는 최소한 1개 이상의 전체 백업이 있어야 한다.

데이터베이스 전체를 백업, 데이터의 변경 유무에 관여하지 않고 전체 데이터의 복사본을 만드는 백업
데이터베이스의 개체 , 시스템 테이블 , 데이터를 모두 백업
데이터베이스의 내용과 더불어서 백업이 진행되는 동안 발생되는 트랜잭션 로그 중 필요한 부분도 백업
복구 과정이 다른 백업 보다 간편, 다른 백업 방식보다 복구 시간이 적게 소요

전체 백업이 필요한 경우는 아래와 같다.

처음 데이터베이스를 생성 하였을 때
트랜잭션 로그를 강제로 비웠을 때
데이터베이스 변경이 생겼을 때 (Alter Database 구문 실행 후)
보통 주기적으로 해줌 (필자의 주관적 생각)
차등 백업과 로그 백업을 하기 이전에 꼭 한번 수행 해야함

차등 백업

가장 마지막 전체 백업 이후에 변경된 데이터를 백업한다. 즉, SQL Server는 내부적으로 전체 백업 이후에 변경된 데이터가 무엇인지 관리하고 있다. DB 크기가 커서 전체 백업을 자주 받을 수 없는 경우 중간 중간 차등 백업을 받음으로써 주기적인 백업을 수행한다. 차등 백업은 혼자서 존재할 수 없으며 반드시 전체 백업을 받은 이후에 수행해야 한다.

차등 백업은 전체백업을 만든 시간과 차등백업을 만든 시간 사이에 변경된 Extent의 상태를 캡쳐한다. 차등 백업의 장점은 아래와 같다.

전체복구 모델 에서 차등백업을 사용하면 복원해야 하는 로그백업의 수를 줄일 수 있다.
차등백업은 전체 백업에 비해 매우 빠른 속도를 낸다. 하지만 차등백업에서 복원을 할 경우 전체 백업을 복원 하는것에 비해 더 많은 시간과 노력이 필요하다.
차등백업은 데이터베이스 하위 집합이 나머지 데이터베이스보다 자주 수정되는 경우 유용하다. 이런 경우 차등 백업을 사용하면 전체 백업의 오버헤드를 발생시키지 않고 자주 백업을 할 수 있다.

트랜잭션 로그 백업

트랜잭션 로그 파일을 백업 받으면서 트랜잭션 로그 파일에 쌓여진 로그를 지운다(옵션으로 보존 가능). DB의 복구모델이 Simple인 경우 트랜잭션 로그가 자동으로 지워지므로 사용이 불가하다. 복구모델이 Full이나 Bulk-Logged인 경우 트랜잭션 로그가 계속 쌓여 디스크가 꽉 차는 현상이 발생할 수 있으므로 꼭 주기적인 트랜잭션 로그 백업이 필요하다. 로그가 꽉 차게 되면 더이상 데이터 변경이 불가능 해질 뿐 아니라 DBMS에도 문제가 발생할 수 있따.

로그백업의 내용이 유실된다면 유실된 이후의 모든 로그백업된 자료는 복원 할 수가 없다. 로그 백업의 특징은 아래와 같다.

로그 백업은 변경된 내용만을 백업하기 때문에 대개는 백업속도가 무척 빠르다. 일반적으로 실무에서 사용되는 대용량의 데이터에서 실제 변경되는 내용은 많지 않기 때문이다.
복원되는 속도는 느리다. 데이터를 백업받은 경우는 데이터를 바로 DB에 복사하는 형식이지만, 로그를 백업받은 경우에는 DML문을 다시 수행해야 하기 때문이다.
대량의 데이터 변경이 일어난 경우에는 로그 백업이 바람직하지 않다. 복원할 양이 많기 때문에 속도가 느려지기 때문이다.따라서, 대량의 데이터 변경이 일어난 후에는 전체 백업을 해주고, 다시 처음부터 로그 백업을 해 주는 것이 바람직 하다.

백업 전략

전체 백업
전체 백업 + 차등 백업
복원 시 전체 백업 후 차등 백업을 여러번 수행했더라도 마지막 차등 백업만 있으면 된다(차등 백업 자체가 전체 백업을 기준으로 변경된 데이터를 백업하는 것이기 때문에)
전체 백업 + 트랙잭션 로그 백업
복원 시 전체 백업 후 실행된 모든 트랜잭션 로그 백업이 필요하다.
전체 백업 + 차등 백업 + 트랜잭션 로그 백업
복원 시 전체 백업 후 마지막 차등 백업과 그 뒤에 일어난 트랜잭션 로그 백업이 필요하다.

복구

복구에는 다음과 같은 3가지가 있다.

단순 복구 모델 (Simple)
전체 복구 모델 (Full)
대량 로그 복구 모델 (Bulk Logged)

단순 복구 모델 (Simple)

단순복구 모델은 데이터가 변경되는 내용을 트랜잭션로그파일에 기록하지 않는 모델이다. 따라서 트랜잭션 로그 백업이 있을수 없으며 마지막 백업된 시점까지만 복원이 가능하다. 단순 복구 모델은 아래와 같은 상황일때 사용 가능하다.

오류 지점 복구가 필요하지 않습니다. 데이터베이스가 손실되거나 손상될 경우 오류 지점과 이전 백업 사이의 모든 업데이트가 손실되어도 상관 없습니다.
로그에 있는 일부 데이터가 손실되어도 상관 없습니다.
트랜잭션 로그를 백업 및 복원하지 않고 전적으로 전체 및 차등 백업을 사용하려고 합니다.

전체 복구 모델(Full)

전체 복구 모델은 데이터가 변경되는 모든 작업과 내용을 로그파일에 기록하는 모델이다. 따라서 장애가 난 최근 시점까지 복구가 가능하다. 아래 경우 중 하나에 해당되는 경우 전체 복구 모델과 선택적으로 대량 로그 복구 모델을 함께 사용한다.

모든 데이터를 복구할 수 있어야 합니다.
데이터베이스에 여러 파일 그룹이 있으며 읽기/쓰기 보조 파일 그룹과 선택적으로 읽기 전용 파일 그룹의 증분 복원을 수행하려고 합니다.
실패 지점까지 복구 할 수 있어야 합니다.
개별 페이지를 복원하려고 합니다.
트랜잭션 로그 백업의 관리 비용이 발생해도 괜찮습니다.

전체 복구 모델을 사용할 경우 트랜잭션 로그 파일의 크기가 커져서 DB백업 파일의 크기가 늘어나게 된다.

대량 로그 복구 모델(Bulk Logged)

대량 로그 복구 모델은 전체 복구 모델과 비슷한 방식으로 작동하는 특수 용도 모델이다. 유일한 차이점은 대량 데이터 수정 작업을 처리하는 방식에 있다. 대량 로그 모델은 최소 로깅 기술을 사용 한다. . 이렇게하면 처리 시간이 크게 절약되지만 특정 시점 복원 옵션을 사용할 수 없다.대량 로그 복구 모델은 단기간 동안 만 사용하는 것이 좋다. 가장 좋;은 방법은 대량 작업을 수행하기 전에 데이터베이스를 대량 로그 복구 모델로 전환하고 이러한 작업이 완료되면 전체 복구 모델로 복원하는 것이다.

Mysql InnoDB

Mr. YeokMaSsal — Sun, 31 Jul 2022 18:44:13 +0900

InnoDB란?

Innodb는 Mysql에서 사용하는 데이터베이스 엔진이다. 트랜잭션 세이프 스토리지 엔진으로서 대용량 데이터를 처리 할 때 많은 장점을 가지고 있다. 또한 Innodb는 오라클과 비슷한 기능들을 제공 하고 있다. (commit, rollback, 장애복구, row-level locking, 외래키 등)

InnoDB 아키텍처

InnoDB는 크게 메모리 영역, CPU 영역, 디스크 스토리지 영역으로 구분할 수 있다.

메모리, 파일 영역

1. Innodb buffer pool

Innodb스토리지 엔진에서 가장 핵심적인 부분으로 디스크의 데이터 파일이나 정보를 메모리에 캐시해두는 공간이다. 오라클의 데이터 버퍼캐시 같은 역할은 한다고 생각하면 될듯 하다. SELECT시 버퍼캐시에 해당 페이지가 없다면 ibdata를 뒤져서 버퍼풀에 기록하고 결과값을 반환한다.

insert구문이 발생 시 해당 데이터가 캐시 안되어있으면 캐시도 생성하고 물리적인 파일에도 내용 기술한다.
변경된 데이터를 모아서 처리하기 때문에 랜덤한 디스크 작업의 횟수를 줄일수 있다. 더티페이지는 주기적 또는 특정 조건이 되면 체크포인트가 발생하는데 이때 wirte thread가 필요한 만큼의 데이터 페이이지만 디스크로 기록 한다. 체크포인트가 발생한다고 해서 버퍼풀의 모든 더티페이지가 디스크로 기록되는것은 아니다.

버퍼풀은 쓰기 작업을 지연시켜 일괄적으로 처리할 수 있게 해주는 버퍼 역할도 같이 한다.일반적으로 innodb_buffer_pool_size는 전체 장착된 물리 메모리의 50~80 수준의 크기를 잡는것이 좋다.

2. Undo 로그

언두 영역은 데이터가 변경 되었을 때 (Update, Delete) 변경되기 이전의 데이터를 보관하는 곳이다.

Update 문을 실행하면 실제 데이터 파일에는 변경된 데이터가 저장 된다. 그리고 변경되지 이전의 데이터를 언두 영역에 백업시켜 놓는다. 이 상태에서 commit을 하게 되면 현재 상태가 그대로 유지되고, rollback을 시키면 언두 영역의 백업된 데이터를 다시 데이터 파일로 복구 시킨다.

언두의 데이터는 크게 두가지 용도로 사용되는데, 첫번째는 롤백을 위한 용도이며, 두번째는 높은 동시성을 제공하는데 사용 된다.

3. Insert buffer

데이터가 Insert, update 될때 데이터 파일만 변경되는 것이 아니라 인덱스 또한변경되어야 한다. 그러나 인덱스 업데이트 작업은 디스크의 많은 자원을 소모하게 되는데 그 때 필요한 것이 Insert buffer이다. 인덱스 변경이 필요할 때 인덱스 페이지가 버퍼 풀에 있으면 바로 업데이트를 수행하고 그렇지 않다면 이를 즉시 실행하지 않고 임시공간에 저장해 두고 바로 사용자에게 결과를 반환하는 형태로 성틍을 향상 시키게 되는데 이때 사용하는 임시 메모리 공간이 인서트 버퍼이다.인서트 버퍼에 임시로 저장되는 인덱스 레코드 조각은 이후 백그라운드 인서트 버퍼 머지 스레드에 의해 병합 된다.

4. Redo 로그 및 로그 버퍼

쿼리로 데이터를 변경 할 때 순차적으로 변경된 내용을 기록하는 파일을 리두로그 라고 한다.

대용량 작업에서 리두 로그 기록 작업이 큰 문제가 되는데 이러한 부분을 보완하기 위해 최대한 ACID 속성을 보정하는 수준에서 버퍼링하게 된다. 로그 버퍼는 이러한 리두 로그 버퍼링에 사용되는 공간이다. 이 크기를 innodb_log_buffer_size로 조정할 수 있는데, 4~16M로 설정하는것이 좋다.

설정값이 클수록 디스크 사용량이 줄어서 성능이 향상되지만, 시스템 다운 시 손실되는 트랜잭션 양도 증가 한다. 반면에 크기가 작으면 로그 버퍼를 로그파일에 쓰기 위한 부하가 많이 발생될 수도 있다.

5. 테이블 스페이스

디스크 스토리지 영역 중 테이블 스페이스는 시스템 테이블 스페이스와 유저 테이블 스페이스로 크게 두가지로 나뉜다. 시스템 테이블 스페이스는 ibdata1에 해당되고 유저 테이블 스페이스는 테이블명.ibd에 속한다.

유저 테이블 스페이스에는 인덱스 파일과 데이터 파일이 속해 있고, 시스템 테이블에는 dictonary(테이블 정보등) 및 undo등 적지 않은 내용들이 속해 있다.

처음 아무것도 설정하지 않았다면 유저 테이블 스페이스는 존재하지 않는다.

my.cnf에서 "innodb_file_per_table"을 설정해야만 유저테이블스페이스가 생성되고, 이를 좋다 나쁘다 이야기를 간간히 하시는것 같은데, 운영편의상 무조건 하는게 좋다고 권고한다.

운영 중간에 innodb_file_per_table을 설정하면 ibdata1이 이미 존재하던 데이터와 꼬이는(복원 등 하는 사례 아닌 이상은 안 꼬임) 현상이 발생되므로 처음 설치 시 설정해놓고 시작하는것을 권고 한다.

InnoDB의 장점

우수한 성능

다수의 사용자가 동시접속을 할 수 있고, 대용량 데이터 처리를 할 수 있다. 데이터 테이블과 인덱스를 테이블 스페이스에 저장 하고 테이블 스페이스는 파일과 파티션으로 구성되어 있다. 따라서 성능이 우수하다.

데이터 무결성 보장

InnoDB설계시 데이터 무결성에 중점을 두었기 때문에 데이터 무결성이 좋다.

장애 복구 기능

단순하게 장애 복구를 하지않고 논리적으로 장애 복구를 수행한다.

InnoDB의 단점

Deadlock 발생

NODE간 데이터 체크로 인해서 Deadlock이 발생할 가능성이 존재함

많은 자원 소모

대용량 처리를 하게 된다면, 순간적으로 많은 자원을 소모 한다.

데이터 복구의 어려움

단순하게 파일 백업으로 복구를 하는게 아니라 특정한 방법을 사용하여 복구를 수행함

MyISAM vs InnoDB

InnoDB가 유리한 경우

대용량 데이터를 컨트롤 하는 경우
트랜잭션 관리가 필요한 경우
복구가 필요할 경우
정렬등의 구문이 들어가는 경우
IUD등이 빈번하게 발생하는 경우(Row-Level locking때문)

MyISAM이 유리한 경우

읽기 위주의 작업만 필요한 경우
전문 검색이 필요한 경우
트랜잭션이나 복구등이 필요 없을 경우
한번에 대량 데이터를 입력하는 배치성 테이블

[Mysql 에러] Truncated incorrect INTEGER value : 'AWS'

Mr. YeokMaSsal — Sun, 31 Jul 2022 12:53:06 +0900

에러 발생 상황

Truncated incorrect INTEGER value : 'AWS' 에러 발생 상황

S전자 보안포털 사이트에서 On-premise → AWS RDS로 이전을 한것에 대한 테스트를 하던 와중 Truncated incorrect INTEGER value라는 에러가 발생하였다. 해당 에러가 발생한 조회조건을 봤는데 컬럼 타입이 모두 VARCHAR로 INTEGER와는 전혀 무관한 타입이었다.

구글링을 해봐도 버그라는 내용만 나오고 당최 이유를 알지 못했다. 그러던 와중에 파라미터값을 SELECT 절로 조회 할 수 있었다.

-- 일반적인 방법
show variables;

-- 이것도 가능
select @@global.sql_mode;

하지만 이렇게 조회할 경우 서로 다른 값이 나왔다. 너무 황당해서 일단 다른 이유는 차차 찾기로 하고 이부분을 고치기로 했다.

에러 원인

에러의 원인은 기존 On-premisse의 파라미터 속성 sql_mode에는 STRICT_TRANS_TABLES 라는 값이 포함되어 있으나 select절로 조회한 결과에는 빠져있었다. 따라서 현재 On-premisse에는 STRICT_TRANS_TABLES이 적용되어 있지 않은 것이었다. 그럼 STRICT_TRANS_TABLES는 무엇이냐?

해당 옵션값은 데이터에 빈공간이 존재하면 에러를 뱉는 그런 옵션인듯 했다. 실제 쿼리에서 에러가 나던 부분을 TRIM 함수로 감싸주게 되면 에러가 나지 않았다.

참고 : https://xinet.kr/?p=2191

해결 방법

일단 RDS의 sql_mode 옵션을 변경하기로 했다. 그리고 2차적으로 On-premise에 있는 파라미터 옵션들을 모두 select 절로 조회하여 show variables 했을때와 차이가 있는지 확인 하는 작업이 필요했다.

[Mysql 에러] This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable)

Mr. YeokMaSsal — Sun, 31 Jul 2022 12:50:34 +0900

에러 발생 이유

Mysql에서 This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable) 에러가 발생하는 이유는 아래와 같다.

구글링 해보니 MySQL 특정 버전대에서 Super 권한이 없는 user에게서 발생할 수 있는 문제이다.

원인은 mysql global variable 중 log_bin_trust_function_creators 옵션이었다.

log_bin_trust_function_creators 옵션은 MySQL이 function, trigger 생성에 대한 제약을 강제할 수 있는 기능이다.

해당 옵션의 default는 OFF이며, OFF상태의 경우 권한이 있더라도 trigger를 생성할 수 없고, function을 생성할 수 없다.

결론적으로 해당 옵션이 OFF 상태일 경우, root 권한이 없는 user가 생성한 function을 일반 user가 실행할 수 없게된다.

해결방법

안정성 검증이 완료된 function을 super유저가 다시 생성하던가
log_bin_trust_function_creators 옵션을 ON 시키는 방법으로 해결한다.

show global variables like 'log_bin_trust_function_creators';
SET GLOBAL  log_bin_trust_function_creators=ON;

[Mysql 에러] THE TOTAL NUMBER OF LOCKS EXCEEDS THE LOCK TABLE SIZE

Mr. YeokMaSsal — Sun, 31 Jul 2022 12:44:47 +0900

에러가 나는 이유

THE TOTAL NUMBER OF LOCKS EXCEEDS THE LOCK TABLE SIZE 에러 발생할때 이유는 아래와 같다.

MySQL은 저 문장이 들어오면 일단 select 결과를 모두 메모리로 가져온다. 그 메모리가 buffer 다.

이걸 조정하는 게 buffer_size 옵션이다. 그런데, 가지고 올 데이터량이 많아서 buffer_size를 넘어간다면? MySQL 은 Temp_Table이 완성되기 전에 You_Table 이 변경되면 안되니까, You_Table 에다가 lock을 걸어버린다. 즉, 그동안 다른 트랜잭션이 데이터를 변경할 수 없다는 소리다. 그래서 이런 에러가 생긴다.

해결방안

innodb_buffer_pool_size의 기본값이 8,388,608이라는데 이것은 byte 값이다.

innodb_buffer_pool_size=64MB 이런식으로 변경해 주면 된다고 한다.

innodb_buffer_pool_size=64M

참고 사이트 : https://avaiable.tistory.com/52#:~:text=0%20%EB%A9%94%EB%89%B4%20%EB%8D%94%EB%B3%B4%EA%B8%B0-,%5Bmysql%20%EC%97%90%EB%9F%AC%5D%20THE%20TOTAL%20NUMBER%20OF%20LOCKS,EXCEEDS%20THE%20LOCK%20TABLE%20SIZE&text=%ED%95%B4%EA%B2%B0%EC%B1%85%EC%9D%80%20mysql%EC%9D%98%20%EC%84%A4%EC%A0%95,%EA%B0%92%EC%9D%84%20%EB%8A%98%EB%A0%A4%EC%A3%BC%EB%8A%94%20%EA%B2%83%EC%9D%B4%EB%8B%A4

캐릭터 셋 바꾸는 방법

Mr. YeokMaSsal — Sun, 31 Jul 2022 12:40:59 +0900

DB 생성시 설정

CREATE DATABASE testdb2 DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

my,cnf 파일 수정

## etc/my.cnf 파일로 가서 수정하기 & timezone도 변경

[client]
default-character-set = utf8

[mysql]
default-character-set=utf8

[mysqldump]
default-character-set=utf8

[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci

[mysqld]
default-time-zone='+9:00' 



## 재시작
systemctl restart mysqld

SHOW PROCESSLIST

Mr. YeokMaSsal — Sat, 30 Jul 2022 21:23:08 +0900

mysql에서 실행중인 쿼리를 확인 하는 방법은 SHOW PROCESSLIST를 통해 확인 할수 있다.

-- 일반적인 PROCESS 확인
SHOW PROCESSLIST;

-- 쿼리 전체 확인 PROCESS 확인
SHOW FULL PROCESSLIST;

SELECT A.*
  FROM information_schema.PROCESSLIST A


Id|User  |Host                |db          |Command|Time|State    |Info                                                                                                                                                                                                                                                           |
--+------+--------------------+------------+-------+----+---------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
12|tester|118.218.214.230:3313|PARTITION_DB|Query  |   0|query end|INSERT INTO DUMMY_TEST_TB(¶                 HIST_SN ¶        , HIST_DT ¶        , CRUD_TY ¶        , SCRIN_SN ¶        , SCRIN_ID1¶        , SCRIN_ID2¶        , SCRIN_ID3¶        , SCRIN_ID4¶        , SCRIN_ID5¶        , SCRIN_ID6¶        , SCRIN_ID7¶    |
27|tester|%                   |PARTITION_DB|Query  |   0|query end|INSERT INTO DUMMY_TEST_TB(¶                 HIST_SN ¶        , HIST_DT ¶        , CRUD_TY ¶        , SCRIN_SN ¶        , SCRIN_ID1¶        , SCRIN_ID2¶        , SCRIN_ID3¶        , SCRIN_ID4¶        , SCRIN_ID5¶        , SCRIN_ID6¶        , SCRIN_ID7¶    |
34|tester|118.218.214.230:4635|            |Sleep  | 378|         |                                                                                                                                                                                                                                                               |
35|tester|118.218.214.230:4636|            |Sleep  |  36|         |                                                                                                                                                                                                                                                               |
36|tester|118.218.214.230:4637|PARTITION_DB|Query  |   0|starting |/* ApplicationName=DBeaver 21.2.1 - SQLEditor <Script-2.sql> */ SHOW FULL PROCESSLIST                                                                                                                                                                          |
38|tester|118.218.214.230:5357|PARTITION_DB|Sleep  | 378|         |                                                                                                                                                                                                                                                               |

Processlist의 항목

id : 쿼리의 ID로써 PID라고 생각하면 된다. SELECT CONNECTION() 했을 때 나오는 값과 동일
User : 쿼리 실행 User
Host : 연결 Host Ip
db : database명
Command
- Query : 실행중인 쿼리
- Sleep : 쿼리의 실행이 완료되고 연결만 유지되고 있는 경우를 나타내며 sleep세션이 너무 많고 정리가 안되는 경우 connection full 로 인해 신규 세션 접속이 불가능 해지고 session별 할당되는 메모리로 인해 메모리 부족 현상이 발생할 수 있다.
- kill : 이 스레드는 다른 스레드를 kill 하고 있음
Time : 쿼리 실행시간(초)
State : 현재 쿼리가 뭘 하고 있는지 나타냄
- Wating or Update : 다른 프로세스가 선점하고 있는 잠금을 기다리는 것을 의미함
- query end : 쿼리 종료
Info : 스레드가 실행중인 쿼리문이거나 쿠리를 실행하지 않는 경우 NULL로 표시됨

Mysql Server parameter

Mr. YeokMaSsal — Sat, 30 Jul 2022 21:17:28 +0900

Server parameter란?

mysql server 환경을 구성하기 위해서 적용되는 파라미터 값으로써 동적 변수, 정적 변수2가지가 있다.

동적 변수 : 변수값을 바꿨을때 서버를 restart하지 않아도 적용되는 변수
정적 변수 : 변수값을 바꿨을때 서버를 restart 해야만 적용되는 변수

시스템 변수 설정 위치

시스템변수는 my.cnf 라는 파일에 있다. mysql 서버를 설치할때 환경파일 위치를 기본 위치 (/etc/my.cnf)이외에 다른 디렉토리서 읽어 들이도록 설정했다면 패키지를 설치한 사람 이외에는 알기가 어렵다

이럴때 아래 명령어로 mysql, mariadb에서 불러들이는 my.cnf파일이 어떤것인지 확일 할 수 있다.

[root@ip etc]# mysqld --verbose --help | grep -A 1 'Default options'
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf

파라미터 설정 방법

my.cnf에 보면 섹션들이 있다.

[client], [mysqld], [myisamchk] ...

위의 것들은 각각의 데몬 혹은 프로그램들이 이용될때 쓰이는 것이다.

예를 들어 [client]는 클라이언트가 접속이 되었을때, [mysqld]는 mysql server가 구동중일때 적용되는 파라미터 들이다. mysqld는 [mysqld], [server]그룹에서 옵션을 읽는다. mysqld_safe는 [mysqld],[server],[safe_mysqld] 그룹에서 옵션을 읽는다. mysql.server는 [mysqld]와 [mysqld.server] 그룹에서 옵션을 읽는다.

Mysql 기본 파라미터

기본적으로 알아야하는 variable이다. 필수옵션이다.

파라미터 적용 방법

mysql 서버는 위에서 설명한대로 my.cnf라는 파라미터 파일을 통해 서버환경을 구성하거나 지금 설명하는 mysqld_safe라는 프로그램을 실행시킬때 서버 파라미터를 옵션형식으로 추가하여 실행하는 방법이 있다.

서버 실행시 시작할 수 있는 파라미터는 보통 대쉬(-) 2개로 표현을 한다.

shell > mysqld_safe --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data

현재 적용 파라미터 확인 방법 (쿼리)

show variables like '%connection%';

파라미터 정보

https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html

Mysql 접속, STRAT, RESTART 명령어

Mr. YeokMaSsal — Thu, 28 Jul 2022 23:01:04 +0900

Mysql 접속

mysql -h[host주소] -u[user명] -p

2가지 방법

## 리눅스 서비스로 등록되지 않은 경우
/etc/init.d/mysql start
/etc/init.d/mysql stop

## 리눅스 서비스로 등록된 경우
service mysqld start
service mysqld stop

Mysql Start, restart, 상태 확인

작업	우분투 명령어	Centos 6 명령어	Centos 7 명령어
시작	service mysql start	service mysqld start	systemctl start mysqld
정지	service mysql stop	service mysqld stop	systemctl stop mysqld
재시작	service mysql restart	service mysqld restart	systemctl restart mysqld
상태 확인	service mysql status	service mysqld status	systemctl status mysqld

리눅스에 Mysql 설치 하기

Mr. YeokMaSsal — Thu, 28 Jul 2022 18:45:42 +0900

리눅스에 Mysql 설치 하기

설치 버전 : mysql 5.7 community
설치 환경 : Amazon Linux 2

Mysql 을 설치하는 방법은 2가지가 있다.

RPM 설치
Source Compile 설치
간단 설치하기

기본적으로 개인 개발을 위해서는 간단하게 설치를 하며 회사의 db나 프로젝트에서는 RPM 설치나 Source Compile 설치하는 형태로 진행될 것이다. 그럼 하나씩 알아보자

RPM 설치

RPM이란?

초창기 리눅스는 설치가 어려웠다 .소스코드를 갖고와서 적재적소에 컴파일을 해야했다. 그래서 일반사용자가 사용하기엔 거의 불가능했다. 이러한 이유로 외면을 받았었다. 결국 Redhat에서 RPM(Redhat Package Manager)을 내놓았다. 윈도우의 setup.exe 라고 생각하면 된다.

RPM 설치 장점

MySQL Repository를 설정해두면 원하는 버전을 마음대로 설
YUM 명령어를 통해 손쉽게 설치가 가능. 제거또한 손쉽게 가능
손쉬운 버전 업그레이드.(엔진 설치만 해당)

RPM 설치 단점

한가지 버전만 설치가 가능
추가적으로 제공되는 기능 사용 불가능
제한된 설치 옵션
제한된 설치 레이아웃.(바이너리 파일을 원하는 위치에 설치 불가능)

설치 순서는 다음과 같다.

1. Download Repository

2가지 방법 중 선택하여 설치한다. (난 repo를 다운 받음)

# repo
wget http://repo.mysql.com/mysql57-community-release-el7-11.noarch.rpm


# dev
wget https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm

2. Install Repository

repository를 설치한다.

rpm -ivh mysql57-community-release-el7-11.noarch.rpm

3. repository check

download한 repository를 확인한다.

rpm -qa | grep mysql57

## mysql repository 추가 여부 확인
yum repolist enabled | grep -i "mysql.*-community.*"

## 설치가능한 mysql 버전 리스트 확인
yum repolist all | grep -i mysql

4. 특정버전 활성화 확인

## 사용가능한 리스트만 출력되고 맨앞에 ! 가 붙으면 사용 가능하다는 표시임
yum repolist enabled | grep mysql

5. 설치하기

yum install mysql-community-server

6. mysql start후 확인

## mysqld start
systemctl start mysqld

## mysqld 상태체크
systemctl status mysqld

7. root 계정 패스워드 찾기&변경

## root 패스워드 찾기
grep -i 'temporary password' /var/log/mysqld.log

## 패스워드 변경하기
mysql -uroot -p

ALTER USER 'root'@'localhost' IDENTIFIED BY 'dusqhd10djr!!QQ';

8. root 계정 tool에서 접속 가능하게 하기

/* 모든 IP 허용 */
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '패스워드';

/* IP 대역대 허용 */
GRANT ALL PRIVILEGES ON *.* TO 'root'@'172.10.0.%' IDENTIFIED BY '패스워드';

/* 특정 IP 허용 */
GRANT ALL PRIVILEGES ON *.* TO 'root'@'172.10.0.254' IDENTIFIED BY '패스워드';

/*
이 설정을 했음에도 불구하고 접근 권한 거부가 뜬다면,
firewall(방화벽)를 확인 해보자. 3306 port를 허용해줘야 한다.

방화벽 포트 확인
firewall-cmd --list-all-zones

3306 포트 허용하기
firewall-cmd --permanent --zone=public --add-port=3306/tcp
*/


flush privileges;

9. my.cnf 파일 설정

vi /etc/my.cnf

## timezone 변경
default-time-zone='+9:00'

## binglog 설정
log-bin=mysql_bin
server-id=1
binlog_format=ROW
expire_logs_days=7
binlog_checksum=NONE
binlog_row_image=FULL

## 캐릭터셋 변경
character-set-server=utf8
collation-server=utf8_general_ci

만약 캐릭터 셋 변경 전 생성된 database나 table이 있는경우

ALTER DATABASE <database_name> CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
ALTER TABLE <table_name> CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Source Compile 설치

Source Compile 설치 장점

같은 서버스펙에 설치시 기존 컴파일된 바이너리로 복사해서 사용가능
편리한 MySQL 엔진 제어. (Systemd, initd, mysqld_safe등을 이용한 엔진 시작 및 종료)
바이너리 파일들을 원하는 디렉토리에 배치
특정 기능 미 사용시 비활성화 가능
RPM에서 제공하지 않는 기능을 활성화해서 사용 가능 (Profiling Code, Dtrace, Archive Storage, Black Hole Storage 등)
컴퓨터 아키텍처에 맞게 소스가 빌드되기 때문에 추가적인 성능을 제공

Source Compile 설치 단점

종속 패키지 설치의 어려움.같은 역할을 하지만 리눅스 배포판별 패키지 이름이 다름
오픈소스 빌드 경험이 있어야 쉽게 접근이 가능(Apahce, Nginx, PHP등)

설치 순서는 다음과 같다.

1. 유저 생성

groupadd mysql
useradd -r -g mysql -s /bin/false mysql

2. 의존성 패키지들 설치

yum install cmake make autoconf openssl openssl-devel ncurses ncurses-devel perl bison automake binutils flex gcc gcc-c++ gettext libtool patch pkgconfig rpm-build rpm-sign

3. mysql 설치

wget https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-5.7.20.tar.gz
tar xvfz mysql-5.7.20.tar.gz
cd mysql-5.7.20

4. mysql 컴파일

cmake \
-DCMAKE_INSTALL_PREFIX=/usr/local/mysql \
-DSYSCONFDIR=/etc \
-DWITH_BOOST=/usr/local/src/boost \
-DDOWNLOAD_BOOST=1 \
-DWITH_ARCHIVE_STORAGE_ENGINE=1 \
-DWITH_BLACKHOLE_STORAGE_ENGINE=1 \
-DWITH_EXAMPLE_STORAGE_ENGINE=1 \
-DWITH_FEDERATED_STORAGE_ENGINE=1 \
-DWITH_PARTITION_STORAGE_ENGINE=1 \
-DENABLED_PROFILING=1 \
-DWITH_CURL=system \
-DOPTIMIZER_TRACE=1 \
-DWITH_INNODB_MEMCACHED=1 \
-DWITH_SSL=system \
-DWITH_ZLIB=bundled



make  ## 30분 정도 걸림
make install

5. 엔진 실행

cd /usr/local/mysql
mkdir data
chown mysql:mysql data

6. 초기환경 설정

##my.cnf 환경 설정.

vi /etc/my.cnf


[mysqld]
datadir=/usr/local/mysql/data
socket=/tmp/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

[mysqld_safe]
log-error=/var/log/mysqld.err
pid-file=/usr/local/mysql/data/mysqld.pid

7. 데이터베이스 생성

cd /usr/local/mysql
bin/mysqld --defaults-file=/etc/my.cnf --initialize --user=mysql

## 위의 명령어를 수행후 바로 아래 나오는 실행 로그에 root 암호가 나옵니다.

8. 데이터베이스 실행

bin/mysqld_safe --defaults-file=/etc/my.cnf --user=mysql &

9. Mysql 접속 및 root 암호 변경

mysql -u root -p
mysql> alter user 'root'@'localhost' identified by '[패스워드설정]’;

## 초기 암호 정책에 따라 대소문자,특수문자,숫자가 반드시 같이 있어야 합니다.

10. Mysql 서버 시작 스크립트 등록

## MySQL 후속 작업.
## MySQL 서버 시작 스크립트 등록.
## MySQL 서버를 편하게 시작 및 종료할 수 있는 스크립트를 MySQL에서 제공함.

cd /usr/local/mysql/support-files
cp mysql.server /etc/init.d/mysqld

## 서버 종료
/etc/init.d/mysqld stop 

## 서버 시작
/etc/init.d/mysqld start

간단하게 설치하기

1. mysql 5.7 설치

yum -y install http://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm
yum -y install mysql-community-server

2. mysql start후 확인

## mysqld start
systemctl start mysqld

## mysqld 상태체크
systemctl status mysqld

3. root 계정 패스워드 찾기&변경

## root 패스워드 찾기
grep -i 'temporary password' /var/log/mysqld.log

## 패스워드 변경하기
mysql -uroot -p

ALTER USER 'root'@'localhost' IDENTIFIED BY 'dusqhd10djr!!QQ';

4. root 계정 tool에서 접속 가능하게 하기

/* 모든 IP 허용 */
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '패스워드';

/* IP 대역대 허용 */
GRANT ALL PRIVILEGES ON *.* TO 'root'@'172.10.0.%' IDENTIFIED BY '패스워드';

/* 특정 IP 허용 */
GRANT ALL PRIVILEGES ON *.* TO 'root'@'172.10.0.254' IDENTIFIED BY '패스워드';

/*
이 설정을 했음에도 불구하고 접근 권한 거부가 뜬다면,
firewall(방화벽)를 확인 해보자. 3306 port를 허용해줘야 한다.

방화벽 포트 확인
firewall-cmd --list-all-zones

3306 포트 허용하기
firewall-cmd --permanent --zone=public --add-port=3306/tcp
*/


flush privileges;

5. my.cnf 파일 설정

vi /etc/my.cnf

## timezone 변경
default-time-zone='+9:00'

## binglog 설정
log-bin=mysql_bin
server-id=1
binlog_format=ROW
expire_logs_days=7
binlog_checksum=NONE
binlog_row_image=FULL

## 캐릭터셋 변경
character-set-server=utf8
collation-server=utf8_general_ci

만약 캐릭터 셋 변경 전 생성된 database나 table이 있는경우

ALTER DATABASE <database_name> CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
ALTER TABLE <table_name> CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

[Linux] 리눅스 명령어 (기초)

Mr. YeokMaSsal — Thu, 28 Jul 2022 18:15:44 +0900

리눅스 명령어

리눅스를 전혀 해본적이 없던 내가 2달간 Mysql DBA를 하면서 급하게 배운 리눅스 명령어에 대해 적어본다.

추가로 배워야 할 게 많지만 가장 기초가 될만한 명령어 리스트이다.

버전확인

grep . /etc/*-release

find

#파일명이 os-rele로 시작하는 파일 찾기 (루트 디렉토리에서 부터 찾는거)
find / -name os-rele* 

# tmp 파일을 찾아서 다 지우기
find . -name "*.tmp" -exec rm -f {} \;

# 현재 경로에서부터 시작해서 file 찾기
find . -type file -name "*.txt"

# 현재 경로에서부터 시작해서 directory 찾기
find . -directory file -name "*abc"

파일 만들기

#abc를 test 파일로 만들어서  출력
echo abc > test

#파일을 만들면서 편집하기
vi test.txt

#빈파일 하나 만들기
touch test.txt

tail, head

# 끝에 10줄 보기
tail bitcoinAutoTrade.py

# 위에 10줄 보기
head bitcoinAutoTrade.py

# 마지막줄 실시간으로 보기
tail -f filename.txt

# 마지막줄 원하는 라인수(20) 만큼 보고싶을때
tail -n 20 filename.txt

ACL

Access Control List로 파일과 디렉토리를 사용할 수 있는 권한을 관리하는 것이다.

d가 나오면 directory 이다. - 가 나오면 파일이다.
ACL과 Permission은 같다고 생각하면 된다.

chmod

change mode로 파일과 디렉토리의 권한설정이다.

chmod [OPTION]...MODE[.MODE]...FILE

chmod u+R user01
#user01의 소유자에게 읽기 권한을 줘라

chmod g-R group01
#group01 그룹에게 읽기 권한을 제거해라

chmod 764 user01
#7은 RWX
#5는 RX
#6은 RW
#3은 WX

권한은 상속 관계이므로 상위 디렉토리의 권한을 제거하면 하위도 적용 된다.

chown

chgrp plan ourpassword
# ourpassword 소유권을 plan 그룹으로 변경

chown egoing:admin ourpassword
#chown으로 소유자와 그룹을 같이 권한 주기 가능

ls

#가장 최신이 위에 올라오게 하기 asc
ls -lta

#가장 최신이 아래에 올라오게 하기 desc
ls -ltar

grep

# test.txt 파일에서 a 찾기
grep "a" test.txt

# 해당 텍스트가 몇번째 줄에 있는지 확인
grep -n "world" *.txt

# 대소문자 상관없이 검색하고싶다.
grep -ni "world" *.txt

# 폴더내의 모든 경로에 한해서 찾고싶다
grep -nir "world" .

history

#지금까지 내린 명령 보기
history

#history 중 ls 명령어 찾기
histroy | grep ls

cp

#파일복사
cp 기존파일 복사파일

less

#내용을 스크롤 할 수 있도록 보는 명령어
less services

#단축키
/문자열 : 찾고자 하는 문자열

# 파일의 마지막 부분 보기
# 라인수를 계산한다는 메세지가 나오면 CTRL + C를 눌러서 라인계산을 멈추기
# b를 누르면 이전페이지로 이동해서 보여주고 다시 페이지로 돌아가려면 f 키를 누르면 된다.
less +G file_name.txt

# 파일을 끊어 볼때
# 스페이스바는 페이지 단위로 넘어가고 엔터는 라인단위로 넘어감
less file_name.txt

vi

#vi 환경에서는 hjkl로 방향키 조정

#문자열 검색
/문자열

#한행 지우기 
dd
2dd : 두행 지우기

#이전작업 되돌리기
u

#한행 복사 및 붙여넣기

yy (복사할 행 가서)
p  해당행 밑에 복사됨

#위에 글자를 입력하고싶다
대문자 O

#아래에 글자를 입력하고싶다
소문자 o

locate

# access.log 위치 찾기
locate access.log

vi 내 글자 찾기

vi 파일명
/찾을 글자 -> n하면 next로 넘어감

chkconfig

## chkconfig 는 리눅스서버가 부팅될 때 실행될 프로그램을 설정하는 역활을 하는 유틸리티


# Linux 리스트 확인
chkconfig --list [프로그램명]

# Linux 시작시 실행되도록 설정
chkconfig [프로그램명] on

# Linux 시작시 실행되지 않도록 설정
chkconfig [프로그램명] off

# Linux 런 레벨별로 시작시 실행되도록 설정
chkconfig --level [레벨] [프로그램명] on

# Linux 런 레벨별로 시작시 실행되지 않도록 설정
chkconfig --level [레벨] [프로그램명] off

pwd

## 현재 위치 
pwd

mv

# 파일 or 디렉토리 이동시키기
mv 이동할파일 이동시킬경로

cd

# 경로이동
cd 경로

# 방금 경로 다시 이동
cd -

cat

# 파일 내용 보기
cat file_name.txt

# 파일 여러개 합쳐서 보기
cat file_name.txt file2_name.txt

# 행번호 붙이기
cat file_name.txt -n

# 행번호 붙일때 개행은 번호 안붙이기
cat file_name.txt -b  
nl file_name.txt

echo

# 출력하기
echo "hellow world"

# 파일 만들면서 내용 넣기
echo "hello world" > new_file.txt

# 기존 파일에 내용 추가
echo "goodbye world" >> new_file.txt

rm

# 파일 삭제
rm file.txt

# 경로 삭제
rm -r directory

메모리 확인

cat /proc/meminfo | grep MemTotal

grep MemTotal /proc/meminfo

cpu 개수

# CPU 코어 개수
# 가상 CPU 코어 수는 48. 따라서 물리적으로는 24 코어
grep -c processor /proc/cpuinfo


# CPU 수
grep ^processor /proc/cpuinfo | wc -l

# CPU당 물리 코어수
grep 'cpu cores' /proc/cpuinfo | tail -1

디스크 사용량 확인

# df : 디스크의 남은 용량을 확인
# 킬로바이트 단위로 현재 남은 용량을 확인
df -k 

# 메가바이트 단위로 남은 용량을 확인
df -m 

# 보기 좋게 보여줌
df -h 

# 현재 디렉토리가 포함된 파티션의 남은 용량을 확인
df .  

#du : 현재 디렉토리에서 서브디렉토리까지의 사용량을 확인 

# 현재 디렉토리의 사용량을 파일단위 출력
du -a 

# 총 사용량을 확인
du -s 

# 보기 좋게 바꿔줌 
du -h 

# 한단계 서브디렉토리 기준으로 보여준다.
du -sh *

압축 및 해제

#================================================
#  압축 하기
#================================================

# tar 압축 (abc라는 폴더를 aaa.tar로 압축)
tar -cvf aaa.tar abc

# tar.gz 압축 (abc라는 폴더를 aaa.tar.gz로 압축)
tar -zcvf aaa.tar.gz abc

# zip 압축 (현재폴더 전체를 aaa.zip으로 압축)
zip aaa.zip ./*


#================================================
#  압축 해제
#================================================

# tar 압축 해제 
tar -xvf aaa.tar
tar -xvf aaa.tar -C ./test_dir # test_dir에 압축해제

# tar.gz 압축 하제
tar -zvxf aaa.tar.gz
tar -zxvf aaa.tar.gz -C ./test_dir # test_dir에 압축해제

# zip 압축 해제
unzip aaa.zip

# 특정 폴더에 압축해제
unzip aaa.zip -d ./target

gzip을 통해 압축 및 압축 풀기

#============================================================
#  압축 하기
#============================================================
-rw-r--r--. 1 test01 test01 10M 2015-08-11 18:31 test01.txt
-rw-r--r--. 1 test01 test01 10M 2015-08-11 18:40 test02.txt
-rw-r--r--. 1 test01 test01 10M 2015-08-11 18:40 test03.txt

# test로 시작하는 파일 gzip 하기
# gzip은 압축을 수행한 후 압축 대상이었던 파일은 삭제한다.
gzip test*
ls -lh

-rw-r--r--. 1 test01 test01 10K 2015-08-11 18:31 test01.txt.gz
-rw-r--r--. 1 test01 test01 10K 2015-08-11 18:40 test02.txt.gz
-rw-r--r--. 1 test01 test01 10K 2015-08-11 18:40 test03.txt.gz

# 압축된 파일은 -l 옵션으로 확인 가능
gzip -l test*


#============================================================
#  압축 풀기
#============================================================
[test01@centos6 temp]$ gunzip test*
[test01@centos6 temp]$ ls -lh 
-rw-r--r--. 1 test01 test01 10M 2015-08-11 18:31 test01.txt
-rw-r--r--. 1 test01 test01 10M 2015-08-11 18:40 test02.txt
-rw-r--r--. 1 test01 test01 10M 2015-08-11 18:40 test03.txt

du -h

# 파일의 사이즈를 보기 좋게 하기 위한 명령어
du -h 파일명

SQL Server 고가용성

Mr. YeokMaSsal — Wed, 27 Jul 2022 10:29:37 +0900

SQL Server 고가용성

Mirroring

미러링이란 장비가 고장나는 사고가 발생 했을때 데이터가 손실되는것을 방지하기 위해 데이터를 하나 이상의 장치에 중복 저장하는 것을 말한다. 주 DB가 장애 발생시 보조 DB를 사용할 수 있다. 미러링 구성시 총 주역할, 보조역할, 모니터링 역할 이렇게 3개의 SQL Server 인스턴스가 필요하다.

모니터 서버는 주서버와 미러 서버를 모니터링 하여 지정한 시간에 장애조치 파트너 중 하나만 주 서버로 작동하게 하는 방식으로 장애조치를 지원한다. 보조서버는 주서버가 장애가 나지 않으면 READ 될 수 없기 때문에 주서버의 부하를 줄여 줄 수 없다. 해당 기능은 2019 이후 버전부터는 제거될 이중화 기술이다.

Log Shipping

주 서버가 정기적으로 백업한 트랜잭션 로그를 보조서버에 정기적으로 복사하고, 이를 복원해서 주 서버와 보조 서버가 같은 데이터베이스가 유지하도록 하는 방법이다. 장점은 주서버어 대한 부하를 감소 시킨다. 단점은 장애 발생시 자동 장애조치가 불가능 하고 수동 장애조치가 매우 까다롭다. 또한 장애조치시 클라이언트의 리다이렉션 기능이 없다.

MSCS

MSCS(Microsoft Cluster Service)는 두개 이상의 컴퓨터 그룹으로써 서로 연결 되어 있으며 하나가 실패하면 MSCS가 장애 복구를 수행하여 실패한 컴퓨터로 부터 클러스터에 있는 다른 컴퓨터로 애플리케이션의 상태 데이터를 전송하고 그 컴퓨터에서 해당 조작을 다시 시작하는 방식으로 구성된다.

두 개의 시스템 클러스터는 가상 IP 주소를 사용하여 클라이언트 액세스를 위해 네트워크에 공동으로 연결된 두 개의 컴퓨터(예: A와 B)로 구성된다. 또한 한 개 이상의 사설 네트워크에 의해 서로 연결될 수도 있으며, A와 B는 각각에 있는 서버 애플리케이션이 최소한 한 개의 디스크를 공유하여 사용한다.

Always on

SQL Server 2012부터 생긴 기능으로서 엔터프라이즈 레벨의 고가용성과 재해복구 기능을 갖춘 하나이상의 데이터베이스에 대한 최대한의 가용성을 보장한다. 가용성 그룹(Availability Group), FCI(Failover Cluster Instance), HA 배포 및 관리에 이르는 전체적인 데이터베이스 고가용성을 위한 기능의 묶음이다. Always on의 장점은 아래와 같다.

DB 이중화
주 서버 장애 발생시 즉각적인 서비스 전환
리스너를 이용한 단일 Connecting String 구성
보조 서버 DB 데이터 읽기를 통한 서비스 부하 분산

DB 데이터 실시간 복제 수행 및 장애조치(Failover)

주 서버와 보조 서버 간의 실시간 데이터 동기화를 통한 데이터 중복성을 제공한다.

기존 DB 미러링 구성과 달리 모니터링 서버가 필요 없으며, 장애 조치 클러스터 (WSFC)를 이용하여 자동 장애 조치를 지원한다.

가용성 그룹

기존 미러링은 장애 조치 시 Application에서 접속하는 인스턴스를 변경해야 했으나, AlwaysOn에서는 가용성 그룹 수신기를 사용하여 Application의 수정 없이 DB 데이터에 연결 할 수 있다.

보조 복사본을 구성할 때 Read/Write를 수행할 것인지 Read Only만 수행할 것인지 설정하므로, Read Only 작업은 해당 역할을 수행하는 보조 복사본으로 구성한다.

SQL Server 아키텍처

Mr. YeokMaSsal — Wed, 27 Jul 2022 10:18:31 +0900

SQL Server 아키텍처

SQL Server Engine

SQL Server는 크게 두개의 Engine으로 구분된다.

Relational Engine

Relational Engine은 쿼리를 실행하기 위한 엔진으로써 쿼리 옵티마이저와 쿼리 실행기가 포함되어 있기 때문에 포괄적으로 쿼리 프로세스라고도 불린다. 쿼리의 Syntax를 체크, 쿼리 Tree를 만들고 옵티마이저가 실행계획을 만들며, 쿼리 실행기가 그 쿼리를 실행하게 된다. Relational Engine에는 아래의 기능들이 포함되어 있다.

Command(CMD) Parser
Command Parser는 T-SQL 구문을 받아서 그 구문이 정상적인 구문인지 검사를 하고 오류가 있으면 syntax error를 클라이언트에 반환을 하며 그 구문이 정상적이면 Buffer Pool 영역의 Plan Cache를 검색하여 기존에 사용하고 있었던 Query Plan이 있다면 Query Executor로 없다면 Query Plan을 만들기 위해 쿼리문을 Query tree 로 쪼개어 Optimizer로 전달이 된다.
Query Optimizer
Query에 대해 효율적인 실행계획 및 SQL 재작성 등의 기능을 수행 한다.
Query Excutor
Query를 실행 시키는 역할을 한다.

Storage Engine

Storage Engine은 데이터에 대한 모든 I/O를 관리하는 액세스 메소드(Access Methods)를 포함해 물리적 작업을 하는 엔진이다. Storage engine에는 SQL Server에서 사용하는 영역중 가장 많은 영역을 차지하고 있는 Buffer Pool을 관리하는 Buffer Manager와 트랜잭션 격리 수준을 유지하기 위해 데이터 잠금을 처리하고 로그를 관리하는 Transaction Manager가 포함되어 있다.

Access Methods
논리적인 페이지의 접근 횟수에 대한 모니터링을 하는 도구이다. 이를 통해 데이터베이스에 있는 데이터, 인덱스, 여유공간의 양을 모니터링 하여 각 서버 인스턴스에 대한 데이터 볼륨 및 족가화 상태를 나타낼 수 있다.
Buffer Manager
SQL Server에서 사용하는 메모리를 관리하는 영역이다. 페이지에서 일부 행을 읽어야 할 때 버퍼 관리자는 메모리에 해당 페이지가 있는지 확인을 하고 있으면 그 페이지를 Access Methods로 전달을 하고 없으면 디스크에서 해당 페이지를 읽어와 메모리 Data Cache 영역에 그 페이지를 올린다.
Transaction Manager
변경된 데이터가 디스크에 기록되기까지 유지되어야 하며 그 역할을 담당하는 것은 Transaction Manager이다. Transaction Manager에는 크게 두가지 요소가 있는데 Lock Manager와 Log Manager이다. Lock Manager는 데이터 동시성 및 트랜잭션 격리성을 보장하기 위하여 격리 수준을 설정하며 Log Manager는 트랜잭션 원자성과 지속성을 보장하기 위하여 존재를 한다. Access Methods는 변경된 내용을 코드로 만들어서 Transaction Manager에 요청을 하고 Transaction Manager는 Log Manager를 통해 그 내용들을 Transaction Log에 쓰는 작업을 하는데 이 작업을 writer-Ahead Logging(로그 미리쓰기)라고 한다. 이는 트랜잭션 속성중 원자성과 지속성을 보장하기 위하여 일어나는 작업이며 SQL Server가 시스템 장애로 부터 데이터를 복구할 수 있는 유일한 수단이 Transaction Log이다.

파일구조

물리적 구조

SQL Server의 파일 구조는 mdf,ndf,ldf로 나뉜다.어떤 데이터베이스에 테이블이 10개가 있다. 3개의 테이블을 가장 많이 사용하고 나머지 7개의 테이블은 거의 사용을 안한다고 생각해 보자. 이때 데이터베이스를 파일 그룹으로 생성하고 많이 사용하는 3개의 테이블을 프라이머리 파일그룹에 생성해 물리적인 하나의 디스크에 구축한다. 아울러 자주 사용하지 않는 7개의 테이블을 보조 파일 그룹에 생성해 또 다른 물리적인 디스크에 구축하는 것이다. 그렇게 되면 물리적으로 다른 디스크를 사용하게 되니 하나의 디스크를 사용 할 때 보다 데이터파일 사용의 경쟁이 줄 것이다. 이렇듯 보조 데이터 파일을 생성하여 데이터 관리를 효율적으로 하게되면 데이터 베이스의 성능을 높힐 수 있을 것이다.

ldf는 트랜잭션 로그 파일 그로써 트랜잭션의 처리내용 및 데이터 추가, 변경, 삭제 내용을 담고 있다. ldf는 데이터베이스를 복구하는데 사용되는 모든 로그정보가 들어 가있다. ldf가 2개 이상 있을수 있으며, 데이터베이스마다 적어도 하나의 ldf 파일은 있어야 한다.

mdf와 ndf는 실제 데이터가 들어가 있는 파일들이다. mdf는 주 데이터 파일(Primary Data File)으로써 실제 데이터가 저장되는 공간이다. 그리고 추가적으로 ndf 파일을 가질 수 있으며 ndf 파일은 mdf 이외에 추가적으로 데이터가 저장되는 공간이다. ndf를 사용하는 이점은 무엇일까?

논리적 구조

page : 논리적인 데이터 읽기의 최소 단위로서 크기는 8kb
Extent : page 공간이 부족할 경우 증분 되는 단위
Heap/Index : ....

Write Ahead Logging(WAL)

무결성을 보장하는 방법이다. 데이터 수정을 하기 전 ldf 파일(Transaction Log File)에 먼저 기록을 하고 이것을 통해 장애 발생시 데이터를 복구 할 수있게 된다. 데이터 변경시 Log에 기록하고 Checkpoint 발생시 disk에 저장하게 된다. 일단 Log에 적히게 되면 누가 조회를 해도 같은 데이터를 보여주는 일관성(Consistency)를 보장하게 되고 서버가 다운되도 이미 Log에 기록 되어 있어 원자성(Atomicity)도 보장할 수가 있다.

Check Point

Dirty page(데이터가 변경되었지만 로그에만 기록되고 디스크에는 기록되지 않은 page)가 Buffer Pool 에서 디스크로 쓰여질 때는 CheckPoint가 발생하거나 LazyWriter가 발생했을 때다. CheckPoint는 퍼지알고리즘으로 발동이 되며 트랜잭션이 완료가 된 Dirty page를 물리적 디스크에 쓰게 된다. Checkpoint를 주기적으로 발생시키고 싶다면 SQL Server 구성옵션에서 Recovery Interval 옵션을 이용하면 된다. Checkpoint가 발생되는 주기를 보고 싶으면 시작 플래그에 3502를 주면 에러로그에 Checkpoint가 발생 시점 끝나는 시점을 기록하게 된다.

Checkpoint와 복구 시점
- Roll Backup(undo) - Checkpoint가 발생하기 전에 시작된 트랜잭션이 있으면 취소
- Roll Forward(redo) - Checkpoint가 발생하기 전에 완료된 트랜잭션이 있으면 다시 실행

Lazy Writer

Lazywriter은 Buffer가 부족할 때 발생하는 Thread이며 LazyWriter은 Checkpoint와는 다르게 데이터 캐시에 존재하고 있는 Dirty page을 디스크에 기록하면서 완전 삭제를 한다. Checkpoint는 디스크에 기록하면 페이지를 Dirty page에서 더 이상 Dirty page가 아니라고 변경만 한다.

[Linux] Shell Script 작성법

Mr. YeokMaSsal — Wed, 27 Jul 2022 09:57:39 +0900

Shell 이란?

Shell(쉘)은 운영체제상에서 사용자가 입력하는 명령을 읽고 해석하여 대신 실행해주는 프로그램이다. 즉 다시말해서, 운영체제의 커널과 사용자 사이를 이어주는 역할을 하며 사용자의 명령어를 해석하고 운영체제가 알아들을 수 있도록 도와주는 명령어 해석기이다. Linux에서 사용하는 Shell의 종류로는 다음과 같은 것들이 있다.

그렇다면 쉘 스크립트란 무엇일까?

Shell Script란?

Shell Script(쉘 스크립트)란 Shell(쉘)에서 사용할 수 있는 명령어들의 조합을 모아서 만든 배치(batch)파일이다. 즉, 운영체제의 Shell을 이용하여 한줄씩 순차적으로 읽으면서 명령어들을 실행시켜주는 인터프리터 방식의 프로그램이다. Shell Script를 활용하여 묶어진 명령어 조합을 수행하거나 반복적인 명령어를 단일 명령으로 쉽게 사용할 수 있다.

Shell Script 작성 순서

1. 파일생성

vi test_shell.sh

2. vi에서 bash shell 선언

#!/bin/bash

3. vi에서 스크립트 작성

#!/bin/bash
echo "HELLO"

4. 실행권한 추가

chmod +x test_shell.sh

5. 실행시키기

./test_shell.sh

[Linux] Crontab 설정

Mr. YeokMaSsal — Wed, 27 Jul 2022 00:31:48 +0900

Crontab 이란?

Linux 운영 체제 내에서 서버 스스로 정해둔 명령을 일정 기간마다 실행하도록 하는 것입니다.

명령어

Crontab 리스트 확인

crontab -l

Crontab 수정

crontab -l

Crontab 제거

해당 crontab을 제거하기 위해서는 Crontab 수정을 통해 명령어를 지우고 프로세스 id를 찾아서 kill해줘야 한다.

Crontab 설정

45 22 * * *                         22시45분에 실행

28 03 * * *                         03시28분에 실행

0 17 * * *                          17시00분에 실행

0 17 * * 1                          매주 월요일 17시00분에 실행

0,10 17 * * 0,2,3                  매주 일, 화, 수요일 17시00 분과 17시10분에 실행

0-10 17 1 * *                      매달 1일 17시00분부터17시10분까지 1분 단위로 실행

0 0 1,15 * 1                        매달 1일과 15일 그리고 월요일 24시00분에 실행

42 4 1 * *                           매달 1일 4시42분에 실행

0 21 * * 1-6                        월요일 부터토요일까지 21시00분에 실행

0,10,20,30,40,50 * * * *         10분 간격으로 실행

*/10 * * * *                         10분 간격으로 실행

*/5 * * * *                           5분 간격으로 실행

* 1 * * *                             1시00분 부터 1시59분 까지 1분 간격으로 실행

0 1 * * *                             1시00분에 실행

0 */1 * * *                          매시간 0분에 실행(1시간 간격으로 실행)

0 * * * *                             매시간 0분에 실행(1시간 간격으로 실행)

5 2-5 * * *	                        2시 5분, 3시 5분, 4시 5분, 5시 5분에 실행

2 8-20/3 * * *                     8시 2분, 11시 2분, 14시 2분, 17시 2분, 20시 2분에 실행

30 5 1,15 * *                      매달 1일과 15일 5시30분에 실행

crontab 서식

[Linux] SED

Mr. YeokMaSsal — Tue, 26 Jul 2022 20:20:44 +0900

SED란?

정규식과 같은 패턴 식을 적용하여 파일을 원하는대로 편집할 수 있는 프로그램 이다. vi 편집기처럼 직접 파일을 열어 고치지 않고 커맨드 창 또는 스크립트에서 동작을 하여 원하는 부분만 변경해준다는 특징이 있다.

SED 특징

sed는 쉘 또는 스크립트에서 파이프(|)와 같이 사용될 수 있는 명령어이다.

그리고 기본적으로 정규표현식이 사용가능하기 때문에 정규표현식을 알면 더 고급지게 sed를 이용할 수 있다.

주의할 점은 정규표현식을 사용하기 때문에 특수문자 앞에 역 슬래시(\,＼)를 붙여주어야 합니다. \를 쓰면 리눅스에서는 역슬래시로 받아들인다.

예) sed 's/\$man/man/g' test.txt

SED 옵션

e : sed를 사용하였을 때 출력되는 값을 보여준다. 이 옵션은 기본값으로 굳이 안 써도 되지만 다중 명령어를 쓸 때는 반드시 써야 한다.
n : 특정 값이 들어간 줄만 출력해주는 기능이다. 주로 p 명령어와 사용된다.
f : 스크립트를 파일로부터 읽어들이며 명령어를 지정하는 명령어라고 하는데 저는 거의 사용하지 않는다.
i : 변경되는 값을 실제로 파일에 저장하는 옵션이다. 출력되는 값이 없이 바로 실제 파일에 적용되는 것이 특징이다.

SED 자주 쓰는 명령어

특정 범위 만큼 파일 내용 출력

# employees파일에서 첫 번째 행만 출력해서 화면에 보여준다.
sed -n '1p' employees;

# employees파일에서 1~3라인 범위의 내용을 출력해서 보여준다.
sed -n '1,3p' employees;

# employees파일에서 8라인부터 파일끝까지 출력해서 보여준다. $는 '끝'을 의미합니다.
sed -n '8,$p' employees;

# employees파일의 1행 출력, 8번부터 마지막 행 까지 출력
sed -n -e '1p' -e '8,$p' employees

# file파일에서 love가 포함된 행들을 찾아 출력으로 보여줘 (-n 옵션이 있어야 love 패턴을 포함하는 줄들만 출력합니다)
sed -n '/love/p' file

# file파일에서 west가 나오는 행과 east가 나오는 행 사이의 모든 행들이 출력됩니다. west가 east 다음에 나오면 west가 나오는 행부터 파일의 마지막까지 출력됩니다.
sed -n '/west/,/east/p' file

# 3번째 행부터 employee로 시작되는 행까지 출력합니다.
sed -n '3,/^employee/p' file

특정 단어로 시작하는 행들만 추출

# 107로 시작하는 행 출력
sed -n '/^107/p' employees  

# 103이 포함된 행 출력
sed -n '/103/p' employees

공백이나 빈줄 제거

# employees파일에서 빈 라인들을 지운 후 내용을 출력해준다.
sed '/^$/d' employees

# employees파일에서 빈 라인들을 삭제한 후 결과를 new_employees라는 파일명으로 저장한다.
sed '/^$/d' employees > new_employees

# employees파일에서 빈 라인들이나 공백으로 채워진 행들을 삭제한 후 new_employees라는 파일명으로 저장한다.
sed '/^ *$/d' employees > new_employees

# file파일에서 3번째 행을 삭제합니다. 나머지 행들이 출력.
sed '3d' file

# 5번째 행부터 마지막 행까지 삭제, 그리고 나머지 행들이 출력된다.
sed '5,$d' file

# 마지막 행을 삭제. d명령어로 삭제된 행 이외의 모든 행들이 출력됨
sed '$d' file

# 파일에서 apple 포함하는 모든 행을 삭제 나머지 행을 출력합니다.
sed '/apple/d' file

단어 치환

# IT_PROG라는 단어를 찾아 DEVELOPER라는 단어로 변경해줘!
sed 's/IT_PROG/DEVELOPER/g' employees

# IT_PROG라는 단어를 찾아 DEVELOPER라는 단어로 변경해줘! (대소문자 무시하고)
sed 's/it_prog/DEVELOPER/gi' employees > new_employees

# [0-9][0-9]는 두 자리 숫자를 의미하죠. 근데 그 다음에 끝을 의미하는'$'가 왔어요. 
# 즉 '두 자리 숫자로 끝나는 행'이 바꿈의 대상이 됩니다. 여기서 '&'는 검색열에서 지정한 문자열을 대신합니다. 
# 그 문자열 뒤에 '.5'가 붙었네요. 즉 두자리 숫자로 끝나는 행 (ex 94) 를 찾으면 뒤에 점오를 붙인 단어로 (ex 94.5) 치환해 보여달라는 명령어입니다.
sed 's/[0-9][0-9]$/&.5/' file

파일 읽기 및 쓰기

# file파일로부터 ref라는 단어를 찾으면 그 패턴찾은 행 뒤에 addfile의 내용을 붙여 출력합니다.
sed '/ref/r addfile' file


# file파일로부터 north라는 패턴이 포함된 행을 찾으면 그 선택한 행들을 outputfile에다가 저장합니다.
sed -n '/north/w outputfile' file

# file파일에서 END로 끝나는 행을 찾아, 그 다음에 'THANK YOU FOR READING'을 추가합니다.
sed '/END$/a\THANK YOU FOR READING' file

SED Subcommand 종류

SED의 메타문자

^ : 행의 시작 지시자
ex) /^test/ : test로 시작하는 행
$ : 행의 끝 지시자
ex) /test$/ : test로 끝나는 행
. : 하나의 문자
ex) /t..t/ : t로 시작하는 문자 다음에 두 글자가 오고 t로 끝나는 문자열을 포함하는 행
*** : 0개 혹은 임의의 임의 갯수**
ex) /*test/ 0개 혹은 임의 갯수의 문자 후에 test로 끝나는 행
[] : [] 사이의 문자 집합
ex) /[Tt]est/ : Test, test
[^] : 문자 집합에 속하지 않는 한 문자와 대응
ex) /[^A-K]est/ : A ~ K를 제외한 문자와 est가 붙어있는 문자열
$..$ : 태그로 문자열을 지정하는데 사용
ex) s/$lov$able/\1er/ : 지정한 lov를 tag 1로 저장한다. tag로 저장한 값은 \1을 사용한다 tag는 9개까지 가능하다.
& : 검색열을 저장하여 다음에 사용
ex) s/test/&/ : test를 test로 치환
\< : 단어의 시작 지시자
ex) /\<test/ : test로 시작하는 단어를 포함하는 행
\> : 단어의 끝 지시자
ex) /\>test/ : test로 끝나는 단어를 포함하는 행
x\{m\}/ : 문자 x를 m번 반복한다.
ex) /a\{5\} : a가 5번 반복
x\{m,\}/ : 문자 x를 최소 m번 반복한다.
ex) /a\{5,\}/ : a가 적어도 5번 반복
x\{m,n\} : 문자 x를 m회 이상 n회 이하 반복한다.
ex) /a\{5,10\}/ : a가 5회에서 10회 사이로 반복

참고자료

https://jhnyang.tistory.com/287

[On-premise DB to AWS] Mysql to Mysql DB Migration

Mr. YeokMaSsal — Tue, 26 Jul 2022 14:19:24 +0900

Mysql DB 클라우드로 이관하기

기존 On-premise DB에서 클라우드(AWS)로 이관하는 방법은 여러가지가 있다. 그중 하나가 AWS에서 제공하는 DMS라는 기능을 이용하는 것인데, Mysql에서 Mysql로 동종DB간의 이행은 왠만하면 비용적인 측면때문에 DMS를 이용하지 않는다. DB가 호환이 안되는 부분이 없다보니 Dump를 이용해서 처리하려고 하는것이 일반적이다.

DB 이관을 어떻게 할지는 각 사이트별 상황과 여건을 고려하여 아래와 같이 결정 할 수있다.

AWS DMS

DMS를 활용하는 경우는 아래와 같다.

비용 측면 : 높은 비용 감당 가능
다운 타임 : 제로 다운 타임
RDS와 On-premise 연결 가능 여부 : 가능하여야 함
Target DB : RDS Mysql

절차는 아래와 같다.

1. Source & Target 생성

Source는 기존 On-premise DB로 할것이며, Target은 RDS 로 설정 하면 된다.

2. Source의 복제 인스턴스 생성

AWS내의 복제 인스턴스를 생성 하여 Source DB 정보를 실시간으로 가져올 수 있게 설정 한다.

3. Source & Target 엔드포인트 생성

Source & Target 각각의 엔드포인트를 설정 한다.

4. DMS Task 생성

주의 사항

Target이나 Source에 AUTO_COMMIT 모드로 해야함
지속적 복제의 경우 binlog를 활성화 시켜 줘야 함

log-bin=mysql_bin
server-id=1
binlog_format=ROW
expire_logs_days=7
binlog_checksum=NONE
binlog_row_image=FULL

관련 사항은 아래 주소에서 확인 할 수 있다.

링크: https://docs.aws.amazon.com/ko_kr/dms/latest/userguide/CHAP_Source.MySQL.html

Dump → RDS

Dump를 활용하는 경우는 아래와 같다.

비용 측면 : 낮은 비용
다운 타임 : 다운 타임이 길어도 괜찮음
RDS와 On-premise 연결 가능 여부 : 가능하여야 함
DB를 내리고나서 이관이 가능해야한다.
Target DB : RDS Mysql

이관 명령어

mysqldump -u tester --databases [DABASE 명] --single-transaction --compress --routines=0 --triggers=0 --events=0 --order-by-primary -p | mysql -u admin --port=3306 --host=[DB주소] -p

유의 사항

Amazon RDS 데이터베이스에서 저장 프로시저, 트리거, 함수 또는 이벤트를 수동으로 만들어야 한다. 복사 중인 데이터베이스에 이런 객체가 하나라도 있는 경우에는 mysqldump 명령과 함께 mysqldump 파라미터를 포함시켜
--routines=0 --triggers=0 --events=0를 실행할 때 이런 객체를 제외 한다.
sys, performance_schema 및 information_schema 스키마는 mysqldump 유틸리티에서 기본적으로 dump에서 제외한다. 즉, DB의 사용자와 권한들을 다시 설정해줘야 한다.

이관 스크립트

쉘 스크립트를 이용하여 이관 스크립트를 생성하였으며 쉘스크립트 실행으로 이관을 실행하였다.

#!/bin/bash
echo " "
echo "#############################################"
echo "Dump Migration Start"
echo "#############################################"
echo " "

echo "-Start Time"
date '+%F  %r'
echo ""
echo ""

# Parameter Setting
SOURCE_DB_USER="[유저명]"
SORUCE_DB_PASSWD="[패스워드]"
SOURCE_DB="[DB명]"

TARGET_DB_USER="admin"
TARGET_DB_PASSWD="dusqhd10djr!!QQ"
TARGET_DB_IP="[IP주소]"


# Migration Start
mysqldump -u $SOURCE_DB_USER -p$SORUCE_DB_PASSWD --databases $SOURCE_DB --single-transaction --compress --routines=0 --triggers=0 --events=0 --order-by-primary | mysql -u $TARGET_DB_USER --port=3306 -p$TARGET_DB_PASSWD  -h $TARGET_DB_IP


echo""
echo""

echo "-End Time"
date '+%F  %r'

echo " "
echo "#############################################"
echo "Dump Migration End"
echo "#############################################"
echo " "

참고자료
링크:https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.SmallExisting.html

Dump → EC2 or S3 → RDS

Dump를 활용하는 경우는 아래와 같다.

비용 측면 : 낮은 비용
다운 타임 : 다운 타임이 길어도 괜찮음
RDS와 On-premise 연결 가능 여부 : 불가능 함
DB를 내리고나서 이관이 가능해야한다.
Target DB : RDS Mysql

Dump파일을 바로 RDS에 이관할수 없을 경우 EC2나 S3와 같은 저장소를 경유해서 이관하게 된다.
절차는 아래와 같다.

1. On-prem Dump file 생성

mysqldump -u test_user --databases [DATABASE명] --single-transaction --compress --routines=0 --triggers=0 --events=0 --order-by-primary -p > dump.sql

2. Dump 파일 신규 중계 EC2에 옮기기

Dump 파일을 중계 EC2를 생성해서 FTP로 옮긴다.

3. 중계 EC2에 Mysql 설치

yum update -y
yum install mysql

4. RDS로 이관하기

mysql -uadmin -p -h[DB주소] < dump.sql

Dump → RDS (Replica)

Dump를 활용하는 경우는 아래와 같다.

비용 측면 : 낮은 비용
다운 타임 : 제로 다운 타임
RDS와 On-premise 연결 가능 여부 : 가능

1. [On-premise] my.cnf 파일 수정

# binglog 설정
log-bin=mysql_bin
server-id=1
binlog_format=ROW
expire_logs_days=7
binlog_checksum=NONE
binlog_row_image=FULL

2. [On-premise] 기초 데이터 백업 생성

mysqldump -u test_user --databases [DATABASE명] --single-transaction --master-data=2 --compress --routines=0 --triggers=0 --events=0 --order-by-primary -p > replica_dump.sql

3. [On-premise] Replication User 생성 및 권한 부여

-- USER 생성
CREATE USER 'REPLICATION_USER'@'%' IDENTIFIED BY '[패스워드]';

-- 권한 부여
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'REPLICATION_USER'@'%';

4. [On-premise] dump에서 position 확인

less replica_dump.sql


-- MySQL dump 10.13  Distrib 5.7.35, for Linux (x86_64)
--
-- Host: localhost    Database: MIG_TEST_DB
-- ------------------------------------------------------
-- Server version       5.7.35-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Position to start replication or point-in-time recovery from
--

## -------------------------------------------------------------------
#  아래의 파일명과 포지션 복사해놓기		
## -------------------------------------------------------------------
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql_bin.000001', MASTER_LOG_POS=1285;

--
-- Current Database: `MIG_TEST_DB`
--

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `[DATABSE명]` /*!40100 DEFAULT CHARACTER SET latin1 */;

USE `[DATABSE명]`;

5. [On-premise] RDS로 기초 데이터 입력

mysql -u admin -p < replica_dump.sql

6. [RDS] external_master 실행

-- binlog 유지기간 늘리기
call mysql.rds_set_configuration('binlog retention hours', 24);

-- external master 실행
CALL mysql.rds_set_external_master ('[IP주소]', 3306, 'replication_user', '[패스워드]', 'mysql_bin.000001', 2859, 0);

7. [RDS] replication start 하기

-- replication 시작
CALL mysql.rds_start_replication;

-- replication 중지
CALL mysql.rds_stop_replication;

8. [RDS] 잘되는지 확인하기

SHOW SLAVE STATUS;

/* Slave_IO_Running, Slave_SQL_Running 두가지의 상태가 YES로 나와야 함 */
Name                         |Value                                                                                                                                                                                |
-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Slave_IO_State               |Waiting for master to send event                                                                                                                                                     |
Master_Host                  |10.0.4.202                                                                                                                                                                           |
Master_User                  |replication_user                                                                                                                                                                     |
Master_Port                  |3306                                                                                                                                                                                 |
Connect_Retry                |60                                                                                                                                                                                   |
Master_Log_File              |mysql_bin.000001                                                                                                                                                                     |
Read_Master_Log_Pos          |3281                                                                                                                                                                                 |
Relay_Log_File               |relaylog.000005                                                                                                                                                                      |
Relay_Log_Pos                |271                                                                                                                                                                                  |
Relay_Master_Log_File        |mysql_bin.000001                                                                                                                                                                     |
Slave_IO_Running             |Yes                                                                                                                                                                                  |
Slave_SQL_Running            |Yes                                                                                                                                                                                  |
Replicate_Do_DB              |                                                                                                                                                                                     |
Replicate_Ignore_DB          |                                                                                                                                                                                     |
Replicate_Do_Table           |                                                                                                                                                                                     |
Replicate_Ignore_Table       |innodb_memcache.cache_policies,innodb_memcache.config_options,mysql.plugin,mysql.rds_configuration,mysql.rds_history,mysql.rds_monitor,mysql.rds_replication_status,mysql.rds_sysinfo|
Replicate_Wild_Do_Table      |                                                                                                                                                                                     |
Replicate_Wild_Ignore_Table  |                                                                                                                                                                                     |
Last_Errno                   |0                                                                                                                                                                                    |
Last_Error                   |                                                                                                                                                                                     |
Skip_Counter                 |0                                                                                                                                                                                    |
Exec_Master_Log_Pos          |3281                                                                                                                                                                                 |
Relay_Log_Space              |584                                                                                                                                                                                  |
Until_Condition              |None                                                                                                                                                                                 |
Until_Log_File               |                                                                                                                                                                                     |
Until_Log_Pos                |0                                                                                                                                                                                    |
Master_SSL_Allowed           |No                                                                                                                                                                                   |
Master_SSL_CA_File           |                                                                                                                                                                                     |
Master_SSL_CA_Path           |                                                                                                                                                                                     |
Master_SSL_Cert              |                                                                                                                                                                                     |
Master_SSL_Cipher            |                                                                                                                                                                                     |

참고 링크 : https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_set_external_master.html

Dump → EC2(Replica) → RDS(Replica)

Dump를 활용하는 경우는 아래와 같다.

비용 측면 : 낮은 비용
다운 타임 : 제로 다운 타임
RDS와 On-premise 연결 : 불가능

STEP 01. On-premise → EC2 (Replica)

1. [Master] 서버 접속 후 유저 생성 및 권한 부여

/* 유저 생성 */
create user 'replication_user'@'%' identified by 'dusqhd10djr!!QQ';

/* 권한 생성 */
GRANT REPLICATION SLAVE ON *.* to 'replication_user'@'%';
flush privileges;

2. [Master] database 및 테이블 생성

/* DB 생성 */
create database replica_db;
use replica_db;

/* TABLE 생성 */
create table replication_tb(id INT AUTO_INCREMENT Primary key,name VARCHAR(30));

3. [Master] my.cnf 파일 설정

## 아래 설정 확인 및 추가
log-bin=mysql_bin
server-id=1
binlog-do-db=replica_db
log-slave-updates

4. [Master] mysql restart

service mysqld restart

5. [Master] 덤프 생성

mysqldump -u replication_user -p --single-transaction --master-data=2 --routines --triggers  replica_db > replica_ec2_dump.sql

## 파일 확인
ls -al

6. [Master] binlog와 포지션 확인하기

less replica_ec2_dump.sql


-- MySQL dump 10.13  Distrib 5.7.35, for Linux (x86_64)
--
-- Host: localhost    Database: MIG_TEST_DB
-- ------------------------------------------------------
-- Server version       5.7.35-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Position to start replication or point-in-time recovery from
--

## -------------------------------------------------------------------
#  아래의 파일명과 포지션 복사해놓기		
## -------------------------------------------------------------------
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql_bin.000001', MASTER_LOG_POS=1285;

--
-- Current Database: `MIG_TEST_DB`
--

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `MIG_TEST_DB` /*!40100 DEFAULT CHARACTER SET latin1 */;

USE `MIG_TEST_DB`;

7. [Slave] my.cnf 파일 설정

log-bin=mysql_bin
server-id=2
read_only=1

8. [Slave] restart 하기

service mysqld restart

9. [Slave] Master db 정보 입력

CHANGE MASTER TO MASTER_HOST='[ip주소]'
               , MASTER_PORT=[port]
			   , MASTER_USER='replication_user'
			   , MASTER_PASSWORD='[패스워드]'
			   , MASTER_LOG_FILE='mysql_bin.000007'
			   , MASTER_LOG_POS=150 ;

10. [Slave] start slave하기

start slave

11. [Slave] 결과 확인

show slave status \G;
*************************** 1. row ***************************

..생략...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes


..생략...


/*
둘다 YES가 나오면 성공이다.
*/

예외 상황

만약 둘중 하나라도 NO가 나온 경우

Last_IO_Error: Fatal error: The SLAVE I/O thread stops because MASTER AND SLAVE have equal MySQL SERVER UUIDs; these UUIDs must be different FOR REPLICATION TO work.

해당 에러는 Slave DB 서버의 auto.cnf 파일에 현재 서버의 UUID가 적혀있는데, 이 파일까지 Master DB 서버에서 함께 가져와서 발생하는 에러다.다음 명령어 들로 해결해보자

systemctl stop mysqld
rm -rf /var/lib/mysql/auto.cnf
systemctl start mysqld

이후 다시 slave를 start하고 확인해보면 적용이 되어 있을 것이다.

Duplicate 이슈

Last_Error: Error 'Duplicate key name 'oauth_users_name_domain'' on query. Default database: 'cyauth'. Query: 'create index oauth_users_name_domain on oauth_users( username , domain , userid )'

이런 경우 slave stop을 하고 아래와 같이 해주면 된다.

SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;

/*
여기선 중복 에러 나는 것이 1개 이므로, 여러 개 일 경우 숫자를 크게
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=100 ;

또는 위에 에러 번호가 1061 이였으므로, my.cnf 파일에 다음과 같이 설정 가능
my.cnf
slave-skip-errors = 1061,1062,1063    등등 스킵하고 싶은 에러번호 나열
*/

AWS RDS 경우
AWS RDS의 EC2로 진행하는 경우 보안그룹에 각각의 Public ip를 열어 줘야 한다.

STEP 02. EC2 (Replica) → RDS (Replica)

1. [EC2] my.cnf 파일 수정

# binglog 설정
log-bin=mysql_bin
server-id=1
binlog_format=ROW
expire_logs_days=7
binlog_checksum=NONE
binlog_row_image=FULL

2. [EC2] 기초 데이터 백업 생성

mysqldump -u test_user --databases [DATABASE명] --single-transaction --master-data=2 --compress --routines=0 --triggers=0 --events=0 --order-by-primary -p > replica_dump.sql

3. [EC2] Replication User 생성 및 권한 부여

-- USER 생성
CREATE USER 'REPLICATION_USER'@'%' IDENTIFIED BY '[패스워드]';

-- 권한 부여
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'REPLICATION_USER'@'%';

4. [EC2] dump에서 position 확인

less replica_dump.sql


-- MySQL dump 10.13  Distrib 5.7.35, for Linux (x86_64)
--
-- Host: localhost    Database: MIG_TEST_DB
-- ------------------------------------------------------
-- Server version       5.7.35-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Position to start replication or point-in-time recovery from
--

## -------------------------------------------------------------------
#  아래의 파일명과 포지션 복사해놓기		
## -------------------------------------------------------------------
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql_bin.000001', MASTER_LOG_POS=1285;

--
-- Current Database: `MIG_TEST_DB`
--

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `[DATABSE명]` /*!40100 DEFAULT CHARACTER SET latin1 */;

USE `[DATABSE명]`;

5. [EC2] RDS로 기초 데이터 입력

mysql -u admin -p < replica_dump.sql

6. [RDS] external_master 실행

-- binlog 유지기간 늘리기
call mysql.rds_set_configuration('binlog retention hours', 24);

-- external master 실행
CALL mysql.rds_set_external_master ('[IP주소]', 3306, 'replication_user', '[패스워드]', 'mysql_bin.000001', 2859, 0);

7. [RDS] replication start 하기

-- replication 시작
CALL mysql.rds_start_replication;

-- replication 중지
CALL mysql.rds_stop_replication;

8. [RDS] 잘되는지 확인하기

SHOW SLAVE STATUS;

/* Slave_IO_Running, Slave_SQL_Running 두가지의 상태가 YES로 나와야 함 */
Name                         |Value                                                                                                                                                                                |
-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Slave_IO_State               |Waiting for master to send event                                                                                                                                                     |
Master_Host                  |10.0.4.202                                                                                                                                                                           |
Master_User                  |replication_user                                                                                                                                                                     |
Master_Port                  |3306                                                                                                                                                                                 |
Connect_Retry                |60                                                                                                                                                                                   |
Master_Log_File              |mysql_bin.000001                                                                                                                                                                     |
Read_Master_Log_Pos          |3281                                                                                                                                                                                 |
Relay_Log_File               |relaylog.000005                                                                                                                                                                      |
Relay_Log_Pos                |271                                                                                                                                                                                  |
Relay_Master_Log_File        |mysql_bin.000001                                                                                                                                                                     |
Slave_IO_Running             |Yes                                                                                                                                                                                  |
Slave_SQL_Running            |Yes                                                                                                                                                                                  |
Replicate_Do_DB              |                                                                                                                                                                                     |
Replicate_Ignore_DB          |                                                                                                                                                                                     |
Replicate_Do_Table           |                                                                                                                                                                                     |
Replicate_Ignore_Table       |innodb_memcache.cache_policies,innodb_memcache.config_options,mysql.plugin,mysql.rds_configuration,mysql.rds_history,mysql.rds_monitor,mysql.rds_replication_status,mysql.rds_sysinfo|
Replicate_Wild_Do_Table      |                                                                                                                                                                                     |
Replicate_Wild_Ignore_Table  |                                                                                                                                                                                     |
Last_Errno                   |0                                                                                                                                                                                    |
Last_Error                   |                                                                                                                                                                                     |
Skip_Counter                 |0                                                                                                                                                                                    |
Exec_Master_Log_Pos          |3281                                                                                                                                                                                 |
Relay_Log_Space              |584                                                                                                                                                                                  |
Until_Condition              |None                                                                                                                                                                                 |
Until_Log_File               |                                                                                                                                                                                     |
Until_Log_Pos                |0                                                                                                                                                                                    |
Master_SSL_Allowed           |No                                                                                                                                                                                   |
Master_SSL_CA_File           |                                                                                                                                                                                     |
Master_SSL_CA_Path           |                                                                                                                                                                                     |
Master_SSL_Cert              |                                                                                                                                                                                     |
Master_SSL_Cipher            |                                                                                                                                                                                     |

이관 후 검증 쿼리

다음은 이관 후 가장 중요한 검증을 위한 쿼리다.

/* 테이블 개수 확인 */
SELECT COUNT(*) 
  FROM INFORMATION_SCHEMA.tables  
 WHERE  table_schema in ('DB1','DB2');

/* 테이블 데이터 건수 확인 */
SELECT concat('select ''',table_name''' AS TB, count(*) AS CNT from  ', table_schema,'.', table_name,';') 
  FROM information_schema.tables 
 WHERE table_schema in ('DB1','DB2');

/* 데이터베이스 사이즈 검증 */
-- DB 사이즈는 기존 DB의 변경이나 삭제 작업이 많은경우나, 통계정보가 정확하지 않은경우 차이가 날수 있다.
SELECT table_schema "Database"
     , ROUND(SUM(data_length+index_length)/1024/1024,1) "MB" 
FROM information_schema.TABLES 
GROUP BY 1
;

/* 프로시저, 이벤트, 함수, 뷰, 트리거 검증 */
SHOW PROCEDURE STATUS WHERE DB = 'DB1'
SHOW FULL TABLES IN ebsesof WHERE TABLE_TYPE LIKE 'VIEW';
SHOW FUNCTION STATUS WHERE DB = 'DB1';
select EVENT_SCHEMA,EVENT_NAME,INTERVAL_FIELD 
  from information_schema.events;
select trigger_schema, trigger_name, action_statement 
  from information_schema.triggers 
 where table_schema in ('DB1','DB2');


/* 유저 및 권한 확인 */
SELECT user,host from user;
show grants [USER]@’%’

Window에서 오라클 삭제 하는 방법

Mr. YeokMaSsal — Mon, 25 Jul 2022 19:51:07 +0900

윈도우에서 오라클 삭제하기

오라클은 한번 설치하고나면 지우기가 굉장히 어렵고 귀찮다. 그래서 내 주위에 사람들을 보면 오라클을 잘못 설치했다가 지우지를 못해 포맷을 하는경우도 종종 봤다. 이번에 윈도우에서 오라클 삭제하는법을 제대로 알아 보도록 하자

1.오라클 관련 서비스 중지 하기

윈도우키 + r을 눌러 실행 창을 띄우고 services.msc를 입력해서 서비스 창을 띄운다.

oracle로 시작하는 서비스는 모두 중지 시킨다.

2.Universal Installer 실행

시작프로그램에서 Oracle 항목 중 Universal Installer를 찾아서 실행한다.

3.설치 히제 하기

해당 배치파일을 관리자 권한으로 실행 시켜준다.

4.삭제 과정 입력 사항

[LISTENER]에서 구성을 해제할 단일 인스턴스 리스너 모두 지정
→ 아무값도 입력하지 않고 엔터를 입력한다.
이 Oracle 홈에 구성된 데이터베이스 이름 목록을 지정하십시오. [ORCL]
→ ORCL 입력
데이터베이스의 진단 대상 위치를 지정하십시오. [C:\app\hojun.jung\diag\rdbms\orcl]
→ 자신의 orcl 경로 입력 ( 난 C:\app\hojun.jung\diag\rdbms\orcl 이것이었음)
ASM|FS 데이터베이스에서 사용하는 저장 영역 유형을 지정하십시오.
→ F5 입력
공유 파일 시스템에 데이터베이스 파일이 존재할 경우 디렉토리 목록을 지정하십시오. 'ORCL' 하위 디렉토리가 발견될 경우 삭제됩니다. 그렇지 않을 경우 지정된 디렉토리가 삭제됩니다. 또는 전체 경로와 함께 데이터베이스 파일 목록을 지정할 수도 있습니다.
→ 공백 후 엔터
플래시 복구 영역 위치(파일 시스템에 구성된 경우)를 지정하십시오. 'ORCL' 하위 디렉토리가 발견될 경우 삭제됩니다.
→ 그냥 엔터
데이터베이스 spfile 위치를 지정하십시오.
→ 공백 후 엔터
계속하겠습니까(y - 예, n - 아니오)? [n]
→ y 입력

5.오라클 경로 삭제

오라클 관련 파일 모두 삭제해준다.

6.시스템 재부팅

시스템을 재부팅 해준다.

7. 레지스트리 삭제

윈도우키 + r 을 눌러 regedit 라고 입력후 실행 시키면 레지스트리 편집기 창이 나온다.
거기서 oracle을 찾아서 모든레지스트리를 삭제 시켜주면 오라클 삭제는 완료된다.

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE 삭제
HKEY_LOCAL_MACHINE\SYSEM\ControlSet001\Service\Oralce 키워드 삭제
HKEY_LOCAL_MACHINE\SYSEM\ControlSet002\Service\Oracle 키워드 삭제
HKEY_LOCAL_MACHINE\SYSEM\CurrentControlSet\Services\Oracle 키워드 삭제
HKEY_CLASSES_ROOT에서 Ora로 시작되는 모든 것 삭제

끝!

이렇게 오라클 삭제 과정이 모두 완료 되었다. 이제 다시 오라클을 재설치 할 수 있게 된다.

부디 오라클 때문에 포맷하는 사람이 없길 바라며.... :)

오라클 실행계획 보기

Mr. YeokMaSsal — Mon, 25 Jul 2022 19:32:39 +0900

오라클 실행 계획 보기

내가 자주 사용하는 방법이다.

select /*+ GATHER_PLAN_STATISTICS */ * from TABLE;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'advanced allstats last'));

인테리어 풍수지리

Mr. YeokMaSsal — Sun, 24 Jul 2022 23:22:22 +0900

'풍수 인테리어 운명을 바꾼다' 를 읽고....

평소 풍수지리에 대해서 공부를 하고싶어 했었고 이번주말에 관련 책을 읽어볼 기회가 생겼다. 그래서 ' 풍수 인테리어 운명을 바꾼다.' 를 읽고 정리를 해보았다.

링크 : http://www.yes24.com/Product/Goods/92134031

현관 & 신발장

신발은 최대한 신발장에 넣어 보이지 않게 하는것이 좋다.
현관이 마주하는 위치에 관엽식물을 두는것이 좋다.
현관은 이중문 구조로 되어있는 것이 좋다.
현관에 매트를 깔아두면 좋은데 붉은색이나 파란색으로 포인트를 준 흰색 매트를 깔면 운이 상승하고 좋다.
현관의 조명은 밝은색으로 하는게 운을 상승시켜 좋다. 밝은색 조명이 없다면 노랜색 계열의 식물도 좋다.
현관 정면에 거울이 있는건 행운을 반사해버려 좋지 않다. 정면 보다는 현관 옆에 두는것이 좋다.
현관에 마주하게 가족사진이나 부모님 사진을 걸어두는것은 좋지 않다.
현관에는 큰 거울은 피하는것이 좋다.

거실

거실의 조명

거실의 조명은 주백색의 은은한 조명으로 하는것이 구성원의 건강과 좋은 기를 불어다 줌
집주인의 키보다는 낮은 키의 스탠드를 놓는 것은 재물을 불러들이고 가정의 불화를 방지함

거실의 식물

거실에 두면 안되는 식물
- 주인의 키보다 큰 식물 ( 주인의 키보다 클 경우 주인이 호흡해야 할 천기를 모두 마셔버려 주인의 명예가 떨어짐)
- 비비 꼬이거나 벽을 타는 식물 (사업이나 가정의 운이 비비 꼬임)
- 뿌리가 드러난 식물 (창피를 당하거나 사업이나 가족의 비밀이 드러남)
- 분재 (가정의 불화를 가져옴)
- 침엽수 (날카로운 기를 가져와 심장에 무리를 줌)
거실에 둬야 하는 식물
- 관엽식물이나 잎이 둥그스름하며 많이 달려있는 식물
관엽식물을 거실에 둘 경우 관리가 중요하다. 관엽식물이 말라 죽으면 매우 좋지 않다.
집안 구석진곳에 화분이나 가구를 배치하면 살기를 막아줘서 좋음

거실의 가구 배치

거실에는 최대한 많은 물건을 놓지 않고 심플하게 하는것이 좋다.
거실에 돌로 이루어진 가구를 두지 않는 것이 좋다. 수석, 석재와 같은 돌로된 가구를 들이는것은 손해가 많이 발생할 수 있다. 돌로된 가구는 거실뿐 아니라 어느곳에든 좋지 않다.
거실의 테이블은 유리를 덮은 테이블은 의욕을 빼앗기 때문에 피하는것이 좋다.
가능한 목재 테이블을 두는것이 좋으며 모서리가 둥근 테이블이 좋다.
그림을 걸땐 단순하고 부드러운 느낌의 그림이 좋다. 그리고 유리로 씌워지지 않은 액자를 사용하는것이 좋다.
꽃 그림은 안방에 걸지 않는 것이 좋다.
그림이나 사진을 걸때 기울여서 걸거나 사선이 되게 나열하는것은 좋지 않다.
소파는 창을 바라보거나 벽을 등지고 있어야 하며 빛을 가리지 않게 측면으로 배치해야 한다.
거실의 TV 밑에는 잡다한 물건들을 놓지 않는다.
소파의 소재는 패브릭이 좋으며 쿠션을 둘때는 홀수보다는 짝수의 수량으로 두는것이 좋다.
책장옆에 관엽식물을 두면 좋다.

거실의 뷰

옛날의 배산임수에서의 수의 역할이 현대사회에서는 도로나 지하철을 의미한다. 따라서 큰도로가 보이는 뷰는 재물의 흐름이 좋게 하여 좋은 역할을 한다.
커다란 베란다 창문은 건강,진ㄹ,지출을 유발할 수 있으므로 적적히 커튼으로 가려주는것이 좋다.

주방

주방의 창문이 큰것이 기의 흐름을 좋게 하여 좋다.
주방 창가에 선인장이나 패랭이 꽃 같은 살아있는 식물을 두면 재물운을 부른다.
식탁은 벽에 붙이는것 보다 앞이 트인곳에 두는게 좋다.
쓰레기통은 안보이는곳에 두는것이 좋다.
차가운 기운인 냉장고와 양의 기운인 전자레인지 같은 가구는 거리를 많이 둘 수록 좋다.
부엌게 거울을 달아두는것은 음과양의 기운을 배로 해주며 금전운을 배로 해주기 때문에 좋다.
주방의 그릇은 세우는것이 아닌 입구가 하늘을 향하도록 보관하는것이 좋다.

침실

침실에는 수맥이 흐르지 않는곳이 좋다.
침실의 벽지는 일반적으로 베이지, 미색, 황토색, 연한 핑크색 계열이 좋다.
조명은 주백색 계열이 좋으며 거실에 비해서는 어두운게 좋다.
거실에는 가족사진을 거는것이 좋지만 침실은 가족사진을 걸지 않는 것이 부부 융화에 도움이 된다.
부부의 침실은 부부의 사진만 거는 것이 좋다.
부부의 침실에 꽃이나 화분을 놓는건 부부관계를 악화시키기 때문에 피한다.
침실에는 드라이플라워는 절대 놓지 않는다.
침대도 벽에 붙이지 않는것이 좋다.
침실에서 가장 중요한 건 청결이다. 침대, 커튼, 침구등이 마구잡이로 어지렵혀져 있거나 지저분하고 구석에 먼지가 쌓여 있으면 건강이 나빠지고 재물이 모이지 않는다.
침대의 위치는 문을 열고 들어갔을때 대각선에 위치한것이 좋다.
큰 베게는 직업운을 상승시키고 노란색과 연두색 침구는 금전운을 높인다.

화장실

화장실 문은 항시 닫아두는게 좋다.
현관문을 들어설때 바로 화장실이 보이면 좋지 않다. 따라서 집 구조상 현관에서 바로 화장실이 보인다면 화분등으로 가려주거나 중문이 있는것이 좋다.

[Azure DB MIgration] BACPAC을 활용한 Migration

Mr. YeokMaSsal — Sun, 24 Jul 2022 22:38:37 +0900

BACPAC을 활용한 On-premise to Azure SQL DB Migration

On premise(SQL Server)에서 Azure SQL Database로 DB Migration하는 방법 중 BACPAC을 통해 Migration이 가능하다.

BACPAC이란?

데이터베이스의 스키마와 데이터를 캡슐화 하는 확장명이 . bacpac인 Windows 파일입니다. BACPAC는 서버 간에 데이터베이스를 이동하거나 로컬 서버에서 클라우드로 데이터베이스를 마이그레이션하고 기존 데이터베이스를 개방 형식으로 보관하는 데 주로 사용된다.

Migration 절차

Source : AWS EC2 (Windows_Server-2016, SQL Server 2019)
Target : Azure SQL Database

1. On premise 확인

2. BACPAC을 Azure SQL Database에 배포

Source db에서 우클릭 후 태스크>Azure SQL Database에 데이터베이스 배포 메뉴를 선택 한다.

3. Azure SQL Database 연결

배포설정시 Target이 되는 Azure SQL Database을 연결한다.

4. 배포 진행

연결후 배포를 진행 한다.

5. Azure SQL Database 배포 결과 확인

배포 후 Azure SQL Database 접속후 Migration 된 db를 확인 할 수 있다.

[Azure DB MIgration] Azure Storage account로 DB Migration

Mr. YeokMaSsal — Sun, 24 Jul 2022 22:26:36 +0900

Azure Storage account 에 Backup 후 Restore

On premise에서 SQL Server Managed Instance나 SQL Server on Azure VM으로 DB Migration을 하는 경우 Azure Storage account로 백업 파일을 전송한 후 Target DB 에서는 Storage에 있는 백업 파일을 이용해 Restore하여 Migration을 할수 있다.

Azure Storage account란?

Azure Storage account는 AWS에서 S3와 같다고 생각하면 된다. Azure에서 제공하는 무제한급의 Storage다. File Storage뿐만 아니라 큐, 테이블 저장소와 같은 다수의 유형의 저장소를 제공한다.

Migration 절차

Source : AWS EC2 (Windows_Server-2016, SQL Server 2019)
Target : SQL Server on Azure VM (SQL Server 2019)

1. Azure Storage account 생성

구독과 리소스그룹을 선택하고 스토리지 계정 명을 입력하여 Storage account를 생성한다.

2. 컨테이너 생성

새 컨테이너 생성을 클릭하여 backup 파일을 저장할 컨테이너를 생성 한다.

3. Source DB Credentials 생성

Source DB에서는 Storage accoun로 backup파일을 전송하기 위한 credentials(자격증명)을 생성한다.

4. Storage account로 Source DB 백업

Source db에서 Storage account로 백업을 한다.

/* 백업 스크립트 */
backup database [DATABASE명]
to url = N’https://[Storageaccount주소]/[백업파일명]’
with credential  = ‘[Credential 명]’
go

5. Storage account 확인

Storage account에 백업 파일이 정상적으로 업로드 되었는지 확인 한다.

6. Target DB Restore.

Target DB  접속 후  Restore Database 를 클릭

복원 형태를 디바이스로 하여 더보기 클릭
백업 미디어 유형을 URL로 선택하고 추가 클릭
백업 파일의 위치를 Storage account로 설정

확인을 클릭 하여 복원 진행

7. 결과 확인

복원 완료후 데이터를 확인해보면 정상적으로 Migration이 수행된걸 확인 할 수 있다.

[Azure DB Migration] Backup 후 VM restore

Mr. YeokMaSsal — Sun, 24 Jul 2022 18:05:07 +0900

On-premise 에서 Backup 후 VM에 Restore 하기

이번에는 On-premiese DB to Azure로 가는 방법 중 backup 후 Restore 하는 방법에 대해 실습을 해보자

이방법은 Azure로 Mig 하는것 뿐만 아니라 On premiese 사이에서도 할 수 있는 방법이다.

작업 방식은 Source DB에서 Fullbackup을 받은 뒤 Target DB로 백업 파일을 옮겨 해당 DB를 Restore 하는 방식

Migration 절차

Source : AWS EC2 (Windows_Server-2016, SQL Server 2019)
Target : SQL Server on Azure VM (SQL Server 2019)

1. Source DB Fullbackup 받기

Source DB에서 Migration 할 Database 선택 후 Backup 기능 실행

Backup type을 Full로 선택하고 ok 버튼 클릭

Backup 완료

2. Backup파일 Target으로 옮기기

3. Target DB 접속 후 Database Restore 하기

Database 우클릭 후 Restore Database 클릭

Source를 Device로 선택 한뒤 파일 업로드를 통해 backup 파일 선택 및 OK 버튼 클릭

정상적으로 DB Restore 및 테이블 & 데이터 확인

[Azure DB Migration] DMA를 활용한 DB Migration

Mr. YeokMaSsal — Sun, 24 Jul 2022 17:56:34 +0900

DMA를 사용하여 On-premise DB 에서 Azure SQL로 DB Migration 하기

On premise(SQL Server)에서 Azure SQL Database로 DB Migration하는 방법 중 Azure에서 제공하는 DMA 라는 Tool을 이용하여 Migration을 수행할 수 있다.

1. On-premise 확인

On - premise 서버를 확인 한다.

Source : AWS EC2 (Windows_Server-2016, SQL Server 2019)
Target : Azure SQL Database

2.DMA Assessment Project 생성

Azure Database Migration Assistant(DMA) Tool을 다운로드 후 실행 하여 Assessment Project를 생성 한다.

3. DMA Source DB 연결

4. Source DB Migration 이슈사항에 대한 결과 확인

DMA와 Source DB를 연결하게 되면 해당 DB를 Migration 할 경우 이슈 사항등에 대한 결과를 확인 할 수 있다.

5. DMA Migration Project 생성

DMA의 Assessment를 통해 Migration 이슈 사항을 확인 후 Migration 프로젝트를 생성 한다.

6. Source DB 연결

Migration을 진행할 Source DB 정보를 입력하여 DMA와 연결 한다.

7. Target DB 연결

Migration을 진행할 Target DB 정보를 입력하여 DMA와 연결 한다.

8. Target DB에 Source DB Schema및 Object 생성

Source, Target 연결 후 Target에 데이터 이관 전 스키마 정보를 생성 한다.

9. Data Migration 진행

10. Data Migration Report 확인

11. Target DB 확인

Target db에서 Migration 결과를 확인 한다.

[Azure] On-premise DB to Azure SQL

Mr. YeokMaSsal — Sun, 24 Jul 2022 17:37:23 +0900

On-premise DB 에서 Azure SQL로 DB Migration 하는 방법

클라우드 서버로 이관을 하는 경우 기존 On-premise SQL Server 에서 Azure SQL로 이관하는 방법은 여러가지가 있다.

각 사이트별 상황에 맞게, 이관 하고자 하는 DB에 맞게 선택 하면 될것이다.

이중 몇가지에 대해서 다음에 실습을 해보도록 하자.

Azure DB Migration 방법

Mr. YeokMaSsal — Sun, 24 Jul 2022 17:21:18 +0900

Azure Migrate

Azure Migrate란?

On-premise에서 Azure로 Migration을 위한 Assessment, Migration을 수행할 수 있도록 해주는 플랫폼이다. Azure Migrate 내에서 제공하는 도구들을 통해 On-premise에 대한 Assessment 및 Migration을 수행 할 수 있으며 해당 작업들에 대한 상태를 추적할 수 있다.

Azure Migrate에서 제공되는 도구

Discovery and Assessment

Azure로 Migration 하기 위한 준비단계에서 사용하는 도구로써 On-premise의 VM 및 물리적 서버를 검색하고 평가함

Server Migration

Vmware, Hyper-V VM, 물리적 서버, 기타 가상화된 서버 및 퍼블릭 클라우드 VM을 Azure로 Migration하기 위한 도구

Data Migration Assistant

On-premise SQL Server를 Migration하기 위한 평가를 수행하고 Migration 수행시 발생할 수 있는 잠재점들을 Reporting하는 도구. 또한 Migration도 해당 도구로 직접 수행할 수 있음

Azure Database Migration Service

On-premis에서 Azure SQL로 Down time을 최소화 하면서 DB Migration을 수행할 수 있게 하는 도구

Movere

On-premis의 VM 및 물리적 서버를 검색하고 Migration 비용 계획 및 평가를 진행하는 도구

ISV도구

ISV : Independent Software Vendor 도구로써 플랫폼 기업들에게 소프트웨어 제품을 제공하고 판매하는 회사

Carbonite : Server Migration 도구
Cloudamize : Server Assessment 도구
Corent Technology : Assessment&Migration 도구
UnifyCloud : Assess Server and Database 도구
Zetro : Server Migration 도구
RackWare : Server Migration 도구

Azure Migrate를 활용한 DB Migration

Azure Migrate를 통해 SQL Server Migration을 진행할 수 있으며 진행 시 Source DB의 Assessment를 진행후 Migration을 진행할 수 있다.

1. Azure Migrate Project 생성

Assessment & Migration을 위한 프로젝트를 생성한다.

2. On Premise 확인

3. DMA Assessment Project 생성

Azure Database Migration Assistant(DMA) Tool을 다운로드 후 실행 하여 Assessment Project를 생성

4. DMA Source DB 연결

DMA와 Source DB를 연결

5. DB Migration 이슈 사항에 대한 결과 확인 및 Upload

DMA와 Source DB를 연결하게 되면 해당 DB를 Migration 할 경우 이슈 사항등에 대한 결과를 확인 할 수 있으며 Azure Migrate로 결과를 업로드 할 수 있다.

6. Azure Migrate 결과 Upload

Azure 구독과 업로드할 Azure Migrate 프로젝트를 선택 한다.

7. Azure Migrate에서 확인

Azure Migrate에 Assessment db에 대한 결과를 확인 할 수 있다.

8. DMS 생성

Assessment 작업 후 Migration을 위한 DMS 리소스를 생성한다.

9. DMS Migration Project 생성

DMS 생성 후 Migration Project를 생성 한다.

10. Source DB 연결

Migration을 위한 Source db 접속정보 입력 후 연결한다.

11. Source DB Migration Database 선택

연결 후 Source DB 내 Migration 대상이 되는 Database를 선택한다.

12. Target DB 연결

13. Save Project

14. Schema 이관 하기

프로젝트 생성 후 Schema Migration을 먼저 수행 한다.

15. Source DB 선택 및 Target DB 선택

Source, Target에 대한 Database를 선택 한다.

16. Schema Migration Start

Start migration 버튼을 클릭하여 Schema Migration을 시작 한다.

17. Schema Migration 결과 확인

18. DataMigration 진행

DataMigration을 클릭하여 진행한다.

19. Source & Target 설정 후 Migration 진행

Schema 설정때와 같이 Source&Target 접속 후 Data Migration을 진행 한다.

20. 결과 확인 및 완료

DataMigration 결과 확인 및 실제 DB접속 후 테이블 및 데이터도 확인 하고 이상이 없다면 완료한다.

끝으로

Azure Migrate 도구를 사용하여 On premise to Azure 로 Migration 하는 방법을 알아 보았고 다음은 이 도구 외에도 다른 여러가지 방법을 통해 Migration을 하는 방법에 대해 알아 보자

Azure SQL Database & Managed Instance HA 구성

Mr. YeokMaSsal — Sat, 23 Jul 2022 23:22:41 +0900

HA 구성

Azure SQL Database와 Managed Instance는 서비스 계층에 따라 2가지의 HA 구성을 제공하며 시스템별 사용목적에 맞는 서비스 계층을 이용하여 HA 구성을 할 수 있다.

Basic, Standard & Genernal Purpose

Primary Replica와 Secondary로 구성 되어있으며 Primary Replica 장애시 Azure Service Fabric에 의해 Failover 수행
Azure Premium Storage에 db파일(mdf, ldf)이 저장되어 있으며 instacne들은 Storage를 공유하는 형태로 구성됨
백업 파일은 다른 리전의 Storage에 복사해두어 이중화 구성을 하게 됨 (GRS)

Preminum & Business Critical

Always On Group 구성으로 1대의 Primary Replica와 3대의 Secondary Replica로 구성
Primary Replica는 Read/Write 가능하며 읽기노드 활성화시 3대의 Secondary Replica 중 1대를 읽기전용으로 활용할 수 있음
General Purpose와는 다르게 각각의 Replica는 각자의 데이터 파일(mdf,ldf)을 가지고 있으며 Primary Replica 장애 시 다른 Secondary node로 즉각 Failover가 수행됨 (평균 4초 이내)
3대의 Secondary Replica 중 1대만 Primary와 동기식으로 데이터 동기화를 진행하며 나머지 2대의 Secondary는 비동기 형태로 데이터 동기화가 진행됨
백업 파일은 다른 리전으로 비동기로 진행됨

미스터 역마살

사이트맵

[DAP / 모델링 문제] [고급] 녹색회관리

문제

엔터티 & 속성 도출

나의 답안

모범 답안

주요 Point

[DAP / 모델링 공부] [중급] 주문배송관리

문제

엔터티 & 속성 도출

나의 답안

모범 답안

주요 Point

[DAP / 모델링 공부] [중급] 소송시스템 문제

문제

엔터티 & 속성 도출

나의 답안

모범 답안

주요 Point

[DAP / 모델링 문제] [중급] 도서관리시스템

문제

엔터티 & 속성 도출

나의 답안

모범 답안

주요 Point

[DAP / 모델링 문제] [중급] 인사평가시스템

문제

엔터티 & 속성 도출

나의 답안

모범 답안

주요 Point

[DAP/모델링 공부] [중급]차량 렌트 회사

문제

엔터티 & 속성 도출

나의 답안

모범 답안

주요 Point

Mysql File Table에 Insert

Mysql 일단위 백업 자동화

1.백업 스크립트 쉘 생성

2.쉘 권한 변경

3.Crontab 등록

백업 및 복원 [feat - mysqldump]

백업

모든 DB 백업

타임스탬프를 이용하여 백업 생성

특정 DB 백업

특정 DB의 특정 테이블 백업

특정 테이블만 제외하고 백업

다른 db에 호환되게 백업

테이블 스키마만 백업

복구

전체 복구

특정 db만 복구

단일 명령으로 데이터베이스 내보내고 가져오기

백업 파일 신규 db에 복구시키기

DB의 테이블 생성 DDL만 덤프

mysqldump 옵션

https://puham.tistory.com/56

Replication

Replication 이란?

Replication의 목적

Replication 주의 사항

Replication 구성 절차

예외 상황

만약 둘중 하나라도 NO가 나온 경우

Duplicate 이슈

AWS RDS 경우

binlog 와 redo log 차이

binlog

redolog

차이점

[DAP/모델링 공부][중급] PC제조 및 판매

문제

엔터티, 속성 정보 추출

나의 답안

모범 답안

Point

한 업체에서는 동일한 부품을 하루에 한번만 납품하며, 2번이상 납품하지 않는다