내가 한 노력들

[ MySQL ] 외래키 설정으로 인한, 데이터 삭제 변경이 안되는 경우 해결 방법 3가지

JONGI-N CHOI — Tue, 9 Jul 2024 18:15:55 +0900

MySQL의 InnoDB엔진을 사용하는 경우, 외래키를 사용할 수 있습니다.

외래키는 부모 테이블과 자식 테이블 간의 관계를 위해 생성하는 키로, 해당 컬럼에 인덱스 생성이 필요하며 변경 시에는 반드시 부모 테이블이나 자식 테이블에 데이터가 존재하는지 체크하는 작업이 필요합니다.

개발 환경에서는 위와같은 테이블간의 관계가 좋은 가이드 역할을 할 수도 있지만, 테이블간의 체크로 인해 잠금이 여러 테이블로 전파하여 데드락이 발생하는 경우도 있습니다.

또한, 부모와 자식 테이블의 관계를 생각안하고 데이터를 삭제 및 변경 하는 경우에도 작업이 실패하는 경우게 생기게됩니다.

ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails

위의 에러는, 외래키 관계를 생각안하고 데이터를 삭제 및 변경을 시도하는 경우에 발생하는 에러입니다.

이렇게 외래키 설정으로 인해서 데이터를 변경 및 삭제가 실패하는 경우를 해결하는 방법에 대해서 설명해보려고 합니다.

실습을 위한 테이블 생성 및 데이터 추가

CREATE TABLE table1 (
    id INT PRIMARY KEY AUTO_INCREMENT,
    column1 VARCHAR(10),
    column2 VARCHAR(10)
);

CREATE TABLE table2 (
    id INT PRIMARY KEY AUTO_INCREMENT,
    table_id INT,
    column1 VARCHAR(10),
    FOREIGN KEY (table_id) REFERENCES table1(id)
);

table1과 table2를 추가하여, table2의 table_id 컬럼에 외래키를 설정하여 table1 과의 관계를 설정했습니다.

부모 테이블 : table1

자식 테이블 : table2

INSERT INTO table1(column1, column2) VALUES ('A', 'B'), ('C', 'D'), ('E', 'F');
INSERT INTO table2(table_id, column1) VALUES (1, 'A'), (1, 'B'), (3, 'C');

자식 테이블의 데이터를 먼저 삭제

부모와 자식 테이블의 관계를 생각하여, 순서대로 자식의 테이블의 데이터를 먼저 삭제하고 부모 테이블의 데이터를 삭제를 하게 되면, 에러가 발생하지 않고 데이터를 삭제하는 것이 가능합니다.

DELETE FROM table1 WHERE id = 1;

자식 테이블에서 부모 테이블의 id컬럼값이 1인 레코드를 참조하고 있는 데이터를 먼저 삭제하기 전에, 부모 테이블의 레코드를 삭제하게 되면 ,

위와같은 에러가 발생하게 됩니다.

DELETE FROM table2 WHERE table_id = 1;
DELETE FROM table1 WHERE id = 1;

연관이 있는 자식 테이블의 레코드를 먼제 삭제하고 난 뒤, 부모 테이블 레코드를 삭제하면 에러없이 실행이 가능합니다.

CASCADE / SET NULL 사용

부모 테이블의 레코드가 삭제시, 자식 테이블에서 연관이 되어있는 레코드를 같이 삭제하거나 해당 컬럼을 NULL로 변경해주는 설정을 추가하는 것이 가능합니다.

FOREIGN KEY (table_id) REFERENCES table1(id) ON [DELETE / UPDATE] [CASCADE / SET NULL]

위와같이 외래키 설정시에 같이 옵션으로 추가할 수 있습니다.

ON [DELETE/UPDATE] : 삭제시 / 변경시

CASCADE : 동일한 작업 실시 (부모 테이블 레코드를 삭제하면 연관있는 자식 테이블 레코드도 삭제)

SET NULL : 부모 테이블의 레코드를 변경시 연관있는 자식 테이블의 레코드 해당 컬럼을 NULL로 변경

CREATE TABLE table2 (
    id INT PRIMARY KEY AUTO_INCREMENT,
    table_id INT,
    column1 VARCHAR(10),
    FOREIGN KEY (table_id) REFERENCES table1(id) ON DELETE CASCADE
);

위와같이 테이블을 다시 생성하고, 외래키의 옵션에 ON DELETE CASCADE 설정을 추가합니다.

DELETE FROM table1 WHERE id = 1;

그 상태에서 부모 테이블의 레코드를 삭제하게 되면, 에러가 발생하지 않고 실행할 수 있게 됩니다.

SELECT * FROM table2;

자식 테이블을 확인해 보면,

table_id컬럼이 1의 값을 가지는 레코드도 부모 테이블과 함께 같이 삭제된 것을 확인 할 수 있습니다.

시스템변수 foreign_key_checks 사용

시스템변수 foreign_key_checks의 값을 OFF로 변경하게 되면, 외래키로 인한 테이블의 관계 체크 작업을 무시할 수 있습니다.

