# SSH 공개키 설정

 

root 계정으로 서비스를 실행하는 것은 보안상 좋은 습관이 아니다

HDFS를 설치할 때 ssh 공개키에 대한 지식이 필요해서 포스팅을 한다

 

우선, 모든 서버에 hadoop이라는 계정을 생성해보자

groupadd hadoop
useradd -c "Apache Hadoop" -d /home/hadoop -g hadoop -s /bin/bash -u 9000 hadoop
passwd hadoop

 

ssh는 public key 암호방식을 사용한다

public key 암호방식은 비대칭 키로 양방향 암호화 방식이다.

public key와 private key를 사용한다

 

public key로 암호화된 데이터는 private key로만 복호화가 가능하다

private key로 암호화 된데이터는 public key로만 복호화가 가능하다

 

SSH Key를 생성하면 public key와 private key가 만들어진다

# 키 생성
ssh-keygen -t rsa -C "hadoop@localhost"

ssh-keygen이라는 프로그램을 이용하여 키를 생성하면 된다

-t rsa 옵션은 rsa 암호화 방식으로 키를 생성한다

-C 옵션은 코멘트이다

Enter file in which to save the key (/root/.ssh/id_rsa):

ssh 키가 저장될 위치를 말한다

기본 경로는 로그인한 사용자의 홈디렉토리의 {사용자}/.ssh/ 이다.

그냥 엔터 누르면 된다.

Enter passphrase (empty for no passphrase):

passphrase는 암호화시 salt처럼 사용하는 값이다.

The key fingerprint is:
SHA256:uIm++us4lxkLQoQJ3c3tp7ygxFsncmBKtBoN2TLGVWk hadoop@localhost

SHA256 해시 알고리즘을 사용했다는 것을 알려준다

 

위와 같이 키를 생성하면 public key와 private key가 생성된다.

### Public 키
# cat ~/.ssh/id_rsa.pub
ssh-rsa (키 내용) (코멘트)

### Private 키
# cat ~/.ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----

id_rsa는 private key로 타인에게 노출되면 안되는 키이고

id_rsa.pub은 public key로 remote 서버의 authorized_keys에 입력한다

authorized_keys 파일을 직접 생성할 경우 chmod 644 설정해줘야 한다.

authorized_keys는 public key 값을 저장하는 파일로 remote 서버에 생성하면 된다

 

HDFS에서는 네임노드가 private key를 가지고 있고

데이터노드가 public key를 가지고 있다고 보면 된다.

 

추가적으로 확인해야 할 사항이 한가지 더 있다

리눅스 접근 통제(tcpwrapper) 설정이 되어 있으면 허용해줘야 한다

# cat /etc/pam.d/sshd
...
account    required     pam_access.so accessfile=/etc/security/access.conf
...

# cat /etc/security/access.conf
...
-:hadoop:ALL EXCEPT 127.0.0.1 192.168.11.60

# cat /etc/hosts.allow
# cat /etc/hosts.deny

 

access.conf 파일에서

hadoop 계정으로 접근하는 ip를 허용해준다

더불어서 hosts.allow와 hosts.deny 파일도 체크하고

허용이 필요하면 허용해준다

 

위의 모든 과정이 끝나면

ssh hadoop@localhost로 비밀번호 없이 접속이 되는지 확인한다

[hadoop@localhost .ssh]$ ssh localhost
Last login: Mon Mar 28 20:12:07 2022 from ip
[hadoop@localhost ~]$

 

[참고자료]

https://storycompiler.tistory.com/112

https://brunch.co.kr/@sangjinkang/52

https://opentutorials.org/module/432/3742

https://gukii.tistory.com/19

To be continued.........

 

 

Made by 꿩

'IT > Bash' 카테고리의 다른 글

[Python] Database connection  (0) 2022.05.09
[Bash] 스크립트 #! 의미  (0) 2021.10.19
[Bash] 터미널 jar 파일 생성  (0) 2021.10.05
[centos] java openjdk 설치 및 삭제  (0) 2021.10.05
Redis 메모리 & 시간 측정 스크립트  (0) 2021.05.14

