[MariaDB] 보안 취약점 점검 #9 백업 & 소산

2025. 6. 18. 11:44

주의

백업 및 복구는 잘 못 하는 경우 DB에 큰 영향을 미치거나 복구가 어려운 상태를 야기 할 수 있습니다.

반드시 충분히 이해하시고 테스트 서버에서 테스트를 거친 후 상용서버에 반영하시기를 당부 드립니다.

1. 백업 플랜

RDBMS의 백업은 풀백업과 증분백업으로 구분합니다.

풀백업은 백업 시점에 지정된 데이터베이스(또는 테이블) 전체를 백업 합니다.

데이터가 많지 않다면 자주 풀백업을 하는게 제일 간단하지만, 풀백업은 서버 리소스를 많이 사용하고 시간도 오래 걸립니다.

증분백업은 풀백업 이후 변동된 사항만 백업하는 방식으로 풀백업 보다는 적은 리소스와 시간이 소요되지만 백업분을 복구 할 때 신경을 써야 하는 부분이 있습니다.

대부분 현업에서는 정기적으로 풀백업 하고 그 중간 중간 증분백업을 해서 보관하는 방식을 사용합니다.

이 글에서는 MariaDB 서버내의 전체 데이이터베이스를 대상으로 주1회 매주 월요일 새벽 4시 풀백업, 이후 매일 새벽 4시에 증분 백업을 실행하도록 해보겠습니다.

2. 백업솔루션

전통적으로 MySQL 계열은 mysqldump 명령을 사용해서 백업을 했습니다. mysqldump 방식은 데이터베이스의 구조와 데이터를 복구 할 수 있는 SQL 스크립트로 생성합니다.

백업 중 잦은 DB 조회로 인한 성능저하, 일관성 문제, 복원 속도 느림, 외래키 제약 등 대용량에 복잡한 스키마에서는 여러가지 허들이 있습니다.

이에 대한 대안으로 Percona XtraBackup을 많이 사용하지만, 아쉽게도 MySQL을 오라클에서 인수 하면서 MariaDB와 소스 관리가 분리 되었고, MariaDB 10.2 까지는 일부 기능 사용가능, 10.3 이후는 공식적으로 지원하지 않는다고 합니다.

MariaDB 진영에서는 XtraBackup의 대체로 Maria Backup을 제공하고 있고, 본 글에서는 Maria Backup을 사용하도록 하겠습니다.

XtraBackup이나 MariaBackup은 SQL 스크립트 형태가 아닌 물리적인 바이너리 형태의 DB파일들을 백업하는 방식으로 속도도 빠르고 안정적이라고 평가 하고 있습니다.(mysqldump 처럼 잦은 select로 인한 성능 저하는 적지만, 어쨌든 대량의 디스크 IO를 발생하기 때문에 상대적으로 빠른 것 이지 서버 성능에 영향이 전혀 없다고는 할 수 없습니다.)

3. MariaBackup 설치

ChatGPT에 의하면 MariaDB를 설치하면 자동으로 설치 된다고 합니다.

확인해 보았습니다.

$ sudo mariabackup --version
sudo: mariabackup: command not found
$ which mariabackup
$ sudo apt-cache policy mariadb-backup
mariadb-backup:
  Installed: (none)
  Candidate: 1:10.11.11-0+deb12u1
  Version table:
     1:10.11.11-0+deb12u1 500
        500 http://deb.debian.org/debian bookworm/main arm64 Packages
$

설치가 안되어 있습니다. 언제나 많은 도움을 받지만, 때때로 인공지능의 거짓말은 그럴 듯 합니다.

Ubuntu 는 apt install mariadb-backup 으로 설치 합니다.

CentOS, ReadHat 계열은 yum 으로 설치합니다.

$ yum install MariaDB-backup

$ sudo apt install -y mariadb-backup
... 생략 ...
$ which mariabackup
/usr/bin/mariabackup                     <== 설치된 위치
$ sudo mariabackup --version
mariabackup based on MariaDB server 10.11.11-MariaDB debian-linux-gnu (aarch64)
$

/usr/bin/mariabackup 으로 설치 되었습니다. (실제로는 /usr/bin/mariadb-backup 의 심볼릭 링크 입니다.)

MariaDB 서버 버전에 맞는 버전으로 잘 설치 되었습니다.

