MySQL 데이터베이스를 다른 머신으로 복사하기

일반적인 규칙에 따라서, 하나의 릴리즈 시리즈에서 다른 시리즈로 업그레이드를 할 경우에는, 시리즈를 건너 띄기 보다는
바로 다음의 시리즈로 업그레이드할 것을 권장한다. 예를 들면, 여러분이 현재 MySQL 3.23을 사용하고 있고 새로운 시리즈로 업그레이드를
하고자 한다면, 4.1 또는 5.0으로 곧장 하지 말고 4.0으로 업그레이드를 하도록 한다.

아래의 사항들은 여러분이 업그레이드를 할 때마다 검사해야 하는 체크 리스트 항목들이다:

  • MySQL4.1에서 5.0으로 업그레이드를 하기 전에, Section 2.10.2, “MySQL 4.1에서 5.0으로 업그레이드 하기”)
    뿐만 아니라 Appendix D, MySQL Change History도 읽기 바란다. 여기에는 MySQL5.0에 포함되어 있는 새로운 기능들
    또는 4.1과의 차이점에 대한 내용이 들어있다. 4.1 이전 버전에서 4.1 버전으로 업그레이드를 하고자 한다면, 현재 사용 버전에서부터
    차례대로 업그레이들 실행해서 4.1 버전까지 진행하도록 해야 하며, 그 다음에 5.0 버전으로 업그레이드를 실행해야 한다. 4.1 버전 또는 그
    이전 버전에서 업그레이드에 대한 보다 자세한 정보는 MySQL 3.23, 4.0, 4.1 Reference Manual을 참조하기 바란다.
  • 업그레이드를 하기 전에, 그랜트 테이블을 갖고 있는 mysql 데이터 베이스를 포함해서 모든 데이터 베이스를 백업 받아두기 바란다.
  • MySQL 버전 중에 어떤 것은 그랜트 테이블에 새로운 권한 또는 기능들을 추가 하기 위해 그 구조를 변경시킨다. 새로운 버전으로
    업그레이드를 할 때마다, 그랜트 테이블을 갱신시켜서 해당 업그레이드 버전이 갖고 있는 새로운 기능을 항상 그랜트 테이블이 갖고 있도록 해야
    한다. Section 5.6.1, “mysql_fix_privilege_tables – 업그레이드 MySQL 시스템 테이블”을 참조할 것.
    MySQL Korea 저작권 공지 :
    http://www.mysqlkorea.co.kr/sub.html?mcode=others&scode=04
  • 윈도우에서 MySQL 서버를 구동시킨다면, Section 2.3.14, “윈도우에서 MySQL 업그레이드 하기”를 참조할 것.
  • 리플리케이션을 사용하고 있다면, Section 6.6, “리플리케이션 설정 업그레이드 하기”를 참조하여 보다 자세한 정보를 얻기 바란다.
  • mysqld-max라는 이름의 서버가 포함된 MySQL-Max배포판을 전에 설치 하였고, 그리고 나중에 MySQL의 non-Max버전으로
    업그레이드를 하였다면, mysqld_safe는 여전히 예전 mysqld-max 서버를 구동시키고자 한다. 만약에 이러한 업그레이드를 한다면,
    수동으로 예전 mysqld-max 서버를 삭제해서 mysqld_safe 서버가 새로운 mysqld 서버를 실행하게끔 해주어야 한다.

동일한 MySQL릴리즈 시리즈 버전 내에서 업그레이드를 한다면 MySQL포맷 파일과 데이터 파일을 서로 다른 버전 간에
언제든지 이동 시킬 수 있다. MySQL을 구동 시킬 때 문자 셋을 변경하고자 한다면, 모든 MyISAM 테이블에서 myisamchk -r -q
–set-collation=collation_name을 실행시켜야 한다. 그렇지 않으면, 인덱스를 올바르게 순서화하지 못할 수 있는데, 그
이유는 문자 셋을 변경하면 정렬 순서까지도 변경 시키기 때문이다.

새로운 버전을 사용하는 것에 부담을 가진다면, 새로운 버전을 설치하기 전에 예전 mysqld의 이름을 변경시켜 놓도록
한다. 예를 들면, 여러분이 지금 MySQL 4.1.13을 사용하고 있고 5.0.10으로 업그레이드를 하고 싶다면, 현재의 서버를
mysqld에서 mysqld-4.1.13로 변경시켜 놓는다. 그런 후에 만약에 새로운 mysqld에 예상하지 못한 문제가 생긴다면, 간단히
이것을 셧다운 시킨 다음에 예전 mysqld를 재 실행시키면 된다.