# PostgreSQL Architecture

 

PostgreSQL = 프로세스 기반의 DBMS

 

PG는 1개의 connection마다 1개의 backend 프로세스가 생성이 된다.

PostgreSQL의 프로세스 리스트를 보면 다음과 같다.

# ps -ef | grep postgres

postgres 11126     1  0  2021 ?        00:00:55 /home/postgresql/bin/postgres -D /home/postgresql/data
postgres 11129 11126  0  2021 ?        00:00:00 postgres: checkpointer 
postgres 11130 11126  0  2021 ?        00:07:01 postgres: background writer 
postgres 11131 11126  0  2021 ?        00:07:20 postgres: walwriter 
postgres 11132 11126  0  2021 ?        00:00:48 postgres: autovacuum launcher 
postgres 11133 11126  0  2021 ?        00:01:49 postgres: stats collector 
postgres 11134 11126  0  2021 ?        00:00:01 postgres: logical replication launcher 
postgres 12671 11126  0 11:03 ?        00:00:00 postgres: postgres postgres [local] idle
root     11245 11198  0 11:02 pts/0    00:00:00 grep --color=auto postgres

여기서 pid가 11126인 프로세스가 바로 Postmaster 프로세스이다.

PostgreSQL를 구동할 때 가장 먼저 프로세스이다

초기 복구 작업, Shared Memory 초기화, Background 프로세스 구동작업을 수행한다.

만약, 당신이 PG에 접속하고 싶은 경우, 이 프로세스가 Backend 프로세스를 생성해 줄 것이다.

 

 Backend 프로세스는 여러개가 있다.

checkpointer는 체크 포인트 발생시 dirty 버퍼를 데이터파일에 기록하고,

background writer는 주기적으로 dirty 버퍼를 데이터파일에 기록한다.

wal writer는 데이터 파일의 변경 사항을 로그파일로 기록하는데,

wal 파일은 데이터베이스에 대한 모든 조작 기록을 보관하고 있다.

이 파일의 존재 이유는 서버가 갑자기 중지되었을 경우

데이터 파일에 적용하지 못한 작업(checkpoint 작업이 안된)을

이 로그에 읽어서 다시 실행하여 서버에 안전하게 복구하기 위해서이다.

wal 파일을 특정 시점까지만 실행하면, 특정 시점 복구도 할 수 있다.

 

autovacuum launcher는 자동으로 vacuum 하는 프로세스이며

stats collector는 쿼리 최적화를 위해 통계 정보를 수집하는 프로세스이다.

logical replication launcher는 subscriber의 위치에서 테이블을 싱크해주는 프로세스이고

pid 12671인 프로세스는 local에서 누군가가 pg에 접속해 있다는 말이다.

 

 

PostgreSQL의 메모리 사용

 

PG의 메모리 사용 부분을 보면 Shared Memory 영역이 있다.

그 중 Shared Buffer는 사용자가 요청한 데이터 블록을 저장하는 공간이며 공유 메모리 버퍼이다.

 많은 사용자가 동시에 접근할 때 경합을 최소화하고

자주 사용하는 블록이 최대한 오랫동안 버퍼 내에 있는 영역이다.

결국 Shared Buffer의 목적은 디스크 I/O를 최소화 하는 것이다.

 

WAL Buffer는 데이터의 변경 사항을 잠시 저장하는 버퍼로

WAL writer 프로세스를 통해 WAL 파일에 기록된다.

 

PostgreSQL의 데이터 구조

 

각 DBMS별로 데이터 저장 구조는 다 다르다.

PG에서는 데이터베이스 > 스키마 > 테이블의 형태로 데이터가 분류되며

다음의 그림처럼 데이터가 저장이 된다.

 

데이터가 저장되는 파일들은 여러 개의 페이지들로 구성되며

하나의 페이지는 일반적으로 8KB를 차지한다.

페이지의 구성요소는 다음과 같다.

Page Header는 24bytes로 기본적인 페이지 정보를 저장하며

Item은 4 bytes로 데이터 시작위치, 크기가 저장된 포인터이다.

Tuple = 데이터 row 한 줄

 

