미네르바

sudo nano /opt/homebrew/etc/nginx/nginx.conf (after password)

디폴트 구성 바꾸기, (nano: vim, emacs 같은 에디터로 수정하게끔 슈퍼유저 설정 권한을 준다)

나노 명령어:

^G : 도움말 보기

^X : 끝내기

^O : 파일 저장(저장할 파일명 입력, 디폴트는 최초 파일명)

^R : 파일 읽기(현재 파일에 새로운 파일 추가)

^W : 텍스트 검색

^\ : 검색 후 바꾸기

^K : 선택한 문자열 잘라내기

^U : 잘라낸 문자열 붙이기

^J : 양쪽 정렬(한줄로 표시)

^T : 맞춤법 체크

^C : 현재 커서 위치

^- : 입력한 행번호, 열번호로 이동

^A : 현재 행의 처음으로 이동

^E : 현재 행의 마지막으로 이동

Mac 폴더 생성 명령어: mkdir servers

mkdir -p /var/www/sena.com

Mac 파일 생성 명령어: touch ~/servers/examplePage/example.com (~ kite까지 포함)

touch ~/servers/examplePage/app.js

nano 안 쓰고 에러 해결법:

sudo vi 만드려는 파일명 or 저장 할 때 

:w !sudo tee % > /dev/null

the page eXample:

make folder and "example.com" file

make app.js (javaScript file)

edit /etc/hosts (add 127.0.0.1 example.com)

새 포트 추가하는 법:

이걸 하고 싶으면 이러면 된다: sudo nano /opt/homebrew/etc/nginx/nginx.conf

.

데이터베이스 트랜잭션

ACID가 뭔지 알아보기 전에 「트랜잭션」 이 뭔지 알아내자.

TRANSACTION

데이터를 다루는 논리적인 작업의 단위 이다.

DBMS가 데이터베이스를 다룰 때 사용하는 작업 (프로그램) 단위 이기도

트랜잭션은 데이터베이스의 무결성을 (일관성)을 유지하기 위해서 쓴다.

+ 장애가 일어났을 때 데이터를 복구하는 작업의 단위 (롤백 단위)

+ 동시성 제어 블록 단위 (같은 데이터를 같은 타이밍에 활용할 때, 서로 분리하는 단위)

「하드웨어적 원리」

START TRANSACTION;

하면 트랜잭션 중에는 데이터를 '주기억장치 버퍼' 즉 '메모리 버퍼'에 저장한다

(메모리는 휘발성이다) 읽어올 때도 버퍼에서 읽어온다.

나중에 COMMIT;을 만나면

하드디스크, SSD 와 같은 실질적 물리적 저장장치에 최종 저장된다.

「종료 알림 구성법 i」

① ② ③ ④ COMMIT ⑤ ⑥

「종료 알림 구성법 ii」

① ② ③ ④ ⑤ ⑥ COMMIT

*COMMIT은 트랜잭션의 종료를 알리는 SQL 문이다.

(우리가 쿼리를 수행 후 CLI 등에서 'QUERY OK!'를 받는 것은 얘 덕분)

[보통]

사용자를 고려하여, 빠른 반응성 즉 '응답성'을 보장하기 위해

본 저장장치 저장 전에, 즉 '메모리 버퍼' '주기억장치 버퍼' 에서의 작업이

끝나면 COMMIT을 하여 트랜잭션을 임시 종료 선언 하고

실제 데이터베이스에 기록하는 것을 DBMS로 하여금 수행하게 한다.

그래서 실제론 요렇게

① ② ③ ④ COMMIT(부분 완료) ⑤ ⑥ 완료-

BEGIN(시작) $

수행(① ② ③ ④) $ 부분완료 $ 버퍼내용 기록(⑤ ⑥) $ 완료(COMMIT)

「COMMIT & ROLLBACK」

TCL

트랜잭션 컨트롤 랭귀지

트랜잭션 제어 명령어로서, 커밋과 롤백이 있다.

기본적으로 트랜잭션 중간에 작업이 잘못되면 '회복 알고리즘'을 쓰는데

자의적으로 트랜잭션을 취소하는 명령어 ROLLBACK이 이때 사용되기도

변경된 내용을 전부 취소한다.

+ SAVE (세이프포인트 생성) (여러 개 가능)

++ AUTO TRANSACTION START

SET TRANSACTION NAME <이름>

OR 'UPDATE'와 같은 데이터 변경 SQL 문이 나오면 자동으로 시작한다

AND ++

COMMIT 또는 ROLLBACK 또는 DDL 문을 만나면 종료된다. (테이블 생성 등)

「트랜잭션 vs 파일 시스템 작업」

트랜잭션: 번역기:: DBMS $ 성질:: ACID

