데이터베이스 서버 구성 및 사용

프로세스

1. /etc/pki/tls/certs/ 디렉터리에 CA 및 서버 인증서를 저장합니다.

   # mv <path>/server.example.com.crt.pem /etc/pki/tls/certs/
   # mv <path>/ca.crt.pem /etc/pki/tls/certs/

2. MariaDB 서버가 파일을 읽을 수 있도록 하는 CA 및 서버 인증서에 대한 권한을 설정합니다.

   # chmod 644 /etc/pki/tls/certs/server.example.com.crt.pem /etc/pki/tls/certs/ca.crt.pem

   인증서는 보안 연결이 설정되기 전에 통신의 일부이므로 모든 클라이언트는 인증 없이 이를 검색할 수 있습니다. 따라서 CA 및 서버 인증서 파일에 대한 엄격한 권한을 설정할 필요가 없습니다.

3. 서버의 개인 키를 /etc/pki/tls/private/ 디렉터리에 저장합니다.

   # mv <path>/server.example.com.key.pem /etc/pki/tls/private/

4. 서버의 개인 키에 대한 보안 권한을 설정합니다.

   # chmod 640 /etc/pki/tls/private/server.example.com.key.pem
   # chgrp mysql /etc/pki/tls/private/server.example.com.key.pem

   권한이 없는 사용자가 개인 키에 액세스할 수 있는 경우 MariaDB 서버에 대한 연결이 더 이상 안전하지 않습니다.

5. SELinux 컨텍스트를 복원합니다.

   #  restorecon -Rv /etc/pki/tls/

프로세스

1. /etc/my.cnf.d/mariadb-server-tls.cnf 파일을 만듭니다.

   1. 다음 콘텐츠를 추가하여 개인 키, 서버 및 CA 인증서에 대한 경로를 구성합니다.

      [mariadb]
      ssl_key = /etc/pki/tls/private/server.example.com.key.pem
      ssl_cert = /etc/pki/tls/certs/server.example.com.crt.pem
      ssl_ca = /etc/pki/tls/certs/ca.crt.pem

   2. CRL(Certificate Revocation List)이 있는 경우 이를 사용하도록 MariaDB 서버를 구성합니다.

      ssl_crl = /etc/pki/tls/certs/example.crl.pem

   3. 선택 사항: 암호화 없이 연결 시도를 제거합니다. 이 기능을 활성화하려면 다음을 추가합니다.

      require_secure_transport = on

   4. 선택 사항: 서버가 지원해야 하는 TLS 버전을 설정합니다. 예를 들어 TLS 1.2 및 TLS 1.3을 지원하려면 다음을 추가합니다.

      tls_version = TLSv1.2,TLSv1.3

      기본적으로 서버는 TLS 1.1, TLS 1.2 및 TLS 1.3을 지원합니다.

2. mariadb 서비스를 다시 시작합니다.

   # systemctl restart mariadb

1. MariaDB에 TLS 암호화가 활성화되어 있는지 확인합니다.

   # mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'have_ssl';"
   +---------------+-----------------+
   | Variable_name | Value           |
   +---------------+-----------------+
   | have_ssl      | YES             |
   +---------------+-----------------+

   have_ssl 변수가 yes 로 설정되면 TLS 암호화가 활성화됩니다.

2. 특정 TLS 버전만 지원하도록 MariaDB 서비스를 구성한 경우 tls_version 변수를 표시합니다.

   # mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'tls_version';"
   +---------------+-----------------+
   | Variable_name | Value           |
   +---------------+-----------------+
   | tls_version   | TLSv1.2,TLSv1.3 |
   +---------------+-----------------+

프로세스

1. 관리 사용자로 MariaDB 서버에 연결합니다.

   # mysql -u root -p -h server.example.com

   관리 사용자에게 원격으로 서버에 액세스할 수 있는 권한이 없는 경우 MariaDB 서버에서 명령을 수행하고 localhost 에 연결합니다.

2. REQUIRE SSL 절을 사용하여 사용자가 TLS 암호화 연결을 사용하여 연결해야 합니다.

   MariaDB [(none)]> ALTER USER 'example'@'%' REQUIRE SSL;

검증

1. TLS 암호화를 사용하여 서버에 예제 사용자로 연결합니다.

   # mysql -u example -p -h server.example.com --ssl
   ...
   MariaDB [(none)]>

   오류가 표시되지 않고 대화형 MariaDB 콘솔에 액세스할 수 있는 경우 TLS와의 연결에 성공합니다.

2. TLS가 비활성화된 사용자로 연결을 시도합니다.

   # mysql -u example -p -h server.example.com --skip-ssl
   ERROR 1045 (28000): Access denied for user 'example'@'server.example.com' (using password: YES)

   이 사용자에게는 TLS가 필요하지만 비활성화됨(--skip-ssl)이므로 서버에서 로그인 시도를 거부했습니다.

프로세스

1. 복원할 데이터베이스가 이미 존재하고 SQL 파일에 DROP Cryostat IF EXISTS 문이 포함되어 있지 않은 경우 테이블 또는 전체 데이터베이스를 수동으로 제거해야 합니다.

   • 테이블을 제거하려면 다음을 입력합니다.

     # mariadb -u root -p -e "DROP TABLE <database>.<table>;"

     SQL 파일이 다시 생성될 모든 테이블에 대해 이 명령을 반복합니다.

   • 데이터베이스를 제거하려면 다음을 입력합니다.

     # mariadb -u root -p -e "DROP DATABASE <database>;"

     SQL 파일이 다시 생성될 모든 데이터베이스에 대해 이 명령을 반복합니다.