PG는 MVCC 동시성 제어를 위해 MGA 방식을 사용하는데

만약 update나 delete가 발생할 경우

위의 그림에서 Tuple은 삭제되는게 아니라 더이상 사용하지 않도록 표시가 된다.

추후, VACUUM 작업을 해줘야 해당 Tuple들이 삭제될 것이다.

즉, Update와 Delete가 빈번하게 일어나면

테이블의 크기가 점점 늘어나게 될 것이다.

 

[참고자료]

https://waspro.tistory.com/146

https://d2.naver.com/helloworld/227936

https://mozi.tistory.com/565

https://dbrang.tistory.com/1579

To be continued.........

 

 

Made by 꿩

# MongoDB Sharded Cluster 기본

 

MongoDB의 sharded cluster를 구성할 때, 3종류의 서버를 알아야한다.

1. mongos(=router)

2. config

3. shard(=replica set)

 

 

mongos 서버는 어플리케이션으로부터 쿼리를 받아서 각 샤드로 쿼리를 보내주는 역할이다.

데이터가 저장되어 있진 않고, 말그대로 router 역할을 해주기만 한다.

어플리케이션으로부터 쿼리가 오면 mongos는 config 서버에 메타정보를 요청한다.

이때, 메타정보는 데이터가 저장되어있는 shard 정보 및 sharding key 정보들이다.

만약 그대가 쿼리에 shard key를 고려했다면, mongos는 해당되는 샤드만 접근할 것이다.

 

mongos는 이러한 정보들을 이용해

특정 replica set에 접근하여 데이터를 요청한다.

shard 서버들이 데이터를 주면 mongos는 merge만 한다.

만약 집계와 같이 여러 샤드에서 온 데이터를 병합을 해야한다면,

무작위로 하나의 샤드서버가 선택되어 거기서 모든 데이터가 병합이 된다.

 

config 서버는 shard들의 메타데이터를 저장하는 서버이다.

메타데이터는 모든 샤드의 chunk 리스트와 chunk의 범위에 대한 정보이다.

mongos서버는 이 데이터를 이용해 적정한 shard에 쿼리를 전달하는데

shard들도 config 서버에서 chunk 메타데이터를 읽기도 한다.

 

shard 서버는 replica set으로 구성되어 있으며 실제 데이터가 저장되는 곳이다.

shard 서버의 데이터는 여러개의 조각으로 파티션되며

이 조각들이 여러 샤드 서버에 분산 저장되는데

이 데이터 조각을 chunk라고 한다.

이 chunk는 각 샤드서버에 균등하게 저장되어야 좋은 성능을 낼 수 있고

한 쪽 샤드에 chunk가 너무 몰려있으면

mongodb 자체적으로 백그라운드로 chunk를 균등하게 balancing 작업을 하기도 한다.

 

 

여기서 zone의 개념도 있다.

zone은 shard key에 기반하여 생성하는 것으로

각 샤드의 zone을 설정하여

zone에 포함되는 shard key를 가진 데이터를 저장하도록 유도하는 것이다.

참고로 동일한 zone이 여러 shard에 해당될 수 있고

하나의 shard가 여러 zone을 가질 수 있다.

 

그리고 각 shard는 replica set으로 구성되어 있는데

보통 primary-secondary-arbiter 혹은 primary-secondary-secondary로 구성된다.

여기서 arbiter는 데이터를 저장하지 않고 오로지 투표 역할만 한다.

 

 

이때, replica set은 최소 3개 이상의 홀수개로 구성해야한다.

replica set은 서로 자기들끼리 heartbeat를 보내는데

만약 한서버가 heartbeat를 보내지 않는다면, 죽은 서버로 판단이 된다.

 

만약 primary가 고장이나면 남은 구성원끼리 투표를 해야하는데

2대뿐이라면 나머지 1대 가지고는 다수결이 안된다.

그리고 남은 1대 secondary는 primary가 되지 못하고 고립된 노드로 남겨진다.

 

참고로 하나의 replica set은 최대 50개 member를 설정할 수 있으며,

투표 member는 최대 7개밖에 설정할 수 없다.

 

 