SET foreign_key_checks=OFF;
SET SESSION foreign_key_checks=OFF;

위의 두 명령은 동일한 작업을 합니다. (SESSION을 생략하면 자동으로 SESSION으로 실행됨)

CREATE TABLE table2 (
    id INT PRIMARY KEY AUTO_INCREMENT,
    table_id INT,
    column1 VARCHAR(10),
    FOREIGN KEY (table_id) REFERENCES table1(id)
);

자식 테이블은 CASCADE등의 옵션을 추가하지 않은 외래키만 추가하여 생성했습니다.

그 상태에서, 부모 테이블 레코드를 삭제하면,

DELETE FROM table1 WHERE id = 1;

foreign_key_checks값을 OFF로 변경 하기 전에는, 자식 테이블에서 부모 테이블의 레코드를 참조하고 있었기 때문에 에러가 발생했지만

OFF로 변경한 뒤로는 에러없이 삭제되는 것을 확인할 수 있습니다.

⚠️주의!
foreign_key_checks의 값을 OFF로 변경하고, 위와같이 관계 상관없이 데이터를 변경할 수 있다고해서 두 테이블의 관계가 깨진 상태로 데이터를 유지해도 된다는 것은 아닙니다. 관계가 유지될 수 있도록 관련있는 자식 테이블 레코드도 삭제가 필요합니다.

또한, foreign_key_checks값이 OFF상태인 경우에는, CASCADE의 옵션도 무시하므로 주의가 필요합니다.

이번에는 외래키 사용에 있어서 두 테이블의 관계를 맺어 개발시에 좋은 가이드 역할을 하기도 하지만, 데이터 작업시 연관 테이블간에 체크 과정으로 인한 작업 실패를 해결할 수 있는 방법에 대해서 알아봤습니다.

[ MySQL ]데이터베이스 문자열 함수 ( concat, substring, upper, lower)

JONGI-N CHOI — Thu, 4 Jul 2024 18:23:31 +0900

데이터베이스에서도 함수가 존재합니다.

흔히 알고있는 count, max, min, sum, avg같은 집계함수도 있지만, 그 외에도 굉장히 많은 함수들이 존재합니다.

그 중에서 문자열과 관련된 자주 사용되는 함수에대해서 알아보려고 합니다.

문자열

concat
substring
upper / lower

문자열관련 함수는 위의 세가지 종류에 대해서 알아보겠습니다.

concat

문자열을 연결하고 싶은 경우에 사용합니다.

SELECT concat("My Name is ", "JONGIN");

위와같이 "My Name is "라는 문자열과 "JONGIN"이라는 문자열을 합치기 위해 실행해보면,

위와같은 결과가 출력되는 것을 확인할 수 있습니다.

결과 컬럼을 보면, 사용한 함수가 그대로 출력되기 때문에 가독성이 굉장히 떨어진다.
그래서 보통 함수를 사용하는 경우에는 별칭과 함께 사용하는 것이 좋다.
예 : concat("My Name is ", "JONGIN") AS myName

concat함수의 매개변수로는 두개밖에 전달 못하는 것이아니라 여러개를 전달하는 것도 가능하다.

SELECT concat("My Name is ", name, ", email is ", email) FROM users;

하지만, 여기서 주의할점은 concat으로 출력할 수 있는 문자열의 최대 길이에 제한이 있다는 것 입니다.

SHOW VARIABLES LIKE 'group_concat_max_len';

위의 명령어를 통해서, 최대길이를 확인하는 것이 가능합니다.

기본값은 1024로 되어있습니다.

만약, 1024보다 더 길게 출력이 필요한 경우에는, 해당 변수값을 변경하면 됩니다.

SHOW VARIABLES LIKE 'group_concat_max_len';

substring

부분 문자열을 추출하고 싶은 경우에 사용합니다.

SELECT substring("JONGIN", 3, 3);

substring함수는 3개의 매개변수를 전달 받을 수 있습니다.

첫번째 인자는 대상이되는 문자열

두번째는 시작할 인덱스

세번째는 글자수

결과를 보면 NGI가 출력되는 것을 확인할 수 있습니다.

인덱스를 3으로 지정했는데 GIN이아닌 NGI가 출력된 것에 대해서, 여기서 이상함을 느끼는 분들도 계실 수 있습니다.
프로그래밍 언어에서 인덱스의 시작은 0으로 시작하는게 보통이지만, 이 substring함수의 인덱스는 시작이 1부터 시작합니다.

인덱스는 음수를 지정하는 것도 가능합니다.

SELECT substring("JONGIN", -3, 3);

음수를 붙히게 되면, 앞에서부터 인덱스가 시작되는게아니라 뒤에서부터 시작되게 됩니다.

위의 이미지를 참고하시면, -3을 인덱스로 전달했을 때, G가 시작 인덱스로 선택되는 것을 알 수 있습니다.