2. SQL 파일을 가져옵니다.

   # mariadb -u root -p < backup.sql"

프로세스

1. 다음 옵션 중 하나를 사용하여 데이터를 복원합니다.

   • /var/mariadb/backup/ 디렉터리의 백업 데이터를 복원하고 원래 백업 파일을 유지하려면 다음을 입력합니다.

     $ mariabackup --copy-back --target-dir=/var/mariadb/backup/

   • /var/mariadb/backup/ 디렉터리의 백업 데이터를 복원하고 원래 백업 파일을 제거하려면 다음을 입력합니다.

     $ mariabackup --move-back --target-dir=/var/mariadb/backup/

2. 파일 권한을 수정합니다. 예를 들어 파일의 소유권을 mysql 사용자 및 그룹으로 재귀적으로 변경하려면 다음을 입력합니다.

   # chown -R mysql:mysql /var/lib/mysql/

   데이터베이스를 복원할 때 mariabackup 은 백업의 파일 및 디렉터리 권한을 유지합니다. 그러나 mariabackup 은 데이터베이스를 복원하는 사용자 및 그룹으로 파일을 디스크에 씁니다. 따라서 백업을 복원한 후 MariaDB 서버의 사용자 및 그룹과 일치하도록 데이터 디렉터리의 소유자를 조정해야 합니다.

3. mariadb 서비스를 시작합니다.

   # systemctl start mariadb.service

프로세스

1. mariadb 서비스를 중지합니다.

   # systemctl stop mariadb.service

2. 백업 디렉터리를 생성합니다. 예를 들면 다음과 같습니다.

   # mkdir -p /root/mariadb-backup/{data,config}/

3. 데이터 디렉터리를 백업합니다.

   # cp -rp /var/lib/mysql/ /root/mariadb-backup/data/

4. 구성 파일을 백업합니다.

   # cp -rp /etc/my.cnf /etc/my.cnf.d/ /root/mariadb-backup/config/

5. mariadb 서비스를 시작합니다.

   # systemctl start mariadb.service

프로세스

1. mariadb 서비스를 중지합니다.

   # systemctl stop mariadb.service

2. 현재 /var/lib/mysql/ 디렉터리를 제거합니다.

   # rm -rf /var/lib/mysql/

3. 백업에서 data 디렉토리를 복원합니다.

   # cp -rp /root/mariadb-backup/data/mysql/ /var/lib/

4. /var/lib/mysql/ 디렉터리의 올바른 소유권을 확인합니다.

   # chown -R mysql:mysql /var/lib/mysql/

5. /var/lib/mysql/ 디렉터리의 SELinux 컨텍스트를 복원합니다.

   # restorecon -Rv /var/lib/mysql/

6. 현재 구성 파일을 제거합니다.

   # rm -rf /etc/my.cnf /etc/my.cnf.d/

7. 백업에서 구성 파일을 복원합니다.

   # cp -rp /root/mariadb-backup/config/my.cnf /root/mariadb-backup/config/my.cnf.d/ /etc/

8. 구성 파일의 올바른 소유권을 확인합니다.

   # chown -R root:root /etc/my.cnf /etc/my.cnf.d/

9. 구성 파일의 SELinux 컨텍스트를 복원합니다.

   # restorecon -Rv /etc/my.cnf /etc/my.cnf.d/

10. mariadb 서비스를 시작합니다.

    # systemctl start mariadb.service

프로세스

1. MariaDB Galera 클러스터 패키지를 설치합니다.

   # dnf install mariadb-server-galera

   결과적으로 다음 패키지가 해당 종속 항목과 함께 설치됩니다.

   • mariadb-server-galera
   • mariadb-server

   • galera

     MariaDB Galera Cluster를 빌드하는 데 필요한 이러한 패키지에 대한 자세한 내용은 MariaDB 클러스터를 빌드하는 구성 요소를 참조하십시오.

2. 시스템을 클러스터에 처음 추가하기 전에 MariaDB 서버 복제 구성을 업데이트합니다. 기본 구성은 /etc/my.cnf.d/galera.cnf 파일에 배포됩니다. MariaDB Galera 클러스터를 배포하기 전에 다음 문자열로 시작하도록 모든 노드의 /etc/my.cnf.d/galera.cnf 파일에서 wsrep_cluster_address 옵션을 설정합니다.

   gcomm://

   • 초기 노드의 경우 wsrep_cluster_address 를 빈 목록으로 설정할 수 있습니다.

     wsrep_cluster_address="gcomm://"

   • 다른 모든 노드의 경우 wsrep_cluster_address 를 설정하여 이미 실행 중인 클러스터의 일부인 모든 노드의 주소를 포함합니다. 예를 들면 다음과 같습니다.

     wsrep_cluster_address="gcomm://10.0.0.10"

     Galera Cluster 주소를 설정하는 방법에 대한 자세한 내용은 Galera Cluster Address 를 참조하십시오.

3. /etc/my.cnf.d/galera.cnf 구성 파일에서 wsrep _on=1 옵션을 설정하여 모든 노드에서 wsrep API를 활성화합니다.

