RastaLion's IT Blog https://rastalion.me Database & SE Fri, 03 Apr 2020 02:32:14 +0000 ko-KR hourly 1 https://wordpress.org/?v=5.4 https://rastalion.me/wp-content/uploads/2019/02/cropped-Rasta-Lion-1-32x32.jpg RastaLion's IT Blog https://rastalion.me 32 32 MongoDB 4.2 설치 on CentOS 7 https://rastalion.me/mongodb-4-2-%ec%84%a4%ec%b9%98-on-centos-7/ https://rastalion.me/mongodb-4-2-%ec%84%a4%ec%b9%98-on-centos-7/#respond Fri, 03 Apr 2020 02:24:04 +0000 https://rastalion.me/?p=1250   MongoDB 4.2 버전 설치 (Community Edition) 2020년 4월 3일 현재 가장 최신 버전의 MongoDB는 4.2 버전입니다. 물론 MongoDB 공홈에는 4.4 버전의 설치 문서까지 올라와 있습니다. 아직 stable 버전이 아니기 때문에 4.2 버전으로 설치를...

The post MongoDB 4.2 설치 on CentOS 7 appeared first on RastaLion's IT Blog.

]]>

 

MongoDB 4.2 버전 설치 (Community Edition)

2020년 4월 3일 현재 가장 최신 버전의 MongoDB는 4.2 버전입니다. 물론 MongoDB 공홈에는 4.4 버전의 설치 문서까지 올라와 있습니다. 아직 stable 버전이 아니기 때문에 4.2 버전으로 설치를 진행해 보겠습니다.

 

Yum을 통한 설치

YUM 레포지토리에 mongodb 4.2 repo를 추가해 줍니다.

vi /etc/yum.repo.d/mongo.repo

[mongodb-org-4.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc

yum install -y mongodb-org

yum install -y mongodb-org
Loaded plugins: fastestmirror, langpacks
Determining fastest mirrors
 * base: data.aonenetworks.kr
 * extras: ftp.kaist.ac.kr
 * updates: data.aonenetworks.kr
base                                                                                                                                                                                                                | 3.6 kB  00:00:00
extras
mongodb-org-4.2
updates
Resolving Dependencies
--> Running transaction check
---> Package mongodb-org.x86_64 0:4.2.5-1.el7 will be installed
--> Processing Dependency: mongodb-org-tools = 4.2.5 for package: mongodb-org-4.2.5-1.el7.x86_64
--> Processing Dependency: mongodb-org-mongos = 4.2.5 for package: mongodb-org-4.2.5-1.el7.x86_64
--> Processing Dependency: mongodb-org-shell = 4.2.5 for package: mongodb-org-4.2.5-1.el7.x86_64
--> Processing Dependency: mongodb-org-server = 4.2.5 for package: mongodb-org-4.2.5-1.el7.x86_64
--> Running transaction check
---> Package mongodb-org-mongos.x86_64 0:4.2.5-1.el7 will be installed
---> Package mongodb-org-server.x86_64 0:4.2.5-1.el7 will be installed
---> Package mongodb-org-shell.x86_64 0:4.2.5-1.el7 will be installed
---> Package mongodb-org-tools.x86_64 0:4.2.5-1.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

===========================================================================================================================================================================================================================================
 Package                                                       Arch                                              Version                                                  Repository                                                  Size
===========================================================================================================================================================================================================================================
Installing:
 mongodb-org                                                   x86_64                                            4.2.5-1.el7                                              mongodb-org-4.2                                            5.8 k
Installing for dependencies:
 mongodb-org-mongos                                            x86_64                                            4.2.5-1.el7                                              mongodb-org-4.2                                             14 M
 mongodb-org-server                                            x86_64                                            4.2.5-1.el7                                              mongodb-org-4.2                                             25 M
 mongodb-org-shell                                             x86_64                                            4.2.5-1.el7                                              mongodb-org-4.2                                             17 M
 mongodb-org-tools                                             x86_64                                            4.2.5-1.el7                                              mongodb-org-4.2                                             62 M

Transaction Summary
===========================================================================================================================================================================================================================================
Install  1 Package (+4 Dependent packages)

Total download size: 119 M
Installed size: 283 M
Downloading packages:
  고: /var/cache/yum/x86_64/7/mongodb-org-4.2/packages/mongodb-org-4.2.5-1.el7.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID 058f8b6b: NOKEY                                                          ]  0.0 B/s |    0 B  --:--:-- ETA
Public key for mongodb-org-4.2.5-1.el7.x86_64.rpm is not installed
(1/5): mongodb-org-4.2.5-1.el7.x86_64.rpm                                                                                                                                                                           | 5.8 kB  00:00:00
(2/5): mongodb-org-mongos-4.2.5-1.el7.x86_64.rpm                                                                                                                                                                    |  14 MB  00:00:01
(3/5): mongodb-org-shell-4.2.5-1.el7.x86_64.rpm                                                                                                                                                                     |  17 MB  00:00:00
(4/5): mongodb-org-tools-4.2.5-1.el7.x86_64.rpm                                                                                                                                                                     |  62 MB  00:00:01
(5/5): mongodb-org-server-4.2.5-1.el7.x86_64.rpm                                                                                                                                                                    |  25 MB  00:00:03
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                                                                       28 MB/s | 119 MB  00:00:04
Retrieving key from https://www.mongodb.org/static/pgp/server-4.2.asc
Importing GPG key 0x058F8B6B:
 Userid     : "MongoDB 4.2 Release Signing Key <packaging@mongodb.com>"
 Fingerprint: e162 f504 a20c df15 827f 718d 4b7c 549a 058f 8b6b
 From       : https://www.mongodb.org/static/pgp/server-4.2.asc
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : mongodb-org-tools-4.2.5-1.el7.x86_64                                                                                                                                                                                    1/5
  Installing : mongodb-org-mongos-4.2.5-1.el7.x86_64                                                                                                                                                                                   2/5
  Installing : mongodb-org-shell-4.2.5-1.el7.x86_64                                                                                                                                                                                    3/5
  Installing : mongodb-org-server-4.2.5-1.el7.x86_64                                                                                                                                                                                   4/5
Created symlink from /etc/systemd/system/multi-user.target.wants/mongod.service to /usr/lib/systemd/system/mongod.service.
  Installing : mongodb-org-4.2.5-1.el7.x86_64                                                                                                                                                                                          5/5
  Verifying  : mongodb-org-server-4.2.5-1.el7.x86_64                                                                                                                                                                                   1/5
  Verifying  : mongodb-org-4.2.5-1.el7.x86_64                                                                                                                                                                                          2/5
  Verifying  : mongodb-org-shell-4.2.5-1.el7.x86_64                                                                                                                                                                                    3/5
  Verifying  : mongodb-org-mongos-4.2.5-1.el7.x86_64                                                                                                                                                                                   4/5
  Verifying  : mongodb-org-tools-4.2.5-1.el7.x86_64                                                                                                                                                                                    5/5

Installed:
  mongodb-org.x86_64 0:4.2.5-1.el7

Dependency Installed:
  mongodb-org-mongos.x86_64 0:4.2.5-1.el7                    mongodb-org-server.x86_64 0:4.2.5-1.el7                    mongodb-org-shell.x86_64 0:4.2.5-1.el7                    mongodb-org-tools.x86_64 0:4.2.5-1.el7

Complete!

 

Default directory 생성
mkdir -p /var/lib/mongo
mkdir -p /var/log/mongodb

/var/lib/mongo는 DB의 기본적인 엔진과 파일들이 설치되는 경로이며 파라미터 값 변경을 통해 바꿀수 있습니다. 특별한 설정이 없다면, 기본 경로를 사용합니다.

/var/log/mongodb는 MongoDB의 log 파일이 쌓이는 경로입니다. 역시 파라미터 값 변경을 통해 바꿀수 있습니다.

 

권한 부여
chown -R mongod:mongod <directory>

생성한 디렉토리에 데이터를 쓰기 위해서는 mongod 라는 유저와 그룹 권한을 부여해야 합니다. 유저와 그룹은 yum 설치를 통해 기본으로 생성이 됩니다.

 

MongoDB의 설정 파일

Yum으로 설치가 완료되면 /etc/mongod.conf 라는 MongoDB의 설정 파일이 생성 됩니다.

mongod.conf 파일의 내용을 아래와 같이 수정합니다.

# mongod.conf

# for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path: /data_vol02/mongodb/log/mongod.log

# Where and how to store data.
storage:
  dbPath: /data_vol02/mongodb/db
  journal:
    enabled: true
    commitIntervalMs: 200
#  engine:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 2
      journalCompressor: snappy
      directoryForIndexes: false
    collectionConfig:
      blockCompressor: snappy
    indexConfig:
      prefixCompression: true

# how the process runs
processManagement:
  fork: true  # fork and run in background
  pidFilePath: /var/run/mongodb/mongod.pid  # location of pidfile
  timeZoneInfo: /usr/share/zoneinfo

# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1  # Enter 0.0.0.0,:: to bind to all IPv4 and IPv6 addresses or, alternatively, use the net.bindIpAll setting.

setParameter:
  enableLocalhostAuthBypass: false

#security:

#operationProfiling:

#replication:

#sharding:

## Enterprise-Only Options

#auditLog:

#snmp:

MongoDB의 configuration 포맷은  key = value 형식의 텍스트였는데 2.6버전에서 YAML 형식으로 변경되었습니다.

system log 설정 부분입니다

systemLog:
  destination: file
  logAppend: true
  path: /data_vol02/mongodb/log/mongod.log

저는 경로를 변경해서 설치 했습니다.

경로를 지정하지 않거나, syslog로 지정하면 런타임의 standard output으로 출력합니다. 이외에도 quiet, verbosity, traceAllExceptions 등의 다양한 옵션이 있습니다.

logAppend 의 경우는 Default 는 false 입니다. true 일 경우에는 존재하는 파일의 맨 아래부분에 새로운 기록이 추가 됩니다. false 일 경우에는 존재하는 것들을 백업하고 새로운 로그파일을 작성합니다.

storage Engine 설정부분 입니다.

MongoDB의 storage engine은 3.2버전부터 wiredTiger 엔진을 기본으로 사용해왔습니다. 4.2버전 부터는 MMAPv1 스토리지 엔진은 더 이상 사용할 수 없습니다.

In-Memory 스토리지 엔진의 경우 엔터프라이즈 에디션에서만 사용가능합니다.

storage:
   wiredTiger:
      engineConfig:
         cacheSizeGB: <number>
         journalCompressor: <string>
         directoryForIndexes: <boolean>
         maxCacheOverflowFileSizeGB: <number>
      collectionConfig:
         blockCompressor: <string>
      indexConfig:
         prefixCompression: <boolean>

기본 값으로 MongoDB는 cache 설정을 하지 않으면, Physical Memory에서 1GB를 뺀 값에 50%를 사용합니다.

50% of (Total RAM Size – 1GB)

이 계산 값으로 나온 값이 256MB보다 작으면, 그냥 256MB를 사용합니다.

journal은 저널링을 할 때 사용할 journal 의 허용여부 및 journal 의 commitInterval 등을 지정할 수 있습니다.

journalCompressor는 journal을 어떤 방식으로 압축할 것인지, 아니면 압축을 하지 않을 것인지를 지정하는 부분입니다.

journalCompressor 옵션은 4가지가 있습니다. 기본값은 snappy입니다.

  • none
  • snappy
  • zlib
  • zstd (4.2버전부터 추가)

directoryForIndexes는 인덱스를 dbpath와 분리하는 옵션입니다. 기본값은 false입니다.

MongoDB는 index라는 서브 디렉토리에 색인을 저장하고, collection이라는 서브 디렉토리에 콜렉션 데이터를 저장합니다.

true로 설정하는 경우 인덱스의 서브디렉토리로 인덱스를 분리 할 수 있는데, 운영중에는 심볼릭링크를 사용하여 분리할수 있고, 후에 MongoDB를 종료한 상태에서 분리된 경로를 심볼릭 링크를 사용한 경로로 옮겨주면 됩니다.

 

processManagement 옵션

processManagement:
   fork: <boolean>
   pidFilePath: <string>
   timeZoneInfo: <string>

fork의 기본값은 false입니다만, yum으로 설치하고나면 true로 된걸 확인할 수 있습니다. mongod, mongos는 기본적으로 daemon형태로 구동되지 않는데, ture로 되어 있는 경우 백그라운드에서 데몬을 활성화 시킵니다.

윈도우 버전에서는 지원하는 않는 설정값입니다.

 

