1. tmp table

검색해보면 tmp_table_size가 global 메모리 영역으로 계산하는 글이 많다.

나도 처음엔 global 메모리에서만 사용되는 설정값인 줄 알았으나,

session 메모리에서 사용되는 설정값이란 걸 나중에 알았다.

즉, 쿼리마다 각각의 tmp table을 사용하는 것이다. (mariadb도 마찬가지)

 

mysql 5.7 버전 이하에는 DB에 접속하는 세션이 많아질수록 tmp table은 끝없이 증가하여

메모리가 엄청 할당될 수 있다.

그러나, mysql 8.0에서는 tmp table의 메모리 한계치 설정값이 등장했다

이름하여, temptable_max_ram...

디폴트는 전체 메모리의 3%이고 최소 1GB에서 최대 4GB까지 늘릴 수 있다 라고 공식문서에 나와있는데

근데 막상 설치하면 1GB로 잡혔다..

뭐 어쨋든...

아무리 많은 세션이 들어와서 tmp table을 사용하더라도 최대 1GB까지 사용할 수 있는 것이다.

만약 1GB를 모두 사용하고 있다면, 세션들은 디스크를 사용하여 성능이 무척 느려질 것이다.

업그레이드 시 한번 주목해볼만하다

 

2. character set 및 collation

5.7의 utf8이 8.0부터는 utf8mb3로 이름이 바뀐다

우리는 한글을 쓰기에 보통 utf8을 사용할 것이다.

근데 기존 utf8로 인코딩되는 3bytes로는 요즘 사용되는 emoji 이모티콘을 저장할 수 없어서

utf8mb4라는 게 생겨나고 4bytes로 저장된다.

그렇다고 모든 문자가 4bytes로 저장되는 건 아니고

3bytes로 저장되는건 3bytes로 저장되고 4bytes로 저장되는건 4bytes로 저장된다

 

무엇보다 collation.... 문제...

5.7에도 utf8mb4가 있는데 collation 디폴트가 utf8mb4_general_ci 이다

근데 8.0의 디폴트는 utf8mb4_0900_ai_ci 이다.

이 두 개가 골때리는게... 한글 비교시 좀 안맞을 수 있다.

물론 정렬할 때도 달라질 수 있음

다음의 코드를 보면 이해가 빠를거 같다

mysql> insert into t_test values (1, '가'), (2, 'ㄱㅏ'),(3, '가 ');
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> select * from t_test;
+----+--------+
| id | c1     |
+----+--------+
|  1 | 가     |
|  2 | ㄱㅏ   |
|  3 | 가     |
+----+--------+
3 rows in set (0.01 sec)

-- utf8mb4_0900_ai_ci 
mysql> select *, length(c1) from t_test where c1='가';
+----+--------+------------+
| id | c1     | length(c1) |
+----+--------+------------+
|  1 | 가     |          3 |
|  2 | ㄱㅏ   |          6 |
+----+--------+------------+
2 rows in set (0.01 sec)

-- utf8mb4_general_ci
mysql> select *, length(c1) from t_test2 where c1 = '가';
+----+------+------------+
| id | c1   | length(c1) |
+----+------+------------+
|  1 | 가   |          3 |
|  3 | 가   |          4 |
+----+------+------------+
2 rows in set (0.00 sec)

 

3. 기타 등등

MySQL 8.0에서는 다음의 설정 파라미터들은 주석 처리 or 제거해줘야 한다.

  • max_tmp_tables
  • query_cache_type
  • query_cache_size
  • innodb_file_format
  • innodb_file_format_max

그리고 sql_mode에서 NO_AUTO_CREATE_USER 옵션도 제거해줘야 하고...

또 rank 같은 예약어는 못사용하니 기존에 사용되는 프로시저 다 확인도 해봐야 한다.

마지막으로 lower_case_table_names 설정은 8.0부터 첫 기동시에만 설정할 수 있고 운영 중에는 변경이 불가능하다.

 

8.0 부터는 MySQL이 좀 더 엄격해진거 같은 느낌이 많이 든다.