4. TLS 키 및 인증서를 사용하여 Galera 구성 파일에 wsrep_provider_options 변수를 추가합니다. 예를 들면 다음과 같습니다.

   wsrep_provider_options="socket.ssl_cert=/etc/pki/tls/certs/source.crt;socket.ssl_key=/etc/pki/tls/private/source.key;socket.ssl_ca=/etc/pki/tls/certs/ca.crt"

5. 해당 노드에서 다음 래퍼를 실행하여 새 클러스터의 첫 번째 노드를 부트스트랩합니다.

   # galera_new_cluster

   이 래퍼를 사용하면 MariaDB 서버 데몬(mariadbd)이 --wsrep-new-cluster 옵션으로 실행됩니다. 이 옵션은 연결할 기존 클러스터가 없다는 정보를 제공합니다. 따라서 노드는 새 클러스터를 식별하기 위해 새 UUID를 생성합니다.

   참고

   mariadb 서비스는 여러 MariaDB 서버 프로세스와 상호 작용하는 systemd 방법을 지원합니다. 따라서 실행 중인 여러 MariaDB 서버가 있는 경우 인스턴스 이름을 접미사로 지정하여 특정 인스턴스를 부트스트랩할 수 있습니다.

   # galera_new_cluster mariadb@node1

6. 각 노드에서 다음 명령을 실행하여 다른 노드를 클러스터에 연결합니다.

   # systemctl start mariadb

   결과적으로 노드는 클러스터에 연결하고 클러스터 상태와 자체적으로 동기화됩니다.

프로세스

1. /etc/pki/tls/certs/ 디렉터리에 CA 및 서버 인증서를 저장합니다.

   # mv <path>/server.example.com.crt.pem /etc/pki/tls/certs/
   # mv <path>/ca.crt.pem /etc/pki/tls/certs/

2. MySQL 서버가 파일을 읽을 수 있도록 하는 CA 및 서버 인증서에 대한 권한을 설정합니다.

   # chmod 644 /etc/pki/tls/certs/server.example.com.crt.pem /etc/pki/tls/certs/ca.crt.pem

   인증서는 보안 연결이 설정되기 전에 통신의 일부이므로 모든 클라이언트는 인증 없이 이를 검색할 수 있습니다. 따라서 CA 및 서버 인증서 파일에 대한 엄격한 권한을 설정할 필요가 없습니다.

3. 서버의 개인 키를 /etc/pki/tls/private/ 디렉터리에 저장합니다.

   # mv <path>/server.example.com.key.pem /etc/pki/tls/private/

4. 서버의 개인 키에 대한 보안 권한을 설정합니다.

   # chmod 640 /etc/pki/tls/private/server.example.com.key.pem
   # chgrp mysql /etc/pki/tls/private/server.example.com.key.pem

   권한이 없는 사용자가 개인 키에 액세스할 수 있는 경우 MySQL 서버에 대한 연결이 더 이상 안전하지 않습니다.

5. SELinux 컨텍스트를 복원합니다.

   # restorecon -Rv /etc/pki/tls/

프로세스

1. /etc/my.cnf.d/mysql-server-tls.cnf 파일을 만듭니다.

   1. 다음 콘텐츠를 추가하여 개인 키, 서버 및 CA 인증서에 대한 경로를 구성합니다.

      [mysqld]
      ssl_key = /etc/pki/tls/private/server.example.com.key.pem
      ssl_cert = /etc/pki/tls/certs/server.example.com.crt.pem
      ssl_ca = /etc/pki/tls/certs/ca.crt.pem

   2. CRL(Certificate Revocation List)이 있는 경우 이를 사용하도록 MySQL 서버를 구성합니다.

      ssl_crl = /etc/pki/tls/certs/example.crl.pem

   3. 선택 사항: 암호화 없이 연결 시도를 제거합니다. 이 기능을 활성화하려면 다음을 추가합니다.

      require_secure_transport = on

   4. 선택 사항: 서버가 지원해야 하는 TLS 버전을 설정합니다. 예를 들어 TLS 1.3만 지원하려면 다음을 추가합니다.

      tls_version = TLSv1.3

      기본적으로 서버는 TLS 1.2 및 TLS 1.3을 지원합니다.

2. mysqld 서비스를 다시 시작합니다.

   # systemctl restart mysqld

1. 이제 MySQL에 TLS 암호화가 활성화되어 있는지 확인합니다.

   # mysql -u root -p -h <MySQL_server_hostname> -e "SHOW session status LIKE 'Ssl_cipher';"
   +---------------+------------------------+
   | Variable_name | Value                  |
   +---------------+------------------------+
   | Ssl_cipher    | TLS_AES_256_GCM_SHA384 |
   +---------------+------------------------+

2. 특정 TLS 버전만 지원하도록 MySQL 서버를 구성한 경우 tls_version 변수를 표시합니다.

   # mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'tls_version';"
   +---------------+---------+
   | Variable_name | Value   |
   +---------------+---------+
   | tls_version   | TLSv1.3 |
   +---------------+---------+

3. 서버가 올바른 CA 인증서, 서버 인증서 및 개인 키 파일을 사용하는지 확인합니다.

   # mysql -u root -e "SHOW GLOBAL VARIABLES WHERE Variable_name REGEXP '{caret}ssl_ca|{caret}ssl_cert|{caret}ssl_key';"
   +-----------------+-------------------------------------------------+
   | Variable_name   | Value                                           |
   +-----------------+-------------------------------------------------+
   | ssl_ca          | /etc/pki/tls/certs/ca.crt.pem                   |
   | ssl_capath      |                                                 |
   | ssl_cert        | /etc/pki/tls/certs/server.example.com.crt.pem   |
   | ssl_key         | /etc/pki/tls/private/server.example.com.key.pem |
   +-----------------+-------------------------------------------------+

