이 페이지는 Cloud Translation API를 통해 번역되었습니다.

고아 테이블

MySQL | PostgreSQL | SQL Server

이 페이지에서는 MySQL의 고아 테이블과 관련된 알려진 문제를 설명합니다.

고아 테이블이란 무엇인가요?

고아 테이블은 MySQL 데이터 사전에서 정의가 연결되지 않은 테이블이며 MySQL 5.6 또는 MySQL 5.7에서 발생할 수 있습니다. 다음 시나리오 중 하나가 MySQL 5.7에서 MySQL 8.0으로의 메이저 버전 업그레이드 (MVU)를 차단할 수 있습니다.

.frm 정의 파일 없이 InnoDB 데이터 파일(.ibd)이 있거나 그 반대의 경우
더 이상 활성 애플리케이션 로직에서 참조하거나 사용하지 않는 ALTER TABLE 문장에서 남은 중간 테이블이 있습니다.

고아 임시 테이블

고아 임시 테이블 이름은 #sql- 프리픽스로 시작합니다(예: #sql-123).

다음 쿼리를 사용하여 고아 임시 테이블을 식별하세요.

SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME RLIKE '#sql-[0-9].*';

DROP TABLE 명령어를 사용하여 다른 추가 단계 없이 고아 임시 테이블을 삭제할 수 있습니다. 다음과 같은 대부분의 경우에 해당합니다.

DROP TABLE `DB`.`#mysql50#TEMPORARY_ORPHAN_TABLE`;

DB을 사용하려는 데이터베이스 이름으로 바꿉니다.

예시는 다음과 같습니다.

DROP TABLE `testdb`.`#mysql50##sql-1234`;

이전 DROP 테이블 명령어가 작동하지 않으면 정의 파일 (.frm)이 다른 ALTER TABLE 작업에서 재사용될 수 있습니다. 이러한 경우 테이블을 삭제하려면 디스크에 .frm 자리표시자 파일을 만들어야 합니다. 도움이 필요하면 Cloud SQL 지원팀에 문의하세요. 지원 계약이 없는 경우 셀프 서비스 방법에서 문제 해결 단계를 확인하세요.

고아 중간 테이블

고아 중간 테이블 이름은 #sql-ib 접두사로 시작합니다(예: #sql-ib23-343224).

다음 쿼리를 사용하여 고아 중간 테이블을 식별합니다.

SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE '%#sql-ib%';

중간 고아 테이블을 삭제하려면 먼저 고아 정의 파일 이름 (.frm)을 테이블 이름과 일치하도록 변경한 다음 명령줄에서 테이블을 삭제합니다.

중간 고아 테이블을 삭제하려면 Cloud SQL 지원팀에 문의하여 도움을 받으세요. 지원 계약이 없는 경우 문제 해결 단계는 셀프 서비스 방법을 참고하세요.

고아 일반 테이블

고아 InnoDB 테이블은 해당 데이터 파일(.ibd) 파일이 파일 시스템에 남아 있지만 데이터 사전에서 더 이상 데이터 파일을 올바르게 참조하지 않는 경우에 발생합니다. 이 시나리오에는 수동 개입이 필요합니다.

이 문제를 해결하려면 Cloud SQL 지원팀에 문의하세요. 지원팀에서 자리표시자 .frm 파일을 만든 다음 DROP TABLE 명령어를 사용하여 테이블을 삭제할 수 있습니다. 실패하면 InnoDB (.ibd) 파일을 데이터 디렉터리에서 수동으로 삭제해야 할 수 있습니다.

파일을 수동으로 삭제한 후 모든 테이블과 데이터베이스 구조를 백업할 수 있습니다.

DROP DATABASE를 사용하여 데이터베이스를 삭제하고 CREATE DATABASE를 사용하여 데이터베이스를 만듭니다. 이 마지막 단계에서는 영향을 받는 데이터베이스에 연결된 애플리케이션의 다운타임이 필요할 수 있습니다.

지원 계약이 없는 경우 셀프 서비스 방법에서 문제 해결 단계를 확인하세요.

셀프 서비스 문제 해결

다음 셀프 서비스 문제 해결 방법은 개별 테이블 삭제가 작동하지 않을 때 고아 테이블을 삭제하기 위해 전체 데이터베이스를 삭제하거나 마이그레이션하는 방법을 포함합니다. 이 방법은 방해가 됩니다. 조직이 지원 계약을 체결한 경우 Cloud SQL 지원팀에 문의하여 도움을 받는 것이 좋습니다.

고아 임시 테이블을 삭제하려면 먼저 고아 임시 테이블의 단계를 따르세요. DROP TABLE 명령어가 실패하면 다음 제안사항을 시도해 보세요.