MariaDB [(none)]> select version();
+--------------------------------+
| version()                      |
+--------------------------------+
| 10.11.11-MariaDB-0+deb12u1-log |
+--------------------------------+
1 row in set (0.001 sec)

MariaDB [(none)]>

4. Backup 디렉토리 선정

백업을 하기 위해 디스크 공간 확보를 위해 디스크 사용 상태를 확인 합니다.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.6G     0  1.6G   0% /dev
tmpfs           380M  1.5M  379M   1% /run
/dev/mmcblk0p2  117G  7.5G  104G   7% /
tmpfs           1.9G  408K  1.9G   1% /dev/shm
tmpfs           5.0M   16K  5.0M   1% /run/lock
/dev/mmcblk0p1  510M  103M  408M  21% /boot/firmware
$

라즈베리파이 128G SD카드 공간 중 117G가 / 에 마운트 되어 있습니다.

MariaDB [(none)]> show variables like 'datadir';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.004 sec)

MariaDB [(none)]>

MariaDB 데이터 디렉토리는 /var ~ 로 역시 / 디렉토리와 같은 파티션에 존재 합니다.

백업 대상 디렉토리를 물리적인 다른 파티션에 지정 할 수 있다면 백업 실행시 디스크 I/O로 발생하는 부하가 DB I/O에 영향을 덜 줄 것 입니다. 위 구조에서는 물리적으로 같은 파티션이기 때문에 어디를 하든 차이가 없겠지만, 물리적으로 다른 디스크에 저장한다는 것을 염두에 두고 /data/backup 이라는 디렉토리를 만들고 그곳에 백업을 받도록 구성하겠습니다.

상황에 따라 물리적으로 다른 디스크를 추가 할 수 있다면 해당 경로로 마운트 해준다면 백업 작업이 DB I/O에 영향을 덜 줄 것 입니다.

디렉토리는 보안상의 목적으로 root 계정만 접근하도록 퍼미션을 구성 합니다.

$ sudo mkdir /data
$ sudo mkdir /data/backup
$ sudo chmod -R g-rwx /data    <= 하위 모두에 그룹권한 읽기, 쓰기, 실행(접근) 제거
$ sudo chmod -R o-rwx /data    <= 하위 모두에 아더권한 읽기, 쓰기, 실행(접근) 제거
$ ls -al /
total 80
drwxr-xr-x  19 root root  4096 Jun 18 14:14 .
drwxr-xr-x  19 root root  4096 Jun 18 14:14 ..
... 생략 ...
drwx------   3 root root  4096 Jun 18 14:14 data
$

root 계정만 읽기, 쓰기, 접근 권한이 허용 되었습니다.

chmod 700 으로 해도 되지만 하위에 root 소유의 일반 파일이 존재 하는 경우 실행 권한이 설정되기 때문에 마음에 들지 않아서 Group, Other 권한을 빼는 방식으로 했습니다.

참고1. 위 처럼 root (소유자) 외에 다른 계정은 접근 불가능 하게 설정 한 경우 sudo 권한이 있는 계정으로도 접근(cd)이 안됩니다.

$ sudo cd /data
sudo: cd: command not found
sudo: "cd" is a shell built-in command, it cannot be run directly.
sudo: the -s option may be used to run a privileged shell.
sudo: the -D option may be used to run a command in a specific directory.
$

su(switch user) 또는 sudo -i 로 root 계정을 완전히 획득해야 합니다.

$ sudo -i
# id
uid=0(root) gid=0(root) groups=0(root)    <= 완전히 root 계정으로 전환 되었습니다.
# cd /data/backup

이후 작업은 모두 root 권한으로 전환해서 작업하는게 편합니다. (root로 명령을 내리실 때는 시스템 안전을 위해 신중해야 합니다.)

5. Backup 계정 생성

백업 수행 할 MariaDB 계정을 생성하겠습니다.

root 계정 으로도 가능하겠지만 스크립트에 비밀번호를 넣는 부담도 있고

백업은 Read Only 권한 중 일부 만 있어도 되기 때문에 localhost 에서만 접속 가능한 백업 전용 계정을 생성하고 권한을 부여하였습니다.

MariaDB [(none)]> CREATE USER 'mariabackup'@'localhost' IDENTIFIED BY '보안삭제';
Query OK, 0 rows affected (0.019 sec)