프로세스

1. 관리 사용자로 MySQL 서버에 연결합니다.

   # mysql -u root -p -h server.example.com

   관리 사용자에게 원격으로 서버에 액세스할 수 있는 권한이 없는 경우 MySQL 서버에서 명령을 수행하고 localhost 에 연결합니다.

2. REQUIRE SSL 절을 사용하여 사용자가 TLS 암호화 연결을 사용하여 연결해야 합니다.

   MySQL [(none)]> ALTER USER 'example'@'%' REQUIRE SSL;

검증

1. TLS 암호화를 사용하여 서버에 예제 사용자로 연결합니다.

   # mysql -u example -p -h server.example.com
   ...
   MySQL [(none)]>

   오류가 표시되지 않고 대화형 MySQL 콘솔에 액세스할 수 있는 경우 TLS와의 연결에 성공합니다.

   기본적으로 클라이언트는 서버에서 제공하는 경우 TLS 암호화를 자동으로 사용합니다. 따라서 --ssl-ca=ca.crt.pem 및 --ssl-mode=VERIFY_IDENTITY 옵션은 필요하지 않지만 이러한 옵션을 사용하여 클라이언트는 서버 ID를 확인하므로 보안을 개선합니다.

2. TLS가 비활성화된 사용자로 연결을 시도합니다.

   # mysql -u example -p -h server.example.com --ssl-mode=DISABLED
   ERROR 1045 (28000): Access denied for user 'example'@'server.example.com' (using password: YES)

   이 사용자에게는 TLS가 필요하지만 비활성화됨(--ssl-mode=DISABLED)이므로 서버에서 로그인 시도를 거부했습니다.

프로세스

1. 복원할 데이터베이스가 이미 존재하고 SQL 파일에 DROP Cryostat IF EXISTS 문이 포함되어 있지 않은 경우 테이블 또는 전체 데이터베이스를 수동으로 제거해야 합니다.

   • 테이블을 제거하려면 다음을 입력합니다.

     # mysql -u root -p -e "DROP TABLE <database>.<table>;"

     SQL 파일이 다시 생성될 모든 테이블에 대해 이 명령을 반복합니다.

   • 데이터베이스를 제거하려면 다음을 입력합니다.

     # mysql -u root -p -e "DROP DATABASE <database>;"

     SQL 파일이 다시 생성될 모든 데이터베이스에 대해 이 명령을 반복합니다.

2. SQL 파일을 가져옵니다.

   # mysql -u root -p < backup.sql"

프로세스

1. mysqld 서비스를 중지합니다.

   # systemctl stop mysqld.service

2. 백업 디렉터리를 생성합니다. 예를 들면 다음과 같습니다.

   # mkdir -p /root/mysqld-backup/{data,config}/

3. 데이터 디렉터리를 백업합니다.

   # cp -rp /var/lib/mysql/ /root/mysqld-backup/data/

4. 구성 파일을 백업합니다.

   # cp -rp /etc/my.cnf /etc/my.cnf.d/ /root/mysqld-backup/config/

5. mysqld 서비스를 시작합니다.

   # systemctl start mysqld.service

프로세스

1. mysqld 서비스를 중지합니다.

   # systemctl stop mysqld.service

2. 현재 /var/lib/mysql/ 디렉터리를 제거합니다.

   # rm -rf /var/lib/mysql/

3. 백업에서 data 디렉토리를 복원합니다.

   # cp -rp /root/mysqld-backup/data/mysql/ /var/lib/

4. /var/lib/mysql/ 디렉터리의 올바른 소유권을 확인합니다.

   # chown -R mysql:mysql /var/lib/mysql/

5. /var/lib/mysql/ 디렉터리의 SELinux 컨텍스트를 복원합니다.

   # restorecon -Rv /var/lib/mysql/

6. 현재 구성 파일을 제거합니다.

   # rm -rf /etc/my.cnf /etc/my.cnf.d/

7. 백업에서 구성 파일을 복원합니다.

   # cp -rp /root/mysqld-backup/config/my.cnf /root/mysqld-backup/config/my.cnf.d/ /etc/

8. 구성 파일의 올바른 소유권을 확인합니다.

   # chown -R root:root /etc/my.cnf /etc/my.cnf.d/

9. 구성 파일의 SELinux 컨텍스트를 복원합니다.

   # restorecon -Rv /etc/my.cnf /etc/my.cnf.d/

10. mysqld 서비스를 시작합니다.

    # systemctl start mysqld.service

프로세스