업그레이드를 한 후에, 클라이언트를 재 컴파일 하는데 문제가 발생한다면, 예를 들면 Commands out of
sync 또는 예상하지 못한 코어 덤프의 경우, 그것은 여러분이 프로그램을 컴파일할 때 아직도 예전 헤더(header) 또는 라이브러리 파일들을
사용하고 있다는 것이다. 이와 같은 경우에는, 우선 mysql.h 파일과 libmysqlclient.a 의 생성 날짜를 검사해서 이것들이 새로운
MySQL이 생성한 것인지를 확인 한다. 그렇지 않다면, 프로그램을 새로운 해더와 라이브러리를 가지고 컴파일 한다.

새로운 mysqld 서버를 구동할 수 없다거나 패스워드 없이 접속하는 것이 불가능하다면, 예전 설치 때 만들어진
my.cnf 파일이 있는지 확인해 본다. 이것은 –print-defaults 옵션을 사용해서 확인할 수 있다 (예를 들면, mysqld
–print-defaults). 이 명령어를 실행한 후에 프로그램 이름 이외의 것이 화면에 나타난다면, 서버와 클라이언트의 실행에 영향을
미치는 my.cnf 파일이 존재하는 것이다.

MySQL의 새로운 릴리즈를 설치할 때마다 펄 (Perl) DBD::mysql 모듈을 재 설치하고 재 구축하는 것은
좋은 생각이다. PHP mysql 확장자 및 Python MySQLdb 모듈과 같은 다른 MySQL 인터페이스에 대해서도 똑 같은 작업을 하는
것이 좋다.

MySQL 5.0에서 업그레이드 하기

5.0에서 5.0.10 또는 그 이상 버전으로 업그레이드를 할 때에는 그랜트 테이블을 업그레이드해야 한다는 점을
알아두기 바란다. 그렇지 않으면, 스토어드 프로시저 및 함수 생성이 진행되지 않는다. Section 5.6.1,
“mysql_fix_privilege_tables – 업그레이드 MySQL 시스템 테이블”을 참조할 것.

MySQL 4.1에서 5.0으로 업그레이드 하기

Note: 새로운 소프트웨어 버전으로 업그레이드를 하기 전에는 데이터를 백업 받아 두는 것이 좋다. 비록 MySQL이
최고 수준의 성능을 보장한다고 하더라도, 여러분은 스스로 데이터를 백업하여 데이터의 안전을 보장해야 한다. MySQL은 5.0 이전 버전에서
5.0으로 업그레이드 하기 위해 테이블을 덤프하여 재 로드(re-load)하는 것을 권장한다.

일반적으로, 4.1에서 5.0으로 업그레이드를 할 때 아래의 과정을 진행해야 한다:

  • 이 섹션 후반에 나와 있는 변경 리스트(change list)의 항목(items)을 검사해서 그 중에 어떤 것이 여러분의 어플리케이션에
    영향을 줄 수 있는지 확인한다. 특히Incompatible change라고 되어 있는 부분을 주목한다. 이러한 것들은 예전 MySQL 버전과의
    비호환성(incompatibilities)을 야기하기 때문에, 업그레이드를 하기 전에 무엇인가를 별도로 해야 한다.
  • MySQL 5.0 변경 디렉토리를 읽음으로써5.0에서 사용할 수 있는 중요한 새로운 기능들을 알아 본다. Section D.1,
    “Changes in release 5.0.x (Production)”를 참조할 것.
  • 윈도우에서 MySQL 서버를 구동시킨다면, Section 2.3.14, “윈도우에서 MySQL 업그레이드 하기”를 참조할 것. 윈도우
    MySQL서버중에 두 개의 이름이 변경된다는 점도 역시 알아두기 바란다. Section 2.3.8, “MySQL 서버 타입 선택하기”를 참조할
    것.
  • MySQL 5.0은 스토어드 프로시저에 대한 지원을 추가 하였다. 이러한 지원은 mysql 데이터 베이스 안에 proc 테이블을 필요로
    한다.
  • MySQL 5.0은 뷰(view)를 지원한다. 이 지원은 mysql 데이터 베이스에서 user와 db 테이블에 추가적인 권한 컬럼들을
    요구하게 된다. 이러한 컬럼들을 만들기 위해서는, Section 5.6.1, “mysql_fix_privilege_tables – 업그레이드
    MySQL 시스템 테이블”에서 설명하는 방식으로 mysql_fix_privilege_tables 스크립트를 구동 시켜야 한다.
  • 리플리케이션을 사용하고 있다면, Section 6.6, “리플리케이션 설정 업그레이드 하기”를 참조하여 여러분의 리플리케이션을 업그레이드
    하기 바란다.