기본적으로 master-slave로 구성된 서버들은

Write 작업은 master로 Read 작업은 slave로 보내어 부하를 최소화 한다.

MongoDB는 이런 기능이 없을까?

mongo에는 read preference 설정이란게 있다

read 작업을 primary로 할건지 secondary로 보낼지 설정할 수 있다.

디폴트는 primary이다.

당연히 primary로 설정하는게 일관성 측면에서 좋긴 하다.

 

[참고자료]

MongoDB Document

https://sarc.io/index.php/nosql/1703-mongodb-chunk-1

To be continued.........

 

 

Made by 꿩

# mariabackup 백업 & 복구

 

내가 하는 업무가 다양해서 일관성이 없다 보니

예전에 했던 일들을 자꾸 까먹어서

블로그에 써놓으면 좀 낫지 않을까?란 생각으로 쓰는 포스트이다.

 

우선 백업부터 하자

# 풀백업
mariabackup \
--backup \
--defaults-file={mariadb config 경로} \
--target-dir={백업파일 저장 경로} \
--user=root  \
--password='...' \
--no-lock 

# 증분백업
mariabackup \
--backup \
--defaults-file={mariadb config 경로} \
--target-dir={백업파일 저장 경로} \
--incremental-basedir={이전 풀/증분백업 LSN 저장 경로} \
--user=root  \
--password='...'

# prepare
mariabackup \
--prepare \
--target-dir={백업파일 저장 경로} \
--user=root \
--password='...'

--backup 백업이므로 이 옵션은 필수!

--defaults-file에는 mariadb config 파일 경로(my.cnf)를 명시한다.

--target-dir에는 백업파일 저장 경로를 명시한다.

--incremental-basdir에는 증분백업을 위한 이전 백업 파일의 저장 경로를 명시한다.

 

그리고 백업 도중 변경사항이 발생할 수 있다.

복원 전, --prepare 옵션을 통해서 백업 중 발생한 변경사항(redo로그)를 데이터 파일에 반영한다. 

prepare를 하게 되면 xtrabackup_checkpoints 파일의 backup_type이 

full-backuped -> log-applied로 변경된다.

 

백업 명령어를 실행하면 다음처럼 백업파일이 생성된다.

drwxr-xr-x 6 root root 4.0K 2022-02-11 18:15 .
drwx------ 4 root root 4.0K 2022-02-11 18:11 ..
-rw-r----- 1 root root  24K 2022-02-11 18:15 aria_log.00000001
-rw-r----- 1 root root   52 2022-02-11 18:15 aria_log_control
-rw-r----- 1 root root  326 2022-02-11 18:15 backup-my.cnf
-rw-r----- 1 root root  972 2022-02-11 18:15 ib_buffer_pool
-rw-r----- 1 root root  12M 2022-02-11 18:15 ibdata1
-rw-r----- 1 root root 2.5K 2022-02-11 18:15 ib_logfile0
drwx------ 2 root root 4.0K 2022-02-11 18:15 mysql
drwx------ 2 root root 4.0K 2022-02-11 18:15 performance_schema
drwx------ 2 root root 4.0K 2022-02-11 18:15 test
-rw-r----- 1 root root   25 2022-02-11 18:15 xtrabackup_binlog_info
-rw-r----- 1 root root   73 2022-02-11 18:15 xtrabackup_checkpoints
-rw-r----- 1 root root  553 2022-02-11 18:15 xtrabackup_info
drwx------ 2 root root 4.0K 2022-02-11 18:15 whatisyourname

 

여기서 xtrabackup_info 파일이 있다.

백업과 관련된 정보를 저장한 파일인데

복원의 목적이 slave서버를 구축하는 것이라면

binlog_pos 정보를 통해서 replication 설정을 하면 된다.