1. [mysqld] 섹션의 /etc/my.cnf.d/mysql-server.cnf 파일에 다음 옵션을 포함합니다.

   • bind-address=source_ip_adress

     이 옵션은 복제본에서 소스로 만든 연결에 필요합니다.

   • server-id=id

     ID 는 고유해야 합니다.

   • log_bin=path_to_source_server_log

     이 옵션은 MySQL 소스 서버의 바이너리 로그 파일의 경로를 정의합니다. 예: log_bin=/var/log/mysql/mysql-bin.log.

   • gtid_mode=ON

     이 옵션은 서버에서 GTID(글로벌 트랜잭션 식별자)를 활성화합니다.

   • enforce-gtid-consistency=ON

     서버는 GTID를 사용하여 안전하게 로깅할 수 있는 명령만 실행하여 GTID 일관성을 적용합니다.

   • Optional: binlog_do_db=db_name

     선택한 데이터베이스만 복제하려면 이 옵션을 사용합니다. 두 개 이상의 선택한 데이터베이스를 복제하려면 각 데이터베이스를 별도로 지정합니다.

     binlog_do_db=db_name1
     binlog_do_db=db_name2
     binlog_do_db=db_name3

   • Optional: binlog_ignore_db=db_name

     복제에서 특정 데이터베이스를 제외하려면 이 옵션을 사용합니다.

2. mysqld 서비스를 다시 시작합니다.

   # systemctl restart mysqld.service

프로세스

1. [mysqld] 섹션의 /etc/my.cnf.d/mysql-server.cnf 파일에 다음 옵션을 포함합니다.

   • server-id=id

     ID 는 고유해야 합니다.

   • relay-log=path_to_replica_server_log

     relay 로그는 복제 중에 MySQL 복제본 서버에서 생성한 로그 파일 집합입니다.

   • log_bin=path_to_replica_sever_log

     이 옵션은 MySQL 복제본 서버의 바이너리 로그 파일의 경로를 정의합니다. 예: log_bin=/var/log/mysql/mysql-bin.log.

     이 옵션은 복제본에 필요하지 않지만 강력하게 권장됩니다.

   • gtid_mode=ON

     이 옵션은 서버에서 GTID(글로벌 트랜잭션 식별자)를 활성화합니다.

   • enforce-gtid-consistency=ON

     서버는 GTID를 사용하여 안전하게 로깅할 수 있는 명령만 실행하여 GTID 일관성을 적용합니다.

   • log-replica-updates=ON

     이 옵션을 사용하면 소스 서버에서 수신된 업데이트가 복제본의 바이너리 로그에 기록됩니다.

   • skip-replica-start=ON

     이 옵션을 사용하면 복제본 서버가 시작될 때 복제 스레드가 시작되지 않습니다.

   • Optional: binlog_do_db=db_name

     특정 데이터베이스만 복제하려면 이 옵션을 사용합니다. 둘 이상의 데이터베이스를 복제하려면 각 데이터베이스를 별도로 지정합니다.

     binlog_do_db=db_name1
     binlog_do_db=db_name2
     binlog_do_db=db_name3

   • Optional: binlog_ignore_db=db_name

     복제에서 특정 데이터베이스를 제외하려면 이 옵션을 사용합니다.

2. mysqld 서비스를 다시 시작합니다.

   # systemctl restart mysqld.service

프로세스

1. 복제 사용자를 생성합니다.

   mysql> CREATE USER 'replication_user'@'replica_server_hostname' IDENTIFIED WITH mysql_native_password BY 'password';

2. 사용자에게 복제 권한을 부여합니다.

   mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'replica_server_hostname';*

3. MySQL 데이터베이스에서 권한 부여 테이블을 다시 로드합니다.

   mysql> FLUSH PRIVILEGES;

4. 소스 서버를 읽기 전용 상태로 설정합니다.

   mysql> SET @@GLOBAL.read_only = ON;

프로세스

1. 복제본 서버를 읽기 전용 상태로 설정합니다.

   mysql> SET @@GLOBAL.read_only = ON;

2. 복제 소스를 구성합니다.

   mysql> CHANGE REPLICATION SOURCE TO
          SOURCE_HOST='source_hostname',
          SOURCE_USER='replication_user',
          SOURCE_PASSWORD='password',
          SOURCE_AUTO_POSITION=1,
          SOURCE_SSL=1,
          SOURCE_SSL_CA='path_to_ca_on_source',
          SOURCE_SSL_CAPATH='path_to_directory_with_certificates',
          SOURCE_SSL_CERT='path_to_source_certificate',
          SOURCE_SSL_KEY='path_to_source_key';

3. MySQL 복제본 서버에서 복제본 스레드를 시작합니다.

   mysql> START REPLICA;

4. 소스 및 복제본 서버에서 모두 읽기 전용 상태를 설정 해제합니다.

   mysql> SET @@GLOBAL.read_only = OFF;

5. 선택 사항: 디버깅을 위해 복제본 서버의 상태를 검사합니다.

   mysql> SHOW REPLICA STATUS\G;

   참고

   복제본 서버가 시작 또는 연결에 실패하면 SHOW MASTER STATUS 명령의 출력에 표시된 바이너리 로그 파일 위치에 따라 특정 수의 이벤트를 건너뛸 수 있습니다. 예를 들어 정의된 위치에서 첫 번째 이벤트를 건너뜁니다.

   mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;

   그런 다음 복제본 서버를 다시 시작합니다.

6. 선택 사항: 복제본 서버에서 복제본 스레드를 중지합니다.

   mysql> STOP REPLICA;

프로세스

1. 소스 서버에서 예제 데이터베이스를 생성합니다.

   mysql> CREATE DATABASE test_db_name;

2. test_db_name 데이터베이스가 복제본 서버에서 복제되는지 확인합니다.

