다음 섹션에있는 모든 항목을 읽고 항목 중 하나가 응용 프로그램에 영향을 미치는지 여부를 확인합니다.

알려진 문제 또는 호환되지 않는 변경이라는 마크가 가진 변화에 특히주의하십시오. 이전 버전의 MySQL과 호환되지 않는 이러한 변경으로 업그레이드하기 전에주의해야 할 수 있습니다. 우리의 목표는 그 변경을 피할 수 있지만 각 릴리스 간의 비 호환성보다 더 심각한 문제를 해결하기 위해 필요한 경우도 있습니다. 사용하는 설치에 적용 업그레이드 문제에 특별한 처리를 필요로하는 호환성 부족과 관련이있는 경우 호환성 부족의 설명의 지침을 따르십시오. 여기에는 테이블의 덤프 및 리로드 또는 CHECK TABLE 과 REPAIR TABLE 과 같은 명령문의 사용이 포함될 수 있습니다.

덤프 및 리로드의 자세한 내용은 섹션 2.11.4 "테이블 또는 인덱스를 다시 만들거나 복구" 를 참조하십시오. USE_FRM 옵션을 사용 REPAIR TABLE 과 관련된 절차는 업그레이드 전에 수행해야합니다. 테이블을 만드는 데 사용한 것과 다른 버전의 MySQL이 문을 사용하면 (즉, 업그레이드 후에는이 문을 사용하면) 테이블이 손상 될 수 있습니다. 섹션 13.7.2.5 "REPAIR TABLE 구문" 을 참조하십시오.

새로운 버전의 MySQL 업그레이드하기 전에 현재 사용하고있는 MySQL 버전과 업그레이드 버전 사이에서 테이블 형식 또는 문자 집합 또는 데이터 정렬로 변경이 있었는지 여부를 섹션 2.11.3 "테이블 또는 인덱스 재구성이 필요한지 확인 " 에서 확인하십시오. 이 경우 그 변경에 따라 MySQL 버전 간의 호환성 부족이 발생하는 경우는 섹션 2.11.4 "테이블 또는 인덱스를 다시 만들거나 복구" 의 단계를 사용하여 영향을받는 테이블을 업그레이드 할 가 필요합니다.

MySQL의 새로운 버전으로 업그레이드 한 후 mysql_upgrade를 실행합니다 ( 섹션 4.4.7 "mysql_upgrade - MySQL 테이블 체크 및 업그레이드" 를 참조하십시오). 이 프로그램은 테이블을 확인하고 필요에 따라 복구를 시도합니다. 또한 부여 테이블을 업데이트하여 최신 구조를 갖게하고 새로운 기능을 활용할 수 있도록합니다. (MySQL 릴리스에는 새로운 권한 또는 기능을 추가하기 위하여 부여 테이블의 구조를 변경하는 것도 있습니다.)

mysql_upgrade는 도움말 테이블의 내용은 업그레이드되지 않습니다. 업그레이드 절차는 섹션 5.1.10 "서버 측의 도움말" 을 참조하십시오.

MySQL Server를 Windows에서 사용하려면 섹션 2.3.7 "Windows에서 MySQL 업그레이드" 를 참조하십시오.

복제를 사용할 경우 복제 설정의 업그레이드 섹션 17.4.3 "복제 설정을 업그레이드" 를 참조하십시오.

MySQL 5.6.6 이후에서는, MySQL Server의 일부 매개 변수의 기본값이 이전 릴리스와 다릅니다. 이러한 변화의 목적은 초기 설정 상태에서 뛰어난 성능을 제공하며, 데이터베이스 관리자가 설정을 수동으로 변경할 필요성을 낮추는 것입니다. 이러한 변화는 피드백의 취득에 따라 향후 릴리스에서 개정으로 이어질 수 있습니다.