파일 시스템 작업: 번역기:: 컴파일러 $ 성질:: NONE $ 작업 (프로그램) 구조:: main(){ ... } $ 활용되는 데이터: 파일에 저장된 데이터

*파일 시스템은 DBMS 없이 파일, 즉 데이터를 직접 처리한다.

「ACID」

원자성, 일관성, 고립성, 지속성

트랜잭션의 성질 4

I. Atomicity 원자성

all or nothing

트랜잭션에 포함된 작업은 전부 수행되거나 아니면 전부 수행되지 않아야 한다.

원자처럼 더 이상 쪼개지지 않는 하나의 프로그램 단위로 동작해야 한다는 것.

II. Consistency 일관성 (무결성)

'무결성 제약조건'을 활용하여

트랜잭션 수행 시 데이터에 변경이 가해질 때

미리 정의해 둔 '무결성 제약조건'을 검사하여 일관성이 깨지는 걸 막는다.

그런데 두 개의 트랜잭션이 동시에 수행될 때 트랜잭션 간에 간섭으로

일관성이 깨지는 현상은 무결성 제약조건을 검사하는 것으로 해결할 수 없다!

그러므로 동시에 같은 데이터를 접근하는 트랜잭션들이 질서 있게 접근하여

데이터베이스의 일관성을 유지하도록 하기 위해서는

'동시성 제어 알고리즘'을 작동시켜야 한다.

트랜잭션을 수행하기 전이나 수행한 후나 데이터베이스는 항상 일관된 상태를 유지해야 한다는 것. (질량 보존의 법칙)

테이블이 생성될 때 CREATE 문과 ALTER 문의 '무결성 제약조건'을 통해 명시된다. 트랜잭션은 이 무결성 제약조건에 따라 일관성을 유지한다.

다만 수행 중에는 일시적으로 일관성을 유지하지 못하는 상태가 있을 수 있다.

일관성 없는 상태: INCONSISTENT

III. Isolation 고립성

수행 중인 트랜잭션에 다른 트랜잭션이 끼어들어 변경 중인 데이터 값을 훼손하는 일이 없어야 한다. (병렬 침범)

데이터베이스는 기본적으로 '공유'가 목적이기에

여러 트랜잭션들이 동시에 수행된다

이때 각 트랜잭션은 병렬적으로 수행되는 다른 트랜잭션의 방해를 받지 않고

독립적으로 작업을 수행한다.

(상호 간섭 이나 데이터 충돌이 일어나지 않는 현상 => 고립성)

고립성을 유지하기 위해서는 변경 중인 임시 데이터를 (in 메모리 $ 주기억장치)

다른 트랜잭션에서 읽거나 쓰려고 할 때 제어하는 작업이 필요하다,

=> 이것도 '동시성 제어 알고리즘'

concurrency control

같은 데이터를 가지고 충돌하지 않도록 제어하는 작업!

IV. Durability 지속성

수행을 성공적으로 완료한 트랜잭션은 변경한 데이터를 영구히 저장해야 한다.

저장된 데이터베이스는 저장 직후 혹은 어느 때나 발생할 수 있는

정전, 장애, 오류 에 영향을 받지 않아야 한다.

DBMS 복구 시스템은 트랜잭션이 작업한 내용을 수시로 log 로그 데이터베이스

에 기록하였다가 문제가 발생하면, 로그 파일을 이용하여 복구 작업을 수행한다

즉 시스템이 멈추어도 트랜잭션 수행으로 변경된 내용은 디스크에 기록된다.

시작 -> 수행 중 (active) -> 부분 완료 -> 버퍼 내용 기록 -> 완료

↳ 실패 -> 작업 취소 -> 취소

시작: BEGIN, 부분 완료: PARTIALLY COMMITTED, 실패: FAILED,

완료: COMMITTED, 취소: ABORTED

실패: 트랜잭션을 중간에 중단하였거나 부분 완료 상태에서 변경 내용을

데이터베이스에 저장하지 못한 상태를 말한다.

실패 상태에서 DBMS는 트랜잭션이 수행한 작업을 모두 원상복구시킨다.

「동시성 제어 알고리즘」

concurrency control

같은 데이터를 가지고 충돌하지 않도록 제어하는 작업!

락킹

마치 한 트랜잭션씩 순차적으로 순서대로 접근하는 것처럼 제어

병렬성을 깨뜨린다.

-> 보다 완화된 방법 「트랜잭션 고립 수준」

isiolation level

「회복 관리자 알고리즘」

「트랜잭션의 성질과 관계된 DBMS의 기능」

A: 회복 (LOG DB)

C: 무결성 제약조건(SQL 문), 동시성 제어(LOCKING)