이 밖에도 너무 많은 옵션이 있기 때문에 자세한 내용은 MongoDB 공식 홈페이지에서 확인하는 것이 좋습니다. 그리고 버전업이 될때마다 없어지는 값과 새로 생기는 값이 있으니 새버전이 릴리즈되면 한번씩 비교해보는 것도 좋겠습니다.

MongoDB 공식 홈페이지, Documentation Page 바로가기

 

MongoDB의 구동

YUM을 이용해 설치하면 CentOS 7버전에서는 특별한 세팅 없이도, systemctl 명령을 통해 MongoDB를 구동할 수 있습니다.

systemctl start mongod
systemctl status mongod
systemctl stop mongod
systemctl enable mongod
systemctl disable mongod
systemctl restart mongod

MongoDB를 구동하면 처음에 경고 문구가 뜨며 Mongo shell로 접속을 합니다.

root@opendb01:/data_vol02/mongodb/db]# mongo
MongoDB shell version v4.2.5
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("d1a36dbd-c078-4d05-98c5-c70c91665858") }
MongoDB server version: 4.2.5
Server has startup warnings:
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten]
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten]
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten]
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] **        We suggest setting it to 'never'
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten]
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] **        We suggest setting it to 'never'
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten]
---
Enable MongoDB's free cloud-based monitoring service, which will then receive and display
metrics about your deployment (disk utilization, CPU, operation statistics, etc).

The monitoring data will be available on a MongoDB website with a unique URL accessible to you
and anyone you share the URL with. MongoDB may use this information to make product
improvements and to suggest MongoDB products and deployment options to you.

To enable free monitoring, run the following command: db.enableFreeMonitoring()
To permanently disable this reminder, run the following command: db.disableFreeMonitoring()
---

>
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] **        We suggest setting it to 'never'
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten]
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] **        We suggest setting it to 'never'

해당 경고문을 제거하기 위해서는

[root@opendb01:/data_vol02/mongodb/db]# echo never > /sys/kernel/mm/transparent_hugepage/enabled

[root@opendb01:/data_vol02/mongodb/db]# echo never > /sys/kernel/mm/transparent_hugepage/defrag

확인해보면

cat /sys/kernel/mm/transparent_hugepage/enabled

always madvise [never]

[always]의 대괄호가 사라지고 never 부분에 [ ] 가 생겨있습니다.

그리고 mongod를 재구동하면 해당 경고 문구들은 사라집니다.

2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2020-04-03T09:29:12.353+0900 I  CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.

이부분은 엑세스 인증 부분인데 mongoDB를 설치하면 기본적으로 admin이라는 db가 생성됩니다. 이 admin db에 앞으로 생성할 db와 user를 관리할 수 있는 administrator 계정을 생성합니다.
그리고 나서 administrator 계정을 통해 작업할 db와 그 db에 접근 가능한 user 계정을 만듭니다. 이후 user 계정으로 접속해 db 작업을 진행합니다. 그리고 mongod 실행 옵션에 –auth 옵션을 넣어주면 사라집니다.

/usr/lib/systemd/system/mongod.service수정

ExecStart=/usr/bin/mongod $OPTIONS --auth

 

The post MongoDB 4.2 설치 on CentOS 7 appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/mongodb-4-2-%ec%84%a4%ec%b9%98-on-centos-7/feed/ 0
2020.04.03 하루 한문장 https://rastalion.me/2020-04-03-%ed%95%98%eb%a3%a8-%ed%95%9c%eb%ac%b8%ec%9e%a5/ https://rastalion.me/2020-04-03-%ed%95%98%eb%a3%a8-%ed%95%9c%eb%ac%b8%ec%9e%a5/#respond Fri, 03 Apr 2020 00:39:50 +0000 https://rastalion.me/?p=1247   Let’s rest a bit. 잠시 쉬자.   무언가 하다가 잠시 쉬었다가 하자고 할 때 쓰는 표현

The post 2020.04.03 하루 한문장 appeared first on RastaLion's IT Blog.

]]>

 

Let’s rest a bit.

잠시 쉬자.

 

무언가 하다가 잠시 쉬었다가 하자고 할 때 쓰는 표현

The post 2020.04.03 하루 한문장 appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/2020-04-03-%ed%95%98%eb%a3%a8-%ed%95%9c%eb%ac%b8%ec%9e%a5/feed/ 0
2020.04.02 하루 한문장 https://rastalion.me/2020-04-02-%ed%95%98%eb%a3%a8-%ed%95%9c%eb%ac%b8%ec%9e%a5/ https://rastalion.me/2020-04-02-%ed%95%98%eb%a3%a8-%ed%95%9c%eb%ac%b8%ec%9e%a5/#respond Wed, 01 Apr 2020 23:56:24 +0000 https://rastalion.me/?p=1244   This is my stash. 이건 내 비상금이야.   stash = 다람쥐나 청설모 등이 숨겨두는 도토리, 양식 같은걸 말하는데, 비상금 또는 혼자서만 먹는 음식, 술 같은걸 표현 하기도 한다.

The post 2020.04.02 하루 한문장 appeared first on RastaLion's IT Blog.

]]>

 

This is my stash.

이건 내 비상금이야.

 

stash = 다람쥐나 청설모 등이 숨겨두는 도토리, 양식 같은걸 말하는데, 비상금 또는 혼자서만 먹는 음식, 술 같은걸 표현 하기도 한다.

The post 2020.04.02 하루 한문장 appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/2020-04-02-%ed%95%98%eb%a3%a8-%ed%95%9c%eb%ac%b8%ec%9e%a5/feed/ 0
MongoDB란? https://rastalion.me/mongodb%eb%9e%80/ https://rastalion.me/mongodb%eb%9e%80/#respond Wed, 01 Apr 2020 04:29:29 +0000 https://rastalion.me/?p=1233   MongoDB란? MongoDB는 NoSQL 데이터베이스로, JSON 형태의 데이터를 저장하는 도큐먼트 지향 데이터베이스 입니다. SQL을 지원하지 않기 때문에 조인(Join) 개념이 없고, 스키마가 유동적입니다. 여기서 유동적이라는 말은 MongoDB에서 저장하는 데이터 단위가 ‘도큐먼트’라는 것을 의미하며, 이는 RDBMS에서...

The post MongoDB란? appeared first on RastaLion's IT Blog.

]]>

 

MongoDB란?

MongoDB는 NoSQL 데이터베이스로, JSON 형태의 데이터를 저장하는 도큐먼트 지향 데이터베이스 입니다.

SQL을 지원하지 않기 때문에 조인(Join) 개념이 없고, 스키마가 유동적입니다. 여기서 유동적이라는 말은 MongoDB에서 저장하는 데이터 단위가 ‘도큐먼트’라는 것을 의미하며, 이는 RDBMS에서 행 단위의 레코드라고 할 수 있습니다. 따라서 MongoDB의 도큐먼트 속성은 SQL처럼 정형화 되어 있지 않고, 가변적이기 때문에 모든 문서 형태가 비정형 데이터를 저장하고 처리하는데 적합합니다.

MongoDB는 RDBMS들이 테이블 형태로 데이터를 저장하는데 방식과 달리 웹서버와 통신할 때 자주 쓰이는 JSON(JavaScript Object Nation) 형식의 문서를 이용합니다. JavaScript Object Notation(JSON)은 XML과 함께 현대 웹에서 사용되는 데이터 교환의 기본 형식입니다. JSON은 숫자, 문자열 및 부울 값과 같은 모든 기본 데이터 유형을 지원하며 배열과 해시도 지원합니다.

MongoDB는 BSON(Binary JSON)이라고 하는 Binary 인코딩 형식으로 JSON 문서를 저장합니다. BSON은 JSON 모델을 확장하여 추가 데이터 유형, 순서 필드를 제공하고 서로 다른 언어 내에서 인코딩 및 디코딩에 효율적입니다.

MongoDB와 RDBMS의 특성을 비교해보면 아래와 같습니다.

RDBMS MongoDB
Database Database
Table Collection
Index Index
Row Document
Join Embedding & Linking

관계형 모델에서는 테이블이라는 틀 때문에 새로운 테이블을 생성하고 두 테이블 사이의 관계를 컬럼에 저장해서 데이터를 표시할 수 밖에 없습니다. 하지만 MongoDB 모델에서는 단순히 값을 배열(array)로 바꾸는 작업만으로 구조를 간단히 바꿀수 있습니다.

MongoDB의 가장 큰 장점은 복제(Replicate)와 샤딩(Sharding)을 기본적으로 제공하고 있다는 점입니다. 복제는 장애 대비 및 데이터의 보존을 위해, 샤딩은 정보를 분산하여 I/O속도를 높이는데 사용할 수 있습니다.

기존의 RDBMS들에 비해 스키마 변경이 자유롭기 때문에, 미래에 대한 예측이 어렵거나 최종적으로 결정되지 않은 모델의 경우 MongoDB를 도입이 유용합니다. 또 분산 컴퓨터 환경이 필요한 경우 MongoDB는 좋은 선택이 될수도 있습니다. Schemaless 환경이라는 것은 RDBMS에 비해 비교적 스키마에 대한 제한에서 자유롭다는 뜻이지 스키마가 없는 환경이 아닙니다. 따라서 MongoDB 역시 Flexible 스키마에 대한 적절한 모델링이 필요하고, DBA는 Schema validate, modeling에 대한 스킬을 필요로 하게 됩니다.

 

MongoDB의 트랜잭션

기존의 NoSQL 데이터베이스들은 트랜잭션을 지원하지 않았지만, MongoDB는 4버전 부터 Replication Set 대한 트랜잭션을 지원하기 시작했고, 4.2부터는 RDBMS 같은 트랜잭션 기능을 지원하기 시작했습니다. 4.2이상의 버전에서 클러스터 샤드간의 ACID 트랜잭션을 지원하며, RDBMS의 트랜잭션과 동일하게 사용하는 것이 목적으로 개발되었습니다. MongoDB에도 트랜잭션을 위해 3버전대에서 세션이라는 항목이 추가 되었고, 꾸준히 4.2까지 버전업을 하면서 트랜잭션에 대한 준비를 많이 해왔습니다. 트랜잭션 기능은 4.2이상 버전의 MongoDB 드라이버를 사용하여야 하며, 기본 DML의 타임아웃은 60초 입니다. 이것은 파라미터 값을 변경해 바꿀수 있습니다. TX경합이 발생하는 경우 60초까지 기다렸다가 타임아웃 혹은 처리를 하게 됩니다. 하나의 트랜잭션 내에서 많은 도큐먼트를 변경하는 작업은 권장하지 않으며, 이런 작업의 경우 배치형태의 처리를 권장합니다.

트랜잭션에 대해서는 나중에 자세히 알아보록하고, 오늘은 MongoDB도 트랜잭션을 지원한다 라는 정도만 알고 넘어가려고 합니다.

The post MongoDB란? appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/mongodb%eb%9e%80/feed/ 0
2020.04.01 하루 한문장 https://rastalion.me/2020-04-01-%ed%95%98%eb%a3%a8-%ed%95%9c%eb%ac%b8%ec%9e%a5/ https://rastalion.me/2020-04-01-%ed%95%98%eb%a3%a8-%ed%95%9c%eb%ac%b8%ec%9e%a5/#respond Wed, 01 Apr 2020 00:52:15 +0000 https://rastalion.me/?p=1229   매일 아침 출근길에 진미영 듣는데 좀 정리해 놨다가 잘 써먹어 봐야겠습니다. 그동안 들었던거 정리하는겸 첫날은 잔뜩 적어둡니다.   It ain’t over, till it’s over. 끝날때 까지 끝난게 아니다.   Your barn door open....

The post 2020.04.01 하루 한문장 appeared first on RastaLion's IT Blog.

]]>

 

매일 아침 출근길에 진미영 듣는데 좀 정리해 놨다가 잘 써먹어 봐야겠습니다.

그동안 들었던거 정리하는겸 첫날은 잔뜩 적어둡니다.

 

It ain’t over, till it’s over.

끝날때 까지 끝난게 아니다.

 

Your barn door open.

너 바지 지퍼 열렸다.

 

It was exhausting.

녹초가 됐다.

 

What are you gonna have?

뭐 먹을래?

 

Why do you have to treat me like that?

왜 나만 가지고 그래?

 

I don’t know, how I feel about that.

정중한 거절 표현

 

I like chilling out.

난 뒹굴뒹굴 거리는게 좋아

 

We couldn’t have done it without you.

나 니덕분이야.

 

You’ve outdone yourself.

넌 너무 손이 커

 