매개 변수가 서로 다른 정적 기본 값을 가지는 경우도 있습니다. 또는 정적 값을 사용하는 것이 아니라 다른 관련 파라미터 나 서버 호스트 구성을 기반으로 공식을 사용하여 서버가 시작할 때 매개 변수를 자동 크기 설정하는 경우도 있습니다. 예를 들어, back_log 의 현재 설정은 이전의 기본 50에서 max_connections 의 값에 비례하는 양에 따라 상향 조정됩니다. 자동 크기 설정의 배후에는 고정 값보다 적절하다고 생각되는 파라미터 설정에 대한 결정을 내리는 데 사용할 수있는 정보를 서버가있는 경우, 그 결정을한다는 생각이 있습니다.

다음 표는 기본에 변화를 요약 한 것입니다. 이들은 모든 서버 시작시에 명시적인 값을 지정하여 재정의 할 수 있습니다.

이전 버전과의 호환성에 관해서 가장 중요한 변화는 :

따라서 기존의 MySQL 설치에서 업그레이드하는 경우에 이러한 매개 변수의 값을 이전 기본에서 아직 변경하지 않고, 후방 호환성이 과제 인 경우 이러한 이전 기본값으로 명시 적으로 세트하면 좋을 것입니다. 예를 들어, 서버 옵션 파일에 다음 행을 삽입합니다.

 [mysqld]
 innodb_file_per_table = 0
 innodb_checksum_algorithm = INNODB
 binlog_checksum = NONE

이러한 설정은 호환이 다음과 같이 유지됩니다.

MySQL 5.6.5에서는 4.1 이전 암호와 mysql_old_password 인증 플러그인은 비추천입니다. MySQL 4.1 이전에서 사용되는 오래된 해시 형식으로 저장되어있는 암호는 기본 암호 해시 방식을 사용하는 암호보다 안전하지 않기 때문에 사용하지 않도록하십시오. 4.1 이전 암호 해시를 가진 계정을 사용하여 연결하는 것을 방지하기 위해 secure_auth 시스템 변수는 기본적으로 활성화되었습니다. (이러한 암호 해시를 가진 계정에 접속을 허용하려면 --secure_auth=0 을 사용하여 서버를 시작하십시오.)

데이터베이스 관리자는 mysql_old_password 인증 플러그인을 사용하는 계정을 대신 mysql_native_password 를 사용하도록 변환하는 것이 좋습니다됩니다. 계정 업그레이드 지침은 섹션 6.3.8.3 "4.1 이전 암호 해시 방식과 mysql_old_password 플러그인에서 마이그레이션" 을 참조하십시오.

알려진 문제 : MySQL 5.6 이전의 개발 버전의 일부 (5.6.6에서 5.6.10)에서는 서버가 암호 해시 인증 플러그인이 일치하지 않는 계정을 만들 수 있습니다. 예를 들어, 기본 인증 플러그인이 mysql_native_password 의 경우 다음 문 시퀀스는 플러그인이 mysql_native_password 하지만 4.1 이전 암호 해시 ( mysql_old_password 에서 사용되는 형식) 계정입니다.

 SET old_passwords = 1;
 CREATE USER 'jeffrey'@ 'localhost'IDENTIFIED BY 'mypass';

이 불일치로 인해 MySQL Server에 연결할 수 없습니다 SET PASSWORD 를 OLD_PASSWORD() 또는 old_passwords=1 에서 사용할 수없는 등의 문제가 발생합니다.

MySQL 5.6.11에서는 이러한 불일치가 발생하지 않습니다. 대신 서버가 오류를 생성합니다.

 mysql> SET old_passwords = 1;
 mysql> CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass';
 ERROR 1827 (HY000) : The password hash does not have the expected
 format. Check if the correct password algorithm is being used with
 the PASSWORD () function.

불일치의 영향을 받고있는 계정을 처리하려면 데이터베이스 관리자는 해당 계정의 mysql.user 테이블의 행 plugin 컬럼 또는 Password 컬럼을 다른 컬럼과 일치하도록 수정할 수 있습니다.