기존 5.7에는 Datetime 데이터에 empty value를 비교해도 warning이 뜨고 동작되는 반면

8.0은 에러 뜨면서 쿼리가 작동하지 않는다.

부동소수점 관련해서도 

5.7은 '1e+52' 값이 insert되긴 하는데... 8.0은 들어가지 않는다.

해당 데이터를 유지한채 업그레이드를 하면 기존에 들어간 데이터는 에러로 나오진 않는다.

 

일단 기억나는건 이정도로 일하다가 더 있으면 업데이트할 예정.

Rocky Linux 8.9에서 Oracle express 설치 내용 (virtual box에 설치)

enterprise 설치하고 싶었지만... 라이센스 무섭..

yum -y update

systemctl stop firewalld
systemctl disable firewalld
systemctl status firewalld

# Oracle 설치
cd /usr/local/src
curl -o oracle-database-preinstall-21c-1.0-1.el8.x86_64.rpm https://yum.oracle.com/repo/OracleLinux/OL8/appstream/x86_64/getPackage/oracle-database-preinstall-21c-1.0-1.el8.x86_64.rpm
yum -y localinstall oracle-database-preinstall-21c-1.0-1.el8.x86_64.rpm
rm oracle-database-preinstall-21c-1.0-1.el8.x86_64.rpm

cd /usr/local/src
wget https://download.oracle.com/otn-pub/otn_software/db-express/oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm
#rpm -ivh oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm 
yum -y localinstall oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm

# 설정 완료되면 자동 실행됨
# 비밀번호 설정
/etc/init.d/oracle-xe-21c configure

# 확인
ps -ef | grep oracle


# 환경변수 설정 - 맨 아래 입력 후 저장
# vi /etc/profile

export ORACLE_HOME=/opt/oracle/product/21c/dbhomeXE
export ORACLE_SID=XE
export PATH=$ORACLE_HOME/bin:$PATH


source /etc/profile

# sqlplus 환경설정
yum install -y epel-release
yum install -y rlwrap

# vi ~/.bashrc

alias sqlplus='rlwrap sqlplus'



source ~/.bashrc

# 재부팅
reboot

# 오라클 실행
/etc/init.d/oracle-xe-21c start

# sqlplus 접속 - system 계정으로 접속
sqlplus

SQL> alter session set "_ORACLE_SCRIPT"=true;
SQL> create user gwchu identified by 12345;
SQL> grant resource, connect, dba to gwchu;

### dbeaver 접속
# 다음의 설정 추가
# vi /opt/oracle/homes/OraDBHome21cXE/network/admin/listener.ora

testdb = 
  (DESCRIPTION =
    (ADDRESS_LIST = 
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.56.116)(PORT = 1521))
    )
    (CONNECT_DATA = 
      (SERVER = DEDICATED)
      (SERVICE_NAME = XE)
    )
  )


# 오라클 재시작
/etc/init.d/oracle-xe-21c restart

# DBeaver 접속확인

# 파일 용량 크므로 삭제
rm -f /usr/local/src/oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm

위처럼 설정한 후 연결 잘 되면 끝~

# my.cnf 메모리 설정

 

MariaDB의 메모리 공간은 글로벌 메모리 영역과 로컬 메모리 영역으로 구분된다

 

글로벌 메모리 영역은 스레드가 공유해서 사용되는 공간이다

DB 최초 기동시 메모리를 최소한만 사용하다가 설정된 값까지 증가되고

증가한 이후 메모리룰 반환하지 않고 설정된 값 이내에서 사용된다

 

글로벌 메모리 = innodb_buffer_pool_size + key_buffer_size + innodb_log_buffer_size

설정 디폴트 설명
innodb_buffer_pool_size 128MB innodb가 data와 index를 캐시하는 곳 (물리적 메모리의 50%정도)
key_buffer_size 128MB MyISAM의 인덱스를 메모리에 저장하는 버퍼의 크기
innodb_log_buffer_size 16MB 로그파일을 디스크에 쓰기위한 버퍼크기

 