You drive me insane.

넌, 너무 답답해

 

Let’s not get carried away.

욕심부리지 말자

The post 2020.04.01 하루 한문장 appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/2020-04-01-%ed%95%98%eb%a3%a8-%ed%95%9c%eb%ac%b8%ec%9e%a5/feed/ 0
Shell https://rastalion.me/shell/ https://rastalion.me/shell/#respond Tue, 31 Mar 2020 03:19:42 +0000 https://rastalion.me/?p=1224   Shell이란 무엇인가? 간단히 정의를 하자면 사용자의 명령을 해석하여 커널에 전달하여 주고, 명령을 실행시켜 주는 명령어 해석기(Command Interpreter)입니다. 명령어와 프로그램을 실행할 때 사용하는 인터페이스이며,  좀 더 자세히 말하면 Shell은 커널(Kernel)과 사용자간의 다리역할을 하는 것으로...

The post Shell appeared first on RastaLion's IT Blog.

]]>

 

Shell이란 무엇인가?

간단히 정의를 하자면 사용자의 명령을 해석하여 커널에 전달하여 주고, 명령을 실행시켜 주는 명령어 해석기(Command Interpreter)입니다.

명령어와 프로그램을 실행할 때 사용하는 인터페이스이며,  좀 더 자세히 말하면 Shell은 커널(Kernel)과 사용자간의 다리역할을 하는 것으로 사용자로부터 명령을 받아 그것을 해석하고 프로그램을 실행하는 역할을 합니다.

사용자가 유닉스 시스템에 접속하면 바로 Shell 상태로 들어가게 됩니다. 간단한 명령인 ls 명령어를 실행시켜 보면, 바로 파일리스트가 출력됩니다. 이렇게 명령의 결과를 볼 수 있는 것은 그 짧은 시간에 Shell이 명령을 해석해서 커널을 거쳐 뿌려주는 것이죠. Shell이 단지 명령 해석 역할만 하는 것은 아닙니다. Shell을 잘 이용하면 시스템 사용을 편리하게 할 수 있습니다. [그림1]은 커널에서부터 사용자 로그인후 Shell 활성화 까지 보여줍니다.

[그림1]

시스템이 부팅하면, init 프로그램이 돌면서 /etc/inittab 파일을 검색합니다. init은 getty 프로그램을 호출하여 터미널화면에 login 프롬프트를 뛰우죠. 사용자의 아이디를 입력한 후 패스워드를 입력하면, getty는 login을 호출하고, login은 /etc/passwd 파일에서 패스워드가 일치하는지를 검색합니다. 만일 패스워드가 틀리면 다시 login 프롬프트를 뛰우고, 패스워드가 일치하면 사용자의 홈디렉토리로 위치시키고 시작프로그램 제어를 맡습니다. 처음 시스템에 접속하여 인증을 받은 후 뜨는 프롬프트는 자신이 사용하는 Shell의 프롬프트이고, 위치는 자신의 홈 디렉토리입니다.

현재 자신이 사용하는 Shell이 무엇인지 알아보려면 다음 명령어를 입력하면 됩니다.

echo $SHELL

 

Shell의 기능

  • 사용자와 커널 사이에서 명령을 해석해 전달하는 명령어 해석기 기능이 있습니다.
  • Shell은 자체 내에 프로그래밍 기능이 있어서 프로그램을 작성할 수 있고, Shell 프로그래밍 기능을 이용하면 여러 명령을 사용해 반복적으로 수행하는 작업을 하나의 프로그램으로 제작 할 수 있습니다. Shell 프로그램을 Shell 스크립트라고 부릅니다.
  • 사용자 환경 설정의 기능: 초기화 파일 기능을 이용해 사용자의 환경을 설정할 수 있습니다. 로그인 할 때 이 초기화 파일이 실행되서 사용자의 초기 환경이 설정됩니다. Shell을 공부하는데 가장 중요한 것 중 하나가 환경변수의 이해입니다.

 

Shell의 종류와 특징

Shell은 커널에서 분리된 별도의 프로그램이어서 다양한 종류의 Shell이 존재하고 현재까지도 지속적으로 개발되고 있습니다.

 

Bash

리눅스의 표준 Shell입니다.

1989년 브라이언 폭스가 GNU프로젝트를 위해 개발한 배시Shell은 shShell을 기반으로 만들어졌습니다. korn Shell과는 다르게 무료였으므로 급속히 전파되었습니다.

일반 유저는 $ 프롬프트를 사용하고 root 유저는 # 프롬프트를 사용합니다.

Bash의 특징
  • Alias 기능 (명령어 단축 기능)
  • History 기능 ( ↑ 또는 ↓ )
  • 연산 기능
  • Job Control 기능
  • 자동 이름 완성 기능 (tab)
  • 프롬프트 제어 기능
  • 명령 편집 기능

The post Shell appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/shell/feed/ 0
AIX에서 vi 사용시 메모리 부족하다고 나올때 https://rastalion.me/aix%ec%97%90%ec%84%9c-vi-%ec%82%ac%ec%9a%a9%ec%8b%9c-%eb%a9%94%eb%aa%a8%eb%a6%ac-%eb%b6%80%ec%a1%b1%ed%95%98%eb%8b%a4%ea%b3%a0-%eb%82%98%ec%98%ac%eb%95%8c/ https://rastalion.me/aix%ec%97%90%ec%84%9c-vi-%ec%82%ac%ec%9a%a9%ec%8b%9c-%eb%a9%94%eb%aa%a8%eb%a6%ac-%eb%b6%80%ec%a1%b1%ed%95%98%eb%8b%a4%ea%b3%a0-%eb%82%98%ec%98%ac%eb%95%8c/#respond Tue, 31 Mar 2020 03:00:38 +0000 https://rastalion.me/?p=1220   AIX에서 vi 사용시 메모리 부족하다고 나올때 Output: 0602-101 Out of memory saving lines for undo.   1. 임시 처방 vi -y 9999999 파일 이름   2.환경 설정 변경 /etc/profile에 다음 내용 추가 #...

The post AIX에서 vi 사용시 메모리 부족하다고 나올때 appeared first on RastaLion's IT Blog.

]]>

 

AIX에서 vi 사용시 메모리 부족하다고 나올때

Output: 0602-101 Out of memory saving lines for undo.

 

1. 임시 처방

vi -y 9999999 파일 이름

 

2.환경 설정 변경

/etc/profile에 다음 내용 추가

# Avoid problems when using vi to edit large files (files with many lines)
export EXINIT="set ll=20000000"

/var 파일 시스템의 용량이 부족할 경우는 임시 조치로 다음과 같이 진행합니다.

export EXINIT="set ll=20000000 dir=임시데이터 저장 디렉토리"

 

The post AIX에서 vi 사용시 메모리 부족하다고 나올때 appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/aix%ec%97%90%ec%84%9c-vi-%ec%82%ac%ec%9a%a9%ec%8b%9c-%eb%a9%94%eb%aa%a8%eb%a6%ac-%eb%b6%80%ec%a1%b1%ed%95%98%eb%8b%a4%ea%b3%a0-%eb%82%98%ec%98%ac%eb%95%8c/feed/ 0
SPIDER 엔진을 이용한 샤딩 환경 구축 #01 https://rastalion.me/spider-%ec%97%94%ec%a7%84%ec%9d%84-%ec%9d%b4%ec%9a%a9%ed%95%9c-%ec%83%a4%eb%94%a9-%ed%99%98%ea%b2%bd-%ea%b5%ac%ec%b6%95-01/ https://rastalion.me/spider-%ec%97%94%ec%a7%84%ec%9d%84-%ec%9d%b4%ec%9a%a9%ed%95%9c-%ec%83%a4%eb%94%a9-%ed%99%98%ea%b2%bd-%ea%b5%ac%ec%b6%95-01/#respond Wed, 25 Mar 2020 09:00:40 +0000 https://rastalion.me/?p=1215   Spider 엔진? Spider 스토리지 엔진은 샤딩 기능이 내장 된 스토리지 엔진입니다. 파티셔닝 및 xa 트랜잭션을 지원하며 다른 MariaDB 인스턴스의 테이블을 마치 동일한 인스턴스에있는 것처럼 처리 할 수 있습니다. Spider 스토리지 엔진으로 테이블을 작성하면...

The post SPIDER 엔진을 이용한 샤딩 환경 구축 #01 appeared first on RastaLion's IT Blog.

]]>

 

Spider 엔진?

Spider 스토리지 엔진은 샤딩 기능이 내장 된 스토리지 엔진입니다. 파티셔닝 및 xa 트랜잭션을 지원하며 다른 MariaDB 인스턴스의 테이블을 마치 동일한 인스턴스에있는 것처럼 처리 할 수 있습니다. Spider 스토리지 엔진으로 테이블을 작성하면 테이블이 원격 서버의 테이블에 링크됩니다. Remote 테이블은 스파이더 엔진이 아닌 MariaDB가 지원하는 모든 스토리지 엔진을 사용할 수 있습니다. 스파이더 엔진을 통한 마스터 노드와 스파이더 노드들의 연결은 Local MariaDB 노드에서 Remote MariaDB노드로 연결설정을 통하여 완성됩니다. 이 링크는 동일한 트랜잭션을 가진 모든 테이블에 대해 공유되어 집니다.

기존의 MySQL의 샤딩은 DB단에서 구현하지 않고, DB 앞단에서 구현을 합니다. 샤드키 기준으로 modulo로도 하고, 아니면 key 값으로 range 로도 구현을 하기도 합니다. 참고할 만한 자료가 카카오테크 페이지에 있습니다. (ADT 활용 예제1)

MariaDB에서는 Spider 엔진을 탑재하면서, DB단에서 샤딩을 구현할 수 있게 되었습니다.

 

 

Spider 엔진을 통한 샤딩 구현 실습

Spider Node 1대, 데이터 노드 2대로 구성했습니다.

 

데이터 노드 구성

각각의 데이터 노드에서 모두 생성해줍니다.

DB 및 테이블 생성
CREATE DATABASE backend;
CREATE TABLE backend.sbtest1 (
  id int(10) unsigned NOT NULL AUTO_INCREMENT,
  k int(10) unsigned NOT NULL DEFAULT '0',
  c char(120) NOT NULL DEFAULT '',
  pad char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (id),
  KEY k (k)
) ENGINE=InnoDB;
DB user 생성
create user 's_user'@'%' identified by 'Shard12#';
grant all privileges on *.* to 's_user'@'%' identified by 'Shard12#';
flush privileges;

 

스파이더 노드 구성
스파이더 엔진 설치

우선 스파이더 스토리지 엔진을 설치합니다.

mysql -uroot -p < /usr/share/mysql/install_spider.sql
엔진 조회
SELECT engine, support, transactions, xa
FROM information_schema.engines;

+--------------------+---------+--------------+------+
| engine             | support | transactions | xa   |
+--------------------+---------+--------------+------+
| SPIDER             | YES     | YES          | NO   |
| MRG_MyISAM         | YES     | NO           | NO   |
| MEMORY             | YES     | NO           | NO   |
| Aria               | YES     | NO           | NO   |
| MyISAM             | YES     | NO           | NO   |
| SEQUENCE           | YES     | YES          | NO   |
| InnoDB             | DEFAULT | YES          | YES  |
| PERFORMANCE_SCHEMA | YES     | NO           | NO   |
| CSV                | YES     | NO           | NO   |
+--------------------+---------+--------------+------+
9 rows in set (0.001 sec)
데이터 노드의 정보 등록
CREATE SERVER backend1
  FOREIGN DATA WRAPPER mysql 
OPTIONS( 
  HOST '172.16.68.3', 
  DATABASE 'backend',
  USER 's_user',
  PASSWORD 'Shard12#',
  PORT 3306
);

CREATE SERVER backend2
  FOREIGN DATA WRAPPER mysql 
OPTIONS( 
  HOST '172.16.68.4', 
  DATABASE 'backend',
  USER 's_user',
  PASSWORD 'Shard12#',
  PORT 3306
);
스파이더 테이블 생성
CREATE DATABASE IF NOT EXISTS backend;
CREATE  TABLE backend.sbtest1
(
  id int(10) unsigned NOT NULL AUTO_INCREMENT,
  k int(10) unsigned NOT NULL DEFAULT '0',
  c char(120) NOT NULL DEFAULT '',
  pad char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (id),
  KEY k (k)
) ENGINE=spider COMMENT='wrapper "mysql", table "sbtest1"'
 PARTITION BY KEY (id) 
(
 PARTITION pt1 COMMENT = 'srv "backend1"',
 PARTITION pt2 COMMENT = 'srv "backend2"' 
) ;