# cat xtrabackup_info 
uuid = 3879b27e-8b1b-11ec-9fd1-6c2b59b09b40
name = 
tool_name = mariabackup
tool_command = --defaults-file=... --user=root --backup --target-dir=...
tool_version = 10.4.11-MariaDB
ibbackup_version = 10.4.11-MariaDB
server_version = 10.4.11-MariaDB-log
start_time = 2022-02-11 18:15:54
end_time = 2022-02-11 18:15:56
lock_time = 0
binlog_pos = filename 'db-bin.000001', position '1766', GTID of the last change '0-1-7'
innodb_from_lsn = 0
innodb_to_lsn = 71865
partial = N
incremental = N
format = file
compressed = N

 

복원 명령어는 --copy-back 옵션을 사용하면 된다.

mariabackup \
--copy-back \
--target-dir={백업파일 저장 경로} \
--datadir={복원 data 디렉토리 경로} \
--user root \
--password '...'

data 디렉토리는 다른 이름으로 변경하여 놓자.

덮어쓰는 옵션은 있지만 미래는 모르는 일...

DB는 보수적으로...

난 나를 믿을 수 없다... ㅜㅡㅜ

 

[참고자료]

https://brush-describr.tistory.com/8

https://techblog.woowahan.com/2576/

https://m.blog.naver.com/anjae83/221749783199

https://semode.tistory.com/335

To be continued.........

 

 

Made by 꿩

'Database > RDBMS' 카테고리의 다른 글

[MySQL/MariaDB] my.cnf 메모리 설정  (0) 2022.06.11
[PostgreSQL] Architecture  (0) 2022.03.01
[MySQL/MariaDB] 계정 정보 추출  (0) 2021.11.11
Transaction과 Isolation Level  (0) 2021.04.07
MVCC 동시성 제어  (0) 2021.02.06

# 인바운드 & 아웃바운드

 

방화벽이란

서버와 서버 간 통신을 하는데 있어서

정의된 보안 규칙에 기반하여

네트워크 트래픽을 제어하는 보안 시스템이다.

쉽게 말하자면

어떤 곳에서 파티가 열렸는데

그 파티에 참석하려면 파티 인원으로 등록된 인원만 출입이 가능하다

파티장 앞에서 등록된 사람만 들여보내주는 역할을 하는게

바로 방화벽의 역할이다.

 

서버간 통신을 하다보면

데이터가 서버로 들어오는 경우가 있고

데이터가 서버밖으로 나가는 경우가 있다.

이때, 데이터가 서버로 들어오는 경우를 인바운드라 하고

데이터가 서버 밖으로 나가는 경우를 아웃바운드라 생각하면 된다.

 

예를 들자면

첨부파일을 서버에 저장한다 = 인바운드

첨부파일을 다운로드 한다 = 아웃바운드

한가지 더 알아야 할 것이 있는데 데이터 전송 방식이다.

데이터 전송 방식은 TCP와 UDP가 있는데

TCP는 신뢰성을 우선시하고

UDP는 성능을 우선시한다.

 

1,2,3이라는 데이터를 보낸다고 생각하자.

TCP 프로토콜은 데이터를 받는 입장에서 1,2,3 순서대로 데이터를 받겠지만

UDP 프로토콜은 1,2,3으로 오든 2,3,1로 오든 데이터를 받기만 하면 된다.

그리고

TCP는 받는 쪽에서 데이터를 잘 받았는지 확인하는 절차가 있는 반면

UDP는 데이터 보내기만 하면 끝이다.

 

그럼 방화벽을 여는 법을 알아보자

<리눅스>

### 인바운드 오픈
# 192.168.123.60 서버가 5432 포트로 들어오도록 허용
iptables -I INPUT 1 -s 192.168.123.60 -p tcp --dport 5432 -j ACCEPT
# 192.168.123.60 서버에 대한 인바운드 모든 포트를 허용
iptables -I INPUT 1 -s 192.168.123.60 -p all -j ACCEPT

### 아웃바운드 오픈
# 192.168.123.60 서버가 5432 포트로 나가도록 허용
iptables -I OUTPUT 1 -s 192.168.123.60 -p tcp --dport 5432 -j ACCEPT
# 192.168.123.60 서버에 대한 아웃바운드 모든 포트를 허용
iptables -I OUTPUT 1 -s 192.168.123.60 -p all -j ACCEPT

# 주의! 테스트 안함 ㅋ 참고용

 