3. 소스 또는 복제본 서버 중 하나에서 다음 명령을 실행하여 MySQL 서버의 바이너리 로그 파일에 대한 상태 정보를 표시합니다.

   mysql> SHOW MASTER STATUS;

   소스에서 실행되는 트랜잭션에 대한 GTID 집합을 표시하는 Executed_Gtid_Set 열은 비워 둘 수 없습니다.

   참고

   복제본 서버에서 SHOW REPLICA STATUS 를 사용할 때 Executed_Gtid_Set 행에 동일한 GTIDs 세트가 표시됩니다.

프로세스

1. 새 데이터베이스를 생성합니다.

   $ createdb <db_name>

2. 개체를 소유하거나 덤프된 데이터베이스의 오브젝트에 대한 권한이 부여된 모든 사용자가 이미 있는지 확인합니다. 이러한 사용자가 존재하지 않는 경우 복원에서 원래 소유권 및 권한으로 오브젝트를 다시 생성하지 못합니다.

3. psql 유틸리티를 실행하여 pg_dump 유틸리티로 생성된 텍스트 파일 덤프를 복원합니다.

   $ psql <db_name> < <dump_file>

   여기서 <dump_file >은 pg_dump 명령의 출력입니다. 비 텍스트 파일 덤프를 복원하려면 대신 pg_restore 유틸리티를 사용합니다.

   $ pg_restore <non-plain_text_file>

프로세스

1. 개체를 소유하거나 덤프된 데이터베이스의 개체에 대한 권한이 부여된 모든 사용자가 있는지 확인합니다. 이러한 사용자가 존재하지 않는 경우 복원에서 원래 소유권 및 권한으로 오브젝트를 다시 생성하지 못합니다.

2. psql 유틸리티를 실행하여 pg_dumpall 유틸리티에서 생성한 텍스트 파일 덤프를 복원합니다.

   $ psql < <dump_file>

   여기서 <dump_file >은 pg_dumpall 명령의 출력입니다.

프로세스

1. postgresql 서비스를 중지합니다.

   # systemctl stop postgresql.service

2. 백업 디렉터리를 생성합니다. 예를 들면 다음과 같습니다.

   # mkdir -p /root/postgresql-backup/

3. /var/lib/pgsql/ 디렉터리를 백업합니다.

   # cp -rp /var/lib/pgsql/ /root/postgresql-backup/

   /var/lib/pgsql/ 에는 구성 파일, 데이터 파일, 로그를 포함하여 PostgreSQL 데이터베이스 서버의 모든 필수 파일이 포함되어 있습니다.

4. postgresql 서비스를 시작합니다.

   # systemctl start postgresql.service

프로세스

1. postgresql 서비스를 중지합니다.

   # systemctl stop postgresql.service

2. 현재 /var/lib/pgsql/ 디렉터리를 제거합니다.

   # rm -rf /var/lib/pgsql/

3. 백업에서 data 디렉토리를 복원합니다.

   # cp -rp /root/postgresql-backup/pgsql/ /var/lib/

4. /var/lib/pgsql/ 디렉터리의 올바른 소유권을 확인합니다.

   # chown -R postgres:postgres /var/lib/pgsql/

5. /var/lib/pgsql/ 디렉터리의 SELinux 컨텍스트를 복원합니다.

   # restorecon -Rv /var/lib/pgsql/

6. postgresql 서비스를 시작합니다.

   # systemctl start postgresql.service

검증

1. postgres 사용자로 로그인합니다.

2. 데이터베이스에 연결합니다.

   $ psql <database>

3. 데이터베이스의 데이터에 액세스합니다.

   <database>=# SELECT * FROM <table>;

4. PostgreSQL 서비스에서 연결을 끊습니다.

   <database>=# \q

프로세스

1. /var/lib/pgsql/data/postgresql.conf 파일에서 다음을 수행합니다.

   1. wal_level 구성 매개 변수를 replica 이상으로 설정합니다.
   2. archive_mode 매개변수를 의 로 설정합니다.

   3. archive_command 구성 매개변수에서 shell 명령을 지정합니다. cp 명령, 다른 명령 또는 쉘 스크립트를 사용할 수 있습니다.

      예를 들면 다음과 같습니다.

      archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'

      여기서 %p 매개변수는 아카이브할 파일의 상대 경로로 교체되고 %f 매개변수는 파일 이름으로 교체됩니다.

      이 명령은 아카이브 가능한 WAL 세그먼트를 /mnt/server/archivedir/ 디렉터리에 복사합니다. %p 및 %f 매개변수를 교체한 후 실행된 명령은 다음과 같습니다.

      test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065

      보관된 각 새 파일에 대해 유사한 명령이 생성됩니다.

      참고

      archive 명령은 완료된 WAL 세그먼트에서만 실행됩니다. WAL 트래픽을 거의 생성하는 서버는 트랜잭션 완료와 아카이브 스토리지에 안전한 기록 사이에 상당한 지연이 발생할 수 있습니다. 보관되지 않은 오래된 데이터를 저장할 수 있는 방법을 제한하려면 다음을 수행할 수 있습니다.

      • archive_timeout 매개변수를 설정하여 지정된 빈도로 서버가 새 WAL 세그먼트 파일로 전환하도록 합니다.
      • pg_switch_wal 매개 변수를 사용하여 세그먼트 스위치가 완료된 직후 트랜잭션이 보관되도록 강제 적용합니다.

2. postgresql 서비스를 다시 시작하여 변경 사항을 활성화합니다.

   # systemctl restart postgresql.service