MariaDB [(none)]> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'mariabackup'@'localhost';
Query OK, 0 rows affected (0.004 sec)

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]>

6. Backup 테스트

/data/backup/full_test 에 현재 기준으로 풀백업을 받는 명령 입니다.

# mariabackup --backup --user=mariabackup --password='보안삭제' --no-lock --target-dir=/data/backup/full_test
... 생략 ...
[00] 2025-06-18 17:31:19 Start copying aria log file tail: /var/lib/mysql//aria_log.00000001
[00] 2025-06-18 17:31:19 Stop copying aria log file tail: /var/lib/mysql//aria_log.00000001, copied 0 bytes
mariabackup: Can't find file: './ddl.log' (errno: 2 "No such file or directory")
[00] 2025-06-18 17:31:19 DDL log file ./ddl.log open failed: 2
... 생략 ...
[00] 2025-06-18 17:31:24 completed OK!
#

중간에 ddl.log 파일이 없다는 메시지가 나옵니다. 이것은 DDL(테이블 생성/변경 등)을 추적하는 로그로, DDL 변경이 없거나 서버 설정 ( innodb_ddl_log_crash_recovery=OFF) 인경우 파일이 생성되지 않으며, 없어도 백업에는 영향이 없다고 합니다.

[00] 2025-06-18 17:31:24 completed OK!

이 메시지가 나오면 정상 백업이 된 것으로 보면 됩니다.

다음은 백업이 완료 되면 백업 데이터를 검증하고 복원 준비 상태로 만드는 명령입니다.

# mariabackup --prepare --no-lock --target-dir=/data/backup/full_test
... 생략 ...
[00] 2025-06-18 17:31:36 completed OK!
#

복원 준비 하는 prepare 명령 의미상 백업을 복구 할 시점에서 하는게 좋을 수도 있다고 생각할 수도 있지만

백업을 수행한 이후 즉시 수행하는게 좋다고 합니다.

백업 확인

# ls -al
total 12
drwx------ 3 root root 4096 Jun 18 17:31 .
drwx------ 4 root root 4096 Jun 18 17:14 ..
drwx------ 7 root root 4096 Jun 18 17:31 full_test
# ls -al full_test
total 12776
drwx------ 7 root root     4096 Jun 18 17:31 .
drwx------ 3 root root     4096 Jun 18 17:31 ..
drwx------ 2 root root     4096 Jun 18 17:31 arcade
-rw-r----- 1 root root   425984 Jun 18 17:31 aria_log.00000001
-rw-r----- 1 root root       52 Jun 18 17:31 aria_log_control
-rw-r----- 1 root root      501 Jun 18 17:31 backup-my.cnf
drwx------ 2 root root     4096 Jun 18 17:31 evmate
-rw-r----- 1 root root 12582912 Jun 18 17:31 ibdata1
-rw-r----- 1 root root    12304 Jun 18 17:31 ib_logfile0
drwx------ 2 root root     4096 Jun 18 17:31 mysql
drwx------ 2 root root     4096 Jun 18 17:31 performance_schema
drwx------ 2 root root    12288 Jun 18 17:31 sys
-rw-r--r-- 1 root root        3 Jun 18 17:31 xtrabackup_binlog_pos_innodb
-rw-r----- 1 root root       97 Jun 18 17:31 xtrabackup_checkpoints
-rw-r----- 1 root root      497 Jun 18 17:31 xtrabackup_info
#

mysql 디렉토리랑 비슷한 내용들이 복사 되었습니다.

이것을 날짜 별로 압축해서 보관 하면 될 것 같습니다.

7. Backup 스크립트 작성

위 내용을 기반해서 스크립트를 만들어 Github 에 올려 놓았습니다.

https://github.com/basscraft/mariabackup/tree/main

GitHub - basscraft/mariabackup

Contribute to basscraft/mariabackup development by creating an account on GitHub.

github.com

mariabackup.sh : 실행 시점 기준으로 백업
deletebackup.sh : 생성된지 20일이 지난 백업 디렉토리 삭제

자세한 내용은 소스 내용을 살펴 보시고 로직을 충분히 숙지 하시고 적용하시기 바랍니다.

백업을 진행하기 위해 /data/backup 에 스크립트를 다운 받습니다.

# cd /data/backup
# wget https://raw.githubusercontent.com/basscraft/mariabackup/main/mariabackup.sh