그리고, 세번째 인자는 생략하는 것이 가능합니다.

생략했을 때에는, 시작 인덱스부터 문자열 끝까지 출력하게 됩니다.

upper / lower

문자열을 모두 대문자 / 소문자로 변환할 때 사용합니다.

SELECT upper("jongin"); -- JONGIN
SELECT lower("JONGIN"); -- jongin

자주 사용되는 문자열 함수에대해서 알아봤는데, MySQL에는 문자열에 관련된 함수가 굉장히 많이 존재합니다.

관심이 있는분은 아래 링크에서 활용성이 높은 함수를 찾아보는 것도 좋을 것 같습니다.

https://dev.mysql.com/doc/refman/8.4/en/string-functions.html

MySQL :: MySQL 8.4 Reference Manual :: 14.8 String Functions and Operators

14.8 String Functions and Operators Table 14.12 String Functions and Operators Name Description ASCII() Return numeric value of left-most character BIN() Return a string containing binary representation of a number BIT_LENGTH() Return length of argument

dev.mysql.com

[DB] 집계함수와 그룹핑(GROUP BY, HAVING)

JONGI-N CHOI — Tue, 2 Jul 2024 17:24:14 +0900

집계함수

SELECT절에 사용되며, 여러 행으로부터 하나의 결가값을 반환하는 함수이다.
종류에는 COUNT, SUM, MIN, MAX, AVG가 존재합니다.

COUNT

레코드의 수를 반환해준다.

SELECT count(*) FROM customers;

count(*)를 사용하게 되면, 모든 레코드 수를 반환하게 됩니다.

customers 테이블에는 총 120개의 레코드가 존재한다는 것을 알 수 있습니다.

⚠️주의
count 함수는 값이 NULL인 값은 집계하지 않습니다.

SELECT count(first_name) FROM customers;

first_name 컬럼에 대해서 카운트 함수를 사용하면,

count(*)의 결과에서는 모든 레코드의 수가 반환되었지만, count(first_name)을 사용하게되면 NULL인 값을 제외하고 카운팅합니다.

SELECT count(*) FROM customers WHERE first_name IS NULL;

그래서, NULL인 값만 카운팅해보면,

6(120 - 114)가 반환되는 것을 확인할 수 있습니다.

SUM

숫자형 데이터 컬럼의 값의 합을 반환합니다.

id	name	no_seats
1	A	72
2	B	36
3	C	36

위와같이 rooms 테이블이 존재할 때, no_seats 컬럼들의 합을 구하고 싶으면

SELECT sum(no_seats) FROM rooms;

sum함수에 합을 구하고자하는 컬럼명을 전달합니다.

결과, 144 (72 + 36 + 36)이 출력됩니다.

만약, 숫자형 테이터 타입이 아닌 컬럼을 대상으로 사용하면 ?

위와같이 문자열 타입인 name 컬럼을 대상으로하면 0이 반환됩니다.

MIN & MAX

컬럼의 최소값과 최대값을 반환합니다.

SELECT MIN(no_seats) FROM rooms;

위에 동일한 rooms 테이블을 대상으로 no_seats 컬럼의 최소값을 구해보면,

SELECT max(no_seats) FROM rooms;

최대값을 구해보면,

MIN과 MAX는 문자열에서도 사용이 가능합니다.

SELECT min(name) FROM rooms;

위와같이 실행하게 되면,

SELECT name FROM rooms ORDER BY name LIMIT 1;

위의 SQL과 동일한 결과값이 출력됩니다.

MAX인 경우는,

SELECT name FROM rooms ORDER BY name DESC LIMIT 1;

위의 SQL과 동일한 결과값이 출력됩니다.

AVG

컬럼의 평균값을 반환합니다.

SELECT avg(no_seats) FROM rooms;

no_seats의 평균을 구해보면,

48 ((72 + 36 + 36) / 3)이 출력되는 것을 확인할 수 있습니다.

그룹핑

집계함수를 사용하다보면, 한가지 문제점을 겪을 수 있는데 SUM 함수를 사용하면서 다른 컬럼을 SELECT에 추가하려고 하면 오류가 발생한다.

오류가 발생하는 이유로는, 여러행을 하나의 값으로 반환하는 집계함수와 다르게 일반 컬럼은 모든 행의 값을 출력할려고 하기 때문입니다.

이러한 문제를 해결하기 위해서 여러행을 묶어서 출력하는 그룹핑 기능을 사용해야합니다.

GROUP BY

GROUP BY절을 사용해서, 그룹핑 기능을 사용할 수 있습니다.

위와같은 rooms 테이블을 가지고 있다고 가정하겠습니다.

SELECT name, count(*) AS total FROM rooms;

name을 그룹핑해서 카운팅 하고 싶어서 위와같이 SQL을 작성하게 되면,

위와같이 GROUP BY없이 집계되지 않은 컬럼을 사용했다는 내용의 에러가 발생하게 됩니다.

SELECT name, count(*) AS total FROM rooms
GROUP BY name;