스파이더 노드에 일반 테이블과 스파이더 테이블의 비교를 위해 일반 테이블을 만들고 데이터를 넣는 작업을 합니다.

일단 테이블은 test 데이터베이스에 sysbench로 생성을 하겠습니다.

계정 생성
create user 's_test'@'%' identified by 'Test12#';
grant all privileges on *.* to 's_test'@'localhost' identified by 'Test12#';
flush privileges;
시스벤치를 이용한 데이터 넣기
sysbench /usr/share/sysbench/oltp_read_only.lua --db-driver=mysql --threads=16 --mysql-socket=/var/lib/mysql/mysql.sock --mysql-db=test  --mysql-user=s_test --mysql-password=Test12# --mysql-port=3306 --table-size=10000000 prepare

시스벤치 설치 및 사용법은 여기 (sysbench)를 참고하세요.

root@master:~]# sysbench /usr/share/sysbench/oltp_read_only.lua --db-driver=mysql --threads=16 --mysql-socket=/var/lib/mysql/mysql.sock --mysql-db=test  --mysql-user=s_test --mysql-password=Test12# --mysql-port=3306 --table-size=10000000 prepare
sysbench 1.0.19 (using bundled LuaJIT 2.1.0-beta2)

Initializing worker threads...

Creating table 'sbtest1'...
Inserting 10000000 records into 'sbtest1'
Creating a secondary index on 'sbtest1'...

천만건의 데이터가 입력 되었습니다.

MariaDB의 test DB에 접속해서 조회해보면

MariaDB [test]> select count(*) from sbtest1;
+----------+
| count(*) |
+----------+
| 10000000 |
+----------+
1 row in set (3.128 sec)

천만건이 조회됩니다.

천만건의 데이터를 backend DB에 만들어놓은 스파이더 테이블에 복사합니다.

insert into backend.sbtest1 select * from test.sbtest1;

입력이 끝나면 각각의 노드에서 테이블을 조회 해보겠습니다.

스파이더 노드
MariaDB [(none)]> select count(*) from backend.sbtest1;
+----------+
| count(*) |
+----------+
| 10000000 |
+----------+
1 row in set (3.280 sec)
Backend1 번 노드
MariaDB [backend]> select count(*) from backend.sbtest1;
+----------+
| count(*) |
+----------+
|  6206684 |
+----------+
1 row in set (1.914 sec)
Backend2 번 노드
MariaDB [(none)]> select count(*) from backend.sbtest1;
+----------+
| count(*) |
+----------+
|  3793316 |
+----------+
1 row in set (1.257 sec)

메인인 스파이더 노드에서는 천만건이 조회 되고, 각각의 데이터 노드에 나눠진 값이 조회됩니다. 샤딩 기능으로 데이터 노드에 분할되어 데이터가 입력된것이죠.

 

일반 테이블과 스파이더 테이블의 벤치마크 성능

일반 테이블의 벤치마크

sysbench /usr/share/sysbench/oltp_read_only.lua --db-driver=mysql --mysql-socket=/var/lib/mysql/mysql.sock --mysql-db=test  --mysql-user=s_test --mysql-password=Test12# --mysql-port=3306 --threads=4 --events=10000000 run

sysbench 1.0.19 (using bundled LuaJIT 2.1.0-beta2)

Running the test with following options:
Number of threads: 4
Initializing random number generator from current time


Initializing worker threads...

Threads started!

SQL statistics:
    queries performed:
        read:                            119546
        write:                           0
        other:                           17078
        total:                           136624
    transactions:                        8539   (853.32 per sec.)
    queries:                             136624 (13653.20 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          10.0044s
    total number of events:              8539

Latency (ms):
         min:                                    2.33
         avg:                                    4.68
         max:                                   32.96
         95th percentile:                        5.47
         sum:                                39986.42

Threads fairness:
    events (avg/stddev):           2134.7500/27.27
    execution time (avg/stddev):   9.9966/0.00

스파이더 테이블의 벤치마크

sysbench /usr/share/sysbench/oltp_read_only.lua --db-driver=mysql --mysql-socket=/var/lib/mysql/mysql.sock --mysql-db=backend  --mysql-user=s_test --mysql-password=Test12# --mysql-port=3306 --threads=4 --events=10000000 run

sysbench 1.0.19 (using bundled LuaJIT 2.1.0-beta2)

Running the test with following options:
Number of threads: 4
Initializing random number generator from current time


Initializing worker threads...

Threads started!

SQL statistics:
    queries performed:
        read:                            17878
        write:                           0
        other:                           2554
        total:                           20432
    transactions:                        1277   (127.36 per sec.)
    queries:                             20432  (2037.72 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          10.0220s
    total number of events:              1277

Latency (ms):
         min:                                   23.92
         avg:                                   31.35
         max:                                   64.70
         95th percentile:                       37.56
         sum:                                40031.27

Threads fairness:
    events (avg/stddev):           319.2500/1.48
    execution time (avg/stddev):   10.0078/0.01

실행 시간은 아주 약간 늘었지만, 쿼리 퍼포먼스나 트랜잭션 자체가 크게 줄어든걸 확인할 수 있습니다.

다음 포스트는 샤딩된 테이블에 대한 레플리카 구성을 해보겠습니다.

The post SPIDER 엔진을 이용한 샤딩 환경 구축 #01 appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/spider-%ec%97%94%ec%a7%84%ec%9d%84-%ec%9d%b4%ec%9a%a9%ed%95%9c-%ec%83%a4%eb%94%a9-%ed%99%98%ea%b2%bd-%ea%b5%ac%ec%b6%95-01/feed/ 0
MariaDB의 XA Transactions https://rastalion.me/mariadb%ec%9d%98-xa-transactions/ https://rastalion.me/mariadb%ec%9d%98-xa-transactions/#respond Tue, 24 Mar 2020 03:26:02 +0000 https://rastalion.me/?p=1196   분산 트랜잭션(Distributed Transactions)이란? 글로벌 트랜잭션(Global transaction)이라고도 불리며 여러개의 분산된 리소스들(ex: 프린터 드라이버, 데이터베이스 등) 각각에 대한 트랜잭션들을 하나의 트랜잭션으로 묶은 것을 의미합니다. 이 경우 하나의 리소스 실패하면 전체를 rollback 합니다. Distributed Transaction Processing(DTP)...

The post MariaDB의 XA Transactions appeared first on RastaLion's IT Blog.

]]>

 

분산 트랜잭션(Distributed Transactions)이란?

글로벌 트랜잭션(Global transaction)이라고도 불리며 여러개의 분산된 리소스들(ex: 프린터 드라이버, 데이터베이스 등) 각각에 대한 트랜잭션들을 하나의 트랜잭션으로 묶은 것을 의미합니다. 이 경우 하나의 리소스 실패하면 전체를 rollback 합니다.

Distributed Transaction Processing(DTP) 아키텍처는 여러 Application이 Transaction Manager를 이용하여 여러 다른 Resource Manager가 제공하는 리소스를 공유 할 수있게 해주는 표준 아키텍처 또는 인터페이스를 의미합니다.

 

XA?

XA는 2PC(2 phase commit)을 통한 분산 트렌젝션 처리를 위한 X/Open에서 명시한 표준입니다. XA는 분산트랜잭션 환경에서 트랜잭션 매니저와 리소스 매니저 사이에 통신을 담당하는 하나의 표준화된 인터페이스를 의미합니다. Oracle, Tibero, DB2등 벤더사별로 해당 interface에 맞는 동작을 구현해서 제공하고 있습니다. 즉 xa_open의 경우 오라클은 내부적으로 oracle server에 connection을 맺는 코드를 구현합니다. Oracle의 분산 트랜잭션은 2PC를 방식으로 DB Link를 통해 쉽게 구현이 가능합니다.

글로벌 트랜잭션을 사용하는 응용 프로그램들은 하나 혹은 그 이상의 리소스 매니저(Resource Manager)와 트랜잭션 매니저(Transaction Manager)를 포함합니다.

리소스 매니저는 일반적으로 컴퓨터 혹은 서버의 공유리소스를 관리하며 트랜잭션 리소스들에 대한 접근을 제공합니다. 공유 리소스의 예시로는 프린터기, Database등이 있으며 리소스 매니저에는 DBMS가 포함됩니다.

트랜잭션 매니저는 글로벌 트랜잭션의 부분인 트랜잭션 리소스들을 통합(coordination)합니다. 각 리소스 매니저별로 XID를 생성하여 transaction 진행을 관리하고 전체 리소스 매니저들의 트랜잭션을 commit 하거나 rollback 하는 기능을 수행합니다. 트랜잭션 매니저는 각각의 트랜잭션을 다루는 리소스 매니저와 함께 정보를 주고 받습니다.

글로벌 트랜잭션이 포함하는 개별적인 로컬 트랜잭션을 트랜잭션 브런치(Transaction branches)라고 합니다. 리소스가 DB인 경우 각 branch는 DBMS 내부의 로컬 트랜잭션을 의미하며, 글로벌 트랜잭션과 그 브런치들은 naming scheme에 의해 구별됩니다.

글로벌 트랜잭션을 실행하기 위해서는 2PC(2 phase commit)를 사용합니다. 2PC는 글로벌 트랜잭션의 branch들에 의해 수행되는 action들 뒤에 발생합니다.

  • 1st Phase – 모든 트랜잭션 브런치들이 준비가 되는 단계로, 각 트랜잭션 매니저가 데이터베이스 노드에 commit을 하기 위한 prepare 메시지를 보내 commit을 준비하는 단계입니다.
  • 2nd Phase – 트랜잭션 매니저가 참여한 모든 데이터베이스 노드로 부터 prepare 완료 메시지를 받을 때까지 대기하며, prepare 메시지 중 하나라도 OK가 아니라면 rollback, 모두 OK라면 commit 메시지를 보냅니다.

 

MariaDB에서 XA 구현

MariaDB의 XA 구현은 X/Open CAE 문서 인 Distributed transaction processing: XA Specification을 기반으로 구현되어 있습니다.

XA 트랜잭션은 트랜잭션 관리자(애플리케이션)가 여러 리소스를 포함하는 트랜잭션을 제어하는 ​​분산 트랜잭션을 허용하도록 설계되었습니다. 분산 트랜잭션을 허용한다는 것은 여러 개의 분리된 트랜잭션 리소스들이 하나의 글로벌(global) 트랜잭션에 포함되어 하나의 그룹으로 트랜잭션 동작을 하는 것을 의미합니다. 트랜잭션 리소스들은 대부분 RDBMS의 것들이지만 다른 리소스가 될 수도 있습니다.

MariaDB에서 XA 트랜잭션은 이를 지원하는 스토리지 엔진에서만 사용할 수 있습니다. 적어도 InnoDB, TokuDB, SPIDER 및 MyRocks가 지원합니다. InnoDB의 경우 innodb_support_xa 서버 시스템 변수를 0으로 설정하여 XA 트랜잭션을 비활성화 할 수 있습니다.

MariaDB에서는 쿼리 조회를 통해 스토리지 엔진에 따라 XA 지원여부를 확인할수 있습니다.

MariaDB 엔진 조회
MariaDB [(none)]> SELECT engine, support, transactions, xa FROM information_schema.engines;
+--------------------+---------+--------------+------+
| engine             | support | transactions | xa   |
+--------------------+---------+--------------+------+
| SPIDER             | YES     | YES          | NO   |
| MRG_MyISAM         | YES     | NO           | NO   |
| MEMORY             | YES     | NO           | NO   |
| Aria               | YES     | NO           | NO   |
| MyISAM             | YES     | NO           | NO   |
| SEQUENCE           | YES     | YES          | NO   |
| InnoDB             | DEFAULT | YES          | YES  |
| PERFORMANCE_SCHEMA | YES     | NO           | NO   |
| CSV                | YES     | NO           | NO   |
+--------------------+---------+--------------+------+

XA 트랜잭션은 일반 트랜잭션과 마찬가지로 액세스 하는 테이블에서 Metadata Locks를 발생 시킵니다.