위에서 생성한 백업 계정으로 계정, 비번을 변경 합니다.

#!/bin/bash

# 백업 계정 (MariaDB)
export BACKUP_USER_ID="mariabackup"
export BACKUP_USER_PASSWORD="보안삭제"

... 생략 ...

BACKUP_USER_ID 와 BACKUP_USER_PASSWORD를 생성한 계정에 맞게 수정하시면 됩니다.

소유자에게 실행 권한을 부여하고 Gourp, Other 에서 접근 못 하도록 퍼미션을 조정합니다.

# chmod 700 mariabackup.sh
# ls -al
total 16
drwx------ 2 root root 4096 Jun 18 18:47 .
drwx------ 4 root root 4096 Jun 18 17:14 ..
-rwx------ 1 root root 4770 Jun 18 18:44 mariabackup.sh
#

풀 백업 테스트

# ./mariabackup.sh
[2025-06-18 19:12:56] Start full backup raspberrypi_full_202524_20250618_191256 to raspberrypi_full_202524
[2025-06-18 19:13:05] Start full backup prepareing to raspberrypi_full_202524_20250618_191256
[2025-06-18 19:13:05] Compress Backup raspberrypi_full_202524 to raspberrypi_full_202524_20250618_191256.tar.gz
[2025-06-18 19:13:06] Backup Complate raspberrypi_full_202524_20250618_191256
#

Backup Complate 메시지가 떨어지면 정상 백업이 완료된 것입니다.

풀 백업 확인

# ls -al
total 20
drwx------ 3 root root 4096 Jun 18 19:12 .
drwx------ 4 root root 4096 Jun 18 17:14 ..
-rwx------ 1 root root 4772 Jun 18 19:12 mariabackup.sh
drwxr-xr-x 4 root root 4096 Jun 18 19:13 raspberrypi
#

/data/backup 하위에 호스트명에 해당하는 디렉토리가 생겼습니다.(라즈베리파이라 호스트 명이 raspberrypi로 되어 있습니다.)

향후에 이곳에 계속 백업이 생성됩니다.

# ls -al raspberrypi/
total 728
drwxr-xr-x 4 root root   4096 Jun 18 19:13 .
drwx------ 3 root root   4096 Jun 18 19:12 ..
drwxr-xr-x 2 root root   4096 Jun 18 19:12 logs
drwx------ 7 root root   4096 Jun 18 19:13 raspberrypi_full_202524
-rw-r--r-- 1 root root 728214 Jun 18 19:13 raspberrypi_full_202524.tar.gz
#

logs : 호스트명 디렉토리 하위에 logs 디렉토리에는 백업 스크립트가 실행 될 때 마다 로그가 쌓입니다.
- {호스트명}_{ full / incormental}_{연도주차}_{시분초}.log 형태의 간단한 로그 파일이 생성됩니다.
- 백업이 제대로 실행되지 않았을 때 이 파일을 확인해 보셔야 합니다.
raspberrypi_full_202524 : {호스트명}_full_202524 디렉토리는 2025년 24주차 최초로 받은 풀백업이라는 의미 입니다.
- 실행 되는 시점의 주차에 풀백업이 존재하지 않으면 풀백업, 이미 존재하면 증분 백업을 수행하도록 스크립트가 구성되어 있습니다.(디렉토리 명명 규칙으로 체크 하므로 명명 규칙을 변경하시면 스크립트를 수정하셔야 합니다.)
- 실행 주차의 풀백업을 기준으로 증분 백업을 수행합니다.
raspberrypi_full_202524.tar.gz : {호스트명}_full_202524.tar.gz 은 실행 주차에 최초로 받은 풀 백업을 압축한 파일입니다.

증분 백업 테스트

202524주차에 풀백업을 수행 했으므로 다시 mariabackup.sh 를 실행하면 풀백업을 기준으로 증분백업을 수행합니다.

# cd /data/backup
# ./mariabackup.sh
[2025-06-18 19:32:50] Start incremental backup raspberrypi_incremental_202524_20250618_193250 for raspberrypi_full_202524
[2025-06-18 19:32:56] Start incremental prepareing raspberrypi_incremental_202524_20250618_193250 to raspberrypi_full_202524
[2025-06-18 19:32:57] Compress incremental Backup raspberrypi_incremental_202524_20250618_193250.tar.gz
[2025-06-18 19:32:57] Remove incremental Backup directory /data/backup/raspberrypi/raspberrypi_incremental_202524_20250618_193250
[2025-06-18 19:32:57] Compress incremented full Backup raspberrypi_full_202524 to raspberrypi_full_202524_incremented_20250618_193250.tar.gz
[2025-06-18 19:32:58] Backup Complate raspberrypi_incremental_202524_20250618_193250
#