GROUP BY 절을 사용해서 name 컬럼을 그룹핑해주면,

위와같이 원하는 결과를 얻을 수 있습니다.

집계함수를 사용할 때, 별칭(AS)을 사용해서 원하는 컬럼명으로 변경하는 것이 가능합니다.

HAVING

HAVING절은 WHERE절 처럼 레코드를 필터링하고 싶은 경우에 사용을 하는데, GROUP BY를 통해 그룹핑해서 얻은 데이터를 필터링할 때 사용합니다. 따라서, GROUP BY를 사용한 경우에만 쓸 수 있습니다.

SELECT name, sum(no_seats) AS total FROM rooms
GROUP BY name;

name 별 no_seats 컬럼의 합을 확인해보면,

위와같은 결과를 얻을 수 있는데, 여기서 total 값이 40 이상인 결과만 얻고 싶으면,

SELECT name, sum(no_seats) AS total FROM rooms
GROUP BY name
HAVING total >= 40;

GROUP BY 다음에 HAVING 을 추가해주면 됩니다.

total이 35였던 B의 레코드가 제외된 것을 확인할 수 있습니다.

또한,

SELECT name, sum(no_seats) AS total FROM rooms
GROUP BY name
HAVING total >= 40
AND name = 'C';

HAVING절도 WHERE절과 마찬가지로 AND나 OR등을 사용하는 것이 가능합니다.

⚠️주의할 점
HAVING으로 필터링하는 것은 어디까지나 그룹핑해서 나온 결과 레코드를 대상으로 하는 필터링입니다.
따라서, HAVING을 통해서 SELECT에 포함되어있지 않은 다른 컬럼을 조건으로 사용하는 것은 불가능합니다.
다른 컬럼을 조건으로 사용하고 싶은 경우에는 기존의 WHERE절을 통해서 처리합니다.

[DB] 데이터 베이스 정규화 (제 1 정규화, 제 2정규화, 제 3정규화)

JONGI-N CHOI — Mon, 1 Jul 2024 22:22:07 +0900

데이터 베이스 정규화란?

데이터베이스 내의 데이터 구조를 조직화하고 최적화하는 과정으로, 데이터의 중복을 제거하는 것이 목적이다.
중복을 제거함으로써, 효율성을 향상시키고 데이터 무결성을 보장할 수 있다.

정규화의 단계에는 1NF, 2NF, 3NF, BCNF(보이스-코드 정규화), 4NF, 5NF가 존재하지만, 여기서는 3NF까지만 다루고 있습니다.

이유는 3NF까지만 만족하더라도, 실무에서는 정규화 되었다고 말하기 때문입니다.

제 1 정규화(1NF)

제1 정규화를 만족하기 위해서는 다음 3가지의 조건을 만족해야한다.

테이블은 기본키를 가지는 것
반복되는 행이 존재하지 않는 것
컬럼에는 오직 단일 값만이 존재하는 것

위의 데이터를 보면 빨강색행이 완전히 중복하고 있기 때문에, 반복되는 행이 존재하지 않는 것 에 위배됩니다.

또한, 노랑색쉘 부분에는 하나의 컬럼에 단일 값이 아닌 복수의 값이 들어있기 때문에 컬럼에는 오직 단일 값만이 존재하는 것 에 위배됩니다.

위와같이 중복되는 행을 제거하고, 하나의 컬럼이 단일의 값을 가지도록 변경하면 1NF을 만족하게 됩니다.

제 2 정규화(1NF)

기본키가 복합키로 구성된 경우가 대상이 되고, 아래의 두가지의 조건을 만족해야합니다.

제1 정규화를 만족하는 것
모든 열은 기본키 전체에 의존하는 것

위의 데이터에서는, 이름과 과목 컬럼을 묶어서 기본키로 생성을 했고, 중복되는 행이 없으며 컬럼마다 단일 값을 가지고 있기 때문에 1NF을 만족하고 있습니다.

하지만, 점수 컬럼은 이름과 과목 컬럼에 모두 의존하고 있지만, 지역 컬럼은 과목 컬럼에는 의존하지 않고 이름 컬럼에만 의존하는 형태를 하고 있기 때문에 모든 열은 기본 키 전체에 의존하는 것 에 위배되게 됩니다.

위와 같이 두개의 테이블로 나누게 되면, 점수도 기본키(이름, 과목) 모두에 의존하게되고 지역도 기본키(이름)에 의존하게 되므로 2NF를 만족하게 됩니다.

제 3 정규화

제 2 정규화를 만족하는 것
기본키가 아닌 컬럼들은 기본키에 의존해야하는데 다른 일반 컬럼에도 의존하는 컬럼이 존재해서는 안된다.

기본키에도 의존하지만, 기본키가 아닌 일반 컬럼에도 의존하는 것을 이전적 함수 종속 관계라고 합니다.

