Cloud Computing On Demand

지난 포스팅에 이어 이번 포스팅에서는 백업한 데이터를 복원하는 방법에 대하여 확인해 보도록 하겠습니다. 백업을 위한 파라메터가 `backup` 이었다면 반대로 복원을 위한 파라메터는 `restore` 입니다. 기억하기 쉽죠? 옵션도 비슷합니다. 백업시 사용한 포맷에 따라 다르겠습니다만 InfluxDB 에서는 신규 포맷을 권장하기 때문에 `-portable` 옵션은 항상 붙인다고 기억하면 편합니다. 

새로운 데이터베이스로 복원하기

백업 파일이 가지고 있는 데이터베이스명, 즉 원본 데이터베이스를 `-db` 옵션에 지정하고 복원시 사용할 데이터베이스의 이름을 `-newdb` 로 지정해 주어야 합니다. 원래의 데이터베이스로 바로 복원하는 것은 제공되지 않고, 약간의 우회 방법을 사용해야 합니다. 우선 새로운 데이터베이스로 복원을 해보겠습니다. 

$ influxd restore -portable -db myreport -newdb myreport_new ./
2020/11/20 15:29:03 Restoring shard 16 live from backup 20201120T062805Z.s16.tar.gz
2020/11/20 15:29:03 Restoring shard 25 live from backup 20201120T062805Z.s25.tar.gz
2020/11/20 15:29:03 Restoring shard 2 live from backup 20201120T062805Z.s2.tar.gz
2020/11/20 15:29:03 Restoring shard 41 live from backup 20201120T062805Z.s41.tar.gz
2020/11/20 15:29:03 Restoring shard 10 live from backup 20201120T062805Z.s10.tar.gz
2020/11/20 15:29:03 Restoring shard 8 live from backup 20201120T062805Z.s8.tar.gz
...
...
2020/11/20 15:29:03 Restoring shard 13 live from backup 20201120T062805Z.s13.tar.gz
2020/11/20 15:29:03 Restoring shard 21 live from backup 20201120T062805Z.s21.tar.gz
2020/11/20 15:29:03 Restoring shard 26 live from backup 20201120T062805Z.s26.tar.gz
2020/11/20 15:29:03 Restoring shard 73 live from backup 20201120T062805Z.s73.tar.gz
2020/11/20 15:29:03 Restoring shard 7 live from backup 20201120T062805Z.s7.tar.gz
$

명령 마지막에 지정된 경로에서 백업에 대한 meta 파일과 manifest 파일을 확인한 뒤 복원 작업이 진행됩니다. meta 파일은 바이너리로 되어 있어 어떤 내용이 들어 있는지 확인하기 어렵습니다만 manifest 파일을 열어보면 백업 폴더에 있는 여러 tar.gz 파일들이 어떤 데이터베이스에 대하여 어떤 리텐션 정책으로 백업되었고 각 파일의 Shard ID 를 확인해볼 수 있습니다. 

$ cat 20201120T062805Z.manifest | head -n 20
{
  "meta": {
    "fileName": "20201120T062805Z.meta",
    "size": 1902
  },
  "limited": false,
  "files": [
    {
      "database": "myreport",
      "policy": "autogen",
      "shardID": 3,
      "fileName": "20201120T062805Z.s3.tar.gz",
      "size": 1024,
      "lastModified": 0
    },
    ...
    ...

복원한 데이터베이스 확인하기

InfluxDB CLI 를 이용하여 데이터베이스가 잘 복원되었는지 확인해 보겠습니다. 원본 데이터베이스의 Measurement 에 저장된 데이터포인트 수를 확인하고, 복원된 데이터베이스의 Measurement 에 저장된 데이터포인트 수를 확인하면 되겠죠? 터미널에서 `influx` 를 입력하여 CLI 에 진입하고 각 데이터베이스에 대하여 간단한 쿼리를 수행했습니다. 

$ influx
Connected to http://localhost:8086 version 1.8.3
InfluxDB shell version: 1.8.3
> use myreport
Using database myreport
> select count(*) from mydata
name: mydata
time count_ratio
---- -----------
0    1063148
> use myreport_new
Using database myreport_new
> select count(*) from mydata
name: mydata
time count_ratio
---- -----------
0    1063148
>

원래의 데이터베이스로 복원하는 방법

그런데 원래의 데이터베이스로 복원을 해야할 경우에는 어떻게 해야 할까요? 우선 아무 생각 없이 원래의 데이터베이스로 복원하도록 앞서 살펴본 복원 명령의 `-newdb` 값을 원래의 데이터베이스 이름으로 지정해 보았습니다. 무슨 에러가 나는지 확인해 보시죠. 

$ influxd restore -portable -db myreport -newdb myreport ./
2020/11/20 15:45:18 error updating meta: DB metadata not changed. database may already exist
restore: DB metadata not changed. database may already exist

원래의 데이터베이스로 복원하는 방법도 어렵지 않습니다. 앞서 살펴본 것처럼 우선 1) 새로운 데이터베이스로 복원을 먼저 한 뒤, 2) 새로운 데이터베이스에서 원래의 데이터베이스로 데이터를 옮기는 방법을 써야 합니다. 굳이 이렇게 해야 할 경우가 많이 생기지 않도록 하는 것이 좋겠지만, 방법은 알아두면 피가되고 살이될 것 같습니다. 

$ influxd restore -portable -db myreport -newdb myreport_temp ./