하나의 글로벌 트랜잭션은 그 안에서 트랜잭션 되는 몇 가지 action들이 포함되어 있습니다. 글로벌 트랜잭션은 하나의 그룹으로 성공적으로 Commit 되거나, 하나의 그룹으로 rollback 됩니다. 이러한 동작을 기반으로 ACID 속성을 “up a level”로 하여 여러 개의 ACID 트랜잭션들이 하나의 글로벌 트랜잭션의 구성원들로서 조화를 이루어 수행될 수 있게 됩니다. XA 트랜잭션을 사용하기 위해선 최소 REPEATABLE READ 수준의 격리 레벨을 요구합니다. 그러나 분산 트랜잭션을 사용해야하는 경우에는 SERIALIZABLE 수준의 격리 레벨을 사용해야 합니다.

  • 하나 이상의 XA 트랜잭션을 동시에 시작하려고하면 1400 오류가 발생합니다 (SQLSTATE ‘XAE09’).
  • 일반 트랜잭션이 적용되는 동안 XA 트랜잭션을 시작하려고 할 때 동일한 오류가 발생합니다.
  • XA 트랜잭션이 적용되는 동안 일반 트랜잭션을 시작하려고하면 1399 오류 (SQLSTATE ‘XAE07’)가 발생합니다.
  • XA 트랜잭션이 유효한 경우 일반 트랜잭션에 대해 내재 된 COMMIT를 발생시키는 명령문은 1400 오류 (SQLSTATE ‘XAE09’)를 생성합니다.

 

Internal XA vs External XA

XA 트랜잭션은 MariaDB에서 오버로드 된 용어입니다. 스토리지 엔진이 XA를 지원하는 경우 다음 중 하나 또는 둘 다를 의미 할 수 있습니다.

  • MariaDB의 내부 2 단계 커밋 API를 지원합니다. 이것은 사용자에게 투명성을 보장합니다. MariaDB의 internal transaction coordinator log가 이러한 트랜잭션 조정을 처리 할 수 ​​있기 때문에 이를 “Internal XA”라고합니다.
  • XA START, XA PREPARE, XA COMMIT 등과 같은 XA 트랜잭션을 지원합니다. 이 기능을 올바르게 사용하려면 external transaction coordinator를 사용해야하기 때문에 이를 “External XA”라고합니다.

 

Transaction Coordinator Log

두 개 이상의 XA지원 가능한 스토리지 엔진이 사용 가능한 경우 Transaction Coordinator Log를 사용할 수 있어야합니다.
Transaction Coordinator Log에는 두 가지 구현 방식이 있습니다.

  • 이진 로그 기반 Transaction Coordinator Log
  • 메모리 매핑 된 파일 기반 Transaction Coordinator Log

서버에서 이진 로그가 활성화 된 경우 서버는 이진 로그 기반 트랜잭션 코디네이터 로그를 사용합니다. 그렇지 않으면 메모리 매핑 된 파일 기반 트랜잭션 코디네이터 로그를 사용합니다.

 

XA function

XA의 c언어 interface는 아래와 같습니다.

함수 설명
xa_open 리소스 매니저(Resource Manager)에 접속한다.
xa_close 리소스 매니저에서 데이터베이스 접속을 해제한다.
xa_start XID값을 주고 새로운 트랜잭션을 시작하거나, 이미 존재하는 트랜잭션에 현재 프로세스를 연결한다.
xa_end XID의 TX에서 현재 프로세스를 분리한다.
xa_rollback XID의 TX를 롤백한다.
xa_prepare XID의 TX에 대한 커밋을 준비한다. Two-phase commit의 First Phase이다.
xa_commit XID의 TX에 대한 커밋을 완료한다. Two-phase commit의 Second Phase이다.
xa_recover prepare 상태인 트랜잭션의 목록을 검사하여 커밋이나 롤백을 수행한다.
xa_forget XID의 TX가 이미 처리된 경우 로그 기록을 삭제한다.

 

Galera Cluster에서 이슈

MariaDB Galera Cluster는 XA 트랜잭션을 지원하지 않습니다. 그러나 MariaDB Galera Cluster 빌드에는 wsrep이라는 내장 플러그인이 포함되어 있습니다. MariaDB 10.4.3 이전에는이 플러그인이 내부적으로 XA 가능 스토리지 엔진으로 간주되었습니다. MariaDB Galera Cluster에서는 실제 XA를 지원하는 스토리지 엔진이 InnoDB뿐이지만, external XA transaction 지원을 동해 XA 트랜잭션이 가능한 경우도 있습니다.

The post MariaDB의 XA Transactions appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/mariadb%ec%9d%98-xa-transactions/feed/ 0
Database Caching Mode https://rastalion.me/database-caching-mode/ https://rastalion.me/database-caching-mode/#respond Fri, 13 Mar 2020 06:30:26 +0000 https://rastalion.me/?p=1177   Database Caching Mode? Oracle Database 12c Release 1(12.1.0.2)부터는 이전 버전의 Oracle Database에서 사용된 Default Database Caching Mode와  새로 추가된 Force Full Database Caching Mode라는 두 가지 Database Caching Mode를 사용할 수 있습니다. Default...

The post Database Caching Mode appeared first on RastaLion's IT Blog.

]]>

 

Database Caching Mode?

Oracle Database 12c Release 1(12.1.0.2)부터는 이전 버전의 Oracle Database에서 사용된 Default Database Caching Mode와  새로 추가된 Force Full Database Caching Mode라는 두 가지 Database Caching Mode를 사용할 수 있습니다. Default Database Caching Mode에서 Oracle Database는 사용자가 큰 테이블을 쿼리로 엑세스 하여도 기본 데이터들을 항상 캐시하지는 않습니다. 하지만 Force Full Database Caching Mode에서 Oracle Database는 (버퍼 캐시가 전체 데이터베이스를 캐시하기에 충분히 크다고 가정하고) 쿼리로 액세스 한 모든 블록을 캐시하려고 합니다.

 

Default Database Caching Mode

기본적으로 Oracle Database는 Full Table Scan을 수행 할 때 Default Database Caching Mode를 사용합니다. Default Database Caching Mode에서 Oracle Database는 사용자가 큰 테이블을 쿼리 할 때 기본 데이터를 항상 캐시하지는 않습니다. 만약에 캐싱을 한다면 버퍼 캐시에서 더 자주쓰는 데이터가 제거 될 수도 있습니다. Oracle Database 인스턴스가 전체 데이터베이스를 버퍼 캐시에 캐시하기에 충분한 공간이 있고 그렇게하는 것이 유리하다고 판단하면 인스턴스는 자동으로 전체 데이터베이스를 버퍼 캐시에 캐시합니다. Oracle Database 인스턴스가 전체 데이터베이스를 버퍼 캐시에 캐시 할 공간이 충분하지 않다고 판단되면 아래와 같은 사항을 체크해야합니다.

  • Small Table은 테이블 크기가 버퍼 캐시 크기의 2 % 미만인 경우에만 메모리에 로드됩니다.
  • 중간 크기의 테이블의 경우 Oracle Database는 마지막 테이블 스캔과 버퍼 캐시의 에이징 타임 스탬프 사이의 간격을 분석합니다. 마지막 테이블 스캔에서 재사용 된 테이블의 크기가 나머지 버퍼 캐시 크기보다 큰 경우 테이블이 캐시됩니다.
  • KEEP 버퍼 풀에 대한 테이블을 명시적으로 선언하지 않는 한 큰 테이블은 일반적으로 메모리에 로드되지 않습니다.

Default Database Caching Mode에서 Oracle Database 인스턴스는 버퍼 캐시에 NOCACHE LOB를 캐시하지 않습니다.

 

Force Full Database Caching Mode

더 많은 메모리가 데이터베이스에 추가됨에 따라 버퍼 캐시 크기도 메모리가 허용하는 만큼 커질 수 있습니다. 경우에 따라 버퍼 캐시의 크기가 엄청나게 커져서 데이터베이스 전체가 메모리에 들어갈 수도 있습니다. 데이터베이스 전체를 메모리에 캐시하게 되면 Table Full Scan을 수행하거나 LOB에 액세스 할 때 데이터베이스 성능을 크게 향상시킬 수 있습니다.

Force Full Database Caching Mode에서 Oracle Database는 데이터베이스 크기가 데이터베이스 버퍼 캐시 크기보다 작은 경우 데이터베이스 전체 를 메모리에 캐시합니다. SecureFile을 사용하는 NOCACHE LOB 및 LOBS를 포함한 모든 데이터 파일이 액세스 될 때 버퍼 캐시에 로드됩니다.

 

Force Full Database Caching Mode를 사용해야하는 경우

데이터베이스 버퍼 캐시의 크기가 데이터베이스 크기보다 클 때, I/O 처리량 또는 응답 시간이 제한되는, 특히 테이블 스캔 및 LOB 데이터 액세스가 많은 워크로드의 데이터베이스에서 성능을 향상 시키기 위해 Force Full Database Caching Mode의 사용을 고려해 볼수 있습니다.

  • 논리적 데이터베이스 크기(또는 실제 사용 된 공간)가 Oracle RAC 환경에서 각 인스턴스의 개별 버퍼 캐시보다 작은 경우. Single 인스턴스일때도 적용되는 사항입니다.
  • 논리적 데이터베이스 크기가 Oracle RAC 환경에서 분할 된 워크로드(인스턴스 별)에 대한 모든 인스턴스의 합산한 버퍼 캐시 크기의 80 %보다 작습니다.
  • 데이터베이스가 SGA_TARGET 또는 MEMORY_TARGET을 사용하는 경우
  • NOCACHE LOB를 캐시해야 하는 경우, NOCACHE LOB은 Force Full Database Caching Mode를 사용하지 않으면 캐시되지 않습니다.

Oracle RAC 데이터베이스의 한쪽 노드의 인스턴스가 Force Full Database Caching Mode를 사용하는 경우 Oracle RAC 환경의 다른 모든 데이터베이스 인스턴스도 Force Full Database Caching Mode를 사용합니다.

다중 테넌트 환경에서 Force Full Database Caching Mode는 CDB 밑에 포함된 모든 PDB에도 적용됩니다.

 

Database Caching Mode의 확인 및 적용

Oracle은 기본적으로 Default Database Caching Mode로 세팅되어 있습니다.

확인

SELECT FORCE_FULL_DB_CACHING FROM V$DATABASE;

Force Full Database Caching Mode 적용

ALTER DATABASE FORCE FULL DATABASE CACHING;

 

The post Database Caching Mode appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/database-caching-mode/feed/ 0
Redo Log Buffer의 튜닝 https://rastalion.me/redo-log-buffer%ec%9d%98-%ed%8a%9c%eb%8b%9d/ https://rastalion.me/redo-log-buffer%ec%9d%98-%ed%8a%9c%eb%8b%9d/#respond Fri, 13 Mar 2020 05:00:07 +0000 https://rastalion.me/?p=1172   지난 Buffer Cache에 대한 내용(Oracle Buffer Cache 튜닝과 Multiple Buffer Pool의 사용)에 이어서 Redo Log Buffer에 대해 이야기 해보겠습니다.   Redo Log Buffer Overview 버퍼 캐시에서 데이터 블록을 변경하는 서버 프로세스는 Log Buffer에...

The post Redo Log Buffer의 튜닝 appeared first on RastaLion's IT Blog.

]]>

 

지난 Buffer Cache에 대한 내용(Oracle Buffer Cache 튜닝과 Multiple Buffer Pool의 사용)에 이어서 Redo Log Buffer에 대해 이야기 해보겠습니다.

 

Redo Log Buffer Overview

버퍼 캐시에서 데이터 블록을 변경하는 서버 프로세스는 Log Buffer에 Redo 데이터를 생성합니다. 다음 조건 중 하나에 해당하면 log writer process (LGWR)는 Redo Log Buffer에서 Online Redo Log로 항목을 복사하기 위해 쓰기를 시작합니다.

  • Redo Log Buffer가 3분의 1 이상 가득 찼을때
  • LGWR이 COMMIT 또는 ROLLBACK을 수행하는 서버 프로세스에 의해 게시
  • DBWR (database writer process)에서 LGWR에 게시

LGWR이 Redo Log Buffer에서 Redo Log File 또는 Disk에 Redo 항목을 쓰면, 사용자 프로세스는 다음 그림과 같이 디스크에 쓰여진 메모리의 항목을 통해 새 항목을 복사할 수 있습니다.

Description of Figure 13-2 follows
LGWR은 액세스가 자주 발생하더라도 새로운 항목을 쓰기 위해 Redo Log Buffer에 지속적으로 공간을 확보 할 수있을 정도로 빠르게 쓰기를 시도합니다. Redo Log Buffer가 크면 새로운 엔트리를 위한 공간이 생길 가능성이 높아지고 LGWR은 리두 레코드를 효율적으로 처리 할 수 ​​있습니다. 업데이트가 많은 시스템에서 Redo Log Buffer가 너무 작은 경우 LGWR은 디스크에 3분의 2를 비우기 위해 계속 Redo를 디스크로 플러시합니다.