Backup Complate {호스트명}_incremental_{년도주차}_{년월일}_{시분초} 로그가 보이면 정상적으로 증분 백업을 마친 것 입니다.

증분 백업 확인

# ls -al raspberrypi/
total 2100
drwxr-xr-x 4 root root   4096 Jun 18 19:32 .
drwx------ 3 root root   4096 Jun 18 19:12 ..
drwxr-xr-x 2 root root   4096 Jun 18 19:32 logs
drwx------ 7 root root   4096 Jun 18 19:32 raspberrypi_full_202524
-rw-r--r-- 1 root root 728128 Jun 18 19:32 raspberrypi_full_202524_incremented_20250618_193250.tar.gz
-rw-r--r-- 1 root root 728214 Jun 18 19:13 raspberrypi_full_202524.tar.gz
-rw-r--r-- 1 root root 675287 Jun 18 19:32 raspberrypi_incremental_202524_20250618_193250.tar.gz
#

기존 파일들 외에 추가된 파일

raspberrypi_full_202524 : 현재 실행한 증분 백업 까지 반영된 백업 디렉토리 입니다.
raspberrypi_full_202524_incremented_20250618_193250.tar.gz : 현재 주차 마지막 풀 백업에 현재 실행한 증분 백업이 추가된 백업 파일입니다. (위 디렉토리를 압축 한 것으로 생각하시면 됩니다.)
raspberrypi_full_202524 .tar.gz : 현재 주차에 최초 생성된 풀백업 압축 파일 입니다.(변동 없음)
raspberrypi_incremental_202524_20250618_193250.tar.gz : 현재 실행한 증분 백업 압축 파일 입니다.

오래된 백업 삭제

계속 백업을 쌓기만 하다 보면 매주 1회 풀백업, 일간 증분백업 파일이 쌓이면서 디스크 공간 낭비가 심해 집니다.

서비스 마다 백업 데이터 보관 정책대로 주간 풀백업은 소산보관 후 오래된 백업을 삭제 해주는게 좋습니다.

소산 보관 역시 스크립트를 작성하여 자동으로 복사 하도록 하면 됩니다. 여기서는 다루지 않겠습니다.

오래된 백업 파일 삭제는 생성한지 20일 기준으로 오래된 백업을 삭제 하는 스크립트 입니다.

https://github.com/basscraft/mariabackup/tree/main

GitHub - basscraft/mariabackup

Contribute to basscraft/mariabackup development by creating an account on GitHub.

github.com

mariabackup.sh : 실행 시점 기준으로 백업
deletebackup.sh : 생성된지 20일이 지난 백업 디렉토리 삭제

# cd /data/backup
# wget https://raw.githubusercontent.com/basscraft/mariabackup/main/deletebackup.sh
# chmod 700 deletebackup.sh
# ls -al
total 24
drwx------ 3 root root 4096 Jun 18 19:57 .
drwx------ 4 root root 4096 Jun 18 17:14 ..
-rwx------ 1 root root  440 Jun 18 19:57 deletebackup.sh
-rwx------ 1 root root 4772 Jun 18 19:12 mariabackup.sh
drwxr-xr-x 4 root root 4096 Jun 18 19:32 raspberrypi
#

참고 : 백업으로 생성된 파일/디렉토리 들이 root 의 umask 값에 영향을 받아서 그룹, 아더에 r_x 권한으로 생성 된것이 보입니다.

처음 부터 그대로 하셨다면 상위 디렉토리 인 /data 와 /data/backup 디렉토리가 root 에게만 접근 허용되어 있기 때문에 큰 문제는 없지만, 보기 싫어서 백업 최상위 디렉토리인 호스트명의 디렉토리라도 퍼미션을 제거 하는게 좋겠습니다.

