3.6 Preparing Your Installation for Upgrade

3.6 업그레이드를 위한 설치 준비

최신 MySQL 9.5 릴리스로 업그레이드하기 전에, 현재 MySQL 9.4 또는 MySQL 8.4 서버 인스턴스가 아래에 설명된 사전 점검을 수행하여 업그레이드 준비가 되어 있는지 확인해야 합니다. 그렇지 않으면 업그레이드 과정이 실패할 수 있습니다.

참고

MySQL 서버 인스턴스가 업그레이드 준비가 되었는지 검증할 수 있는 MySQL Shell upgrade checker utility 사용을 고려하십시오. 이 유틸리티를 사용하면 업그레이드하려는 대상 MySQL Server 릴리스를 MySQL Server 8.0.11부터 현재 MySQL Shell 릴리스 번호와 일치하는 MySQL Server 릴리스 번호까지 범위 내에서 선택할 수 있습니다. upgrade checker 유틸리티는 지정한 대상 릴리스와 관련된 자동 점검을 수행하고, 사용자가 수동으로 수행해야 하는 추가 관련 점검을 안내합니다. upgrade checker는 MySQL의 모든 버그 수정, 이노베이션, LTS 릴리스에서 동작합니다. MySQL Shell 설치 방법은 여기에서 확인할 수 있습니다.

사전 점검:

1. 다음 문제들이 존재해서는 안 됩니다:

   • 사용되지 않는 데이터 타입 또는 함수를 사용하는 테이블이 없어야 합니다.

   • 고아 .frm 파일이 없어야 합니다.

   • 트리거에 누락되었거나 비어 있는 definer, 또는 잘못된 생성 컨텍스트가 없어야 합니다 (이는 SHOW TRIGGERS 또는 INFORMATION_SCHEMA TRIGGERS 테이블이 표시하는 character_set_client, collation_connection, Database Collation 속성으로 나타납니다). 이러한 트리거는 덤프한 뒤 복원하여 문제를 수정해야 합니다.

이러한 문제를 점검하려면 다음 명령을 실행합니다:

1mysqlcheck -u root -p --all-databases --check-upgrade

mysqlcheck가 오류를 보고하면, 해당 문제를 수정해야 합니다.

2. 네이티브 파티셔닝 지원이 없는 스토리지 엔진을 사용하는 파티션 테이블이 존재해서는 안 됩니다. 이러한 테이블을 식별하려면 다음 쿼리를 실행합니다:

1SELECT TABLE_SCHEMA, TABLE_NAME
2    FROM INFORMATION_SCHEMA.TABLES
3    WHERE ENGINE NOT IN ('innodb', 'ndbcluster')
4        AND CREATE_OPTIONS LIKE '%partitioned%';

이 쿼리로 보고되는 테이블은 모두 InnoDB를 사용하도록 변경하거나 비파티션 테이블로 변경해야 합니다. 테이블 스토리지 엔진을 InnoDB로 변경하려면 다음 구문을 실행합니다:

1ALTER TABLE table_name ENGINE = INNODB;

MyISAM 테이블을 InnoDB로 변환하는 방법은 Section 17.6.1.5, “Converting Tables from MyISAM to InnoDB”를 참조하십시오.

파티션 테이블을 비파티션 테이블로 변경하려면 다음 구문을 실행합니다:

1ALTER TABLE table_name REMOVE PARTITIONING;

3. 이전에는 예약어가 아니었던 일부 키워드가 MySQL 9.5에서 예약어일 수 있습니다. Section 11.3, “Keywords and Reserved Words”를 참조하십시오. 이로 인해 이전에 식별자로 사용되던 단어가 허용되지 않을 수 있습니다. 영향을 받는 구문을 수정하려면 식별자 쿼oting을 사용하십시오. Section 11.2, “Schema Object Names”를 참조하십시오.

4. MySQL 9.4 mysql 시스템 데이터베이스에는 MySQL 9.5 데이터 딕셔너리에서 사용하는 테이블과 동일한 이름을 가진 테이블이 존재해서는 안 됩니다. 이러한 이름의 테이블을 식별하려면 다음 쿼리를 실행합니다:

1SELECT TABLE_SCHEMA, TABLE_NAME
2FROM INFORMATION_SCHEMA.TABLES
3WHERE
4    LOWER(TABLE_SCHEMA) = 'mysql'
5    AND
6    LOWER(TABLE_NAME) IN
7    (
8    'catalogs',
9    'character_sets',
10    'check_constraints',
11    'collations',
12    'column_statistics',
13    'column_type_elements',
14    'columns',
15    'dd_properties',
16    'events',
17    'foreign_key_column_usage',
18    'foreign_keys',
19    'index_column_usage',
20    'index_partitions',
21    'index_stats',
22    'indexes',
23    'parameter_type_elements',
24    'parameters',
25    'resource_groups',
26    'routines',
27    'schemata',
28    'st_spatial_reference_systems',
29    'table_partition_values',
30    'table_partitions',
31    'table_stats',
32    'tables',
33    'tablespace_files',
34    'tablespaces',
35    'triggers',
36    'view_routine_usage',
37    'view_table_usage'
38    );

이 쿼리로 보고되는 테이블은 모두 드롭하거나 이름을 변경해야 합니다 (RENAME TABLE 사용). 이 과정에서는 해당 테이블을 사용하는 애플리케이션의 변경도 필요할 수 있습니다.

5. 외래 키 제약 조건 이름이 64자를 초과하는 테이블이 존재해서는 안 됩니다. 제약 조건 이름이 너무 긴 테이블을 식별하려면 다음 쿼리를 사용하십시오:

1SELECT TABLE_SCHEMA, TABLE_NAME
2FROM INFORMATION_SCHEMA.TABLES
3WHERE TABLE_NAME IN
4  (SELECT LEFT(SUBSTR(ID,INSTR(ID,'/')+1),
5               INSTR(SUBSTR(ID,INSTR(ID,'/')+1),'_ibfk_')-1)
6   FROM INFORMATION_SCHEMA.INNODB_SYS_FOREIGN
7   WHERE LENGTH(SUBSTR(ID,INSTR(ID,'/')+1))>64);

제약 조건 이름이 64자를 초과하는 테이블의 경우, 해당 제약 조건을 드롭한 후 64자를 초과하지 않는 제약 조건 이름으로 다시 추가해야 합니다 (ALTER TABLE 사용).

6. sql_mode 시스템 변수에 사용되지 않는 SQL 모드가 정의되어 있어서는 안 됩니다. 사용되지 않는 SQL 모드를 사용하려고 시도하면 MySQL 9.5가 시작되지 않습니다. 사용되지 않는 SQL 모드를 사용하는 애플리케이션은 이를 사용하지 않도록 수정해야 합니다. MySQL 9.5에서 제거된 SQL 모드에 대한 정보는 Server Changes를 참조하십시오.

7. 적절하게 셧다운된 MySQL 서버 인스턴스만 업그레이드해야 합니다. 인스턴스가 예기치 않게 셧다운된 경우, 인스턴스를 재시작한 뒤 업그레이드 전에 innodb_fast_shutdown=0으로 설정하고 셧다운해야 합니다.

8. 명시적으로 정의된 컬럼 이름이 64자를 초과하는 뷰가 존재해서는 안 됩니다 (MySQL 5.7에서는 컬럼 이름을 최대 255자까지 허용했습니다). 업그레이드 오류를 피하려면 이러한 뷰를 업그레이드 전에 변경해야 합니다. 현재로서는 컬럼 이름이 64자를 초과하는 뷰를 식별하는 유일한 방법은 SHOW CREATE VIEW를 사용하여 뷰 정의를 검사하는 것입니다. 또한 Information Schema VIEWS 테이블을 조회하여 뷰 정의를 검사할 수도 있습니다.

9. 개별 ENUM 또는 SET 컬럼 요소 길이가 255자 또는 1020바이트를 초과하는 테이블이나 저장 프로시저가 존재해서는 안 됩니다. MySQL 9.5 이전에는 ENUM 또는 SET 컬럼 요소의 최대 합계 길이가 64K였습니다. MySQL 9.5에서는 개별 ENUM 또는 SET 컬럼 요소의 최대 문자 길이가 255자이며, 최대 바이트 길이는 1020바이트입니다 (1020바이트 제한은 멀티바이트 문자 집합을 지원하기 위한 것입니다).

MySQL 8.0으로 업그레이드하기 전에 새로운 제한을 초과하는 모든 ENUM 또는 SET 컬럼 요소를 수정해야 합니다. 이를 수행하지 않으면 업그레이드가 오류와 함께 실패합니다.

10. MySQL 9.4 설치에는 MySQL 9.5에서 지원되지 않는 기능을 사용하고 있어서는 안 됩니다. 이와 관련된 변경 사항은 필연적으로 설치 환경에 따라 달라지지만, 다음 예시는 살펴봐야 할 항목의 유형을 보여 줍니다:

일부 서버 시작 옵션과 시스템 변수는 MySQL 9.5에서 제거되었습니다. Features Removed in MySQL 9.5와 Section 1.5, “Server and Status Variables and Options Added, Deprecated, or Removed in MySQL 9.5”를 참조하십시오. 이러한 항목을 사용하는 경우, 업그레이드 시 설정 변경이 필요합니다.

11. 업그레이드 시점에 lower_case_table_names 설정을 1로 변경할 계획이 있다면, 업그레이드 전에 스키마와 테이블 이름이 모두 소문자인지 확인해야 합니다. 그렇지 않으면 스키마 또는 테이블 이름의 대소문자 불일치로 인해 실패가 발생할 수 있습니다. 스키마와 테이블 이름에 대문자가 포함되어 있는지 확인하려면 다음 쿼리를 사용할 수 있습니다:

1mysql> select TABLE_NAME, if(sha(TABLE_NAME) !=sha(lower(TABLE_NAME)),'Yes','No') as UpperCase from information_schema.tables;

lower_case_table_names=1인 경우, 업그레이드 과정에서 테이블 및 스키마 이름을 검사하여 모든 문자가 소문자인지 확인합니다. 테이블 또는 스키마 이름에서 대문자가 발견되면 업그레이드 과정은 오류와 함께 실패합니다.

참고

업그레이드 시점에 lower_case_table_names 설정을 변경하는 것은 권장되지 않습니다.

MySQL 9.5로의 업그레이드가 위에서 설명한 문제들 중 하나로 인해 실패하면, 서버는 데이터 디렉터리에 대한 모든 변경 사항을 되돌립니다. 이 경우 모든 리두 로그 파일을 제거하고 기존 데이터 디렉터리에서 MySQL 9.4 서버를 재시작하여 오류를 해결하십시오. 리두 로그 파일 (ib_logfile*)은 기본적으로 MySQL 데이터 디렉터리에 위치합니다.

오류를 수정한 후에는 업그레이드를 다시 시도하기 전에 innodb_fast_shutdown=0을 설정하여 느린 셧다운을 수행하십시오.