위의 테이블에는 기본키가 존재하고, 중복된 행이 없으며 단일 값을 가진 컬럼이므로 1NF를 만족하고, 담임과 담당과목 컬럼 모두 기본키 (학년, 반) 모두에 종속 되어 있으므로 2NF를 만족합니다.

하지만, 담당과목은 기본키에도 의존하지만 기본키가 아닌 담임 컬럼에도 의존하고 있기 때문에 3NF 정규화를 위배하고 있습니다.

위와같이 두 테이블로 분리하게 되면, 각 컬럼은 일반 컬럼에 의존하는 것이아니라 기본 컬럼에만 의존하기 때문에 3NF을 만족하게 됩니다.

맨 처음에 말했듯이, 정규화를 진행하게 되면 중복 데이터를 삭제하여 무결성을 보장하고, 데이터베이스의 저장공간을 효율적으로 사용할 수 있다. 또한, 쿼리 성능이 향상되어 효율성이 올라가게 된다.

하지만, 정규화는 위와같은 장점만 존재하는 것이 아닙니다.

테이블을 분리하기 때문에, 데이터 조회시에 조인을 유발하여 많은 자원을 사용하게 되고, 쿼리의 작성의 복잡성이 높아지게 됩니다.

이와같은 문제를 해결하기위해서, 반정규화를 수행하기도 합니다.

반정규화란?
데이터베이스 성능 향상을 위해서, 데이터의 중복을 허용하고 조인을 줄여 성능을 향상하는 방법

다음에는 반정규화에 대해서도 공부해서, 정리해보겠습니다.

컬럼 수정하기 (제약조건, 컬럼명, 데이터 타입)

JONGI-N CHOI — Mon, 24 Jun 2024 23:43:25 +0900

MySQL에서 새로운 컬럼을 추가 및 삭제하는 것부터,

기존의 컬럼의 제약조건/컬럼명/데이터 타입을 수정하는 SQL을 정리해봤습니다.

컬럼 추가 & 삭제

추가

ALTER TABLE <table_name>
ADD COLUMN <column_name> <data_type>;

위의 sql은 기본적 데이터 타입만 추가한 컬럼이지만, 그 외에도 제약조건이나 컬럼의 위치를 변경하는것도 가능하다.

ALTER TABLE users
ADD COLUMN email VARCHAR(50) UNIQUE AFTER name;

위와같이, users 테이블에 email 컬럼을 추가하는데 데이터타입은 VARCHAR(50)이고, UNIQUE 제약조건을 가지며 name 컬럼 뒤에 위치시킨다.

삭제

ALTER TABLE <table_name>
DROP COLUMN <column_name>;

제약조건 수정

기본키 추가

ALTER TABLE <table_name>
ADD PRIMARY KEY (<column_name>);

기본키 삭제

ALTER TABLE <table_name>
DROP PRIMARY KEY;

외래키 추가

ALTER TABLE <table_name1>
ADD CONSTRAINT <constraint_name>
FOREIGN KEY (<column_name1>) REFERENCES <table_name2>(<column_name2>);

<table_name1>과 <column_name1>은 자식 테이블 이름과 컬럼명이고,
<table_name2>과 <column_name2>은 부모 테이블 이름과 컬럼명입니다.

외래키 삭제

ALTER TABLE <table_name>
DROP CONSTRAINT <constraint_name>;

컬럼명

방법1

ALTER TABLE <table_name>
CHANGE <old_column_name> <new_column_name> <data_type>;

<data type>을 적어줘야한다. 컬럼명만 변경하고 싶은 경우에는 기존의 데이터 타입을 그대로 적으면 된다.

방법2

ALTER TABLE <table_name>
RENAME COLUMN <old_column_name> TO <new_column_name>;

방법1과 다르게 데이터 타입을 적지 않고 컬럼명만 적으면 되기 때문에 방법2를 선호

데이터 타입

방법1

ALTER TABLE <table_name>
CHANGE <column_name> <column_name> <data_type>;

컬럼명을 수정할 때 사용했었던 CHANGE 를 통해서 데이터 타입을 바꾸는 것이 가능하다.
컬럼명을 수정하는게 아니라, 데이터 타입만을 변경하는 것이기 때문에 대상의 컬럼명을 2번을 적어줘야할 필요성이 있다.
이 과정에서 오타가 날 가능성이 높기 때문에 사용하지 않는편이 좋다.

방법2

ALTER TABLE <table_name>
MODIFY COLUMN <column_name> <data_type>;

CHANGE 구문을 사용하면, 컬럼명과 데이터타입을 변경할 수 있기 때문에 한가지의 명령어만 알고 있으면 두개다 처리할 수 있는 장점은 있지만 한가지의 SQL이 너무 많은 역할을 하고 있기 때문에 복잡성과 불명확성이 높아질 수 있다.

git - working directory, staging area, git repo 영역에 대해서

JONGI-N CHOI — Fri, 10 Nov 2023 11:38:37 +0900

Git이란?

Git은 소규모 프로젝트부터 대규모 프로젝트까지 모든 것을 빠르고 효율적으로 처리하도록 설계된 무료 오픈 소스 분산 버전 제어 시스템