고속 프로세서와 상대적으로 느린 디스크가 있는 시스템에서, 프로세서가 Redo Log WriterRedo Log Buffer의 일부를 디스크로 이동하는데 걸리는 시간동안 나머지 Redo Log Buffer를 채울 수 있습니다. 이 경우 Redo Log Buffer가 크면 디스크 속도가 느려짐으로 인한 영향을 일시적으로 차단할 수 있습니다. 아니면 다음중 하나를 개선사항으로 고려해야 합니다.

  • The Checkpointing 또는 Archiving 프로세스
  • 모든 Online Log를 빠른 Read/Write 성능을 가진 저장 장치로 이동함으로써 LGWR의 성능을 향상

Redo Log Buffer의 성능을 향상 시키려면 다음과 같은 사항을 확인해야 합니다.

  • LGWR이 Redo Log 항목을 효율적으로 쓸 수 있도록 배치 작업에 대한 배치 커밋 작업
  • 대량의 데이터를 Load 할 때 NOLOGGING 옵션 사용

 

Redo Log Buffer를 구성하는 방법

Redo Log Buffer의 기본 크기는 다음과 같이 계산됩니다.

MAX(0.5M, (128K * number of cpus))

대량의 데이터를 Insert, Modify 또는 Delete하는 어플리케이션이 있는 경우 Redo Log Buffer의 기본 크기를 변경해야 할 필요가 있습니다. Oracle은 Redo Log Buffer의 크기를 최소 8MB로 설정할 것을 권장하고 있습니다. Flashback 기능을 사용하고 4GB 이상의 SGA를 사용하는 데이터베이스의 경우 최소 64MB로 설정해야 합니다. 비동기 Redo 전송(Asynchronous redo transport)과 Redo의 갱신 속도가 빠른 환경에서 Oracle Data Guard를 사용하는 경우에는 최소 256MB로 설정해야 합니다.

Redo Log Buffer 크기가 너무 작은지 확인하려면 Redo Log Buffer 통계를 모니터링해야 합니다. 또한 log buffer space wait event가 데이터베이스 인스턴스의 대기 시간에 중요한 요소임을 확인 할 수 있습니다. 확인이 되지 않는다면 현재 사용중인 Log Buffer 크기가 이미 적절한 크기를 가진것 입니다.

 

Redo Log Buffer 통계의 사용법

REDO BUFFER Assocation RETRIES 통계는 사용자 프로세스가 Redo Log Buffer에서 새로운 항목을 기록하기 위한 공간을 대기하는 횟수를 반영합니다. 이 통계는 V$SYSSTAT View를 사용하여 조회 할 수 있습니다.

애플리케이션이 실행되는 동안 일정 기간 동안 Redo Log Buffer 할당 재시도 통계를 모니터해야합니다. 이 통계량의 값은 구간에서 거의 0에 가까워 야합니다. 이 값이 지속적으로 증가하면 사용자 프로세스가 Redo Log Buffer의 공간을 사용할 수있을 때까지 기다려야한다는 의미입니다. Redo Log Buffer가 너무 작거나 잦은 Checkpoint로 인해 대기가 발생할 수 있습니다. 이런 경우에는 Redo Log Buffer의 사이즈를 늘리거나 checkpoint와 archiving process를 확인해 봐야 합니다.

아래는 Redo Log Buffer 통계를 조회하는 쿼리입니다.

SELECT name, value
  FROM V$SYSSTAT
  WHERE name = 'redo buffer allocation retries';

 

The post Redo Log Buffer의 튜닝 appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/redo-log-buffer%ec%9d%98-%ed%8a%9c%eb%8b%9d/feed/ 0
Oracle Logminor 사용법 https://rastalion.me/oracle-logminor-%ec%82%ac%ec%9a%a9%eb%b2%95/ https://rastalion.me/oracle-logminor-%ec%82%ac%ec%9a%a9%eb%b2%95/#respond Thu, 12 Mar 2020 07:44:41 +0000 https://rastalion.me/?p=1168   ORACLE 로그마이너(logminer) 사용하기 LogMiner 는 8I 에서부터 새롭게 제공하는 기능으로 Oracle 8 이상의 Redo log file 또는 Archive log file 분석을 위해 이용됩니다.   1. logminer로 추출한 로그파일 지정 execute DBMS_LOGMNR.ADD_LOGFILE (LOGFILENAME =>...

The post Oracle Logminor 사용법 appeared first on RastaLion's IT Blog.

]]>

 

ORACLE 로그마이너(logminer) 사용하기

LogMiner 는 8I 에서부터 새롭게 제공하는 기능으로 Oracle 8 이상의 Redo log file 또는 Archive log file 분석을 위해 이용됩니다.

 

1. logminer로 추출한 로그파일 지정

execute DBMS_LOGMNR.ADD_LOGFILE (LOGFILENAME => '/u01/app/oracle/oradata/devdb/redo_a/r1a.log',OPTIONS => DBMS_LOGMNR.NEW);

 

2. logminer 시작

execute DBMS_LOGMNR.START_LOGMNR (OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);

 

3. v$logmnr_contents 안의 내용 확인

SELECT username, operation, SQL_REDO, sql_undo from v$logmnr_contents;

 

4. 분석 대상 Redo(Archive) log file 등록

begin
dbms_logmnr.add_logfile('/oracle/oradata/orcl/redo01.log');
dbms_logmnr.add_logfile('/oracle/oradata/orcl/redo02.log');
dbms_logmnr.add_logfile('/oracle/oradata/orcl/redo03.log');
end;

 

5. 등록 log file 확인

select filename from v$logmnr_logs;

FILENAME
--------------------------------------------------------------------------------
/oracle/oradata/orcl/redo02.log
/oracle/oradata/orcl/redo03.log
/oracle/oradata/orcl/redo01.log

 

6. Logminer 분석 시작

BEGIN
DBMS_LOGMNR.START_LOGMNR
(options => dbms_logmnr.dict_from_online_catalog);
END;

 

7. 분석이 필요한 데이타 조회

select sql_undo from v$logmnr_contents
  where  seg_owner = 'SCOTT'
  and    seg_name = 'DEPT_TEST'

SQL_UNDO
--------------------------------------------------------------------------------
delete from "SCOTT"."DEPT_TEST" where "DEPTNO" = '10' and "DNAME" = 'ACCOUNTING'
and "LOC" = 'NEW YORK' and ROWID = 'AAANd8AAEAAAAIMAAE';

delete from "SCOTT"."DEPT_TEST" where "DEPTNO" = '20' and "DNAME" = 'RESEARCH'
and "LOC" = 'DALLAS' and ROWID = 'AAANd8AAEAAAAIMAAF';

 

8. logminer 끝내기

execute dbms_logmnr.end_logmnr ;

 

 

The post Oracle Logminor 사용법 appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/oracle-logminor-%ec%82%ac%ec%9a%a9%eb%b2%95/feed/ 0
Oracle Buffer Cache 튜닝과 Multiple Buffer Pool의 사용 https://rastalion.me/oracle-buffer-cache-%ed%8a%9c%eb%8b%9d%ea%b3%bc-multiple-buffer-pool%ec%9d%98-%ec%82%ac%ec%9a%a9/ https://rastalion.me/oracle-buffer-cache-%ed%8a%9c%eb%8b%9d%ea%b3%bc-multiple-buffer-pool%ec%9d%98-%ec%82%ac%ec%9a%a9/#comments Thu, 12 Mar 2020 06:18:20 +0000 https://rastalion.me/?p=1142   우선 Keep buffer에 대해 알아보기 전에 Buffer Cache에 대해 짚고 넘어가겠습니다. 이전에 간단하게 SGA에 대한 포스팅을 하면서 Buffer Cache에 관해서도 짤막하게 포스팅 한 적이 있습니다. (Oracle SGA)   Buffer Cache Overview 많은 유형의...

The post Oracle Buffer Cache 튜닝과 Multiple Buffer Pool의 사용 appeared first on RastaLion's IT Blog.

]]>

 

우선 Keep buffer에 대해 알아보기 전에 Buffer Cache에 대해 짚고 넘어가겠습니다.

이전에 간단하게 SGA에 대한 포스팅을 하면서 Buffer Cache에 관해서도 짤막하게 포스팅 한 적이 있습니다. (Oracle SGA)

 

Buffer Cache Overview

많은 유형의 작업에서 Oracle Database는 버퍼 캐시를 사용하여 디스크에서 읽은 데이터 블록을 저장합니다. 그러나 Oracle Database는 정렬 및 병렬 읽기와 같은 특정 작업에 대해 버퍼 캐시를 사용하지 않을때도 있습니다.

버퍼 캐시는 SYSTEM GLOBAL AREA(SGA)의 한 부분이며, 오라클 인스턴스에 접속된 모든 프로세스들이 공유하여 사용합니다. 사용에 대한 이점은 자주 사용되는 데이터 블럭에 대한 물리적 I/O를 줄이는데 있습니다. 데이터베이스 버퍼 캐시를 효과적으로 사용하려면 불필요한 자원 소비를 피하기 위해 응용 프로그램에 대한 SQL 문을 튜닝해야합니다. 그러기 위해서는 자주 실행되는 SQL 문과 버퍼에 많은 블럭을 읽어오는 SQL 문이 올바르게 작성되었는지 확인해야합니다.

병렬 쿼리를 사용할 때는 데이터베이스 버퍼 캐시를 사용하는 대신에 PGA (Program Global Area)로 직접 읽기를 수행하도록 데이터베이스를 구성해야합니다. 이러한 구성은 시스템에 많은 양의 메모리가있는 경우 적절합니다.

Oracle 7 까지의 Buffer Cache는 별개의 틀처럼 기능하여 각 오브젝트들의 특성별, 차별화에 따른 구현이 어려웠고, 지금의 Buffer Cache 같은 기능을 제공하기 위해 Oracle 8i 에서부터 Multiple Buffer Pool이라는 기능이 추가 되었습니다. 물론 LRU 알고리즘에 의해 Buffer cache가 관리되었지만 이는 가끔 아주 큰 오브젝트가 사용되어 질 때에는 물리적 디스크 I/O의 증가를 야기 할 수 밖에 없습니다. 그러나 Oracle 8 이상에서 제공하는 Multiple Buffer Pool은 이러한 Object Access의 다양성 및 빈도의 차별성을 구분하여 Buffer Cache가 보다 세밀하게 데이터 블럭을 관리할 수 있게 되었습니다.

 

Buffer Cache 설정

새 데이터베이스 인스턴스를 구성 할 때 버퍼 캐시의 올바른 크기를 알 수 없습니다. 일반적으로 데이터베이스 관리자는 먼저 캐시 크기를 추정 한 다음 인스턴스에서 대표적인 워크로드를 실행하고 관련 통계를 검사하여 캐시가 필요 이상으로 구성되지 않았는지 또는 부족하게 구성되지 않았는지 확인해야합니다.

이 섹션에서는 데이터베이스 버퍼 캐시를 구성하는 방법에 대해 설명합니다. 자동 공유 메모리 관리를 사용하여 SGA (Shared Global Area)를 구성하는 경우이 섹션에 설명 된대로 데이터베이스 버퍼 캐시를 수동으로 조정할 필요가 없습니다.

  • V$DB_CACHE_ADVICE View 이용하기
  • Buffer Cache Hit Ratio 계산하기
  • Buffer Cache Hit Ratio 해석

 

V$DB_CACHE_ADVICE View

v$DB_CACHE_ADVICE view는 다양한 잠재적 버퍼 캐시 크기에 대해 시뮬레이션 된 누락 비율을 보여줍니다. 이 View는 각 잠재적 캐시 크기에 대한 실제 읽기 수를 예측하는 정보를 제공하여 캐시 크기 조정을 지원합니다. 데이터는 또한 물리적 판독 계수를 포함하는데, 이는 버퍼 캐시가 주어진 값으로 크기 조정될 때 현재 물리적 판독 횟수가 변경 될 것으로 추정되는 요인을 나타냅니다.

그러나 실제 읽기는 파일 시스템 캐시에서 읽기를 통해 실제 읽기를 수행 할 수 있으므로 Oracle Database의 디스크 읽기라고 확신할 수는 없습니다. 따라서 캐시에서 성공적으로 블록을 찾는것과 캐시 사이즈 사이의 관계가 항상 일정하지 않습니다. 버퍼풀의 사이즈를 조정할 때, cache hit ratio에 영향을 주지 않는 의미없는 버퍼 추가는 피해야 합니다.