I: 동시성 제어(락킹)

D: 회복 (로그 데베)

[대처법]

트랜잭션이 두 개라고 하자. T1 T2

읽고 읽을 때는 문제 없다. (동시 접근을 허용한다)

읽고 쓸 때에는 문제가 발생한다. 3가지. (동시 접근을 허용하거나 거부하거나)

오손 읽기 dirty-read, uncommitted-dependency

반복불가능 읽기 non-repeatable-read, inconsistent-analysis

유령 데이터 읽기 phantom-read

쓰고 쓸 때에는? 치명적인 문제가 발생할 수 있으니. (거부. LOCK을 이용)

갱신 손실 lost-update

「락킹」

동시성 제어를 위한 기법

갱신 손실 방지.

락은 트랜잭션이 데이터를 읽거나 수정할 때 데이터에 표시하는 잠금 장치다

== 자신이 데이터를 읽는 중 또는 수정 중 또는 추가 중이라는 걸 알리는 장치

LS, LX로 wait 대기 시키거나 UN 해지한다.

shared lock, eXclusive lock, unlock

공유락 (LS)는 공유락을 허용하고, 배타락은 거부한다.

베타락 (LX)는 공유락을 거부하고, 배타락도 거부한다.

COMMIT 안 하면 영구 저장된 게 아니다.

[그냥 락킹과 '2단계 락킹'의 차이]

트랜잭션이 끝날 때까지 락을 놓아주지 않는다. (일관성 보호)

데드락 즉 교착 상태가 발생할 수 있다.

확장 단계 & 수축 단계로 나뉜다.

확장 단계: Growing phase, Expanding phase

트랜잭션이 필요한 락을 획득하는 단계로,

이 단계에서는 트랜잭션이 끝나기 전까지 이미 획득한 락을 해제하지 않는다.

수축 단계: Shrinking phase

트랜잭션이 락을 해제하는 단계로,

이 단계에서는 새로운 락을 획득하지 않는다. (몽땅 해지, 언락)

[교착 상태 == 데드락]

deadrock

순서상 T1이 LX(A), T2가 LX(B)을 가져버리면 망한다.

점유와 대기, HOLD AND WAIT

무한 대기 상태에 빠질 수 있다.

생각하는 철학자들의 식사 시간

[데드락을 해결하려면]

대기 그래프를 그려서 사이클이 있는지 확인할 필요가 있다.

wait-for graph

락킹 단위란,

락이 걸리는 데이터 범위로

락킹 단위가 작아지면 병행성 수준이 높아진다.

...락킹 오버헤드는 락 걸었다가 풀었다가가 줄어드니까 줄어들고

「고립 수준」

읽고 쓰기 상황상 고려할 수 있는 방법이다.

오손 읽기 -> 배타락은 걸어도 공유락은 걸지 않아.

(다른 트랜잭션의 공유락과 배타락이 걸린 데이터를 읽을 수 있다)

롤백을 걸어버리면, 롤백 걸기 전 수행 중이던 데이터마저 읽어버리기에 (버퍼)

잘못된 데이터를 읽어버리는 셈이 된다.

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

(레벨 0)

=> 공유락을 걸어버린다. (공유락 걸려 있으면 못 바꾸게)

반복불가능 읽기 -> 공유락을 걸지만 끝나면 트랜잭션 전에 바로 해지한다

(다른 트랜잭션이 설정한 공유락은 읽지만 배타락은 읽지 못한다)

트랜 중 전에 출력한 거랑 후에 출력되는 게 달라도, 사용자는 모른다 (뭐지)

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

(레벨 1) (=기본 락)

=> 트랜잭션 끝날 때까지 락 걸자.

유령 데이터 읽기 -> 공유락을 걸고 트랜잭션 끝까지 유지한다

(다른 트랜잭션이 설정한 공유락은 읽지만 배타락은 읽지 못한다)

수정은 방지하는데, 추가는 방지 못 한다.

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

(레벨 2) (=2단계 락킹)

=> 인덱스별로 락 걸자. (INSERT 거부)

*그럼 결국 순차적으로, 직렬화된 것과 같아진다

마지막 레벨 -> 인덱스에 공유락을 설정하여

다른 트랜잭션의 INSERT 문이 금지된다

(SELECT 질의의 대상이 되는 테이블에 미리 배타락을 설정한 것과 같은 효과)

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

(레벨 3)

MYSQL은 공유락을 걸지 않고 최초 트랜잭션 SELECT 수행 시

SNAPSHOT을 만든 후 그 스냅샷으로 수행해 트랜잭션의 변경 시에도

「클라이언트」

· basic

· lifecycle 생명주기

· inflate (menu and intent) & adapter (entries) & ...

「서버」