<윈도우>

제어판 > Windows Defender 방화벽 > 고급 설정

> 인바운드/아웃바운드 규칙 > 새규칙 > 

포트 선택 + 다음 > TCP(기본) + 모든/특정 로컬 포트(특정 port 입력) + 다음

> 연결 허용 + 다음 > 다음 > 이름 및 설명 입력 마침

 

[참고자료]
https://prinha.tistory.com/entry/%EB%B0%A9%ED%99%94%EB%B2%BD
https://mangkyu.tistory.com/15
https://yunyoung1819.tistory.com/20

 

 

To be continued.........

 

 

Made by 꿩

'IT > 보안' 카테고리의 다른 글

[Spring] Google reCAPTCHA v3  (6) 2019.07.07
OAuth  (0) 2019.06.17
SSL인증서  (0) 2019.03.21
CSRF  (0) 2018.12.25
XSS 공격과 방어  (2) 2018.10.25

# 나의 신(神)

 

지난 2년은 나에게 사건사고가 많은 해였다.

2020년과 2021년...

경자년과 기축년...

안그래도 가뜩이나 차가운 사주에

경자와 기축이란 세운은 내 사주를 더욱 차갑게 만든다

다시는 겪고 싶지 않은 무섭고 힘든 나날이었다.

 

삶이 힘들다보면 결국 운명학에서 답을 찾곤 한다

내 사주가 극단적으로 차가워서

내 차트의 토성과 화성이 주요 지표성을 건드려서

등등

어떤 일이 안풀릴때 사주나 차트를 펴보면

항상 답이 나온다

하지만 바꿀 수 없는 답이다.

나무위키 - 음양오행설

불교에 귀의하고자 하는 친구는 나에게 말한다

전생의 업보로 받게 된 팔자라고...

그래, 내가 전생에 많은 죄를 지었나보다.

 

그 친구는 업보를 해소하기 위한 방법을 알려준다.

하루에 두시간씩 기도하고 주말에는 4시간...

너의 신한테 도움을 요청하라고

니가 지금 하고 있는 하루 20분 정도의 기도는

20분 정도의 값어치밖에 없는 기도라고..

매일 100일 동안 간절히 몇시간씩 기도하면

너의 업보가 많이 해소되고 너가 원하는게 이뤄질거라고..

 

정말 그럴까?

논리적이고 설득력있는 얘기였다

현생의 운명은 내 전생의 업보로 인해 만들어지고

현생의 운명을 조금이라도 변화시키고 싶으면

너보다 더 영력이 쎈 신에게 간절히 기도해서

업보로 인해 막혀있는 너의 소망을 이뤄지게 만들라는 것이었다.

 

기도하기 싫다고?

그럼 넌 간절히 원하지 않는거야

너의 간절함은 그정도가 끝이라는 거야

화생방 들어가봣지?

벽을 부수고 나오고 싶을 정도의 간절함이 넌 없는거야

그만큼 니가 간절히 원한다면

넌 100일 2시간 기도를 할거야.

 

이성적으로 논리적으로 맞는 말이다

하지만 가슴에는 와닿지가 않았다

그럼 내가 그만큼 간절히 원하지 않는다는 것인가?

라고 스스로에게 되물으면

그렇지 않다..

아니 나는 내 삶을 운명을 바꾸고 싶다

그걸 위해 내년에는 개명을 할 것이다

근데 그건 쉬운 길이잖아

정말로 업보를 해소하고 싶으면

그만큼 정성을 들여야

신도 너의 정성을 보고 그만큼 너의 업보를 해소해주겠지.

 

근데 난 직장인이야.

일하고 와서 자기전에 2시간이나 기도하라고?

주말에는 4시간?

일하고 나면 몸에 힘이 없어

퇴근하고 하는건 손가락만 움직여도 되는 게임이야

"그럼 넌 간절함이 없는거야."

 

그럼 다른 방법을 알려주지

일하면서 속으로 계속 기도해

일하면서 딴 생각할 수 있잖아

만약 중간에 끊기면 다시 해야해

아니, 못해...

일하면서 약먹는 것도 까먹는데