분산 버전제어시스템이란?

분산형 버전제어시스템(DVCS, Distributed Version Control System)이란, 중앙에서 관리하고 있는 전체 프로젝트의 히스토리와 변경 내용을 복제하여, 로컬 환경에 저장소를 만들어 관리하는 방식

그래서 왜 써야하는데?

개발자라면 당연히 알고있어야되고, 써야하는 것으로 잘 알려져있는 git은 도대체 왜 필요한 것 일까?

이직하기 전의 회사가, 버전관리시스템없는 환경이었기 때문에 얼마나 git(버전관리시스템)이 편리하고 중요한지에 대해 깨달을 수 있었습니다.

파일은 서버 파일 시스템으로부터 FTP를 이용해 다운로드하거나, 업로드하는 형식이었습니다.

어느날, 시스템에 문제가 있어서 해당 파일을 확인해보니 수정날짜가 변경되어있어 누군가 수정은 했지만, 누가? 무엇을? 수정했는지 추적하는 것이 불가능 했습니다. (그리고, 아무도 자기가 수정했다고 말하는 사람이 없음...)

결국, 옛날에 백업한 파일을 가지고 있던 사람이, 해당 파일을 그대로 옛날 버전으로 덮어씌우는 식으로 해결한 적이 있었습니다.

이것을 제외하더라도, 서버 내에는 여러 백업 파일(index.html_20231111, index_test.html, 등등...)이 그대로 남아있어, 프로젝트 관리도 점점 힘들어지고, 서버 용량에도 영향을 끼치기 때문에 버전관리시스템의 도입이 필요했던 환경이었습니다.

하지만, git(버전관리시스템)을 이용하게 되면, 위와같은 문제를 해결 할 수 있습니다.

git은 변경사항을 저장하고, 언제든 해당 변경사항 지점으로 되돌아갈 수 있습니다.

사진과 앨범같은 느낌으로 이해하면 좋을 것 입니다.
우리는 지금의 순간, 추억을 남기기 위해, 사진을 찍어 대상의 모습이 사진으로써 저장을 합니다.

또한, 여러 사진들을 모아서 하나의 앨범으로 만드는 것도 가능합니다. 또한, 앨범에는 이름이나 앨범의 설명을 적어두는 것도 가능합니다.
초등학생의 모습이 그리운 경우에는, 초등학교 졸업 앨범을 찾아서 안에있는 사진을 보고 추억을 떠올리곤 합니다.

git도 마찬가지입니다.
변경사항이 있는 파일(사진)들을 모아서, 커밋(앨범) 을 통해서 설명을 적고 repo에 저장합니다.
그리고, 언제나 원하는 커밋으로 이동해, 그 때 당시의 파일의 변경사항을 확인할 수 있습니다.
(물론, git은 그외에도 다양한 기능을 제공합니다 )

그래서 개발자뿐만 아니라, 작가, 음악인, 학생등등 모든 사람이 활용할 수 있는 좋은 도구입니다.
git을 왜 사용해야하는지에 알았기 때문에, 이젠 깃을 잘 활용하기 위해서, 기초개념에 대해서 알아보도록 합시다.

repository(=repo)

하나의 프로젝트나, 서비스등의 단위를 repo 단위로 관리하게 됩니다.

채팅 서비스를 개발하고 싶으면, chatting-project라는 이름의 repo를 생성하고, 그 안에서 파일들을 변경하고 추적합니다.

각각의 repo는 서로에게 아무런 영향을 주지않는 독립적인 영역입니다.

git 추적하고 싶은 프로젝트가 있는 경우, 맨처음으로 해줘야하는 것이 git repository를 생성하여, 프로젝트를 git이 추적할 수 있도록 하는 것 입니다.

repository를 생성하는 방법은, git init 명령어를 통해 생성할 수 있습니다.

(또는, git clone 명령어를 통해 github으로 부터 이미 존재하는 repository를 복제하는 것도 가능하다.)

3개의 영역 (working directory, staging area, repository)

git은 3가지의 영역으로 나뉘어져 있습니다.

working directory

우리의 로컬 작업공간을 의미합니다.

실제 파일을 변경하고 있는 우리의 컴퓨터 공간

staging area

repository에 저장에 하기전, 저장할 파일들을 저장하는 공간

repository

변경 사항의 파일들을 영구적으로 git내에 저장하는 공간

변경사항을 git 에 저장하는 순서도

맨 처음, 로컬 환경에서 a.txt과 b.txt파일을 추가했다고 생각을 하겠습니다.

그럼 working direct리에 첫 번째 사진과 같이 파일 두 개가 추가되는 것을 확인할 수 있습니다.

그리고, git add <파일명>을 입력하게 되면, 해당 파일을 staging area로 이동할 수 있습니다.

마지막으로, git commit 명령어를 통해서, staging area에 있는 파일을 git의 repository에 저장하게 됩니다.