MySQL 4.1이 5.0으로 업그레이드 되면서 표준 SQL과의 호환성을 우지하기 위한 몇 가지 변화가 있다. 이런
변경은 여러분이 사용하고 있는 어플리케이션에도 영향을 미칠 것이다.

다음에 나오는 것은 어플리케이션에 영향을 열 수 있는 것들과 5.0으로 업그레이드를 할 때 주의해야 할 사항들에 대한
설명이다.

Server Changes:

  • Incompatible change: TEXT 컬럼에 있는 InnoDB 와 MyISAM 테이블을 위한 엔드-스페이스(end-space)용
    인덱싱 순서가 변경 되었다. 5.0.3버전 이후에, TEXT 인덱스는 마지막에서 스페이스-패드(space-padded)와 비교된다(마치
    MySQL이 CHAR, VARCHAR 및 TEXT 필드를 정렬시키는 것처럼). TEXT 컬럼에 인덱스가 있다면, 여기에서 CHECK TABLE을
    실행해야 한다. 실행 후에 에러가 발생하면, 인덱스를 재 구축한다: InnoDB 테이블이 있다면 테이블을 덤프하고 재 로드 하거나,
    또는MyISAM 테이블이 있다면 OPTIMIZE TABLE 또는 REPAIR TABLE를 실행한다.
  • Warning: Incompatible change. BINARY 컬럼에 대해서는, 패드(pad) 값과 이것을 다루는 방법이 MySQL
    5.0.15이후로 변경 되었다. 현재 삽입을 위한 패드 값은 스페이스가 아니라 0x00 이고, 그리고 선택을 위한 패드 값
    스트라이핑(stripping)은 없다. 자세한 사항은, Section 11.4.2, “BINARY 와 VARBINARY 타입”을 참조할 것.
  • Incompatible change: MySQL 5.0.3에서 5.0.5까지 DECIMAL 컬럼을 가지고 생성된 MyISAM 과
    InnoDB 테이블은 5.0.6으로 업그레이드를 한 후에는 깨져 버린다(corrupted). 업그레이드를 하기 전에 이 테이블들을
    덤프(Dump)해 놓은 다음에, 업그레이드를 한 후에 다시 재 로드 한다. (동일한 비호환성 문제가 5.0.6에서 생성한 테이블을 5.0.3과
    5.0.5로 다운 그레이드할 때에도 발생한다.)
  • Incompatible change: DECIMAL구현 방법이 MySQL 5.0.3에서 변경 되었다. 어플리케이션이 이 변경 사항을
    인식하도록 해야 하는데, 자세한 내용은, Section 21.2, “DECIMAL 데이터 타입 변경”을 참조하기 바란다.
    DECIMAL
    과 NUMERIC 고정-소수점 타입(fixed-point data types)의 구현 방법의 변경으로 인해 서버는 표준 SQL의 규칙을 보다
    확실하게 준수하게 되었다. 예를 들면, DECIMAL(3,1)의 데이터 타입은 99.9의 최대 값을 저장한다. MySQL 5.0.3 이전에서는,
    서버는 보다 큰 숫자를 저장했어야 했다. 즉, 서버는 100.0에 대해 100.0으로 저장을 했다. MySQL 5.0.3 이후에는, 서버는
    100.0을 절사해서(clips) 최대 가능 숫자 99.9로 저장된다. 여러분이 5.0.3 이전 버전에서 생성된 테이블을 갖고 있고 이 테이블이
    부동 소수점 데이터 타입을 갖고 있다면, 이 데이터를 변경 시켜야 한다. 예를 들면:
    ALTER TABLE tbl_name MODIFY
    col_name DECIMAL(4,1);
  • Incompatible change: MySQL 5.0.3 이후부터는, 서버가 메인 함수 심볼에 추가적으로 정의된 보조
    심볼(auxiliary symbol)(예를 들면 xxx_init 또는 xxx_deinit 심볼)을 적어도 하나 이상 갖고 있지 않는다면 디폴트로
    더 이상 사용자 정의 함수를 로드 하지 않는다. 이런 동작은 –allow-suspicious-udfs 옵션을 가지고 우선적으로 실행시킬 수
    있다. Section 24.2.4.6, “사용자 정의 함수 보안 사전 대책”을 참조할 것.
  • Incompatible change: 업데이트 로그는 MySQL 5.0에서 삭제 되었다. 여러분이 전에 이것을 활성화 시켰다면, 이것
    대신에 바이너리 로그를 활성화 시켜야 한다.
  • Incompatible change: ISAM 스토리지 엔지에 대한 지원은 없어졌다. 만약에 ISAM 테이블을 갖고 있다면,
    업그레이드하기 전에 그 테이블을 변환시켜야(convert) 한다. 예를 들면, MyISAM 스토리지 엔진을 사용하도록 ISAM 테이블을 변환
    시키기 위해서는, 다음의 명령문을 사용한다:
    ALTER TABLE tbl_name ENGINE = MyISAM; 데이터 베이스에 있는
    각각의 ISAM 테이블에 대해 비슷한 명령문을 실행한 다.
  • Incompatible change: MySQL5.0부터는 MyISAM 테이블에 있는 RAID 옵션에 대한 지원이 삭제 되었다. 이러한
    옵션을 사용하는 테이블을 갖고 있다면, 업그레이드 하기 전에 변환을 해 놓아야 한다. 한 가지 방법은 mysqldump을 가지고 덤프를 하고,
    덤프 파일을 CREATE TABLE 명령문에 있는 RAID 옵션을 삭제하고 덤프 파일을 다시 로드 하는 것이다. 다른 방법으로는 CREATE
    TABLE new_tbl … SELECT raid_tbl을 사용해서 RAID 테이블로부터 새로운 테이블을 생성하는 것이다. 하지만, 명령문의
    CREATE TABLE 부분에는 반드시 인덱스뿐만 아니라 컬럼 속성을 재 생성을 위한 충분한 정보가 포함되어야 하는데, 그렇지 않을 경우에는
    컬럼 속성을 잃어 버리게 되고 인덱스는 새로운 테이블에서 사라지게 될 것이다. Section 13.1.5, “CREATE TABLE 신텍스”를
    참조할 것.
    주어진 데이터베이스에 있는 RAID 테이블을 위한 .MYD 파일들은 00에서 ff까지의 16진수로 이름이 되어 있는 서브
    디렉토리에 있는 데이터 디렉토리 아래에 저장된다. RAID 옵션을 가지고 있는 모든 테이블을 변환시킨 다음에도, 이러한 RAID-관련 서브
    디렉토리는 아직까지 존재하게 되지만 삭제가 가능하다. 이 디렉토리가 비어 있음을 확인하고, 수동으로 이것들을 삭제한다. (디렉토리가 비어 있지
    않으면, 아직까지도 변환되지 않은 RAID 테이블이 있는 것이다.)
  • MySQL 5.0.6에서는, 스토어드 루틴과 트리거의 바이너리 로깅이 변경 되었다. 이 변경 사항은 Section 17.4, “스토어드
    루틴과 트리거의 바이너리 로깅”에서 설명하듯이 보안, 리플리케이션, 그리고 데이터 복구와 관련되어 있다.