일에 집중해야하는데

어떻게 딴생각을 할 수 있어?

 

그래 알았어,

그럼 딱 두달만 하루 한시간씩 기도해봐

그렇게 해도 안되면

내가 주술해줄께

...

이미 내 마음은 갈갈이 찢어졌다

내가 그렇게까지 하면서 살아야해?

만약 그렇게 해서 소망이 이뤄지지 않는다면?

"그럼 넌 신에게 믿음이 없는거지"

 

내가 핑계를 너무 많이 대는걸까

자유의지로 운명을 바꾸는게 쉽진 않다고 들었다

나는 운명을 바꿀 수 있는 사람은 아닌가보다

나는 간절함이 없나보다.

 

나는 간절하다고 생각했는데

그만큼 노오력을 안하니 간절함이 없는거다

난 신을 믿지만

너의 믿음은 그정도뿐이다.

 

결론은

삶을 바꾸려면 결국 노력을 해야하고

노력을 하지 않는다면

전생의 업보로 이루어진 팔자대로

살아가는 수밖에 없다는 것이다.

 

그래서

너는 그것을 믿니?

아니 안믿어

믿고 싶지도 않아.

 

그건 너의 논리고 너의 세계고 너의 신이야

나의 논리, 나의 세계, 나의 신은

그렇게 빡세게 하지 않아도

문을 두드리기만 해도 열어줄거야

이름만 부르기만 해도 나를 위해 와줄거야.

 

그게 바로 내가 믿는 나의 주님이야

To be continued.........

 

 

Made by 꿩

'일상' 카테고리의 다른 글

[일상] 헬스장 창문 너머  (1) 2024.03.17
[일상] 청룡의 해가 들어오고 있어요!  (0) 2024.02.01
[일상] 솔라리턴  (0) 2018.12.19
[일상] 명동성당 아침  (2) 2018.10.30
[일상] 북한산 3인방  (1) 2018.10.27

MySQL -> MariaDB로 마이그레이션 하는 중

계정정보를 따로 추출하는 걸 발견해서

따로 기록해둔다.

나중에 유용할듯?!

mysql -u유저 -p`비밀번호` -e"select concat('show grants for ','\'',user,'\'@\'',host,'\'') from mysql.user" > user_list_with_header.txt
sed '1d' user_list_with_header.txt > ./user.txt
while read user; do
    mysql -u유저 -p`비밀번호` -e"$user" > user_grant.txt
    sed '1d' user_grant.txt >> user_privileges.txt
    echo "flush privileges" >> user_privileges.txt
done <user.txt
awk '{print $0";"}' user_privileges.txt >user_privileges_final.sql
rm user.txt user_list_with_header.txt user_grant.txt user_privileges.txt

발견지: https://stackoverflow.com/questions/23519797/how-to-export-import-existing-user-with-its-privileges?noredirect=1&lq=1 

To be continued.........

 

 

Made by 꿩

'Database > RDBMS' 카테고리의 다른 글

[MySQL/MariaDB] my.cnf 메모리 설정  (0) 2022.06.11
[PostgreSQL] Architecture  (0) 2022.03.01
[MariaDB] mariabackup 백업 & 복구  (0) 2022.02.15
Transaction과 Isolation Level  (0) 2021.04.07
MVCC 동시성 제어  (0) 2021.02.06

# [Kafka Connect/Debezium] SMT 란?

 

SMT는 Single Message Transformation의 약자이다.

 

Kafka Connect에 대해서 복기해보자.

여러 데이터베이스로부터 데이터를 추출하여 Kafka topic에 넣고

Kafka topic에 있는 데이터를 다른 데이터 소스에 전달하기 위해 만들어졌다.

https://debezium.io/documentation/reference/1.7/architecture.html

 

즉, 다양한 Database로부터 메세지를 생산하여

메세지들이 Kafka topic에 저장하고

다양한 데이터 소스들에게 메시지를 소비하는 것이다.

 

근데 debezium으로 메세지를 만들어 본 사람은 알겠지만

row 한 줄 당 메세지 한 개이다.