다음 그림은 물리적 I/O 비율과 버퍼 캐시 크기 간의 관계를 보여줍니다.

Description of Figure 13-1 follows

위 그림에 예시 된 예를 살펴보면 다음과 같은 결과가 나타납니다.

  • 버퍼 수가 증가하면 물리적 I/O 비율이 감소합니다.
  • 점 A와 B와 점 B와 C 사이의 물리적 I / O 감소는 그래프에서 점선으로 표시된 것처럼 매끄럽지 않습니다.
  • 지점 A에서 지점 B로 버퍼를 증가시키는 이점은 지점 B에서 지점 C으로 보다 상당히 높습니다.
  • 버퍼 크기의 지속적인 증가가 계속 늘어난다 하여도 그것이 가져오는 이익은 점점 줄어듭니다.

V$DB_CACHE_ADVICE view를 활성화 하는것에는 약간의 Overhead가 있을수 있습니다. Advisory view를 활성화하면 CPU 사용량이 약간 증가합니다. Advisory view와 관련된 CPU 및 메모리 오버 헤드를 줄이기 위해 Oracle Database는 샘플링을 사용하여 cache advisory statistics를 수집합니다. 버퍼 풀의 버퍼 수가 적으면 처음에는 샘플링이 사용되지 않습니다.

 

V$DB_CACHE_ADVICE view 사용법
  • DB_CACHE_ADVICE 초기화 매개 변수의 값을 ON으로 설정하십시오. 이 설정은 advisory view를 사용가능하게 합니다. DB_CACHE_ADVICE 파라미터는 dynamic이며, 그래서 운영중에 설정을 on/off 할 수 있습니다.
  • 운영중인 인스턴스에서 워크로드를 실행합니다. V$DB_CACHE_ADVICE view를 조회하기 전에 워크로드가 안정화 될때까지 기다려야 합니다.
  • V$DB_CACHE_ADVICE view를 조회합니다.

다음 예는 V$DB_CACHE_ADVICE view의 다양한 캐시 크기에 대한 기본 버퍼 풀에 대한 예상 I/O 요구 사항을 리턴하는 값을 조회합니다.

COLUMN size_for_estimate          FORMAT 999,999,999,999 heading 'Cache Size (MB)'
COLUMN buffers_for_estimate       FORMAT 999,999,999 heading 'Buffers'
COLUMN estd_physical_read_factor  FORMAT 999.90 heading 'Estd Phys|Read Factor'
COLUMN estd_physical_reads        FORMAT 999,999,999 heading 'Estd Phys| Reads'

SELECT size_for_estimate, buffers_for_estimate, estd_physical_read_factor,
       estd_physical_reads
FROM   V$DB_CACHE_ADVICE
WHERE  name = 'DEFAULT'
  AND  block_size = (SELECT value FROM V$PARAMETER WHERE name = 'db_block_size')
  AND  advice_status = 'ON';

이 쿼리의 결과는 다음과 같습니다.

                                Estd Phys    Estd Phys
 Cache Size (MB)      Buffers Read Factor        Reads
---------------- ------------ ----------- ------------
              30        3,802       18.70  192,317,943      10% of Current Size 
              60        7,604       12.83  131,949,536
              91       11,406        7.38   75,865,861
             121       15,208        4.97   51,111,658
             152       19,010        3.64   37,460,786
             182       22,812        2.50   25,668,196
             212       26,614        1.74   17,850,847
             243       30,416        1.33   13,720,149
             273       34,218        1.13   11,583,180
             304       38,020        1.00   10,282,475      Current Size 
             334       41,822         .93    9,515,878
             364       45,624         .87    8,909,026
             395       49,426         .83    8,495,039
             424       53,228         .79    8,116,496
             456       57,030         .76    7,824,764
             486       60,832         .74    7,563,180
             517       64,634         .71    7,311,729
             547       68,436         .69    7,104,280
             577       72,238         .67    6,895,122
             608       76,040         .66    6,739,731      200% of Current Size

위 예시에서는 캐시가 현재 크기 인 304MB 대신 212MB 인 경우 예상 물리적 읽기 수가 1.74 배 증가 함을 보여줍니다. 따라서 캐시 크기를 212MB로 줄이는 것은 좋지 않습니다.

그러나 캐시 크기를 334MB로 늘리면 잠재적으로 읽기가 0.93배  감소 할 수 있습니다. 시스템에서 추가 30MB 메모리를 사용할 수 있고 SGA_MAX_SIZE 매개 변수 값이 증가를 허용하는 경우 기본 버퍼 캐시 풀 크기를 334MB로 늘리는 것이 좋습니다.

 

Buffer Cache Hit Ratio 계산하기

Buffer Cache Hit Ratio은 디스크 액세스없이 버퍼 캐시에서 요청 된 블록을 찾은 빈도를 계산합니다. 이 비율은 V$SYSSTAT 성능보기에서 선택한 데이터를 사용하여 계산됩니다. 버퍼 캐시 적중률을 사용하여 V$DB_CACHE_ADVICE view에서 예측 한대로 물리적 I/O를 확인할 수 있습니다.

아래 테이블은 버퍼 캐시 적중률을 계산하는 데 사용 된 V $ SYSSTAT보기의 통계값을 설명합니다.

Statistic Description
consistent gets from cache 버퍼 캐시에서 블록에 대해 일관된 읽기가 요청 된 횟수.
db block gets from cache 버퍼 캐시에서 CURRENT 블록이 요청 된 횟수.
physical reads cache 디스크에서 버퍼 캐시로 읽은 총 데이터 블록 수.

V$SYSSTAT 조회

SELECT name, value
  FROM V$SYSSTAT
  WHERE name IN ('db block gets from cache', 'consistent gets from cache', 
  'physical reads cache');

V$SYSSTAT view를 이용하여 계산식을 만들어서 Buffer Cache Hit Ratio를 계산할 수 있습니다.

1 – ((‘physical reads cache’) / (‘consistent gets from cache’ + ‘db block gets from cache’))

실제로 이 계산식을 이용해 만든 쿼리입니다.

COL bcache for 999.99 HEADING 'Database Buffer Cache Hit Ratio'

select ((1-((phy.value)/(cur.value+con.value)))*100) AS bcache
  from v$sysstat cur, v$sysstat con, v$sysstat phy
  where cur.name = 'db block gets'
  and con.name = 'consistent gets'
  and phy.name='physical reads';

 

Buffer Cache Hit Ratio 해석

버퍼 캐시 크기를 늘리거나 줄 일지 결정하기 전에 먼저 버퍼 캐시 적중률을 검사해야합니다.

캐시 적중률이 낮다고해서 반드시 버퍼 캐시 크기를 늘리면 성능에 도움이된다는 의미는 아닙니다. 반대로 캐시 적중률이 높다고 해서 버퍼 캐시의 크기가 현재의 워크로드에 적합한 크기를 가진다고 할 수도 없습니다.

버퍼 캐시 적중률을 해석하려면 다음 요인을 고려해야 합니다.

  • Single pass로 처리를 수행하거나 SQL 문을 최적화하여 자주 액세스하는 데이터의 반복 스캔을 피해야합니다.
  • 동일한 큰 테이블이나 인덱스를 반복적으로 스캔하면 캐시 적중률이 인위적으로 높아질 수 있습니다. 자주 실행되고 많은 Buffer Gets를 발생하는 SQL문을 검사하여 실행 계획이 최적인지 확인해야합니다.
  • 클라이언트 프로그램 또는 중간 계층에서 자주 액세스하는 데이터를 캐싱하여 동일한 데이터를 다시 쿼리하지 않게 합니다.
  • OLTP 응용 프로그램을 실행하는 큰 데이터베이스에서는 많은 행에 한 번만 액세스하거나 액세스 하지 않게 합니다. 사용 후에 블록을 메모리에 보관할 목적이 없는 경우가 많기 때문입니다.
  • 버퍼 캐시 크기를 지속적으로 늘려서는 안됩니다. 데이터베이스가 전체 테이블 스캔을 수행하거나 버퍼 캐시를 사용하지 않는 조작을 수행하는 경우 버퍼 캐시 크기의 지속적인 증가는 성능에 영향을 미치지 않습니다.
  • 큰 테이블의  Full scan이 발생할 때 적중률이 낮은 것을 고려해야합니다.

Short table scan은 특정 크기 임계 값 아래의 small table에서 수행되는 스캔입니다. Small table에 대한 정의는 최대 Buffer Cache 사이즈의 2% 입니다.

 

Multiple Buffer Pool 설정

대부분의 시스템에는 단일 기본 버퍼 풀이 일반적으로 적합합니다. 그러나 응용 프로그램의 버퍼 풀에 대한 자세한 지식이 있는 DBA라면 Multiple buffer pool을 구성하면 도움이 될 수 있습니다.

비정형 액세스 패턴이있는 세그먼트의 경우이 세그먼트의 블록을 두 개의 별도 버퍼 풀 (KEEP Pool 및 RECYCLE Pool)에 저장하는 것이 좋습니다. 세그먼트의 액세스 패턴은 지속적으로 액세스 (때로는 Hot이라고 함)하거나 자주 액세스하지 않는 경우 (예 : 하루에 한 번 일괄 작업으로 액세스하는 큰 세그먼트)에는 비정형적일 수 있습니다.

Multiple buffer pool을 사용하면 이러한 불규칙성을 해결할 수 있습니다. KEEP Pool을 사용하여 버퍼 캐시에서 자주 액세스하는 세그먼트를 유지하고, RECYCLE Pool을 사용하여 객체가 버퍼 캐시에서 불필요한 공간을 소비하지 않도록 할 수 있습니다. 객체가 버퍼 캐시와 연결되면 해당 객체의 모든 블록이 해당 캐시에 배치됩니다. Oracle Database는 특정 버퍼 풀에 할당되지 않은 객체에 대해 DEFAULT 버퍼 풀을 유지 관리합니다. 기본 버퍼 풀 크기는 DB_CACHE_SIZE 초기화 매개 변수에 의해 결정됩니다. 각 버퍼 풀은 동일한 LRU 교체 정책을 사용합니다. 예를 들어, KEEP 풀이 할당 된 모든 세그먼트를 저장할만큼 크지 않은 경우 가장 오래된 블록이 캐시에서 만료됩니다.

적절한 버퍼 풀에 오브젝트를 할당하면 다음을 수행 할 수 있습니다.

  • I/O 감소 또는 제거
  • 객체를 별도의 캐시로 격리 또는 제한

이 섹션에서는 다중 버퍼 풀을 구성하는 방법에 대해 설명하고 다음 주제를 설명해 보도록 하겠습니다.

  • Multiple buffer pool 사용시 고려 사항
  • Multiple buffer pool 사용
  • 개별 버퍼 풀에 V $ DB_CACHE_ADVICE보기 사용
  • 개별 버퍼 풀에 대한 버퍼 풀 적중 비율 계산
  • 버퍼 캐시 사용 패턴 검사
  • KEEP 풀 구성
  • RECYCLE 풀 구성

 

Multiple buffer pool 사용시 고려 사항

Multiple buffer pool을 사용하는 경우 다음 사항을 고려해야 합니다.

  • 큰 세그먼트에 대한 Random Access.
  • Oracle Real Application Cluster 인스턴스

 

큰 세그먼트에 대한 Random Access

매우 큰 세그먼트(버퍼 캐시의 크기와 비교하여)가 크거나 제한되지 않은 인덱스 범위 스캔으로 액세스되는 경우 LRU 에이징 방법에 문제가 발생할 수 있습니다. 비 순차 물리적 읽기의 상당 부분 (10 % 이상)을 차지하는 단일 세그먼트는 매우 큰 것으로 간주 될 수 있습니다. 큰 세그먼트에 대한 Random reads는 다른 세그먼트의 데이터를 포함하는 버퍼 블록이 캐시에서 제거 될 수 있습니다. 큰 세그먼트는 많은 양의 버퍼 캐시를 소비하지만, 실제로 캐시에 상주하면서 발생하는 이점이 없습니다.