호환되지 않는 변경하는 열의 DEFAULT 값이 테이블 작성시 sql_mode 값에 대해서는 유효하지만 행을 삽입하거나 갱신 할 때 sql_mode 값에 대해서는 유효하지 않다는 것을이 일어날 수 있습니다 . 예 :

 SET sql_mode = '';
 CREATE TABLE t (d DATE DEFAULT 0);
 SET sql_mode = 'NO_ZERO_DATE, STRICT_ALL_TABLES';
 INSERT INTO t (d) VALUES (DEFAULT);

이 경우 0은 CREATE TABLE 에 대해서는 받아 들여 져야하지만, INSERT 에 대해서는 받아 들여 져야하지 않습니다. 그러나 서버는 삽입 또는 업데이트시 DEFAULT 값을 현재 sql_mode 에 대해 평가하지 않았습니다. 이 예에서는 INSERT 성공하고 '0000-00-00' 을 DATE 컬럼에 삽입합니다.

MySQL 5.6.13에서 서버는 적절한 sql_mode 체크를 적용하여 삽입하거나 갱신 할 때 경고 또는 오류를 생성합니다.

그 결과, 명령문 기반 로깅 ( binlog_format=STATEMENT )를 사용하는 경우 복제에 대한 비 호환성이 발생합니다. 슬레이브가 업그레이드 된 경우 업그레이드되지 않은 마스터가 다음 예제를 오류없이 실행되지만 INSERT 는 슬레이브에서 실패 복제가 중지됩니다.

이를 해결하려면 마스터의 모든 새로운 문을 중지하고 슬레이브가 따라 잡을 때까지 기다립니다. 그 후, 슬레이브에 이어 마스터를 업그레이드합니다. 또는 새로운 문을 중지 할 수 없으면 마스터 일시적으로 행 기반 로깅 변경 ( binlog_format=ROW ) 모든 슬레이브가이 변경 시점에 생성 된 모든 바이너리 로그를 처리 할 때까지 기다립니다. 그 후, 슬레이브에 이어 마스터를 업그레이드하고 마스터를 문 기반 로깅으로 되돌립니다.