그리고 그 메세지는 매우 많은 정보가 들어가 있으며 그만큼 크기가 크다.

예시로 PostgreSQL Debezium에서 생성된 기본 메세지 형식을 보자.

{
  "schema": {
    ...
  },
  "payload": {
    "before": null,
    "after": {
      "id": 2,
      "product": "candle",
      "price": 13000,
      "ins_timestamp": 1635084000213
    },
    "source": {
      "version": "1.3.1.Final",
      "connector": "postgresql",
      "name": "pg_test",
      "ts_ms": 1635052376362,
      "snapshot": "last",
      "db": "test",
      "schema": "public",
      "table": "t_market",
      "txId": 113669095,
      "lsn": 905751868160,
      "xmin": null
    },
    "op": "r",
    "ts_ms": 1635052376362,
    "transaction": null
  }
}

schema 부분은 너무 내용이 많아 생략했고

payload 부분을 보면 before과 after로 나뉘어져 있는 것을 볼 수 있다.

그리고 해당 소스에 대한 정보가 들어가 있다. 

row 한 줄마다 데이터의 before 정보와 소스 정보가 모두 들어간다고 보면 된다.

그리고 해당 정보에 대한 스키마도 모두 포함된다.

참고로 해당 메세지는 insert 동작으로 before는 null임을 알 수 있다.

 

그렇다면 SMT를 적용한 메세지 형식을 알아보자.

우선, SMT를 적용할 경우 다음 transform을 추가해주면 된다.
(참고로 mongodb는 다른 transform type을 사용해야 한다.)

        "transforms": "unwrap",
        "transforms.unwrap.type":"io.debezium.transforms.ExtractNewRecordState",
        "transforms.unwrap.drop.tombstones":false,
        "transforms.unwrap.delete.handling.mode":"rewrite",
        "transforms.unwrap.add.fields":"op,schema"

 

위의 설정들은

debezium 공식문서(https://debezium.io/documentation/reference/transformations/event-flattening.html)

에서 확인하면 되고...

이렇게 SMT로 변환하도록 추가한 뒤, 메세지 형식은 다음과 같이 변경된다.

# insert
{
  "schema": {
     ...
  },
  "payload": {
    "id": 3,
    "product": "mask",
    "price": 1500,
    "ins_timestamp": 1635086072124,
    "__op": "c",
    "__schema": "public",
    "__deleted": "false"
  }
}

# update
{
  "schema": {
    ...
  },
  "payload": {
    "id": 3,
    "product": "mask",
    "price": 1490,
    "ins_timestamp": 1635086072124,
    "__op": "u",
    "__schema": "public",
    "__deleted": "false"
  }
}

# delete
{
  "schema": {
    ...
  },
  "payload": {
    "id": 3,
    "product": null,
    "price": null,
    "ins_timestamp": null,
    "__op": "d",
    "__schema": "public",
    "__deleted": "true"
  }
}
null

메세지가 훨씬 간결해지고

before 값이 없어지고 after 값만 나오는 것을 확인할 수 있다.

그리고 소스 정보도 위의 설정에서 명시한 내용만 나오도록 변형했다.

https://www.confluent.io/blog/kafka-connect-single-message-transformation-tutorial-with-examples/

이처럼 kafka topic에 메세지를 넣기 전

transformation을 이용하여 메세지를 변형하여

필요한 정보만 kafka topic에 넣도록 하여

메세지 크기를 줄일 수 있다.

 

transform은 SMT 말고도 더 다른 기능들도 있다.

저장되고자 하는 kafka topic을 임의로 설정한다든지

특정 데이터를 필터링 한다든지

Debezium이 릴리즈 되면서

점점 다양한 기능들이 추가되고 있는것 같다.

그런 기능들을 조사 및 연구해서 사용하면

좀 더 편리하게 원하는 대로 데이터 파이프라인을 구축할 수 있을 것이다.

To be continued.........

 

 

Made by 꿩

 

'CDC > Kafka Connect' 카테고리의 다른 글

Kafka Connect 설정  (0) 2021.01.09
Kafka Connect란?  (0) 2021.01.09

+ Recent posts