시작하기 전에

데이터 손실 위험을 줄이기 위해 전체 인스턴스 백업을 수행하는 것이 좋습니다.
애플리케이션 다운타임의 가능성을 줄이기 위해 인스턴스를 클론하고 프로덕션 환경에서 완료하기 전에 다음 마이그레이션 단계를 확인하는 것이 좋습니다.

자세한 내용은 인스턴스 클론을 참고하세요.

객체 마이그레이션을 사용하여 스키마 삭제

데이터베이스 객체 마이그레이션은 테이블과 같은 데이터베이스 객체를 임시 스키마로 이동하는 다단계 프로세스입니다.

프로시저, 함수, 뷰를 비롯한 다른 데이터베이스 객체를 백업합니다.
영향을 받는 스키마를 삭제하고 다시 만듭니다.
백업된 객체를 원래 스키마로 다시 가져옵니다.

이 마이그레이션 방법을 사용하면 일반적으로 애플리케이션 다운타임이 발생합니다. 중단을 최소화하려면 필요한 모든 스크립트를 미리 준비하세요. 예를 들어 스크립트가 다음을 처리할 준비가 되어 있는지 확인합니다.

테이블 이름을 바꾸고 임시 스키마로 이동합니다.
프로시저, 함수, 뷰 등 기타 데이터베이스 객체 백업
모든 데이터베이스 객체를 원래 스키마로 복원합니다.

이러한 스크립트가 준비되면 다음 단계를 완료합니다.

동일한 인스턴스에 임시 스키마 (예: fix_orphan_tables)를 만듭니다.
영향을 받는 스키마의 애플리케이션 트래픽을 중지합니다.
RENAME TABLE를 사용하여 모든 테이블을 임시 스키마로 이동합니다.
```
RENAME TABLE DB.TABLE_NAME TO fix_orphan_tables.TABLE_NAME;
```
다음을 바꿉니다.
- DB: 사용할 데이터베이스 이름입니다.
- TABLE_NAME: 테이블 이름
뷰, 루틴, 저장 프로시저, 트리거, 이벤트와 같은 데이터베이스 객체를 백업합니다. 이를 위한 한 가지 방법은 mysqldump를 사용하는 것입니다.
```
mysqldump -u USER --password=PASSWORD \
  -h HOST_IP --set-gtid-purged=OFF --no-data --no-create-db  \
  --no-create-info --routines --triggers --skip-opt --events \
  DB > DB_export.sql
```
다음을 바꿉니다.
- USER: 사용자 이름입니다.
- PASSWORD: 데이터베이스 비밀번호입니다.
- HOST_IP: 호스트의 IP 주소입니다.
- DB: 사용할 데이터베이스 이름입니다.
SHOW CREATE VIEW 명령 스니펫을 사용하여 뷰를 수동으로 백업하는 것이 좋습니다.
고아 테이블이 포함된 스키마를 삭제합니다.
원래 이름으로 스키마를 만듭니다.
고아 테이블이 삭제되었는지 확인합니다.
```
SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE '%ORPHAN_TABLE_NAME</var>';
```
ORPHAN_TABLE_NAME을 고아 테이블 이름으로 바꿉니다.
테이블을 원래 스키마로 다시 복사합니다.
```
RENAME TABLE fix_orphan_tables.TABLE_NAME TO DB.TABLE_NAME;
```
다음을 바꿉니다.
- TABLE_NAME: 테이블 이름
- DB: 사용할 데이터베이스 이름입니다.
4단계에서 가져온 백업에서 모든 데이터베이스 객체를 복사합니다.
```
mysql -u USER \
  --password=PASSWORD \
  -h <var>HOST_IP \
  -D<var>DB < <var>DB_export.sql
```
다음을 바꿉니다.
- USER: 사용자 이름입니다.
- PASSWORD: 데이터베이스 비밀번호입니다.
- HOST_IP: 호스트의 IP 주소입니다.
- DB: 사용할 데이터베이스 이름입니다.
CREATE VIEW 문을 사용하여 뷰를 다시 만들어 수동으로 복원하는 것이 좋습니다.
이전에 중지한 애플리케이션 트래픽을 재개합니다.

덤프를 사용하여 스키마를 삭제하고 동일한 인스턴스에 로드

고아 테이블을 삭제하는 또 다른 방법은 영향을 받는 스키마를 완전히 덤프하고 스키마를 삭제하고 다시 만든 다음 덤프를 복원하는 것입니다. 이 방법이 더 빠르고 덜 복잡한 경우도 있습니다. 중단을 최소화하려면 모든 백업 및 복원 스크립트를 미리 준비해야 합니다.