호환되지 않는 변경 : MySQL 5.6.11 이후에는 CREATE TABLE ... [SUB]PARTITION BY ALGORITHM= n [LINEAR] KEY (...) 를 지원합니다. 이것은 KEY 의 분할이 MySQL 5.1 Server와 호환 테이블을 만드는 데 사용할 수 있습니다 ( n = 1). (Bug # 14521864, Bug # 66462)이 구문은 MySQL 5.5.31 이후의 MySQL 5.5에서 지원되어 있지만 MySQL 5.6.10 이전 버전에서는 허용되지 않습니다. MySQL 5.5.31 이후의 MySQL 5.5 릴리즈 mysqldump이 옵션을 사용하여 테이블을 덤프 할 때 ALGORITHM 옵션이 포함되지만, 다음과 같이 조건 주석으로 처리합니다.

 CREATE TABLE t1 (a INT)
 / *! 50100 PARTITION BY KEY * / / *! 50531 ALGORITHM = 1 * / / *! 50100 ()
       PARTITIONS 3 * /

이러한 CREATE TABLE 문을 포함 덤프를 MySQL 5.6.10 이전의 MySQL 5.6 Server로 가져올 경우 버전있는 코멘트는 무시되지 않고 구문 오류가 발생합니다. 따라서 이러한 덤프 파일을 가져 오기 전에, MySQL 5.6 Server가 코멘트를 무시하도록 변경하거나 (문자열 !50531 이 출현 할 때마다 그것을 삭제하거나 !50611 로 대체함으로써) 또는 삭제합니다.

이것은 MySQL 5.6.11 이상을 사용하여 생성 된 덤프 파일은 문제가되지 않습니다. 여기에서는 ALGORITHM 옵션은 /*!50611 ... */ 를 사용하여 기록되어 있습니다.

호환되지 않는 변경 : TIME , DATETIME , 그리고 TIMESTAMP 컬럼은 MySQL 5.6.4 이전에 생성 된 테이블에 필요한 스토리지는 5.6.4 이상에서 생성 된 테이블에 필요한 스토리지와 다릅니다 . 이것은 5.6.4에서 이러한 시간 형이 소수 부분을 가지는 것을 허용하도록 변경 되었기 때문입니다. MySQL 5.5에서 MySQL 5.6.4 이상으로 업그레이드 한 뒤, MySQL 5.5에서 MySQL 5.6 TIME , DATETIME , 그리고 TIMESTAMP 타입도 업그레이드 할 것을 권장합니다. ALTER TABLE 은 현재 MySQL 5.5 및 MySQL 5.6.4 (이상) 바이너리 형식의 시간 컬럼을 포함하는 테이블 작성을 허용하지만이 때문에 .frm 파일을 사용할 수없는 경우에 테이블을 다시 작성하는 것이 더 어렵습니다. 또한 MySQL 5.6.4에서는 위의 시간 형은 공간 효율이 개선되고 있습니다. MySQL 5.6.4에서의 시간 형식 변경의 자세한 내용은 Storage Requirements for Date and Time Types 를 참조하십시오.

MySQL 5.6.16에서는 ALTER TABLE 은 ADD COLUMN , CHANGE COLUMN , MODIFY COLUMN , ADD INDEX 및 FORCE 조작에 대해 이전 시간 컬럼을 5.6 형식으로 업그레이드합니다. 따라서 다음 문은 이전 형식의 컬럼을 포함하는 테이블을 업그레이드합니다.

 ALTER TABLE tbl_name FORCE;

테이블을 재구성해야하므로이 변환은 INPLACE 알고리즘을 사용하여 수행 할 수 없습니다. 따라서 이러한 경우 ALGORITHM=INPLACE 를 지정하면 오류가 발생합니다. 필요하다면 ALGORITHM=COPY 를 지정합니다.

ALTER TABLE 은 시간 형식의 변환을 실행하지 않는 경우에는 SHOW WARNINGS : TIME/TIMESTAMP/DATETIME columns of old format have been upgraded to the new format 에서 볼 수있는 메시지를 생성합니다.

상기의 호환되지 않는 변경에 설명 된 시간 형식 변경을위한 DATETIME 형 및 TIMESTAMP 형을 포함한, MySQL 5.6.4 이전의 테이블을 MySQL 5.6.4 (이상)에 가져가 실패합니다. 이러한 시간 형을 가지는 MySQL 5.5 테이블을 MySQL 5.6.4 (이상)로 가져올 경우이 문제가 발생할 가능성이 가장 높은 시나리오입니다.

다음 단계에서는 원래 MySQL 5.6.4 이전의 .frm 파일을 사용하여 5.6.4 (이상)와 호환되는 행 구조를 가진 테이블을 다시 작성하는 해결 방법을 설명합니다. 이 단계는 .frm 파일을 원하는 인스턴스의 데이터 디렉토리에 복사하고 ALTER TABLE 을 사용하여 테이블의 스토리지 엔진 타입을 InnoDB 로 되 돌리는 것으로, MySQL 5.6.4 이전의 원래 .frm 파일을 , InnoDB 대신 Memory 스토리지 엔진을 사용하도록 변경할 수 있습니다. 테이블에 외래 키가없는 경우는 첫 번째 단계를 사용합니다. 테이블에 외래 키가 포함 된 경우에는 추가 단계를 포함 두 번째 단계를 사용합니다.

테이블에 외래 키가없는 경우 :

테이블에 외래 키가있는 경우 :

호환되지 않는 변경 : MySQL 5.6에서는 character_set_server 이 ucs2 , utf16 , utf16le 또는 utf32 의 경우 전문 스톱 워드 파일이로드되어 latin1 을 사용하여 검색됩니다. 서버의 캐릭터 세트가 ucs2 , utf16 , utf16le 또는 utf32 인 동안 FULLTEXT 인덱스를 가진 테이블이 작성된 경우에는 다음 문을 사용하여 복구하십시오.

 REPAIR TABLE tbl_name QUICK;

호환되지 않는 변경 : MySQL 5.6.20에서는 Bug # 69477에 대한 패치하여 BLOB 에 기록 된 Redo 로그의 크기가 Redo 로그 파일 크기의 10 %로 제한됩니다. 이 새로운 제한의 결과로 innodb_log_file_size 테이블의 행에서 발견 된 최대의 BLOB 데이터 크기의 10 배보다 큰 값으로 설정해야합니다. innodb_log_file_size 설정이 이미 최대의 BLOB 데이터 크기의 10 배가되어 있거나 테이블에 BLOB 데이터가 포함되지 않는 경우, 어떤 조치도 필요하지 않습니다.

MySQL 5.6.22에서는 Redo 로그 BLOB 쓰기 제한은 총 Redo 로그 크기 ( innodb_log_file_size * innodb_log_files_in_group )의 10 %에 이완했습니다. (Bug # 19498877)

MySQL 5.5에서는 예약되지 않은 일부 키워드는 MySQL 5.6에서는 예약되어있는 경우가 있습니다. 섹션 9.3 "예약어" 를 참조하십시오.

YEAR(2) 데이터 형식은 사용하기 전에 고려해야 할 특정 문제가 있습니다. MySQL 5.6.6 이후 YEAR(2) 는 비추천입니다. 기존 테이블의 YEAR(2) 컬럼은 이전과 같이 취급되지만 신규 또는 변경된 테이블에서 YEAR(2) 는 YEAR(4) 로 변환됩니다. 자세한 내용은 섹션 11.3.4 "YEAR (2)의 제한 및 YEAR (4)로 전환" 을 참조하십시오.

MySQL 5.6.6에서는 값 DEFAULT 를 저장 프로 시저 또는 저장 함수의 매개 변수 및 저장 프로그램의 로컬 변수에 할당 할 ( SET var_name = DEFAULT 문) 명시 적으로 불허합니다. 이것은 이전에는 지원되지 않고 허용된다는 설명도하지 않았지만, 어떤 사정으로 기존 코드에서이 구조가 사용 된 경우를 위해, 호환되지 않는 변경으로 플래그가 붙여졌습니다. 시스템 변수에 DEFAULT 를 지정할 수는 이전과 같이 허용되지만, DEFAULT 를 매개 변수와 지역 변수에 할당하면 구문 오류가 발생합니다.

MySQL 5.6.6 이상으로 업그레이드 한 후이 구조를 사용하는 기존의 저장 프로그램이 시작되면 구문 오류입니다. 5.6.5 이전의 mysqldump 파일이 5.6.6 이후에로드되면로드 조작이 실패하고 영향을받는 저장 프로그램 정의를 변경해야합니다.

MySQL은 TIMESTAMP 데이터 유형은 비 표준 방식이라는 점에서 다른 데이터 형식과 다릅니다.

이러한 비표준 동작은 TIMESTAMP 대해서는 기본 남아 있지만 MySQL 5.6.6 이후로는 사용되지 않으며 시작할 때 다음과 같은 경고가 표시됩니다.

 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated.
 Please use --explicit_defaults_for_timestamp server option (see
 documentation for more details).

경고가 같이 비표준 동작을 해제하려면 새로운 explicit_defaults_for_timestamp 시스템 변수를 시작할 때 사용합니다. 이 변수를 사용하면 서버는 TIMESTAMP 를 대신 다음과 같이 처리합니다.

복제에 사용되는 서버를 업그레이드하려면 먼저 슬레이브를 업그레이드 한 후 마스터를 업그레이드합니다. 마스터와 슬레이브 사이의 복제는 모든 explicit_defaults_for_timestamp 동일한 값을 사용하고 있다는 조건에서 작동됩니다.