3. archive 명령을 테스트하고 기존 파일을 덮어쓰지 않고 실패하는 경우 0이 아닌 종료 상태를 반환하는지 확인합니다.
4. 데이터를 보호하려면 세그먼트 파일이 그룹 또는 세계 읽기 액세스 권한이 없는 디렉터리에 보관되어야 합니다.

프로세스

1. pg_basebackup 유틸리티를 사용하여 기본 백업을 수행합니다.

   • 개별 파일로 기본 백업을 생성하려면 다음을 수행합니다.

     $ pg_basebackup -D <backup_directory> -Fp

     backup_directory 를 선택한 백업 위치로 바꿉니다.

     tablespaces를 사용하고 서버와 동일한 호스트에서 기본 백업을 수행하는 경우 --tablespace-mapping 옵션도 사용해야 합니다. 그렇지 않으면 백업을 동일한 위치에 작성하려고 할 때 백업이 실패합니다.

   • 기본 백업을 tar 아카이브(tar 및 압축 형식)로 만들려면 다음을 수행합니다.

     $ pg_basebackup -D <backup_directory> -Ft -z

     backup_directory 를 선택한 백업 위치로 바꿉니다.

     이러한 데이터를 복원하려면 올바른 위치에 파일을 수동으로 추출해야 합니다.

   연결할 데이터베이스 서버 pg_basebackup 을 지정하려면 다음 명령줄 옵션을 사용합니다.

   • 호스트를 정의하는 -h 옵션입니다.

     기본 호스트는 로컬 호스트 또는 PGHOST 환경 변수에 의해 지정된 호스트입니다.

   • 포트를 정의하는 -p 옵션입니다.

     기본 포트는 PGPORT 환경 변수 또는 컴파일된 상태로 표시됩니다.

2. 기본 백업 프로세스가 완료되면 백업 기록 파일에 지정된 백업 중에 사용되는 데이터베이스 클러스터 및 WAL 세그먼트 파일의 복사본을 안전하게 보관합니다.
3. 기본 백업보다 오래되고 복원에 더 이상 필요하지 않기 때문에 기본 백업에 사용되는 WAL 세그먼트 파일보다 숫자적으로 낮은 WAL 세그먼트를 삭제합니다.

프로세스

1. 서버를 중지합니다.

   # systemctl stop postgresql.service

2. 필요한 데이터를 임시 위치에 복사합니다.

   전체 클러스터 데이터 디렉터리 및 모든 테이블 공간을 복사하는 것이 좋습니다. 이를 위해서는 시스템에 기존 데이터베이스의 두 복사본을 저장할 수 있는 충분한 여유 공간이 필요합니다.

   공간이 충분하지 않은 경우 시스템이 중단되기 전에 보관되지 않은 로그를 포함할 수 있는 클러스터의 pg_wal 디렉터리의 내용을 저장합니다.

3. 클러스터 데이터 디렉터리 및 사용 중인 테이블 공간의 루트 디렉터리 아래에 있는 기존 파일 및 하위 디렉터리를 모두 제거합니다.

4. 기본 백업에서 데이터베이스 파일을 복원합니다.

   다음을 확인하십시오.

   • 파일이 올바른 소유권( root가 아닌 데이터베이스 시스템 사용자)으로 복원됩니다.
   • 파일이 올바른 권한으로 복원됩니다.
   • pg_tblspc/ 하위 디렉터리의 심볼릭 링크가 올바르게 복원됩니다.

5. pg_wal/ 하위 디렉터리에 있는 모든 파일을 제거합니다.

   이러한 파일은 기본 백업에서 생성되었으므로 사용되지 않습니다. pg_wal/ 를 보관하지 않은 경우 적절한 권한으로 다시 생성합니다.

6. 2단계에서 저장한 모든 보관되지 않은 WAL 세그먼트 파일을 pg_wal/ 로 복사합니다.

7. 클러스터 데이터 디렉터리에 recovery.conf 복구 명령 파일을 생성하고 restore_command 구성 매개 변수에 shell 명령을 지정합니다. cp 명령, 다른 명령 또는 쉘 스크립트를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

   restore_command = 'cp /mnt/server/archivedir/%f "%p"'

8. 서버를 시작합니다.

   # systemctl start postgresql.service

   서버는 복구 모드로 전환되고 필요한 아카이브된 WAL 파일을 통해 읽습니다.

   외부 오류로 인해 복구가 종료되면 서버를 다시 시작할 수 있으며 복구를 계속합니다. 복구 프로세스가 완료되면 서버는 recovery.conf 의 이름을 recovery.done 로 바꿉니다. 이렇게 하면 일반 데이터베이스 작업이 시작된 후 서버가 실수로 복구 모드로 다시 입력되지 않습니다.

9. 데이터베이스 내용을 확인하여 데이터베이스가 필요한 상태로 복구되었는지 확인합니다.

   데이터베이스가 required 상태로 복구되지 않은 경우 1 단계로 돌아갑니다. 데이터베이스가 필수 상태로 복구된 경우 pg_hba.conf 파일에서 클라이언트 인증 구성을 복원하여 사용자가 연결할 수 있도록 합니다.

프로세스