왜 git은 이렇게 3가지의 영역으로 나뉘어져있을까요???

그 이유는, 만약에 a.txt파일과 b.txt파일을 두 개를 생성했는데, 한 가지의 파일만을 commit하고 싶은 경우가 존재할 것 입니다.

commit은 작업의 최소 단위로 묶어서 하는 것이 좋다고 알려져있습니다.

예를들어, 오전중에 여러가지의 기능을 개발한 경우, 변경사항을 한 번에 다 commit하는 것이 아닌, 각 기능에 관련된 변경사항의 파일만을 커밋으로써 저장하는 것을 권장합니다.

그렇지 않고, 두 가지의 기능을 하나의 커밋으로 묶어서 저장하게 되면, 나중에 채팅을 작성하는 기능 전의 파일로 되돌아가고 싶은데

채팅을 작성하는 기능뿐만아니라 채팅 내용을 가져오는 가능까지도 삭제된 상태로 되돌아가게 됩니다.

따라서, 파일을 a.txt와 b.txt 두 개를 추가했지만 파일을 각각 나누어 커밋하고 싶은 경우에는 우선 git add a.txt로 working directory에 있는 파일을 staging area에 이동시키고, git commit 명령을 통해서 커밋을 하면 됩니다.

git commit 명령어는 staging area에 있는 파일을들을 묶어서 커밋으로 저장하는 것이기 때문에, 커밋 단위로 묶고 싶은 파일만 staging area에 옮겨서 처리하기 위해서 위와 같이 3개의 영역으로 나뉘어진 것을 알 수 있습니다.

[ 쿠키 ] 생명주기 / 세션쿠키 / 영속쿠키 / 도메인 / 보안

JONGI-N CHOI — Sun, 19 Feb 2023 00:28:51 +0900

쿠키

Set-Cookie

서버에서 클라이언트 쿠키 전달(응답)

ex) set-cookie: sessionId=asdasd124; expires=날짜; path=/; domain=.google.com;Secure

로그인 과정

1. 클라이언트 From을 통해 로그인

POST /login HTTP/1.1
Host: ...

user=jongin

2. 서버, DB에서 유저 확인후 응답

HTTP/1.1 200 OK
Set-Cookie: user=jongin

jongin님 안녕하세요~!

Set-Cookie에 user의 정보를 함께 보냄

3. 웹브라우저 쿠키 저장

웹브라우저에는 쿠키를 저장할 수 있는 공간이 있어서, 그 곳에 쿠키 저장

4. 또 다른 요청

GET /welcome HTTP/1.1
Cookie: user=jongin

쿠키가 웹 브라우저에 저장된 이후에는 요청을 보낼 때 마다, cookie 값을 넣어서 요청을 보냄

Cookie

클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP요청시 서버로 전달

활용

- 사용자 로그인 세션 관리

- 광고 정보 트래킹

쿠키 정보는 항상 서버에 전송됨

- 웹브라우저에 쿠키가 존재하면 서버에 요청할 때마다, 쿠키도 같이 보냄 -> 추가 트래픽 발생

- 최소한의 정보만을 사용 (세션 id, 인증 토큰)

- 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지(localStorage, sessionStorage)참고

Cookie에는 보안에 민감한 정보를 저장하면 안됨

쿠키 - 생명주기

set-Cookie: expires = 날짜 (GMT)

- 만료일 되면 쿠키 삭제

set-Cookie: max-age=3600 (초)

- 3600초가 지나면 쿠키 삭제 ( 0이나 음수이면 쿠키 삭제)

세션 쿠키

만료 날짜를 생략하면, 브라우저 종료시 까지만 유지

영속 쿠키

만료 날짜를 입력하면 해당 날짜까지 유지

쿠키 - 도메인

domain=google.com

domain을 명시한 경우

- 명시한 domain은 물론이고, 서브 도메인에서도 쿠키 접근 가능

domain을 명시안한 경우

- 현재 문서 기준에서만 쿠키 접근가능

쿠키 - 경로

path=/home

이 경로를 포함한 하위 경로 페이지만 쿠키 접근

일반적으로 "path=/"로 지정 ( 해당 도메인에서는 모든 곳에서 쿠키를 사용하게 하고 싶으니까)

쿠키 - 보안

Secure

Secure 생략시

쿠키 http, https를 구분하지 않고 전송

Secure 명시시

https인 경우에만 전송

HttpOnly

- XSS 공격방지

- 자바스크립트에서 접근 불가

- HTTP전송에서만 사용

SameSite

- XSRF공격 방지

- 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키 전송

[ Docker ] systemctl사용시 Failed to get D-Bus connection 에러 해결

JONGI-N CHOI — Wed, 11 Jan 2023 12:13:51 +0900

Docker 기반 컨테이너 환경에서 systemctl명령어를 사용하게 되면, "Failed to get D-Bus connection"에러가 나오는 경우가 있습니다.

컨테이너 생성시

docker run --privileged --name container image /sbin/init

