정보보안공부
DBMS_day_14 본문
# 트리거 진행
# 네이버, 구글 등 웹 사이트에서 회원가입을 할 때 회원정보를 3년 또는 5년 동안 개인 정보를 보관한다. 약완에 써져있다.
# 회원가입을 할 때 입력했던 데이터들은 전부 DB에 저장이 되는 데, 회원탈퇴를 했을 때 DB에 저장 돼 있는 데이터가 삭제 되는 지??
# 회원탈퇴를 해도 입력했던 내 정보는 DB에서 삭제가 안된다.
# 로그인을 할 때나 회원 정보를 수정할 때 select 쿼리를 무조건 사용해야 한다.
# 위에 상황에서 사용하는 회원 테이블에 회원이 탈퇴하면 회원테이블에 정보를 삭제한다.
# 회원정보를 저장하는 테이블은 통상 적으로는 2개를 운영한다.
- 현재 회원으로 유지 중인 정보를 저장하는 테이블
- 탈퇴한 회원 정보를 저장하는 테이블
# 회원 탈퇴가 진행 됐을 때는 현재 회원 테이블에 정보를 삭제하고 삭제 된 회원 정보는 다른 테이블로 백업 한다.
# 고객들이 회원을 탈퇴할 때 마다 DBA가 일일이 그 정보를 삭제하고 다른 테이블로 백업할 수 는 없다. 자동화가 필요
# 위에 같은 상황에서 트리거라는 것을 사용하기가 적합하다.
# 트리거 : insert, update, delete 쿼리가 발생했을 때 실행시키는 SQL을 의미한다.
# 회원탈퇴를 진행하면 웹 사이트를 만드는 프로그램에서 delete 쿼리를 DB로 전송한다.
# 트리거를 통해 delete 쿼리가 전송되면 그 delete 쿼리를 수행하기 전에 회원정보를 다른 테이블로 복사를 시킨 후에 delete쿼리를 동작시킨다.
# 회원테이블과 회원탈퇴 테이블을 나눠서 운영할 때 두 테이블 컬럼에 자료형과 글자 제한이 일치해야 한다.
# 회원 탈퇴 테이블에는 회원 탈퇴를 언제 했는지 같이 기록한다.
-> 필요에 따라 회원 탈퇴 사유를 따로 DB 저장할 때도 있다.
# MySQL에서 CURDATE() 함수라는 것을 제공 한다.
-> 현재 날짜 정보를 알아낼 때 사용된다.
# CURDATE() 함수는 MySQL 서버에 설정 된 날짜 정보가 들어간다.
# CURDATE() 함수를 쓰는데 MySQL 서버에 날짜가 이상하면 심각한 문제가 발생한다.
# MySQL 서버에 날짜와 시간 정보는 반드시 정확하게 유지되고 있어야 CURDATE() 함수를 사용했을 때 문제가 발생 안한다.
# 리눅스 date 명령어를 통해 운영체제에 설정 된 날짜와 시간 정보를 확인 해 볼 수 있다.
-> date -s "2010-01-05 14:25:30"
# NTP(Network Time Protocol) : 현재 날짜와 시간 정보를 알려주는 서비스
# 운영체제 리눅스에도 NTP 서버를 통해서 날짜와 시간 정보를 알아온 후에 운영체
제 시간정보로 설정 할 수 있다. 이것을 NTP를 통한 시간정보 동기화라고 한다.
# MySQL 서버는 NTP를 통해 주기적으로 시간을 동기화 해와야한다. 정확한 시간정보 유지
# BOOTPROTO=dhcp
-> dhcp로하면 dns서버의 아이피를 알게해준다.
# dns서비스는 도메인을 사용하게 해준다.
-> dns서버의 아이피를 알아야한다.
# rdate설치
-> yum -y install rdate
# rdate -s "time.bora.net"
-> time.bora.net이라는 NTP서버와 날짜/시간을 동기화한다.
# 데이터베이스 백업 : 만일에 사태를 대비해서 데이터가 없어질 것을 대비 하는 목적으로 데이터를 파일로 다른 곳에 저장시키는 것을 백업이라고 한다.
# MySQL 유료 버전에서는 실시간 데이터 백업을 제공 한다.
# 실시간 백업을 진행하면 다른 장비로 데이터가 삽입, 수정, 삭제가 진행될 때 마다 변경사항을 백업할 수 있다.
# 데이터베이스를 1회성 백업을 진행한다.
# drop trigger trg_deletememberTBL
# drop table deletememberTBL
# Management -> Export -> shopDB체크 -> Export to self-contained file (데이터베이스를 어디에 백업할지 선택) -> startExport
( 백업할때 스토어드프로시저, 트리거, 등을 체크하면 같이백업된다. )
# VMWare에 스냅샷 찍고
# Management -> import -> self 원하는shopDB선택 -> 이름 shopDB
-> 백업되는거 확인
# 데이터베이스 백업은 보통 하루에 1번 진행 한다.
# 백업을 진행할 때 성능이 저하되기 때문에 데이터베이스를 고객들이 이용을 가장 적게 하는 시간 새벽에 보통 작업을 진행한다.
# 리눅스 운영체제에서 MySQL 데이터 백업 방법
-> mysqldump -u root -p shopDB > shopDB.sql
( 위에 리눅스 명령어를 통해 shopDB라는 데이터베이스를 내 현재 위치에 shopDB.sql이라는 파일로 백업하겠다. 위에 리눅스 명령어는 데이터만 백업하는 명령어이다. )
-> vi/shopDB.sql
-> mysql -u root -p;
-> drop schema shopDB;
-> exit
-> mysql -u root -p
-> create schema shopDB; 복구할대상 만든다.
-> exit로 종료
-> mysql -u root -p shopDB < shopDB.sql
( 위에 리눅스 명령어를 통해 shopDB라는 데이터베이스에 shopDB.sql 파일을 통해 데이터를 가지고오는 작업, 복구를 진행한다. )
# 추 후에 리눅스 명령어를 통해서 스토어드 프로시저 등등 같이 백업되는 것을 진행 예정
-> workbench에서는 체크만 실행하면 된다.
< 트리거 만드는법 >
-> create쿼리를통해 삭제되고 보관할 테이블을 만든다.
-> 이때 삭제하는 테이블의 자료형과 똑같이 작성하고 대부분 삭제할 데이터의 날짜를 보관하기위해 DATE자료형의 컬럼을 추가한다.
-> select쿼리로 삭제되고 보관할 테이블이 만들어졌는지 확인한다.
-> 트리거를 이용해 삭제된 데이터를 자동으로 삭제된 데이터를 보관하는 테이블로 삽입시킨다
-> memberTBL에 있는 memberName이 당탕이 인 행을 삭제한다.
-> 삭제된 당탕이가 deleteMemberTBL로 이동된것을 select쿼리로 확인한다.
-> 트리거를 이용해 테이블의 항목을 삭제하면 다른 테이블로 이동하도록 설정할 수 있다.
-> deletedate : 날짜가 이상할경우 밑에 방법으로 현재날짜,시간을 불러온다.
< yum명령어로 rdate설치하기>
-> yum 명령어를 통해 rdate 설치
-> 외부와 통신하기위해 BOOTPROTO=dhcp로 설정한다.
-> rdate -s "time.bora.net" 으로 NTP제공해주는 time.bora.net에서 현재시간을 받는다.
<workbench에서 백업진행>
-> 백업하는 방법
-> workbench -> Management -> 백업하려는 shopDB데이터베이스 선택 -> Export to self-contained file로 백업하려는 파일의 위치선택 -> startExport -> 백업성공
-> drop schema shopDB; 또는 GUI로 shopDB 마우스우클릭 Drop schema 클릭
-> Management -> Export -> shopDB체크 -> Export to self-contained file (데이터베이스를 어디에 백업할지 선택) -> startExport
( 백업할때 스토어드프로시저, 트리거, 등을 체크하면 같이백업된다. )
< 리눅스 운영체제에서 백업 >
-> mysqldump -u root -p shopDB > shopDB.sql
-> shopDB데이터 베이스를 백업한다는 의미이다.
-> vi 를통해 shopDB.sql파일이 만들어졌는지 확인
-> mysql -u root -p;로 Mysql창 드어간다.
-> drop schema shopDB; shopDB데이터베이스를 지운다.
-> exit로 MySQL나온다.
-> 백업해놓은 shopDB.sql을 불러오기위해 create schema shopDB;
-> shopDB라는 이름의 데이터베이스를 만든다.
-> exit
-> 만든 shopDB로 shopDB.sql을 집어넣는다. 이때 mysql비밀번호입력하면
-> 백업한파일이 성공적으로 불러와진다.
'데이터베이스' 카테고리의 다른 글
DBMS_day16 (0) | 2017.08.01 |
---|---|
DBMS_day15 (0) | 2017.08.01 |
DBMS_day13 (0) | 2017.07.27 |
DBMS_day12 (0) | 2017.07.26 |
DBMS_day11 (0) | 2017.07.25 |