기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 분할된 테이블에 데이터 아카이브
<a name="archive-partitioned-tables"></a>

MySQL은 InnoDB 스토리지 엔진에 대한 [분할](https://dev.mysql.com/doc/refman/8.0/en/partitioning.html)을 지원하며, 이 기능을 통해 대용량 테이블을 분할할 수 있습니다. 분할된 테이블에서 작동하는 SQL은 전체 테이블을 읽지만 테이블 내 파티션은 별도의 물리적 테이블로 저장됩니다. 이 방식을 사용하면 행 단위 삭제를 수행하지 않고도 테이블에서 불필요한 파티션을 자유롭게 제거할 수 있으므로 데이터베이스에서 기록 행을 아카이브할 수 있습니다.

다음 예제 코드를 고려합니다. `TABLE orders`는 `orderprocessing` 스키마에 있습니다. 해당 기록 데이터는 2021년 이전에 속하는 데이터를 포함하는 파티션 `phistorica`l에 있습니다. 동일한 테이블에서 애플리케이션 수준 핫 데이터는 2022년 매월 라이브 파티션에 존재합니다. 파티션 `phistorical`에서 데이터를 아카이브하려면 `archive` 스키마에서 동일한 구조의 `table orders_2021_and_older` 아카이브를 생성할 수 있습니다. 그런 다음 MySQL [EXCHANGE PARTITION](https://dev.mysql.com/doc/refman/8.0/en/partitioning-management-exchange.html)을 사용하여 `phistorical` 파티션을 해당 테이블로 이동할 수 있습니다. 아카이브 테이블은 분할되지 않습니다. 아카이브한 후 데이터를 확인하고 Amazon S3로 이동할 수 있습니다.

```
CREATE TABLE orders (
      orderid bigint NOT NULL AUTO_INCREMENT,
      customerid bigint DEFAULT NULL,
      ............
      ............
      order_date date NOT NULL,
      PRIMARY KEY (`orderid`,`order_date`))
    PARTITION BY RANGE (TO_DAYS(order_date)) (
          PARTITION pstart   VALUES LESS THAN (0),
          PARTITION phistorical VALUES LESS THAN (TO_DAYS('2022-01-01')),
          PARTITION p2022JAN VALUES LESS THAN (TO_DAYS('2022-02-01')),
          PARTITION p2022FEB VALUES LESS THAN (TO_DAYS('2022-03-01')),
          PARTITION p2022MAR VALUES LESS THAN (TO_DAYS('2022-04-01')),
          PARTITION p2022APR VALUES LESS THAN (TO_DAYS('2022-05-01')),
          PARTITION p2022MAY VALUES LESS THAN (TO_DAYS('2022-06-01')),
          PARTITION p2022JUN VALUES LESS THAN (TO_DAYS('2022-07-01')),
          PARTITION p2022JUL VALUES LESS THAN (TO_DAYS('2022-08-01')),
          PARTITION p2022AUG VALUES LESS THAN (TO_DAYS('2022-09-01')),
          PARTITION p2022SEP VALUES LESS THAN (TO_DAYS('2022-10-01')),
          PARTITION p2022OCT VALUES LESS THAN (TO_DAYS('2022-11-01')),
          PARTITION p2022NOV VALUES LESS THAN (TO_DAYS('2022-12-01')),
          PARTITION p2022DEC VALUES LESS THAN (TO_DAYS('2023-01-01')),
          PARTITION pfuture       VALUES LESS THAN MAXVALUE
      );
CREATE TABLE orders_2021_and_older (
        orderid bigint NOT NULL AUTO_INCREMENT,
        customerid bigint DEFAULT NULL,
        ............
        ............
        order_date date NOT NULL,
        PRIMARY KEY (`orderid`,`order_date`));
mysql> alter table orderprocessing.orders exchange partition phistorical with table archive.orders_2021_and_older;
  Query OK, 0 rows affected (0.33 sec)
```

`EXCHANGE PARTITION` 기능을 사용하여 기록 데이터를 아카이브하는 경우 다음 모범 사례를 따르는 것이 좋습니다.
+ 애플리케이션에 아카이브 데이터를 저장하기 위해 별도의 스키마를 생성합니다. 이 스키마에는 아카이브된 데이터를 보관할 아카이브 테이블이 포함됩니다. 아카이브 스키마의 아카이브 테이블은 인덱스 및 프라이머리 키를 포함하여 라이브 테이블과 구조가 동일해야 합니다. 그러나 대상 아카이브 테이블은 분할된 테이블일 수 없습니다. MySQL에서는 분할된 두 테이블 사이에서 파티션을 교환할 수 없습니다.
+ 아카이브 테이블의 이름 지정 규칙을 따릅니다. 그러면 아카이브 테이블에 저장된 기록 데이터를 식별하는 데 도움이 됩니다. 감사 태스크를 수행하거나이 데이터를 Amazon S3로 이동하는 작업을 설계할 때 유용합니다.
+ Aurora MySQL 호환 라이터, Amazon RDS for MySQL 또는 Amazon RDS for MariaDB 인스턴스로 들어오는 트래픽이 없는 경우 가동 중지 시간 동안 `EXCHANGE PARTITION` 데이터 정의 언어(DDL) 문을 수행합니다.

  애플리케이션 또는 마이크로서비스에서 트래픽이 적은 기간에 `EXCHANGE PARTITION`을 실행할 수도 있습니다. 그러나 분할된 테이블에 쓰기가 없고 선택 항목이 없거나 거의 없어야 합니다. 기존의 장기 실행 select 쿼리로 인해 `EXCHANGE PARTITION` DDL이 대기하여 데이터베이스에서 리소스 경합이 발생할 수 있습니다. 시스템에서 `EXCHANGE PARTITION`을 실행하기 전에 이러한 모든 조건이 충족되는지 확인하는 스크립트를 설계합니다.

애플리케이션 설계가 분할된 데이터를 지원할 수 있고 현재 분할되지 않은 테이블이 있는 경우 데이터 아카이브를 지원하기 위해 데이터를 분할된 테이블로 이동하는 방법을 고려합니다. 자세한 내용은 [MySQL 설명서](https://dev.mysql.com/doc/refman/8.0/en/alter-table-partition-operations.html)를 참조하세요.