# chmod 700 raspberrypi
# ls -al
total 24
drwx------ 3 root root 4096 Jun 18 19:57 .
drwx------ 4 root root 4096 Jun 18 17:14 ..
-rwx------ 1 root root  440 Jun 18 19:57 deletebackup.sh
-rwx------ 1 root root 4772 Jun 18 19:12 mariabackup.sh
drwx------ 4 root root 4096 Jun 18 19:32 raspberrypi
#

8. 크론텝 등록

최초에 정한 백업 플랜 대로 테스트 한 스크립트를 root 계정의 크론텝에 등록 하겠습니다.

매일 새벽 3시에 생성된지 20일이 지난 백업 삭제
매주 월요일 새벽 4시에 풀백업
일주일간 매일 새벽 4시에 증분 백업

플랜입니다.

# crontab -e
... 생략 ...
0 3 * * * /data/backup/deletebackup.sh >> /data/backup/logs/mariabackup.log 2>&1
0 4 * * * /data/backup/mariabackup.sh >> /data/backup/logs/mariabackup.log 2>&1
... 생략 ...

크론 텝에는 요일, 풀백업 구분이 없이 매일 새벽 4시에 실행만 하면 mariabackup.sh 에서 알아서 해당 주차에 풀백업이 없으면 풀백업, 풀백업이 있으면 증분백업을 수행하도록 되어 있습니다.

/data/backup/logs/mariabackup.log 파일에는 크론텝에서 쉘스크립트가 실행되면서 발생하는 로그가 쌓이게 되어 있습니다.

새벽에 백업이 잘 실행 되었는지 확인하는 용도 입니다.

위에 등록한 크론텝 명령으로는 자동으로 파일과 디렉토리를 생성하지 못하므로 미리 생성하겠습니다.

# mkdir /data/backup/logs
# cat /dev/null > mariabackup.log
# chmod g-rwx /data/backup/logs -R
# chmod o-rwx /data/backup/logs -R
# ls -alR /data/backup/logs
/data/backup/logs:
total 12
drwx------ 2 root root 4096 Jun 19 12:16 .
drwx------ 4 root root 4096 Jun 19 12:15 ..
-rw------- 1 root root  756 Jun 19 12:23 mariabackup.log
#

위 부터 순서대로

/data/backup 아래에 logs 디렉토리 생성

/data/backup/logs 아래에 빈 파일 mariabackup.log 생성

/data/backup/logs 하위 모든 파일/디렉토리에 group 권한 제거

/data/backup/logs 하위 모든 파일 /디렉토리에 other 권한 제거

/data/backup/logs 하위 디렉토리 리스트 및 퍼미션 확인

정상적으로 크론이 동작 하면 mairabackup.log 파일에 아래와 같은 로그가 생성 됩니다.

[2025-06-20 03:00:01] Old backup delete complete
[2025-06-20 04:00:01] Start incremental backup raspberrypi_incremental_202524_20250620_040001 for raspberrypi_full_202524
[2025-06-20 04:00:07] Start incremental prepareing raspberrypi_incremental_202524_20250620_040001 to raspberrypi_full_202524
[2025-06-20 04:00:08] Compress incremental Backup raspberrypi_incremental_202524_20250620_040001.tar.gz
[2025-06-20 04:00:08] Remove incremental Backup directory /data/backup/raspberrypi/raspberrypi_incremental_202524_20250620_040001
[2025-06-20 04:00:08] Compress incremented full Backup raspberrypi_full_202524 to raspberrypi_full_202524_incremented_20250620_040001.tar.gz
[2025-06-20 04:00:09] Backup Complate raspberrypi_incremental_202524_20250620_040001

여기까지 수고 하셨습니다..

끝.

저작자표시 (새창열림)

'DataBase' 카테고리의 다른 글

[MySQL, MariaDB] 최초 설치 후 외부 접속 시 Connection refused: getsockopt 발생하는 경우 체크 (0)	2025.06.02
[AWS] MariaDB RDS - Spring Boot 'Error: 1040-08004: Too many connections' 처리 (0)	2025.05.31
[AWS] RDS - MySQL/MariaDB 테이블 명 대소문자 구분(lower_case_table_names) 문제 (0)	2025.04.30
[MariaDB] 보안 취약점 점검 #8 감사 로그 관리 (0)	2025.03.13
[MariaDB] 보안 취약점 점검 #7 감사 정책 준비 (0)	2025.03.01

Open Source Developer

Category

Menu

Recent Comments