$ influx
> USE myreport_temp
> SELECT * INTO myreport..:MEASUREMENT FROM /.*/ GROUP BY *
> DROP DATABASE myreport_temp

간단한 구문입니다만 한번 설명을 하면 1) 임시 데이터베이스(myreport_temp)를 사용하도록 명령을 하고, 2) select~into 구문을 사용하여 모든 measurement 의 값을 원래의 데이터베이스(myreport) 로 넣습니다. 이 작업은 데이터포인트의 수에 따라 시간이 많이 소요될 수 있습니다. 마지막으로 3) 임시 데이터베이스는 삭제해 줍니다. 

사실 백업과 복원은 지난 포스팅에서 처럼 풀 백업만 하는 것 보다는 증분 백업을 섞어서 해주는 것이 좋습니다. InfluxDB 는 시작과 끝 Timestamp 지정을 통해 일정 기간의 데이터포인트를 백업하는 방법을 제공하고 있습니다. 물론 저장 방식으로 인해 정확히 시작과 끝 시간 구간 내의 데이터만 추출되지는 않습니다. 

그럼에도 불구하고 데이터포인트가 많아지면 처리 속도가 영향을 받을 수 있으니 공식 문서를 참고하여 지정된 시간 범위의 데이터를 백업하고 복원하는 시도, 도전도 해보시기 바라겠습니다! (공식 문서 : docs.influxdata.com/influxdb/v1.8/administration/backup_and_restore/)

>> 지난 포스팅을 안보았다면...

influxDB 는 시계열 DB (TSDB) 입니다. 일반적인 SQL 문장을 사용할 수 있다보니 종종 TSDB 가 아닌 RDB 로 착각할때가 많습니다. 때문에 일어나는 해프닝이 참 많은데요, <SELECT INTO> 를 이용하여 Measurement 간에 데이터를 옮길 때도 종종 문제가 생기곤 합니다. 

사실 저 역시 infludDB 를 많이 사용해 보지는 못했습니다. 어쩌다 보니 다른 분이 운영하던 Graphite 에 저장하고 있던 데이터가 더 이상 적재되지 않고 있어 어디서부터 손을 대볼까하다 "새롭게 해보자!" 는 마음으로 influxDB 를 구성해서 쓰는 정도이기 때문입니다. 아시겠지만 무언가를 할 때마다 매번 새로운 기분이라...

우선, influxDB 에서 <SELECT INTO> 구문을 사용하기 전에 공식 문서를 한 번 읽어보는 것을 추천드립니다. influxDB 의 공식문서가 마음에 드는 점 중 하나는 설명만 나열하는 것이 아니라 샘플 쿼리와 같은 예시가 중간중간에 소개된다는 점입니다. 설명을 읽는 것도 중요하지만 샘플을 가지고 이해하는 것이 더 좋을떄도 많기 때문이지요!

InfluxDB 공식 문서의 <SELECT INTO> 구문 사용법

# 관련 URL : archive.docs.influxdata.com/influxdb/v1.0/query_language/data_exploration/#the-into-clause

여전히 많은 사람들이 RDB 사고 방식으로 TSDB 를 보고 있나 봅니다. 공식 문서에서도 <Common Issues> 항목으로 <Missing data> 가 있어서 빠르게 해결할 수는 있었습니다. TSDB 에 대한 인식, InfluxDB 의 Tag 에 대한 이해 없이 막 사용하다 보니 발생한 해프닝이겠죠? 사실 이렇게 글을 적고는 있지만 현업에서의 이슈 해결이 급하다 보니 Tag 에 대해 이해할 수 있는 문서들을 더 열람해 보지는 않았습니다. 공부하는대로 다음 포스팅으로 적을 것을 약속합니다 :-)

제 경우의 이슈는 Issue 1 에 설명된 부분이었습니다. RDB 에서 의례 했던 것처럼 아래의 구문으로 특정 값을 가진 데이터를 다른 Measurement 로 옮기려는 것이 제 의도였습니다. 하지만, where 절의 값을 바꾸면서 3회 정도 쿼리를 수행했지만, 목적지의 레코드 갯수는 턱없이 적었습니다. 

SELECT * INTO "new_table" FROM "old_table" WHERE "type"='audio'
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='video'
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='etc'

공식 문서의 Issue 1 에 나온 것처럼 <현재 Measurement 의 태그(tags)를 새로운 Measurement 의 필드(Fields)로 컨버트한다> 는 동작 때문이었습니다. 인지하지 못한 사이에 현재 Measurement 의 "type" 은 태그였던 것입니다. 왜냐구요? 아직 공부하지 못했습니다 ㅜㅜ 여튼 그런연유로 데이터가 계속 겹쳐 써지면서 제대로 이관이 되지 않았던 상황이었습니다.

역시나 문서에 나온것처럼 원래의 태그를 유지하기 위해서는 "GROUP BY *" 구문을 추가하여 사용하여 문제를 해결했습니다. 새로운 데이터베이스에 대한 이해가 부족한 상태에서 필요한 결과물을 빨리 얻으려다보니 생긴 해프닝입니다. 여러분들도 혹시 유사한 문제를 만난다면 구문을 살펴보고 GROUP BY 를 추가해 주면 이슈를 벗어날 수 있을겁니다!

SELECT * INTO "new_table" FROM "old_table" WHERE "type"='audio' GROUP BY *
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='video' GROUP BY *
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='etc' GROUP BY *