728x90

 

지난 포스팅에 이어 이번 포스팅에서는 백업한 데이터를 복원하는 방법에 대하여 확인해 보도록 하겠습니다. 백업을 위한 파라메터가 `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, 데이터의 백업과 복원 #1 / 백업의 두가지 방법

InfluxDB 도 데이터베이스이기 때문에 만일의 상황을 대비하여 백업과 복원 방법에 대하여 알아둘 필요가 있습니다. 근래에 클라우드 기반으로 서비스를 제공하고 있다보니 공식 문서에서 설치형

ondemand.tistory.com

 

728x90
728x90

InfluxDB 도 데이터베이스이기 때문에 만일의 상황을 대비하여 백업과 복원 방법에 대하여 알아둘 필요가 있습니다. 근래에 클라우드 기반으로 서비스를 제공하고 있다보니 공식 문서에서 설치형 InfluxDB 인 InfluxDB OSS 로 문서를 찾아보아야 합니다. OSS 버전이 2.0 까지 출시되었지만 사용중인 1.8 버전을 기준으로 내용을 정리해 보겠습니다. 

 


데이터 백업과 복원 절차의 InfluxDB 버전 호환성

SaaS 혹은 PaaS 형 서비스인 InfluxDB Cloud 를 제외하면 우리가 선택할 수 있는 옵션은 두가지 입니다. 하나는 InfluxDB OSS 이고 다른 하나는 InfluxDB Enterprise 입니다. 전사에서 InfluxDB 를 도입해서 쓰는 경우가 아니라면 대부분 OSS 버전이겠습니다만, 중요한 것은 이 두가지 종류간에는 백업 데이터의 상호 호환이 된다고 합니다. 

다만, 공식 문서에서 버전에 대한 언급이 있는데요, 메이저 버전이 같아야 상호 백업, 복원이 가능하다고 합니다. 현재 OSS 의 2.0 버전과 1.8 버전 간에는 데이터 호환이 되지 않을 수 있다는 이야기입니다. 문제가 없는 예시로 들고 있는 것은 1.7.3 버전과 1.8.2 버전인데요, 이런 경우에는 문제가 없다고 합니다. 다른 메이저 버전간의 백업, 복원은 그런 상황이 오면 확인해 보도록 하겠습니다 ^^;;

 

백업 파일은 두가지 포맷이 존재한다!?

InfluxDB 를 백업할 때 사용할 수 있는 포맷은 두가지입니다. 하나는 Enterprise 버전과 호환되는 포맷으로 CLI 에서 백업시 -portable 옵션을 사용해야 합니다. -portable 옵션 없이 백업을 하는 경우 이전 세대의 포맷인 Legacy 버전으로 백업됩니다. Enterprise 버전을 당장 사용할 일이 없다고 하더라도 -portable 옵션을 이용하는 것이 좋아보입니다.

백업된 데이터를 복원할 때도 백업 파일의 버전을 지정해 주어야 합니다. 복원시 -portable 옵션을 주게 되면 Enterprise 버전과 호환되는 포맷의 백업파일을 복원한다는 의미가 됩니다. 백업때와는 달리 Legacy 버전의 데이터를 복원할때는 -online 옵션을 지정해 주어야 합니다. 

어쨋든 새로운 포맷을 추천하는 InfluxData 의 안내


백업#1 - InfluxDB 로컬에서 백업 수행해보기

기본적인 InfluxDB 의 백업, 복원에 대한 특징과 주의사항을 살펴보았으니 실제로 백업을 해보겠습니다. InfluxDB 를 백업하는 방법은 1) 해당 머신에서 직접 백업하는 방법과, 2) 리모트 접근 포인트를 열어서 백업하는 방법의 두가지가 있습니다. 간단한 것이 1번의 방법이니 로컬에서 백업을 먼저 해보도록 하겠습니다.

$ influxd backup -portable -database myreport ./
2020/11/18 16:22:12 backing up metastore to meta.00
2020/11/18 16:22:12 backing up db=myreport
2020/11/18 16:22:12 backing up db=myreport rp=autogen shard=3 to myreport.autogen.00003.00 since 0001-01-01T00:00:00Z
...
...
2020/11/18 16:22:13 backup complete:
2020/11/18 16:22:13     20201118T072212Z.meta
2020/11/18 16:22:13     20201118T072212Z.s3.tar.gz
...
...
2020/11/18 16:22:13     20201118T072212Z.manifest

가장 간단한 방식으로 명령을 만들어 보았습니다. 터미널로 InfluxDB 가 구동되는 서버에 접근하여 CLI 로 명령을 내리시면 됩니다. 첫번째 인자로 backup 을 지정하여 백업 작업의 수행을 알려줘야 합니다. 앞서 살펴본 것처럼 새로운 버전의 포맷을 쓰기 위해 -portable 옵션을 넣었고, 특정한 데이터베이스만 백업하기 위하여 -database 로 데이터베이스 이름(제 경우는 myreport)을 지정해 주었습니다. 데이터베이스가 여러개 생성되어 있고 전체 백업을 진행하려면 -database ##DB명## 을 제외하고 명령을 내리시면 됩니다. 

마지막 인자는 백업 파일이 저장될 경로입니다. 명령을 실행하는 디렉토리에 백업 파일을 만들기 위하여 ./ 를 넣었습니다만 각자의 상황에 맞게 경로를 지정해 주면 문제 없을겁니다. 이렇게 명령을 내리고 나면 지정된 경로에 아래와 같이 백업 파일이 생성됩니다. 뭔가 복잡하지만 자세히 알아보지는 않겠습니다 ^^

 

백업#2 - 리모트에서 InfluxDB 백업해보기

리모트에서 InfluxDB 를 백업하기 위해서는 두가지 작업이 필요합니다. 1) 작업을 진행하는 컴퓨터에서 influxd 를 실행할 수 있도록 바이너리가 설치되어 있어야 하며, 2) InfluxDB 장비 설정에 원격지에서 접근을 허용하도록 주소와 포트가 지정되어 있어야 합니다. 우선 2) 번의 작업을 진행해 보겠습니다.

2번의 작업을 위해 InfluxDB 의 설정 파일인 influxdb.conf 를 열겠습니다. 패키지 관리자를 이용하여 설치했다면 아마도 /etc/influxdb/influxdb.conf 정도의 경로에서 설정 파일을 찾아보실 수 있을 겁니다. vim 등의 에디터로 파일을 열고 bind-address 항목을 찾아보도록 하겠습니다. 주석 처리된 부분을 해제하면 기본적으로 서버의 모든 IP 의 지정된 포트로 influxd 가 액세스 할 수 있게 됩니다. 

설정이 반영되도록 systemctl restart influxdb.service 명령으로 InfluxDB 를 재기동 하겠습니다. 참고로 InfluxDB 의 기본 포트가 8086 이기 때문에 제어를 위한 HTTP 서비스 포트는 8086 이 아닌 다른 포트를 사용해야 합니다. 공식 문서에서는 8088 포트를 쓰고 있는데 각자의 사정에 맞추어 포트를 지정해주시면 되겠습니다. 참고로 위와 같이 설정하면 서버의 모든 IP 로 8088 번 접근이 가능해집니다.

원격으로 백업 작업을 수행하기 위해서는 -host 옵션을 추가로 지정해 주어야 하고 ##influxdb_IP_주소##:8088 을 지정해 주어야 합니다. 다른 장비에서 아래와 같은 명령으로 8088번 포트로 접근하여 백업을 정상적으로 수행할 수 있었습니다. 

[다른장비]$ influxd backup -portable -database myreport -host ##서버주소##:8088 ./
2020/11/18 17:23:48 backing up metastore to meta.00
2020/11/18 17:23:48 backing up db=myreport
2020/11/18 17:23:48 backing up db=myreport rp=autogen shard=3 to myreport.autogen.00003.00 since 0001-01-01T00:00:00Z
2020/11/18 17:23:48 backing up db=myreport rp=autogen shard=4 to myreport.autogen.00004.00 since 0001-01-01T00:00:00Z
...

 


이번 포스팅에서는 InfluxDB 백업시 알아두어야 할 점과 InfluxDB 가 제공하는 두가지 백업 방법을 살펴보았습니다. 다음 포스팅에서는 이렇게 백업한 파일을 복원하는 방법에 대해서 살펴보겠습니다. 

>>> 이어지는 복원 방법 포스팅은 이쪽입니다!

 

InfluxDB, 데이터의 백업과 복원 #2 / 백업 파일 복원하기

지난 포스팅에 이어 이번 포스팅에서는 백업한 데이터를 복원하는 방법에 대하여 확인해 보도록 하겠습니다. 백업을 위한 파라메터가 `backup` 이었다면 반대로 복원을 위한 파라메터는 `restore`

ondemand.tistory.com

 

728x90
728x90

시계열 데이터베이스는 기본적으로 다량의 데이터 포인트를 수집하여 보관하고, 시각화 도구를 이용하여 필요한 메트릭을 만드는 과정을 거치게 됩니다. 하지만 데이터 포인트가 지속적으로 쌓이게 되면 데이터를 조회하는 속도가 느려질 뿐만 아니라 스토리지의 공간 문제도 발생할 수 밖에 없습니다.

이 때 사용하는 것이 대용량의 데이터 포인트를 일정한 주기로 다시 요약하여 가공된 데이터로 만드는 것인데요, 롤업 혹은 리텐션이라는 용어로 많이 부릅니다. 처음 사회 생활을 시작했을 때는 RDBMS 에 쿼리를 만들어 배치 작업으로 주단위, 월단위 등의 리텐션 작업을 했던 기억이 새록새록 납니다 (아재 인증...)

InfluxDB 는 패키지를 이용하여 기본 값으로 제품을 설치했을 때, 리텐션 주기에 대한 설정이 켜져 있지 않습니다. 이 상태에서 데이터베이스를 생성하면 리텐션 주기에 맞추어 데이터를 롤업, 리텐션 하지 않고 라인 프로토콜을 통해 입력된 그대로 쌓아두게 됩니다. 시간이 흐름에 따라 데이터의 조회 속도가 느려지고 스토리지 문제의 영향이 생길 수 밖에 없겠죠?

출처 : wikipedia

InfluxDB 의 리텐션 자동 활성화 옵션 켜기

리텐션을 활성화 하고 리텐션 주기를 설정하기 위해서는 아래의 단계로 작업을 해야 합니다. 이미 데이터베이스를 생성해서 사용하고 있는 경우와 처음 생성하는 경우로 나뉘어 질텐데요, InfluxDB 설정 파일의 변경 이전에 만든 DB 인가, 이후에 만든 DB 인가로 설정 값이 적용되게 됩니다. 

InfluxDB 의 설정 파일은 CentOS 기준으로 /etc/influxdb/influxdb.conf 로 저장되어 있습니다. 이 파일을 열어서 초반부를 살펴보면 `retention-autocreate=true` 라는 옵션이 주석 처리 되어 있는걸 볼 수 있습니다. 데이터 베이스 생성시 자동으로 리텐션을 사용하도록 하기 위해서 주석문을 풀어야겠죠?

// CentOS 기준
$ vim /etc/influxdb/influxdb.conf

###
### [meta]
###
### Controls the parameters for the Raft consensus group that stores metadata
### about the InfluxDB cluster.
###

[meta]
  # Where the metadata/raft database is stored
  dir = "/var/lib/influxdb/meta"

  # Automatically create a default retention policy when creating a database.
  # retention-autocreate = true

  # If log messages are printed for the meta service
  # logging-enabled = true

리텐션 작업이 필요한지 확인하는 설정 항목은 조금 더 아랫쪽에 있습니다. vim 을 쓰고 있다면 슬래시를 눌러 키워드를 검색하여 위치를 빠르게 찾아가도록 하겠습니다. 주석처리 되어 있는 두가지 옵션을 활성화 해야 합니다. `enabled=true` 는 주기적인 점검시 정의된 리텐션 정책을 적용의 On, Off 역할이고, `check-internal` 은 점검을 수행하는 간격을 지정하는 값입니다. 

(vim 에서 /[retention] 을 입력하면 빠르게 찾을 수 있습니닷!)

###
### [retention]
###
### Controls the enforcement of retention policies for evicting old data.
###

[retention]
  # Determines whether retention policy enforcement enabled.
  # enabled = true

  # The interval of time when retention policy enforcement checks run.
  # check-interval = "30m"

 

리텐션 자동 활성화 확인하기

위의 옵션들의 주석 처리를 해제한 후 InfluxDB 를 재기동 했습니다. 재기동을 했으니 새로운 변경 사항이 반영되었겠죠? InfluxDB CLI 에 접근하여 새로운 DB 를 생성하여 설정 변경전에 생성한 DB 와 리텐션 정책이 어떻게 차이가 나는지 확인해 보도록 하겠습니다. 

// InfluxDB 재기동 (CentOS 7.x 이후 기준)
$ systemctl restart influxdb.service

// 리텐션 자동 생성 활성화 전에 만든 DB 의 정보
$ influx
Connected to http://localhost:8086 version 1.8.3
InfluxDB shell version: 1.8.3
> use encreport
Using database encreport
> show retention policies
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        true

// 리텐션 자동 생성 활성화후 DB 생성 및 정보 확인
>
> create database test
> use test
> show retention policies
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        true

어랏..? 생각과는 좀 다릅니다. 리텐션 자동 활성화를 선택 하건 하지 않건 변화가 보이지 않습니다. 자동 생성 되었음을 알려주는 이름인 `autogen` 을 가진 정책이 각 데이터베이스에 이미 존재합니다. 도대체 무슨일이 일어나는지 알수가 없어서 가장 처음에 나온 설정인 `retention-autocreate=false` 로 명시적으로 끈 뒤에 데이터베이스를 생성해 보겠습니다. 당연히 리로딩도 해주셔야 합니다!

> create database test2
> use test2
Using database test2
> show retention policies
name duration shardGroupDuration replicaN default
---- -------- ------------------ -------- -------

아하... 이런 것이었습니다. 설정의 주석을 풀던 풀지 않던 일단 기본 값은 `autogen` 정책을 만드는 것이었습니다. 어렵게 주석을 묶고 풀고 할 이유가 없었던 것 같은 느낌적 느낌입니다. 여튼, 기본 정책은 자동으로 잘 생성되니 다음 포스팅에서는 실제 정책을 만들어서 데이터베이스에 적용하는 방법을 살펴보도록 하겠습니다!

 


오늘의 교훈 : 기본 문서를 잘 읽자

 

Configure InfluxDB OSS | InfluxDB OSS 1.8 Documentation

Configure InfluxDB OSSThe InfluxDB open source (OSS) configuration file contains configuration settings specific to a local node.ContentConfiguration overviewInfluxDB is configured using the configuration file (influxdb.conf) and environment variables. If

docs.influxdata.com

 

728x90
728x90

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

 

Data Exploration | InfluxData Documentation

 

archive.docs.influxdata.com

여전히 많은 사람들이 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 *

 

 

 

728x90

+ Recent posts