1. 마이그레이션할 기존 PostgreSQL 인스턴스가 있는 호스트에서 다음을 수행합니다.

   1. 모든 데이터베이스를 /var/lib/pgsql/pgdump_file.sql 파일로 내보냅니다.

      # su - postgres -c "pg_dumpall > /var/lib/pgsql/pgdump_file.sql"

   2. 내보낸 파일을 확인합니다.

      # su - postgres -c 'less "/var/lib/pgsql/pgdump_file.sql"'

   3. 이전 단계에서 생성한 데이터베이스 덤프와 PostgreSQL 구성 파일을 RHEL 10 호스트에 복사합니다. 예를 들면 다음과 같습니다.

      # scp /var/lib/pgsql/pgdump_file.sql \
             /var/lib/pgsql/data/pg_hba.conf \
             /var/lib/pgsql/data/pg_ident.conf \
             /var/lib/pgsql/data/postgresql.conf \
             <user>@<rhel_10_host>:/tmp/

2. RHEL 10 호스트에서 다음을 수행합니다.

   1. postgresql-server 패키지를 설치합니다.

      # dnf install postgresql-server

   2. /var/lib/pgsql/data/ 디렉터리를 초기화합니다.

      # postgresql-setup --initdb

   3. 복사한 구성 파일을 /var/lib/pgsql/data/ 디렉터리로 이동합니다.

      # mv /tmp/pg_hba.conf \
           /tmp/pg_ident.conf \
           /tmp/postgresql.conf \
           /var/lib/pgsql/data/

   4. /var/lib/pgsql/data/ 디렉터리에 있는 콘텐츠의 올바른 소유권을 확인하십시오.

      # chown -R postgres:postgres /var/lib/pgsql/data/

   5. /var/lib/pgsql/data/:에 SELinux 컨텍스트를 복원합니다.

      # restorecon -Rv /var/lib/pgsql/data/

   6. postgresql 서비스를 활성화하고 시작합니다.

      # systemctl enable --now postgresql.service

   7. postgres 사용자로 데이터를 가져옵니다.

      # su - postgres -c 'psql -f /tmp/pgdump_file.sql postgres'

   8. 데이터베이스를 확인하고 PostgreSQL 서버를 사용하는 애플리케이션이 예상대로 작동하는지 확인합니다.

프로세스

1. 마이그레이션할 기존 PostgreSQL 인스턴스가 있는 호스트에서 다음을 수행합니다.

   1. postgresql 서비스를 중지합니다.

      # systemctl stop postgresql.service

   2. /var/lib/pgsql/ 디렉터리로 변경하고 data 하위 디렉터리를 백업합니다.

      # cd /var/lib/pgsql/
      # tar -zcf ~/pgdata.bak.tar.gz data/

   3. ~/pgdata.bak.tar.gz 아카이브를 RHEL 10 호스트에 복사합니다. 예를 들면 다음과 같습니다.

      # scp ~/pgdata.bak.tar.gz <user>@<rhel_10_host>:/tmp/

2. RHEL 10 호스트에서 다음을 수행합니다.

   1. 필수 패키지를 설치합니다.

      # dnf install postgresql-server postgresql-upgrade

      postgresql-upgrade 패키지는 마이그레이션 중에 필요한 PostgreSQL 13 서버를 제공합니다.

   2. 타사 PostgreSQL 서버 모듈을 사용하는 경우 postgresql-devel 및 postgresql-upgrade-devel 패키지에 대해 빌드하고 설치합니다.

   3. postgresql 서비스가 중지되었는지 확인합니다.

      # systemctl stop postgresql.service

   4. /var/lib/pgsql/ 디렉터리로 변경하고 이전 호스트에서 백업된 데이터 디렉토리를 추출합니다.

      # cd /var/lib/pgsql/
      # tar -zxf /tmp/pgdata.bak.tar.gz

   5. 선택 사항: /tmp/pgdata.bak.tar.gz 아카이브를 제거하십시오.

      # rm /tmp/pgdata.bak.tar.gz

   6. 업그레이드 프로세스를 수행합니다.

      # postgresql-setup --upgrade

      postgresql-setup 쉘 스크립트는 /var/lib/pgsql/data/ 디렉터리의 이름을 /var/lib/pgsql/data-old/ 로 변경하고 pg_upgrade 유틸리티를 사용하여 데이터베이스를 다시 생성한 /var/lib/pgsql/data/ 디렉터리로 마이그레이션합니다.

      중요

      pg_upgrade 유틸리티는 구성 파일이 아닌 데이터베이스만 마이그레이션합니다. 마이그레이션 후 /var/lib/pgsql/data/ 에는 기본 .conf 파일만 포함됩니다. 이전에 사용자 지정 구성 파일이 있는 경우 /var/lib/pgsql/data-old/ 디렉터리에서 복사하여 새 PostgreSQL 버전과 호환되는지 확인합니다.

   7. postgresql 서비스를 활성화하고 시작합니다.

      # systemctl enable --now postgresql.service

   8. 모든 데이터베이스를 정리하고 분석합니다.

      # su postgres -c 'vacuumdb --all --analyze-in-stages'

   9. 데이터베이스를 확인하고 PostgreSQL 서버를 사용하는 애플리케이션이 예상대로 작동하는지 확인합니다.

   10. 선택 사항: 마이그레이션 전의 데이터베이스 및 구성 파일이 포함된 /var/lib/pgsql/data-old/ 디렉터리를 제거합니다.

       # rm -r /var/lib/pgsql/data-old/

   11. 선택 사항: postgresql-upgrade 패키지를 제거합니다.

       # dnf remove postgresql-upgrade