컨테이너를 생성시에 --privileged 옵션을 추가하고, /sbin/init 명령어로 컨테이너를 실행시킵니다.

docker exec -it container /bin/bash

생성된 컨테이너에 bash쉘로 프로세스를 가동시켜서 접속하게 되면, 문제없이 systemctl 명령어를 사용할 수 있게 됩니다.

Mac 환경에서서는 추가적으로 설정

맥에서는 버전에 따라서 추가적인 설정파일의 수정이 필요합니다.

위의 방법으로도 해결이 되지 않는 경우에는 아래의 파일 경로의 설정파일을 수정해보세요.

설정파일 수정

// ~/Library/Group\ Containers/group.com.docker/settings.json
{
  ...
  "deprecatedCgroupv1": true
  ...
}

위의 경로의 파일에서 "deprecatedCgroupv1"값이 false 인 경우에 true로 변경해줍니다.

[ Docker ] centos7와 php8환경에서 imageMagick7 을 설치

JONGI-N CHOI — Tue, 20 Dec 2022 17:58:20 +0900

ImageMagick 설치전 필수 패키지 설치

yum install php-pear php-devel gcc

ImageMagick 설치

(1) 빌드 도구 설치

# yum groupinstall "Development Tools"
# yum install kernel-devel kernel-headers

먼저 ImageMagick의 소스 파일을 다운로드하기 전에 ImageMagick에는 컴파일러 및 기타 필요한 개발 도구와 같은 개발 환경이 필요하므로 아래 명령을 사용하여 빌드 필수 도구를 설치해야 합니다.

(2) 소스파일 다운로드

# yum install -y wget
# wget https: // www.imagemagick.org / 다운로드 / ImageMagick.tar.gz

(3) 압축해제

# yum install -y tar
# tar xzvf ImageMagick.tar.gz

(4) ImageMagick 디렉토리로 이동

# cd ImageMagick-7.1.0-55

(5) ImageMagick 및 구성의 컴파일을 수행

# ./configure

# make
# make install

(6) 동적 링커 런타임 바인딩을 구성

# ldconfig /usr/local/lib

존재하는 파일을 조사하고, 필요한 라이브러리를 로드하고 심볼릭 링크를 만드는 역할

(7) 버전확인

# magick --version

또는 간단한 imageMagick의 로고 이미지를 다운로드할 수 있는 명령어를 실행

# magick logo: logo.gif

[ Dcoker ] Centos7환경에서 php8 버전 설치

JONGI-N CHOI — Tue, 20 Dec 2022 17:33:57 +0900

컨테이너 생성

컨테이너 생성 & 실행

docker run -d --privileged --name centos7-php8 centos:centos7 /sbin/init

-d는 백그라운드로 실행

--privileged 와 /sbin/init 명령어는 나중에 systemctl 명령어를 사용할 때를 대비해서 설정 ( docker에서는 systemctl을 옵션없이 사용하면, 에러가 발생)

centos:centos7 는 centos이름의 이미지를 사용하는데, 버전은 7버전을 사용 (이미지는 docker pull centos:centos7로 다운로드 하는 것이 가능하지만, 설치된 이미지가 없이 컨테이너를 생성하는 경우에 자동적으로 docker에서 이미지를 설치함)

컨테이너에 프로세스 실행 (접속)

docker exec -it centos7-php8 /bin/bash

-i : 상호 입출력

-t : tty를 활성화해서 배시(bash) 셸을 사용하도록 활성화

-it 상호 커뮤니케이션 형식으로 명령어를 입력하고 출력하는 형태로 실행

/bin/bash : bash 쉘을 사용

PHP 설치

(1) 먼저 Remi를 사용하는 데 필요한 EPEL 을 설치합니다.

# yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

EPEL (Extra Packages for Enterprise Linux)는 기존의 패키지에서는 제공하지 않는, 패키지의 최신 버전을 제공하는 community 기반의 저장소이다.

(2) Remi 리포지토리 구성 패키지 설치

# yum install -y https://rpms.remirepo.net/enterprise/remi-release-7.rpm

REMI는 LAMP 기반으로 기존 패키지에서 제공하지 않는 최신 버전의 패키지를 제공

(3) yum-config-manager 명령 사용에 필요한 yum-utils 패키지 설치

# yum install -y yum-utils

(4) yum-config-manager 명령 사용

# yum-config-manager --disable 'remi-php*'
# yum-config-manager --enable remi-php80

다른 Remi 패키지의 php 버전을 비활성화 하고, PHP8.0 패키지 만 활성화하여 사용하도록

(5) 사용 가능한 리포지토리 확인.

sudo yum repolist

"remi-php80"이 표시되면 성공

(6) 설치 패키지의 최신화를 실시

# yum update -y

(7) PHP를 설치

# yum install -y php

(8) 버전확인

php -v

PHP 8버전이 제대로 출력이되면 끝입니다.

PHP8.0버전 설치 참고자료

https://qiita.com/C_HERO/items/1512ba1e33c330c9ab0d