문서번호 : 11-401390
Document Information
•
최초 작성일 : 2022.08.04
•
최종 수정일 : 2022.10.26
•
이 문서는 아래 버전을 기준으로 작성되었습니다.
◦
SinglestoreDB : 7.8
Goal
•
예제를 통해, 운영 서버를 유지한 상태에서 PITR 수행하는 절차에 대해서 알아본다.
Solution
운영중인 database는 그대로 유지하고, Unlimited Storage Database를 새로운 object storage로 복제해 PITR 또는 clone 작업을 수행할 수 있다.
USD(Unlimited Storage Database) 의 cloning 사유 중 대표적인 것으로 아래의 경우가 있다.
•
운영 서버를 유지한 상태에서 PITR 수행 목적
•
개발 및 QA cluster의 분리 구성
•
소산 및 media backup 목적의 복제
3개의 절차는 비슷하므로, 운영 서버를 유지한 상태에서 PITR 수행 테스트 만을 기술한다.
사전 절차
서버 1은 production system 으로 가정하고, Slave를 복구를 위한 임시 서버 또는 개발기로 가정한다. 복구를 위한 경우라면, 서버 1에서 직접 복제된 USD를 attach하는 것도 가능하다.
사전에 USD 가 사용하는 bucket이 replicate 설정되어 있어 정상동작 중이라 가정한다. replicate 를 수행하지 않고 있다면, bucket을 copy할 수 있으나 database retention 범위내에서 모든 작업이 완료되어야 복구 가능하다.
Object Storage의 구성 절차는 생략하며, object storage의 replicate 절차 예시를 위해 test에서는 minio를 사용한다. 사용하는 object storage의 절차에 맞게 명령어 또는 절차를 수정해야 한다.
TEST
기술된 절차는 test를 위한 database와 data의 생성절차를 모두 포함한다. 실제 replicate된 object storage를 이용한 attach 절차는 9번과 11번을 참조한다.
1.
서버 1 (Master)에 USD 생성
CREATE DATABASE bottomless_db ON S3 "singlestore/testdb"
CONFIG '{"endpoint_url":"http://1.221.218.250:30192"}'
CREDENTIALS '{"aws_access_key_id":"minioadmin","aws_secret_access_key":"minioadmin"}';
SQL
복사
Bucket, endpoint url 및 key 정보는 사용하는 object storage 환경에 맞게 설정한다.
2.
Test 용 schema와 sample data 생성
서버 1에 Sample data를 생성한다.
아래의 스크립트를 다운로드 받고, 자신의 환경에 맞게 ss.conf파일을 수정한다.
그 후, 1_create_table.sh와 2_insert.sh를 실행한다.
아래의 파일들은 기본적으로 bottomless_db의 데이터베이스와 t1의 테이블에 1,000건의 데이터를 insert 한다.
chmod +x 1_create_table.sh 2_insert.sh insert.sql
./1_create_table.sh
./2_insert.sh
Bash
복사
3.
장애 유발
서버 1에서, 다음과 같이 운영 환경에서 원하지 않는 데이터 삭제 발생 시킨다.
DELETE FROM t1 WHERE session_id > 200 and session_id < 501;
SQL
복사
4.
retention 확인
운영 환경의 USD retention 시간을 확인한다. PITR은 현재 시각에서 정의된 retention 시간 범위에서 복원 가능하다.
SHOW variables like 'bottomless_gc_retention_period_minutes';
SQL
복사
+----------------------------------------+-------+
| Variable_name | Value |
+----------------------------------------+-------+
| bottomless_gc_retention_period_minutes | 1440 |
+----------------------------------------+-------+
SQL
복사
5.
milestone 생성 (optional)
USD는 짧은 시간내에 database의 변경을 object storage로 flush한다. Milestore 생성과정에 flush되지 않은 모든 변경을 object storage로 flush 시킨다. 이 특성을 이용해 명시적인 flush가 요구될 때 milestone을 생성할 수 있다.
Milestone 이름은 시점을 이해할 수 있는 의미 있는 이름을 사용하는 것을 권장한다.
CREATE MILESTONE "2022-08-04 14:25:00 retention_1440 delete_300" for bottomless_db;
SQL
복사
6.
생성한 milestone 확인 (optional)
SELECT MILESTONE_NAME, MILESTONE_TIME
FROM information_schema.MV_MILESTONES;
SQL
복사
+------------------------------------------------+----------------------------+
| MILESTONE_NAME | MILESTONE_TIME |
+------------------------------------------------+----------------------------+
| 2022-08-04 14:25:00 retention_1440 delete_300 | 2022-08-04 14:24:42.754480 |
| _first_milestone | 2022-08-03 16:20:42.226675 |
+------------------------------------------------+----------------------------+
SQL
복사
7.
디렉터리 확인 (optional)
버킷 안에 reference partition을 저장하고 있는 디렉터리에서 확인한다. 확인된 위치는 replicate된 object storage 내에서 milestone name을 확인할 때 사용될 수 있다.
SELECT STORAGE_DIRECTORY
FROM information_schema.MV_BOTTOMLESS_STATUS
WHERE STORAGE_DIRECTORY like '%ref%';
SQL
복사
+---------------------------------------------+
| STORAGE_DIRECTORY |
+---------------------------------------------+
| testdb/dccdcbba/10372050815265422250_21/ref |
+---------------------------------------------+
SQL
복사
8.
서버 1(master)에서 replicate 중단
기술된 절차는 minio 절차이며, 사용하는 object storage의 절차를 따른다. 기존에 replicate 구성이 없다면, bucket을 copy해 동일한 결과를 낼 수 있으나, database retention 시간 안에 copy와 attach가 이루어져야 한다.
•
버킷 id를 확인한다.
mc replicate ls master_minio/singlestore
Bash
복사
ID
cc23jms5nutvsa3qplag
Bash
복사
•
해당 버킷의 rule을 disable로 변경한다.
mc replicate edit master_minio/singlestore \
--id "cc23jms5nutvsa3qplag" \
--state disable
Bash
복사
9.
Replicate된 bucket에서 lock 파일 삭제
Object storage의 replicate를 통해 USD를 복제시, 복제된 파일은 사용 중인 database의 image이다. 따라서 attach 상태를 의미하는 lock file을 삭제해 다른 곳에 attach될 수 있도록 수정이 필요하다.
기술된 절차는 서버 2에서 minio 를 이용해 복제된 bucket 내에서 파일을 삭제하는 절차이다. 사용하는 object storage에 맞게 수정되어야 한다.
버킷에서 숫자 형식의 디렉터리를 삭제한다.
{bucket_name}/{folder_name}/{storage_id}/storage_locks/{storage_id} 위치에 해당하는 folder를 삭제한다. 각 정보는 MV_BOTTOMLESS_DATABASES, MV_BOTTOMLESS_STATUS 에서 확인할 수 있다. 만약 운영환경에서 object storage의 replicate 과정에 database를 detach 시켰다면, storage_locks folder가 존재하지 않는다.
select distinct(database_name), storage_id FROM information_schema.MV_BOTTOMLESS_STATUS;
Bash
복사
운영환경에서 storage id 를 확인한다.
mc rm slave_minio/singlestore/testdb/10372050815265422250_21/storage_locks/10372050815265422250_21
Bash
복사
10.
서버 2(slave) 에서 복구 할 milestone 확인 (reference 파티션에 존재) (optional)
ll /tmp/minio/singlestore/dccdcbba/10372050815265422250_21/ref/milestones
Bash
복사
drwxr-xr-x. 2 minio-user minio-user 21 8월 4 14:24 2022-08-04 14:25:00 retention_1440 delete_300
drwxr-xr-x 2 minio-user minio-user 21 8월 3 16:20 _first_milestone
Bash
복사
11.
복제된 bucket을 이용한 database attach
데이터가 delete 되기 전에 있던 시점으로, 새로운 데이터베이스로 attach 한다. 이 때 지정 시간은 replicate 중단 시점에서 database 의 retention 지정 시간만큼 과거 범위에서 지정할 수 있다. 허용 범위를 벗어나는 시간을 지정할 경우 에러가 발생한다.
ATTACH DATABASE bottomless_db_recover ON S3 "singlestore"
CONFIG '{"endpoint_url":"http://119.71.107.226:30192"}'
CREDENTIALS '{"aws_access_key_id":"minioadmin","aws_secret_access_key":"minioadmin"}'
AT TIME "2022-08-04 14:00:00";
SQL
복사
예시는 minio를 이용한 테스트 환경으로 사용하는 object storage에 맞게 수정되어야 한다.
12.
데이터 복구 작업
bottomless_db 데이터베이스에서 삭제된 데이터를 bottomless_db_recover 데이터베이스에서 insert 한다.
INSERT INTO bottomless_db.t1
(
SELECT *
FROM bottomless_db_recover.t1
WHERE session_id > 200 and session_id < 501
);
SQL
복사
예시는 동일 cluster에 운영과 복구용 database가 동시에 attach된 경우를 가정한다. 분리된 cluster에 attach된 경우 csv 로 unload하거나, tool을 이용해 data를 복구한다.
13.
결과
SELECT count(*)
FROM bottomless_db.t1
WHERE session_id > 200 and session_id < 501;
+----------+
| count(*) |
+----------+
| 300 |
+----------+
SQL
복사
References
History
일자 | 작성자 | 비고 |
2022.08.04 | wee | 최초 작성 |
2022.08.23 | wee | 복제 중단 절차 변경 |
2022.10.25 | jnshin | 설명 글 추가 |
2022.10.26 | jnshin | manual link 추가 |