매우 자주 액세스하는 세그먼트는 버퍼가 버퍼 캐시에서 수명을 초과하지 않을 정도로 자주 예열되므로 큰 세그먼트 읽기의 영향을 받지 않습니다. 그러나 이 문제는 큰 세그먼트 읽기로 인한 버퍼 에이징을 견딜 수있을 정도로 자주 액세스하지 않는 웜 세그먼트에 영향을줍니다. 이 문제를 해결하기위한 세 가지 옵션이 있습니다.

  • 액세스 한 오브젝트가 인덱스인 경우 인덱스가 selective인지 판별하십시오. 그렇지 않은 경우 인데스를 selective으로 사용하도록 SQL 문을 조정하십시오.
  • SQL 문이 최적화되면 큰 세그먼트를 별도의 RECYCLE 캐시로 이동하여 다른 세그먼트에 영향을 미치지 않도록하십시오. RECYCLE 캐시는 DEFAULT 버퍼 풀보다 작아야하며 버퍼를 더 빠르게 재사용해야합니다.
  • Small 또는 warm 세그먼트를 큰 세그먼트에 사용되지 않는 별도의 KEEP 캐시로 이동하는 것을 고려해야합니다. 캐시에서 누락을 최소화하려면 KEEP 캐시 크기를 조정해야합니다. 쿼리에서 액세스 한 세그먼트를 KEEP 캐시에 저장하여 특정 쿼리에 대한 응답 시간을 보다 예측 가능하게하고 버퍼에서 LRU 정책에 의해 만료되어 제거되지 않도록 할 수 있습니다.

 

Oracle Real Application Cluster 인스턴스

Oracle RAC (Oracle Real Application Cluster) 환경에서 각 데이터베이스 인스턴스에 대해 Multiple buffer pool을 사용할 수 있습니다. 데이터베이스의 각 인스턴스에 대해 동일한 버퍼 풀 세트를 적용하지 않아도 상관없습니다. 각각의 인스턴스의 애플리케이션 요구 사항에 따라 각 인스턴스를 조정하면 됩니다.

 

Multiple buffer pool의 종류

Multi Buffer Pool의 Cache운영형태는 Keep, Recycle, default로 구분되어지는데 다음과 같습니다.

KEEP

요즘 많이 사용하는 In-Memory DB들과 비슷한 개념인데, 특정 재사용률이 아주 높은 Object들만 Buffer Cache에 항상 상주시키며, Access 빈도가 아주 높은 Object들에 대하여 Disk I/O를 최소화시켜 성능적인 개선을 이끌어낼수 있습니다. Keep 설정을 해두면 DB가 시작할때, 해당 데이터들을 자동으로 읽어 Buffer Cache위에 상주 시킵니다.

RECYCLE

재사용 빈도가 낮은 특정 Object들의 데이터 블럭들을 Access 후 바로 메모리에서 제거하도록 관리합니다. 따라서 Recycle 영역을 필요로 하는 다른 Object들이 언제나 즉시 필요한 Buffer를 할당 받을 수 있도록 유지합니다.

DEFAULT

기존의 단독 Buffer Cache와 동일한 관리체계를 가집니다.

 

Buffer Cache에 상주되어 있는 오브젝트 확인

모든 세그먼트가 가지는 블럭의 수를 조회하는 쿼리

COLUMN object_name FORMAT A40
COLUMN number_of_blocks FORMAT 999,999,999,999

SELECT o.object_name, COUNT(*) number_of_blocks
  FROM DBA_OBJECTS o, V$BH bh
 WHERE o.data_object_id = bh.OBJD
   AND o.owner != 'SYS'
 GROUP BY o.object_Name
 ORDER BY COUNT(*);

아래와 같은 결과 값을 보여줍니다.

OBJECT_NAME                              NUMBER_OF_BLOCKS
---------------------------------------- ----------------
OA_PREF_UNIQ_KEY                                        1
SYS_C002651                                             1
..
DS_PERSON                                              78
OM_EXT_HEADER                                         701
OM_SHELL                                            1,765
OM_HEADER                                           5,826
OM_INSTANCE                                        12,644

아래와 같은 쿼리를 통해 현재 Buffer Cache에 어떤 Object들이 상주하고 있는지 알수 있습니다.

select a.object_name "Object_Name", a.OBJECT_TYPE, round(((sum(v.cnt)*8192)/1024/1024),2) "buff_size(MB)"
from   dba_objects a,
      ( select obj,count(*) cnt
          from   x$bh
          group by obj ) v
where  a.data_object_id = v.obj
group by rollup(object_name,object_type)
order by 3;

※ 8192는 오라클 DB에 기본값으로 설정된 (8K) Block Szie입니다. 다른 값으로 변경되었다면, 마찬가지로 해당 DB에 맞게 바꿔줘야 합니다.

 

Cache 대상 테이블의 선정
  1. 프로그램 중요도
    Keep 대상 선정에 있어서 가장 중요한 부분이 바로 해당 세그먼트를 조회하는 업무 프로그램의 중요도입니다. 해당 프로그램이 중요하지 않다면 굳이 Keep Buffer를 사용해야 할 필요가 없습니다. 반대로 해당 세그먼트를 조회하는 프로그램이 중요도가 아주 높고 어떻게든 수행시간을 단축해야 한다면 프로그램 수행 빈도와 상관없이 KEEP 대상으로의 선정을 고려할 수 있습니다.
  2. 세그먼트 크기
    세그먼트 크기가 일정하지 않고, 과다하게 커지는 세그먼트는 Keep Buffer 의 효율성을 떨어뜨릴 수 있습니다. Keep된 세그먼트는 Keep Buffer의 용량이 부족하면 오래된 블록부터 Default Buffer 로 밀려나게 되는데, 크기가 계속 커지는 세그먼트가 Keep Buffer에 존재한다면 타 세그먼트를 조회하는 프로그램의 성능 저하를 가져올 수 있기 때문입니다. 따라서 일정한 사이즈 또는 변동 량이 심하지 않으면서 최대 크기가 일정 수준 이하인 경우의 세그먼트를 선정하는 것이 바람직합니다. 예를 들면 ‘최대 크기가 10 만 블록 이하인 세그먼트’ 같은 기준을 정할 수 있습니다.
  3. Full Table Scan & Index Full Scan & Index Fast Full Scan
    KEEP Buffer에 KEEP 된 세그먼트를 조회할 때 효율성을 극대화 하기 위해서는 다소 많은 량을 처리해야 하는 경우도 있습니다. Scan 범위가 넓은 비효율 Index Scan 이나 Full Table Scan, Index Fast Full Scan으로 처리되는 세그먼트가 대상이 될 수 있습니다.

 

Keep 대상 선정 SQL 쿼리
SELECT owner, 
       table_name, 
     index_name, 
     partition_name, 
     SUM(blocks) AS t_blocks
  FROM (
        SELECT sg.owner, 
               decode(SUBSTR(s.ob_type, 1, 5), 'TABLE', s.ob_name, 'INDEX', (
              SELECT table_name 
                FROM dba_indexes
                    WHERE index_name = s.ob_name
                   ) ) AS table_name, 
               decode(SUBSTR(s.ob_type, 1, 5) , 'INDEX', s.ob_name) AS index_name,
               sg.partition_name,
               sg.blocks
          FROM (
                SELECT DISTINCT object_name AS ob_name ,
                       object_type AS ob_type
                  FROM v$sql_plan
                  WHERE (operation = 'TABLE ACCESS'
                    AND options = 'FULL')
                  OR (operation = 'INDEX'
                    AND options = 'FULL SCAN')
                  OR (operation = 'INDEX'
                    AND options = 'FAST FULL SCAN')
               ) s,
               dba_segments sg
          WHERE s.ob_name = sg.segment_name
     )
  GROUP BY owner, table_name, index_name, partition_name
  HAVING SUM( blocks ) > 100000;

 

Keep Buffer Pool, Recycle Buffer Pool 적용 방법
alter table hr.employeers storage(buffer_pool keep);

alter index hr.employeers_pk storage(buffer_pool keep);

alter table hr.salary storage(buffer_pool recycle);

 

Multi Buffer Pool Monitoring

각 Pool이 가지는 Buffer Cache Hit Ratio를 조회 하는 쿼리 입니다.

SELECT name, physical_reads, db_block_gets, consistent_gets, round(((1 - (physical_reads / (db_block_gets + consistent_gets)))*100),2) "Hit Ratio%"
  FROM V$BUFFER_POOL_STATISTICS;

결과 값은 아래와 같이 나옵니다.

NAME                    Hit_Ratio
-------------    -----------------
KEEP                       95.23%
RECYCLE                    85.01%
DEFAULT                    90.01%

 

이런식으로 Multiple buffer pool를 적용하여 Disk I/O를 감소시키고, 효율적인 Buffer Cache 사용이 가능해 집니다.

 

 

 

The post Oracle Buffer Cache 튜닝과 Multiple Buffer Pool의 사용 appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/oracle-buffer-cache-%ed%8a%9c%eb%8b%9d%ea%b3%bc-multiple-buffer-pool%ec%9d%98-%ec%82%ac%ec%9a%a9/feed/ 1
WordPress Redis object cache 적용기 https://rastalion.me/wordpress-redis-object-cache-%ec%a0%81%ec%9a%a9%ea%b8%b0/ https://rastalion.me/wordpress-redis-object-cache-%ec%a0%81%ec%9a%a9%ea%b8%b0/#respond Thu, 27 Feb 2020 01:51:01 +0000 https://rastalion.me/?p=1063   WordPress Redis object cache 적용기 워드프레스는 플러그인이 많아지거나, 스킨이 무거울 경우 속도가 많이 느려지는 경우가 있습니다. 제 블로그의 스킨도 무거운 편이고, 플러그인도 제법 많아 로딩 속도를 개선하기 위해서 Redis Object Cache를 적용해 보았습니다....

The post WordPress Redis object cache 적용기 appeared first on RastaLion's IT Blog.

]]>

 

WordPress Redis object cache 적용기

워드프레스는 플러그인이 많아지거나, 스킨이 무거울 경우 속도가 많이 느려지는 경우가 있습니다. 제 블로그의 스킨도 무거운 편이고, 플러그인도 제법 많아 로딩 속도를 개선하기 위해서 Redis Object Cache를 적용해 보았습니다.

 

Redis 5.0.7 소스 설치 및 실행

wget http://download.redis.io/releases/redis-5.0.7.tar.gz
tar zxvf redis-5.0.7.tar.gz

cd redis-5.0.7

make

redis.conf 수정

redis가 host node의 메모리를 마구 가져다 쓰면 안되기 때문에 Max memory 값을 제한해 둡니다.

vi redis.conf

maxmemory  256mb
maxmemory-policy  allkeys-lfu

호스트 노드의 메모리 여유분에 따라 max값을 조정해야 합니다.

redis 구동

src/redis-server &

레디스는 백그라운드 명령없이 구동하면 세션을 지속적으로 물고 있고, 세션이 끊어지면 redis 서버가 종료됩니다. &을 붙여 백그라운드 실행을 해줍니다.

 

php에 redis 모듈 연동

기존에 php7.3을 소스 설치하여 사용중이기 때문에 yum 으로 php-redis-perl 패키지 추가가 아닌 수동으로 컴파일 하였습니다.

wget https://github.com/nicolasff/phpredis/zipball/master -O phpredis.zip
unzip phpredis.zip
cd phpredis-phpredis-c3ca003/

$PHP_HOME/php/bin/phpize
./configure --with-php-config=<$PHP_HOME>/bin/php-config
make && make install

$PHP_HOME은 php가 소스 설치되어 있는 경로 입니다. $PHP_HOME은 그대로 사용하면 안되고 본인의 php 설치 경로를 지정해야 합니다.

phpize를 먼저 실행 후 컴파일 해줍니다.

php/bin의 경로가 기본 경로가 아니기 때문에   –with-php-config 옵션을 추가 해주었습니다.

그리고 php.ini에 아래 내용을 추가 해줍니다.

vi php.ini

[redis]
extension=$PHP_HOME/lib/php/extensions/no-debug-non-zts-20180731/redis.so
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379"

php를 재구동하기 전에 워드프레스 설정파일인  wp-config.php에 아래와 같은 내용을 추가 해줍니다.

define( 'WP_CACHE_KEY_SALT', 'rastalion.me' );
define( 'WP_CACHE', true );

rastalion.me 부분에는 적용 할 블로그의 도메인을 추가 하시면 됩니다.

그리고 php-fpm 재구동

systemctl restart php-fpm

 

플러그인 설치

워드프레스 플러그인에 Redis object cache를 검색해보면 바로 나옵니다. 설치 후 활성화하고 Setting을 눌러 enable 버튼을 누르면

Connected 상태로 나오는 것을 보니 정상적으로 캐시 적용이 되었습니다.

페이지 로딩 속도의 체감이 조금은 빨라진듯 한 기분(?)이네요.

 

 

The post WordPress Redis object cache 적용기 appeared first on RastaLion's IT Blog.

]]>
https://rastalion.me/wordpress-redis-object-cache-%ec%a0%81%ec%9a%a9%ea%b8%b0/feed/ 0