SQL Changes:

  • Incompatible change: 이전에는, 잠금 대기 타임 아웃(lock wait timeout)은 InnoDB가 현재의 모든
    트랜젝션을 롤백(roll back)하게끔 만들었다. MySQL 5.0.13이후에는, 이것은 가장 최신의 SQL명령문만 롤백 시킨다.
  • Incompatible change: 트리거용 이름 공간(namespace)은 MySQL 5.0.10에서 변경 되었다. 이전 버전에서는,
    트리거의 이름은 테이블 별로 서로 틀린 것을 사용해야 했다. 이제는 스키마(데이터베이스)별로 서로 틀린 이름을 사용해야 한다. 이 변경은 이제는
    DROP TRIGGER 신텍스가 테이블 이름 대신에 스키마 이름을 사용한다는 것을 의미하는 것이다(스키마 이름은 옵션 사항이며, 만약에 생략
    되면, 현재의 스키마가 사용 된다).
    MySQL 5.0 이전 버전에서 MySQL 5.0.10 또는 그 이후 버전으로 업그레이드를 할 때,
    여러분은 모든 트리거를 드롭(drop)시킨 후에 다시 생성 시켜야 하는데, 그렇지 않으면 DROP TRIGGER가 업그레이드 후에 동작하지
    않는다. 이것을 실행하기 위한 권장 과정이 여기에 있다:

    1. MySQL 5.0.10 또는 그 이후 버전으로 업그레이드를 해서 INFORMATION_SCHEMA.TRIGGERS 테이블에 있는 트리거
      정보를 접근할 수 있도록 한다. (이것은 5.0.10 이전 트리거에 대해서도 실행해야 한다.) [출처] ::: MySQL Korea ::: –
      http://www.mysqlkorea.co.kr/ MySQL Korea 사이트의 컨텐츠 소유권은 MySQL Korea 에 있으므로 허락 없이
      이를 무단전재 하는 경우 저작권법에 민형사적 책임을 지게 되므로 절대 무단 사용을 금해 주시기 바 랍니다 MySQL Korea 저작권 공지 :
      http://www.mysqlkorea.co.kr/sub.html?mcode=others&scode=04
    2. 다음의 SELECT 명령문을 사용해서 모든 트리거 정의문을 덤프한다Dump all trigger definitions using the
      following SELECT statement:

      SELECT CONCAT('CREATE TRIGGER ', t.TRIGGER_SCHEMA, '.',t.TRIGGER_NAME,
      
                    ' ', t.ACTION_TIMING, ' ', t.EVENT_MANIPULATION, ' ON ',
      
                 t.EVENT_OBJECT_SCHEMA, '.', t.EVENT_OBJECT_TABLE,
      
               ' FOR EACH ROW ', t.ACTION_STATEMENT, '//' )
      
      INTO OUTFILE '/tmp/triggers.sql'
      
      FROM INFORMATION_SCHEMA.TRIGGERS AS t;
      
      
              

      명령문은 INTO OUTFILE을 사용하기 때문에, 여러분은 FILE 권한을 반드시 갖고 있어야 한다. 이
      파일은 서버 호스트에서 생성 되어진다; 원하면 다른 이름을 사용 한다. 100% 안전을 보장하기 위해, triggers.sql 파일에 있는
      트리거 정의문을 조사하고, 이 파일의 복사본을 만들어 둔다.

    3. 서버를 종료하고 데이터 디렉토리에 있는 모든 .TRG 파일을 삭제해서 모든 트리거를 드롭시킨다. 데이터 디렉토리로 위치를 변경한 다음에
      다음의 명령어를 입력한다:

              shell> rm */*.TRG
              
    4. 서버를 구동 시킨 다음에 triggers.sql 파일을 사용해서 모든 트리거를 재 작성한다: 예를 들면:
              mysql> delimiter // ;
              mysql> source /tmp/triggers.sql //
              
    5. SHOW TRIGGERS 명령문을 사용해서 모든 트리거가 성공적으로 생성되었는지 확인한다.
  • Incompatible change: MySQL 5.0.15 이후에는, CHAR() 함수는 연결 문자 셋에 있는 스트링이 아닌 바이너리
    스트링을 리턴 한다. USING charset_name 옵션 구문은 이것 대신에 특수 문자 셋을 리턴할 때 사용할 수 있다. 또한, 256보다
    큰 인수들은 다중 문자(multiple character)를 만들어 낸다. 더 이상 모듈로 256을 해석해서 단일 문자 셋을 만들지는 못한다.
    이러한 변경으로 인해 몇 가지 비호화성이 발생하게 되었다:

    • CHAR(ORD('A')) = 'a' 는 더 이상 허용(true)되지 않는다:
      mysql> SELECT CHAR(ORD('A')) = 'a';
      +----------------------+
      | CHAR(ORD('A')) = 'a' |
      +----------------------+
      |                    0 |
      +----------------------+
      
              

      대소 문자를 구분하지 않는 비교문을 실행하기 위해서는, USING 구문을 추가 하거나 또는 결과를 변환
      시킴으로써 비-바이너리(non-binary)문자 셋에 결과 스트링을 만들 수 있다:

      mysql> SELECT CHAR(ORD('A') USING latin1) = 'a';
      +-----------------------------------+
      | CHAR(ORD('A') USING latin1) = 'a' |
      +-----------------------------------+
      |                                 1 |
      +-----------------------------------+
      mysql> SELECT CONVERT(CHAR(ORD('A')) USING latin1) = 'a';
      +--------------------------------------------+
      | CONVERT(CHAR(ORD('A')) USING latin1) = 'a' |
      +--------------------------------------------+
      |                                          1 |
      +--------------------------------------------+
      
      
    • CREATE TABLE … SELECT CHAR(…)는 VARBINARY 컬럼을 만들고, VARCHAR 컬럼을 만들지는 않는다.
      VARCHAR 컬럼을 만들기 위해서는, USING 또는 CONVERT()를 사용해서 CHAR() 결과를 변환해서 위에서 설명하였듯이 비 바이너리
      문자 셋에 넣도록 한다.
    • 이전 버전에서는, 다음의 명령문은 0x00410041 (ucs2 스트링 값으로'AA'를 씀) 값을 테이블에 넣었다:
      CREATE TABLE t (ucs2_column CHAR(2) CHARACTER SET ucs2);
      INSERT INTO t VALUES (CHAR(0x41,0x41));
            

      MySQL 5.0.15 이후에는, 이 명령문은 단일 ucs2 문자를 0x4141값과 함께 넣는다.

  • Incompatible change: MySQL 5.0.12 이후에는, 외부 결합 변형(outer join variants)를 포함해서,
    내추럴 결합(natural)과 USING을 사용하는 결합은 SQL:2003 표준을 준수한다. 여기에는 NATURAL 결합에 대한 여분의 결과
    컬럼 삭제와 USING 구문을 사용해서 지정된 결합과 결과 컬럼의 올바른 순서도 포함되어 변경 되었다. 콤마 연산자의 우선권 역시 지금은
    JOIN보다 떨어진다.
    이러한 변경을 통해 MySQL은 표준 SQL과 보다 호환성을 유지하게 되었다. 하지만, 이러한 변경으로 인해 어떤
    결합에서는 서로 다른 결과를 만들기도 한다. 또한, 5.0.12에서는 올바르게 작동하였던 쿼리들 중에는 표준과 호환을 유지하기 위해 새로 작성
    되어야 하는 것들도 있다. 어떤 쿼리를 다시 작성해야 하는지에 대한 사항과 변경 범위 및 예제에 대한 보다 자세한 정보는 Section
    13.2.7.1, “JOIN 신텍스”를 참조하기 바란다.
  • Incompatible change: MySQL 5.0.13이전에는, GREATEST(x,NULL) 와 LEAST(x,NULL)은x 가
    NULL 값이 아닐 때 x를 리턴 했었다. 5.0.3이후에는, 양쪽 함수는 NULL이 되는 인수가 있으면 둘 다 NULL을 리턴 한다. 이것은
    오라클과 같다. 이러한 변경으로 인해 예전 동작에 관련된 어플리케이션에 대해서는 문제가 나타나게 된다.
  • Incompatible change: MySQL 4.1.13/5.0.8 이전에는, 0(zero)를 추가해서 DATETIME 값을 숫자
    형태로 변환시키면 YYYYMMDDHHMMSS 포맷이 만들어졌었다. 지금은 DATETIME+0 의 결과로 YYYYMMDDHHMMSS.000000
    포맷이 만들어 진다.
  • 4.1에서는 사용 예약(reserved)되지 않았던 키워드들이 5.0에서는 사용 예약 되어 진다. Section 9.5, “MySQL에서
    사용 예약된(reserved) 단어 사용하기”를 참조할 것.
  • DECIMAL 컬럼이 이제는 보다 효율적인 포맷으로 저장된다. 새로운 DECIMAL 타입을 사용하도록 테이블을 변환하기 위해서는, 이
    테이블에서 ALTER TABLE을 실행해야 한다. ALTER TABLE은 테이블의 VARCHAR 컬럼이 새로운 VARCHAR 데이터 타입을
    사용하도록 하는 변경도 함께 해 준다. 예정 어플리케이션과의 비호환성에 대한 보다 많은 정보는 Chapter 21, Precision Math를
    참조할 것
  • MySQL 5.0.3 및 그 이후 버전은 DECIMAL 값(64 진법 숫자)를 사용해서 식을 계산할 때와 정확한 값을 얻기 위한
    절사(rounding)을 위해서 precision math를 사용한다. Chapter 21, Precision Math를 참조할 것.
  • MySQL 4.1에서 사용했던 FLOAT 또는 DOUBLE 값 비교는 5.0에서는 사용할 수 없다. 이러한 형태의 값들은 모든
    MySQL버전에서 애매한 값을 가지게 되며, 따라서 여러분이 어떠한 버전을 사용하는지에 상관없이 WHERE column=some_double과
    같은 비교는 하지 말것을 권장한다. Section A.5.8, “Problems with Floating-Point Comparisons”를
    참조할 것.
  • MySQL 5.0.3 이후에는, 스페이스를 길게 누르는 것(trailing spaces)으로는 더 이상VARCHAR 과VARBINARY
    컬럼에 있는 값을 삭제할 수 없다. 5.0.3과 그 이후 버전에서 VARCHAR 과VARBINARY 컬럼의 최대 길이는 각각 65,535 개의
    문자와 65,535 바이트가 된다.
    Note: 5.0.3 또는 그 이후 버전에서 새로운 VARCHAR 또는 VARBINARY 컬럼을
    가지고 테이블을 만들었다면, 5.0.3 이전 버전으로 다운 그레이드 할 경우에는 이 테이블을 사용할 수 없게 된다. 테이블을 덤프한 다음에 다우
    그레이드를 하고 그 후에 다시 이 테이블을 로드한다.
  • MySQL 5.0.3이후에는, BIT는 TINYINT(1)과 동일한 데이터 타입이 아닌 별개의 데이터 타입이 된다. Section
    11.1.1, “Overview of Numeric Types”을 참조할 것.
  • MySQL 5.0.2은 몇 가지 SQL 모드를 추가해서 유효하지 않거나 누락된 값을 가진 레코드를 확실하게 제거하도록 하고 있다.
    Section 5.2.5, “서버 SQL 모드”, 및 Section 1.9.6.2, “유효하지 않은 데이터에 대한 제약 사항”을 참조할 것.
    이러한 제어를 활성화 시키지만 '2004-02-31’과 같은 올바르지 않은 데이터를 저장하는 것이 가능하도록 MySQL을 사용하고자 한다면,
    서버를 –sql_mode=TRADITIONAL,ALLOW_INVALID_DATES과 함께 구동 시켜야 한다.
  • MySQL 5.0.2이후에는, SCHEMA 와SCHEMAS 키워드는 각각 DATABASE 와 DATABASES의 동의어로 취급된다. (
    “schemata”가 문법적으로 맞고 어떤 MySQL5.0데이터 베이스와 테이블 이름에서 나타나기는 하지만, 이것은 입력용 키워드로 사용하지는
    못한다.)
  • MySQL 5.0에서는 사용자 변수는 대소 문자를 구분하지 않는다. MySQL 4.1에서는, SET @x = 0; SET @X = 1;
    SELECT @x; 는 두 개의 변수를 만드는데 0을 리턴한다. MySQL 5.0에서는, 하나의 변수를 만들며, 1을 리턴한다.
  • innodb_table_locks 이라는 이름의 새로운 스타트업 옵션이 추가 되었고, LOCK TABLE 이 InnoDB 테이블도
    잠금(locks0을 하도록 만든다. 이 옵션은 디폴트로 활성화 된다. 이것은 AUTOCOMMIT=1 과 LOCK TABLES을 사용하는
    어플리케이션에서는 데드락(deadlock)을 발생시킨다. 업그레이드 후에 어플리케이션이 데드락 상태가 되면, my.cnf 파일에
    innodb_table_locks=0를 추가해야 한다.

C API Changes:

  • Incompatible change: MySQL 5.0 서버는 새로운 DECIMAL 데이터 타입을 구현하기 때문에, 4.1클라이언트
    라이브러리와 아직도 링크가 되어 있는 예전 클라이언트가 서버를 사용하고 있다면 문제가 생기게 된다. 숫자 값을 가지게 되는 결과 셋을 만드는
    명령문을 실행하기 위해 클라이언트가 바이너리 클라이언트/서버 프로토콜을 사용한다면, 에러가 발생할 것이다: 'Using unsupported
    buffer type: 246'
    이 에러는 4.1 클라이언트 라이브러리가 5.0에서 추가된 새로운 MYSQL_TYPE_NEWDECIMAL
    타입의 값을 지원하지 않기 때문에 생기는 것이다. 서버 측면에서 새로운 DECIMAL 데이터 타입을 비활성화 시킬 수 있는 방법은 없다. 이
    문제는 어플리케이션을 5.0으로부터 클라이언트 라이브러리와 함께 어플리케이션을 재 링크시켜서 피할 수 있다.
  • Incompatible change: ER_WARN_DATA_TRUNCATED 경고 심볼은 5.0.3에서는
    WARN_DATA_TRUNCATED로 다시 이름 붙여 졌다.
  • MYSQL에 있는 reconnect 플래그는 mysql_real_connect()에 의해 0으로 설정된다.
    mysql_real_connect() 실행 후에 이 플래그를 0 또는 1로 확정적으로 설정되지 않은 프로그램만이 변경된다. 디폴트로 자동 인식
    활성화를 시키는 것은 매우 위험한 행위이다(재 연결후에 테이블 잠금, 임시 테이블, 사용자 변수 및 세션 변수들을 잃어 버리기 때문이다).
MySQL 데이터 베이스를 다른 머신으로 복사하기

여러분은 MyISAM 테이블용 .frm, .MYI, 및 .MYD 파일을 동일한 부동 소수점 포맷을 지원하는 서로 다른
머신 사이에서 이동 시킬 수 있다.

서로 다른 머신간에 데이터 베이스를 전달할 필요가 있을 경우에는, mysqldump를 사용해서 SQL명령문을 갖는
파일을 만든다. 그 다음에는 그 파일을 다른 머신에 전달하고 mysql 클라이언트의 입력 값으로 사용한다.

mysqldump –help옵션을 사용해서 사용 가능한 옵션을 알아 본다. 데이터를 새로운 버전의 MySQL에
전달하는 경우에, mysqldump –opt 를 사용하면 데이터를 최대로 최적화를 시켜서 덤프를 함으로서 크기를 작게 할 수 있다.

두 머신간의 데이터 이동 (빠르지는 않더라도) 방법 중에 가장 간단한 것은 데이터 베이스가 있는 머신에서 아래의
명령어들을 실행하는 것이다:

shell> mysqladmin -h 'other_hostname' create db_name
shell> mysqldump --opt db_name | mysql -h 'other_hostname' db_name

속도가 느린 네트워크 상에 있는 리모트 머신에서 데이터를 복사하고자 한다면, 다음의 명령어를 사용하면 된다:

shell> mysqladmin create db_name
shell> mysqldump -h 'other_hostname' --opt --compress db_name | mysql db_name

여러분은 파일 안에 덤프 파일을 저장하고, 타겟 머신에 그 파일을 전송하고, 그 다음에 그곳에 있는 데이터 베이스로
파일을 로드할 수도 있다. 예를 들면, 아래와 같이 소스 머신에서 데이터 베이스를 압축 파일로 덤프할 수 있다:

shell> mysqldump --quick db_name | gzip > db_name.gz

데이터 베이스를 갖고 있는 파일을 타겟 머신으로 전송한 다음에 아래의 명령어를 그곳에서 실행한다:

shell> mysqladmin create db_name
shell> gunzip < db_name.gz | mysql db_name

데이터 베이스를 전송하기 위해서는 mysqldump 와mysqlimport 도 사용할 수 있다. 테이블의 크기가 큰
경우에는, 이것을 사용하는 것이 단순히 mysqldump를 사용하는 것보다 빠르다. 아래의 명령어에서 보면, DUMPDIR 는
mysqldump의 결과를 저장하는 디렉토리 전체 경로 이름을 표시하는 것이다.
우선, 결과 파일을 위한 디렉토리를 만들고 데이터
베이스를 덤프한다:

shell> mkdir DUMPDIR
shell> mysqldump --tab=DUMPDIR db_name

그 다음에는 DUMPDIR 디렉토리에 있는 파일을 타겟 머신의 대응되는 디렉토리에 전송하고 그 곳에 있는
MySQL안으로 로드를 한다:

shell> mysqladmin create db_name           # create database
shell> cat DUMPDIR/*.sql | mysql db_name   # create tables in database
shell> mysqlimport db_name DUMPDIR/*.txt   # load data into tables

mysql 데이터 베이스를 복사하는 것을 잊지 말아야 하는데, 거기에 그랜트 테이블이 저장되어 있기 때문이다. 여러분이
새로운 머신에 mysql 데이터 베이스를 갖기 전까지는 그 곳에서 root 권한으로 명령어를 실행해야 할 것이다.

mysql 데이터 베이스를 새로운 머신으로 전송한 다음에는, mysqladmin flush-privileges를
실행해서 서버가 그랜트 테이블 정보를 다시 로드하도록 만든다.

MySQL 업그레이드 하기

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다