로컬 메모리 영역은 각 스레드별로 사용되며 공유되지 않는 공간이다

 

로컬 메모리 = ( tmp_table_size + sort_buffer_size + read_buffer_size + read_rnd_buffer_size + join_buffer_size + thread_stack + binlog_cache_size) * max_connections

설정 디폴트 설명
tmp_table_size
16MB 쿼리가 수행될때 사용되는 임시테이블 크기, 해당 설정 넘어가면 디스크에 write 됨.
sort_buffer_size 2MB 정렬에서 사용되는 메모리
read_buffer_size 131072 풀스캔에서 사용되는 메모리
read_rnd_buffer_size 256kB 정렬 후, read에서 사용되는 메모리
join_buffer_size 256kB index 사용하지 않는 조인에서 사용되는 메모리
thread_stack 299008 스레드별 스텍 크기
binlog_cache_size 32768 트랜잭션의 bin log를 캐시로 들고 있음
max_connections 151 최대 동시 접속 수

 

총 메모리 = 글로벌 메모리 영역 + 로컬 메모리 영역 + Mariadb 기본 기동(350MB) + performance_schema data(150MB) + OS / 파일 버퍼링 공간(전체 메모리의 약 10%) 를 고려할 것

 

[참고자료]
https://www.webcomand.com/docs/admin_guide/configuration/mysqlmariadb/index.html
https://support.skdt.co.kr/ko/support/solutions/articles/42000064656--cloud-z-db-mariadb%EC%9D%98-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%84%A4%EC%A0%95%EC%9D%84-%EC%96%B4%EB%96%BB%EA%B2%8C-%ED%95%B4%EC%95%BC-%ED%95%98%EB%82%98%EC%9A%94-
MariaDB 공식문서

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

 

 

Made by 꿩

# BOM (Bill Of Materials)

 

데이터를 다루다보면 계층형 데이터들이 있다

대표적으로 카테고리 데이터!!!

카테고리 데이터는 동일한 데이터이지만

서로 부모와 자식 관계를 가질 수 있다

 

이렇게 계층형 데이터를 DB에 저장할 때

우리가 잘아는 순환 관계로 표현이 된다

위의 모델은 1:M 관계를 표현하지만

M:M 관계를 표현하지 못한다

 

다시말해서

상위 데이터(1)가 여러 개의 하위 데이터(M)을 가질 수 있다.

(상위 카테고리는 여러 하위 카테고리를 가진다)

그러나

여러 개의 하위 데이터(M)가 여러 상위 데이터(M)를 가질 순 없다.

(하위 카테고리는 여러개의 상위 카테고리에 포함되지 않는다 - parent_category_no 컬럼이 하나)

 

이를 해결하는 모델이 바로 BOM 모델이다.

BOM 구조는 새로운 관계 엔티티를 추가하여 1:M 관계로 구성된 모델이다.

보통 제조업에서 많이 쓰여서 부품, 조립규칙으로 많이 설명되는데

요즘 식욕이 많아져서...

음식을 조합하는 걸로 예시를 들어보려한다.

 

샐러드를 만드는 데 기본적으로 채소와 드레싱이 조합이 된다

닭가슴살 샐러드와 일반 샐러드를 만들 때

동일한 채소와 드레싱을 사용하여 만들게 되는데

채소가 닭가슴살 샐러드와 일반 샐러드에 포함이 되고

샐러드가 채소와 드레싱을 포함하는 다대다(M:M)관계가 성립된다

 

BOM 모델은 이렇게 계층형 데이터들 간의 M:M 순환 구조를 가지고 있는

데이터를 저장하는데 사용되는거라 보면 된다.

 

[참고자료]
https://ora-sysdba.tistory.com/entry/Seminar-%EC%88%9C%ED%99%98-%EA%B4%80%EA%B3%84-BOMBill-Of-Materials
http://wiki.gurubee.net/pages/viewpage.action?pageId=983056

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

 

 

Made by 꿩

# 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

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

+ Recent posts