Sun Developer Network 공식 블로그

필자: Mike Hillyer
>Mike Hillyer는 MySQL AB의 테크니컬 라이터로서 캐나다 앨버타에 거주합니다.

입문

다양한 MySQL 포럼과 메일 그룹에 있는 공통 테마 중 하나는 데이터 마이그레이션이며, 이는 일반적으로 데이터와 클라이언트 애플리케이션을 MySQL 데이터베이스로 마이그레이션할 길을 찾고 있는 Microsoft® Access 및 Microsoft SQL Server 사용자들이 요청하는 부분이기도 합니다. 개발자는 단순히 데이터를 변환하는 것이 애플리케이션을 MySQL로 마이그레이션하는 전적인 목적이 아니라는 사실을 간파하지 못하고 Access 데이터베이스를 MySQL로 변환하거나 MSSQL 데이터베이스를 MySQL로 변환하는 데 사용할 수 있는 도구를 요구하는 경우가 많습니다.

이 기사에서는 Access 또는 SQL Server 데이터베이스에서 MySQL로 애플리케이션을 마이그레이션하는 기본적인 내용을 다룹니다. 기존 Access 또는 SQL Server 데이터베이스를 MySQL로 마이그레이션해야 하거나 마이그레이션하면 안 되는 여러 가지 이유부터 설명한 다음, 애플리케이션 마이그레이션의 계획 단계를 다루겠습니다. 그 다음, Access/MSSQL에서 MySQL로 실제 데이터를 마이그레이션하기 위한 도구와 방법을 살펴보고 클라이언트 애플리케이션을 Microsoft 데이터베이스에서 MySQL로 수정하기 위한 몇 가지 일반적인 지침을 설명하겠습니다. 마지막으로, MySQL 데이터베이스와 애플리케이션을 새로 배포할 때 고려해야 할 몇 가지 사항에 대해 살펴보겠습니다.

MySQL로 마이그레이션해야 하는 이유

이 기사를 읽고 있는 독자는 이미 Access 또는 SQL Server에서 MySQL로 애플리케이션을 마이그레이션하거나 적어도 기존 Windows® 애플리케이션에 MySQL의 지원을 추가하는 방법에 관심이 있을 가능성이 높습니다. 애플리케이션을 마이그레이션하는 이유는 다양하지만, 그 중 몇 가지만 살펴봅시다.

MySQL은 크로스플랫폼임

MySQL을 사용하는 큰 장점 중 하나는 크로스플랫폼 기능입니다. 이 기능을 사용할 수 있는 플랫폼의 예를 몇 가지만 들자면, Windows 랩탑에서 데이터베이스를 개발하여 Windows Server 2003, Linux 서버, IBM 메인프레임 또는 Apple XServe에 배포할 수 있습니다. 따라서 매우 유연하게 서버 하드웨어를 선택할 수 있습니다. Linux 슬레이브가 있는 Windows 플랫폼에서 마스터를 사용하여 복제를 설정할 수도 있습니다. 플랫폼 간 이동이 정말 쉽고 간단합니다. 대부분의 플랫폼에서 서버 간에 데이터와 구성 파일을 복사하여 바로 사용할 수 있습니다!

MySQL은 빠름

Ziff Davis가 독자적으로 수행한 연구 결과, DB2, Oracle, ASE 및 SQL Server 2000이 포함된 그룹에서 MySQL의 성능이 최고 수준에 속하는 것으로 밝혀졌습니다. 뛰어난 성능과 안정성을 요구하는 Yahoo!, Slashdot, Cisco, Sabre 등의 다양한 기업에서 MySQL을 사용하고 있습니다. MySQL은 사용 가능한 하드웨어로 최고의 성능을 달성할 수 있게 해주므로, 서버 업그레이드 간격을 늘려 비용 절감에 도움이 됩니다.

MySQL은 무료로 제공됨

MySQL은 오픈 소스 소프트웨어입니다. 따라서 아무런 비용 부담 없이 소스 코드를 검사하고 마음대로 변경할 수 있습니다. GPL 라이센스에 따라, 자신의 소프트웨어 역시 오픈 소스라면 얼마든지 그렇게 변경한 소스 코드를 무료로 재배포해도 됩니다. 자신의 소프트웨어를 오픈 소스로 하고 싶지 않을 경우에도 애플리케이션을 외부로 배포하지만 않는다면 역시 비용 부담 없이 원하는 대로 할 수 있습니다. GPL의 요구사항을 준수하면 MySQL을 무료로 사용할 수 있습니다. 클로즈드 소스 애플리케이션을 외부로 배포하려는 경우 MySQL 사용 라이센스 가격이 매우 저렴하다는 사실을 알 수 있을 것입니다(MySQL 라이센스 가격은 미화 249달러부터 시작함). 또한 MySQL AB의 상용 지원 비용도 저렴하며, 여타 지원 서비스 가격보다 현저히 낮은 수준입니다.

고객들은 오픈 소스를 원함

MySQL이 오픈 소스로 제공된다는 사실이 마이그레이션의 주된 동기가 아닐 수도 있지만, 필자는 고객의 요구 때문에 MySQL로 마이그레이션한 사용자를 많이 봤습니다. 많은 고객들은 저렴한 비용으로 자신의 인프라에서 MySQL과 다른 오픈 소스 기술을 자유자재로 사용할 수 있기를 원합니다. MySQL과 같은 오픈 소스 소프트웨어를 사용하면 미래의 라이센스 및 업그레이드 비용으로부터 자유로울 수 있고, 전용 소프트웨어를 사용하면서 발생할 수 있는 여러 가지 생각지도 못했던 추가 비용 부담이나 문제를 겪지 않아도 됩니다.

MySQL로 마이그레이션하면 안 되는 이유

Access 또는 SQL Server 데이터베이스를 MySQL로 변환하면 많은 이점이 있지만, 특정 애플리케이션에서는 이상적인 솔루션이 아닐 수도 있습니다. MySQL로 변환하는 것이 이상적인 솔루션이 아닐 수도 있는 상황을 몇 가지 살펴봅시다.

단일 사용자용 애플리케이션

Microsoft Access와 JET를 함께 사용하여 데이터를 관리하는 애플리케이션이 많이 있습니다. 이런 애플리케이션은 단 한 명의 사용자만 사용하는 것으로, 데이터 파일을 이동할 필요가 있을 때 해당 데이터 파일만 새 시스템으로 복사하는 상황에서 종종 사용됩니다. 그런 경우에는 MySQL을 사용해서 득이 될 것이 별로 없는 게 사실입니다. MySQL은 다중 사용자 서버로 개발되었으며, 소수의 사용자부터 수백 명의 사용자까지 어디서든 동시 액세스가 중요한 상황에 적합한 솔루션입니다. MySQL은 데이터베이스를 애플리케이션에 직접 통합할 때 유용하게 쓰일 수 있는 임베디드 서버를 제공하지만, 애플리케이션이 ADO와 같은 기술을 기반으로 할 때 쉽게 마이그레이션되지 않는 전문 API가 필요합니다.

호환되지 않는 기능을 가진 애플리케이션

MySQL AB는 끊임없이 MySQL에 새로운 기능을 추가하고 있지만, SQL Server 또는 Access에서 제공할 일부 기능이 현재로서는 MySQL에서 사용할 수 없는 경우가 늘 있기 마련입니다. MySQL 4.0을 사용 중인 경우 준비된 문, 저장된 프로시저, 서브셀렉트(subselect) 및 뷰가 부족하면 애플리케이션을 MySQL로 쉽게 마이그레이션할 수 있는 능력에 영향을 미친다는 사실을 알 수 있을 것입니다. 이는 물론 애플리케이션에서 그런 기능을 얼마나 광범위하게 사용했는지에 따라 다릅니다. MySQL 4.1에서는 준비된 문과 서브셀렉트가 도입되어 있습니다. 저장된 프로시저 구문이 Microsoft의 T-SQL 언어와는 확실히 어느 정도 차이가 있겠지만, MySQL 5.0에서는 저장된 프로시저와 뷰가 도입되었습니다.

많은 경우에 MySQL과 MSSQL/Access의 차이는 그런대로 해결할 수 있습니다. 기존 애플리케이션에서 저장된 프로시저를 사용하지만 MySQL 4.0 또는 4.1을 사용해야 하는 경우에는 언제든지 저장된 프로시저에 있었던 논리를 애플리케이션의 함수로 옮길 수 있습니다. 물론 이 과정의 난해도는 사용하는 저장된 프로시저의 수와 그 복잡성에 따라 다릅니다.

데이터베이스 추상화가 없는 대규모 애플리케이션

필자가 야심만만한 애플리케이션 개발자에게 주고 싶은 조언이 있다면 바로 데이터베이스 액세스를 추상화하라는 것입니다. 애플리케이션에서 적당한 데이터베이스 추상화를 사용하면 Access 또는 SQL Server에서 해당 애플리케이션을 매우 원활하게 변환할 수 있습니다. 애플리케이션이 작고 추상화가 없는 경우에도 변환할 코드가 많지 않기 때문에 비교적 간단히 변환할 수 있을 것입니다. 그렇다고는 해도, 애플리케이션 크기가 커짐에 따라 마이그레이션 작업의 복잡성과 마이그레이션 소요 시간은 늘어날 것입니다. 이는 결국 대규모 애플리케이션을 변환하는 것이 불가능해질 것이라는 말이 아니라, MySQL로 전환하는 비용이 전환에 따른 이익보다 커지는 지점까지 시간과 비용이 늘어날 가능성이 있을 것이라는 말입니다.

마이그레이션 계획

변환을 시작하기에 앞서 우선 확고한 전략을 세워두는 것이 좋으므로, 데이터베이스 애플리케이션을 MySQL로 마이그레이션할 때는 미리 계획하는 것이 매우 중요합니다. 계획을 세울 때는 필요할 수 있는 실제 데이터 수정뿐 아니라 데이터 형식의 수정과 같은 데이터 변경 사항을 고려해야 합니다. 또한 커서 사용, 함수, 저장된 프로시저, 내부 데이터 형식 등을 비롯하여 클라이언트 애플리케이션에서 변경해야 할 사항들을 살펴보고, 현재의 유지보수 전략을 점검하고 MySQL에서 지속적인 유지보수가 필요한 수정 작업도 수행하고 싶을 것입니다. 마지막으로, MySQL, SQL Server 및/또는 Access의 강점과 약점을 살펴보고 MySQL을 최대한 활용한다는 목표도 있을 것입니다.

데이터 형식

SQL Server와 MySQL에는 데이터 형식에 관한 한 겹치는 부분이 상당히 많지만, 아직도 해소해야 할 몇 가지 차이점이 있습니다. 따로 시간을 내어 테이블에서 사용하는 다양한 데이터 형식을 살펴보고 그런 테이블을 가장 적합한 MySQL 데이터 형식으로 마이그레이션할 계획을 세워야 합니다. 계획을 세울 때 주의할 점은, 꼭 이름을 기준으로 할 필요는 없고 용량을 기준으로 데이터 형식을 일치시킨다는 것입니다. 예를 들어, MySQL VARCHAR에는 최대 255자까지만 들어갈 수 있지만 SQL Server VARCHAR에는 최대 4,000자까지 들어갈 수 있습니다. 이 경우에는 VARCHAR 대신 MySQL TEXT 열 형식을 사용해야 합니다.

일부 데이터 형식은 SQL Server 또는 Access와 MySQL 사이에 직접적인 상관관계가 없습니다. 한 가지 예를 들자면 CURRENCY 데이터 형식이 있는데, MySQL에는 (아직) CURRENCY 데이터 형식이 없지만 DECIMAL(19,4)라는 정의로 열을 생성하면 같은 용도로 사용할 수 있습니다. MSSQL에서는 nCHAR 및 nVARCHAR과 같은 유니코드 문자 형식을 기본값으로 하지만, MySQL에서는 문자 집합을 필드 형식에 그리 엄격하게 바인딩하지 않고, 그 대신 유니코드를 포함한 임의 개수의 문자 집합에 바인딩할 수 있는 문자 형식 집합 하나를 준비합니다.

MySQL Reference Manual에서 최신 MySQL 열 형식 목록을 찾아볼 수 있습니다. Visual Basic 데이터 형식과 MySQL 열 형식 사이의 매핑 테이블을 기본적인 MySQL 열 형식, 용량 및 그에 상응하는 VB6를 빠르게 참조할 수 있는 자료로 이용할 수 있습니다. MSDN에서는 SQL Server 데이터 형식 목록도 제공합니다.

데이터 수정

데이터를 변환할 때 데이터 자체를 수정해야 하는 경우도 있을 수 있습니다. 그 한 예가 바로 날짜 정보가 포함된 열입니다. MySQL에서는 YYYY-MM-DD의 표준 형식으로 날짜 정보를 저장하지만, Microsoft 데이터베이스는 MM-DD-YYYY 형식으로 되어 있는 경우가 많습니다. 사용 중인 변환 도구에서 자동으로 이 문제를 해결할 가능성이 높지만, 자체적인 변환 도구를 만들어 사용하는 경우에는 이 점을 염두에 두어야 합니다. MSSQL과 MySQL 모두 작은따옴표 안에 날짜 정보를 넣지만(예: '2000-12-13'), Access에서는 해시 표시로 나타냅니다(예: #23-11-2001#). Access에서 MySQL로 변환하는 경우 그에 맞춰 쿼리를 변경해야 합니다. 다른 데이터 수정에는 데이터를 변환하는 동안 테이블을 표준화하기 위한 스키마 변경이 포함될 수 있습니다. 데이터베이스 표준화에 대한 자세한 내용은 "데이터베이스 표준화 개론(An Introduction to Database Normalization)" 기사를 읽어 보십시오.

내장 함수

이름이 다른 경우가 가끔 있긴 해도, 내장된 MySQL 함수 중 다수는 SQL Server의 내장 함수와 같습니다. 한 가지 예를 들자면 MSSQL ISNULL() 함수가 있습니다. MySQL에서 이와 같은 함수는 IFNULL() 함수이며, 동일한 구문을 사용합니다. 반대로, Access의 ISNULL() 함수에서는 다른 구문을 사용하고 대체된 값 대신 부울 값만 반환합니다. MySQL에는 Microsoft의 SQL보다 내장 함수가 많으므로, 기존 쿼리에서 사용하는 모든 내장 함수에 대해 MySQL에도 그에 상응하는 함수가 있어야 합니다.

커서

일반적인 Windows 애플리케이션에서는 ADO와 같은 API를 통해 데이터에 액세스할 때 서버 측 동적 커서 또는 키 집합 커서를 사용합니다. Connector/ODBC 드라이버에서는 키 집합 커서를 지원하지 않고 어떤 경우든 서버 측 커서 지원이 매우 제한적입니다. 변경할 필요가 있는지 결정하기 위해 애플리케이션에서 사용되는 커서 형식과 커서 위치를 평가하려면 "CursorTypes, LockTypes 및 CursorLocations(CursorTypes, LockTypes, and CursorLocations)" 기사의 내용이 도움이 될 것입니다.

사용자 정의 함수

사용자 정의 함수(UDF)는 SQL Server와 MySQL 사이에 차이가 있습니다. SQL Server 함수는 저장된 프로시저와 매우 흡사하므로, 일련의 쿼리를 호출 가능한 함수로 캡슐화한 후 하나의 쿼리로 통합할 수 있습니다. 이에 반해, MySQL UDF는 C 코드로 컴파일되므로 하나의 함수 이름에 할당하여 여러 쿼리에서 사용할 수 있습니다. 한 가지 예로 MySQL 쿼리에서 컬러 사진을 흑백 사진으로 변환하여 BLOB 열에서 컬러로 저장된 이미지를 흑백 이미지로 반환하는 C 함수를 사용하는 경우를 들 수 있습니다. 일단 C 코드를 컴파일한 후에는 그 코드를 서버에 넣어 두었다가 쿼리에서 호출할 수 있습니다.

MySQL에서는 현재 SQL Server 스타일의 UDF에 해당하는 함수를 제공하지 않으며, 사용자 데이터베이스에 있는 모든 UDF의 기능을 클라이언트 측 애플리케이션 코드로 변환해야 합니다.

저장된 프로시저

MySQL에서는 데이터베이스 서버 버전 5에서 저장된 프로시저를 최근에 구현했습니다. MySQL은 표준 SQL 규칙을 따르지만, 이것으로 T-SQL이 MySQL에서 바뀌지 않고 작동한다고 보장할 수는 없습니다. MySQL 5를 사용하지 않을 경우에는 클라이언트 측 코드를 사용하도록 저장된 프로시저를 다시 작성해야 합니다.

유지보수 계획

데이터 및 애플리케이션 변환을 계획하는 것 외에, 데이터베이스 유지보수 전략과 도구의 변환도 검토할 필요가 있습니다. 일부 주요 백업 공급업체는 MySQL용 백업 도구를 제공하므로, 기존 공급업체에 문의하여 그에 상응하는 MySQL용 도구를 제공하는지 여부를 확인해보는 것이 좋습니다. MySQL의 백업 전략은 SQL Server의 백업 전략, 즉 정기적으로 전체 백업을 수행하고 로그 파일도 일정한 주기로 백업한다는 전략과 매우 유사합니다.

마이그레이션 도구

SQL Server 또는 Access 데이터베이스를 MySQL로 마이그레이션할 때 사용할 수 있는 도구의 종류는 무척 많습니다. 각 사용자의 요구사항에 가장 적합한 도구를 선택할 수 있도록 여러 가지 다른 도구를 살펴보겠습니다. 여기서 살펴볼 도구는 다음과 같습니다.

• MSSQL2MYSQL
• Microsoft DTS
• SQLyog
• Access Export
• Text Import/Export

SQLYog와 Microsoft DTS 마법사는 MSSQL 및 Microsoft Access 모두와 함께 사용하여 MySQL로 테이블을 가져올 수 있는 그래픽 인터페이스를 제공합니다. MSSQL2MYSQL은 테이블 구조와 데이터뿐 아니라, 인덱스 정보도 변환할 수 있도록 Michael Kofler가 작성한 스크립트입니다. Microsoft Access를 사용한다면 상기한 도구에 액세스할 수 없겠지만, Access의 데이터 내보내기 기능을 사용하면 됩니다.

MSSQL2MYSQL

MSSQL2MYSQL은 Apress의 The Definitive Guide to MySQL의 저자인 Michael Kofler가 만들었습니다. MSSQL2MYSQL은 Microsoft Visual Basic 6 또는 Microsoft Word나 Excel 같이 VBA를 지원하는 애플리케이션을 사용하여 실행할 수 있는 Visual Basic 스크립트입니다.

자세한 사용법은 저자의 웹 사이트에서 확인할 수 있고, 이 웹 사이트에는 프로그래머가 아닌 사용자가 MSSQL2MYSQL을 좀 더 쉽게 사용할 수 있도록 한 GUI 프런트 엔드 목록도 있습니다.

VB6와 함께 MSSQL2MYSQL을 사용하려면 http://www.kofler.cc/mysql/mssql2mysql.txt에 있는 텍스트를 복사하여 VB 양식의 코드 섹션에 붙여 넣기만 하면 됩니다. SQL Server 및 MySQL 설치에 맞춰 코드 시작 부분에 있는 상수들을 변경해야 하며, 그런 다음 VB6 애플리케이션을 실행하면 변환 내용이 적용됩니다. MSSQL2MYSQL에서는 변환 진행률에 대한 시각적 피드백을 제공하지 않고 변환 완료 시 간단한 메시지 상자만 표시합니다.

MSSQL2MYSQL의 한 가지 뛰어난 기능은 모든 문을 하나의 텍스트 파일에 넣어 두었다가 나중에 검토하고 편집한 후 MySQL 서버에서 실행할 수 있는 기능입니다.

Microsoft 데이터 변환 서비스

Microsoft DTS는 Microsoft SQL Server에 포함된 데이터 조작 도구입니다. DTS는 데이터베이스, 스프레드시트, 더 나아가 HTML 등의 시스템과 다양한 형식 간에 데이터를 이동하는 능력이 우수합니다. Microsoft 데이터 변환 서비스는 매우 복잡할 수 있지만, 대부분의 사용자는 DTS에 있는 가져오기/내보내기 마법사만 사용하면 됩니다.

DTS 사용법은 무척 간단합니다. 데이터를 읽을 ODBC 데이터 소스를 선택한 다음 데이터의 변환 대상이 되는 ODBC 데이터 소스를 선택합니다. 그러면 변환할 테이블 목록이 나타나며, 대상 테이블의 이름을 바꾸고 대상 데이터베이스에 데이터를 삽입하기 전에 데이터에 대한 기본적인 변환을 수행할 수 있는 옵션이 제공됩니다. 이런 변환은 Visual Basic 스크립팅을 통해 수행됩니다. 또한 사용할 테이블 생성 문을 제어할 수 있고, 이를 통해 MySQL 테이블 정의를 미세 조정하여 실행할 스크립트에 테이블 핸들러(InnoDB, BDB 등)와 같은 매개변수를 추가할 수 있습니다.

DTS에는 예약된 데이터 변환을 수행하는 기능도 있는데, SQL Server 데이터 분석을 위해 MySQL을 사용할 때나 애플리케이션 마이그레이션 작업을 하면서 최신 데이터를 사용하려 할 때 매우 유용하게 쓸 수 있는 기능입니다.

SQLyog

SQLyog는 관리자가 GUI 환경에서 MySQL을 관리할 때 사용할 수 있는 타사의 상용 도구입니다. SQLyog는 MySQL 파트너인 webyog에서 제공하는 30일 평가판 도구입니다. SQLyog는 DTS와 유사한 ODBC 가져오기 도구를 제공하는데, 이 도구에서는 DTS에 비해 사용법이 훨씬 간단한 인터페이스가 제공됩니다.

SQLyog는 예약된 데이터 가져오기 작업을 수행할 수 있고, 여러 MySQL 서버 사이에서 데이터와 스키마를 모두 동기화하는 데 사용할 수도 있습니다.

Access Export

Microsoft Access 사용자로서 Microsoft DTS 또는 SQLyog에 액세스하지 못하는 경우 Microsoft Access의 내보내기 기능을 사용하는 방법이 있습니다. Access는 ODBC를 비롯한 다양한 형식으로 테이블을 내보낼 수 있습니다. 이 기능을 사용하면 MySQL AB에서 제공하는 Connector/ODBC ODBC 드라이버를 사용하여 Access 테이블을 MySQL로 내보낼 수 있습니다.

Access 테이블을 MySQL로 내보내려면 해당 테이블을 마우스 오른쪽 버튼으로 클릭하고 'Export' 옵션을 선택합니다. 여러 단계를 거친 후 MySQL로 데이터를 내보내게 됩니다. 이 경우 Access에서의 열 형식 선택사항을 수정해야 할 수 있고, Access에서는 인덱스 정보를 데이터와 함께 내보내지는 않는다는 점을 유의해야 합니다. 즉, 인덱스를 내보낸 후에 테이블에서 인덱스를 구현해야 합니다.

Text Import/Export

MSSQL/Access에서 데이터를 텍스트 형식으로 내보내고 이 데이터를 MySQL로 바로 가져오는 것이 데이터를 가져오는 마지막 방법입니다. 데이터를 내보낼 때 탭으로 구분되거나 쉼표로 구분된 형식과 같은 공통된 형식은 나중에 MySQL로 가져올 때도 그대로 유지됩니다.

이 접근 방법을 사용할 경우에는 MySQL 테이블을 수동으로 생성한 다음 mysql 명령줄 클라이언트에서 LOAD DATA 명령으로 데이터를 가져와야 합니다. LOAD DATA 명령에 관한 추가 정보는 MySQL Reference Manual의 "LOAD DATA INFILE syntax" 단원에서 확인할 수 있습니다.

이 방법은 아마 가장 손이 많이 가고 시간도 많이 걸리는 방법이지만, 데이터를 가져오기 전에 테이블을 수동으로 생성하므로 테이블 스키마에 대한 제어 능력은 최고 수준입니다.

애플리케이션 수정

모든 데이터베이스 애플리케이션은 저마다 다르므로, 모든 애플리케이션 마이그레이션에 적용되는 간단하고 확실한 규칙은 없습니다. 아래에서는 Access 또는 SQL Server 데이터베이스를 MySQL로 마이그레이션할 때 대부분의 개발자가 고려해야 하는 몇 가지 영역에 대해 설명하겠습니다.

액세스 제어

수많은 Windows 애플리케이션에서는 통합된 Windows NT 보안을 이용하여 데이터베이스에 대한 액세스 제어 기능(SSPI라고도 함)을 제공합니다. 이 기능을 현재는 MySQL 서버에서 사용할 수 없으므로, 그런 인증을 클라이언트 애플리케이션으로 옮겨야 할 것입니다. 또한 MySQL에서는 데이터베이스 권한을 지정할 때 매우 세분화되어 있으며, 이를 적절히 구현하면 애플리케이션 보안 수준을 높이는 데 도움이 될 수 있습니다.

커서

서버 측 커서가 MySQL을 위해 보류 중인 기능이라고는 하지만, 진정한 서버 측 커서는 현재 구현되지 않은 상태입니다. 애플리케이션에서 현재 서버 측 커서를 사용하는 경우에는 해당 애플리케이션을 평가하여 Connector/ODBC에서 제공하는 시뮬레이트된 서버 측 커서가 적당할지, 애플리케이션의 클라이언트 측 커서를 이용해 비슷한 기능을 구현할 수 있을지 결정해야 합니다.

저장된 프로시저와 뷰

저장된 프로시저와 뷰는 MySQL 5에서 새로 구현된 기능입니다. 사용 중인 애플리케이션에서 이 두 가지 기능 중 어느 것이든 많이 사용하는 경우에는 MySQL 5 서버를 마이그레이션의 기준으로 삼거나 저장된 프로시저를 클라이언트 애플리케이션으로 옮길 방법을 찾는 것이 좋습니다. MySQL은 ANSI SQL 표준을 바탕으로 저장된 프로시저 구문을 사용하며, 이에 따라 T-SQL 구문과 MySQL의 저장된 프로시저 구문 간 일부 항목이 호환되지 않습니다. ANSI SQL 표준을 준수할 수 있도록 T-SQL의 저장된 프로시저 중 아주 사소한 항목을 빼고는 모두 재작성 작업을 수행할 계획을 세워야 합니다.

일반적인 SQL 구문

거의 모든 관계형 데이터베이스 시스템은 이런저런 식으로 SQL 표준과는 다르므로, 향상된 기능과 원래 표준에서 다루지 않았던 다른 특수한 기능을 추가하는 경우가 많습니다. 성공적인 애플리케이션 마이그레이션을 위한 한 가지 관건은 애플리케이션에서 사용되고 있지만 MySQL과는 호환되지 않을 SQL 쿼리와 문을 식별하는 것입니다.

테이블 이름을 따옴표로 표시하는 것이 한 가지 관심 영역인데, Access에서는 대괄호를 사용하지만(예: SELECT myfield FROM [my table]), MySQL에서는 역따옴표를 사용합니다(예: SELECT myfield FROM `my table`). 가능하다면 따옴표를 사용해야 하는 테이블 이름을 사용하지 않는 것이 최선입니다. 테이블 이름에 따옴표를 사용해야 하는 경우에는 그에 맞춰 쿼리를 변경해야 합니다.

MySQL 최적화

애플리케이션을 마이그레이션할 때 MySQL에 애플리케이션에서 이용할 수 있는 확실한 장점이 있다는 사실을 간과하면 안 됩니다. MySQL은 다른 SQL보다 애플리케이션 내에서 연결을 만들고 삭제하는 속도가 대체로 더 빠르며, 이런 특징은 개발을 하면서 연결을 만들고 삭제하는 방법에 영향을 줄 수 있습니다. 또한 MySQL에는 필요한 클라이언트 측 프로그래밍 작업량을 줄일 수 있는 전문적인 기능들이 있습니다. 이런 장점을 찾아서 활용하면 애플리케이션 성능 향상과 클라이언트 측 개발 간소화에 도움이 될 수 있습니다.

개발 고려사항

데이터베이스 및 클라이언트 애플리케이션의 마이그레이션은 하찮은 작업이 아닙니다. 마이그레이션 절차를 완수하기까지 상당한 시간이 걸릴 뿐 아니라, 가동 중단 시간을 최소화하면서 운영 중인 시스템에서 마이그레이션을 수행해야 할 경우도 많기 때문입니다. 데이터베이스 애플리케이션을 마이그레이션하고 배포할 때는 다음 몇 가지 권장사항을 충분히 참작해야 합니다.

시간을 충분히 가질 것

가장 완벽하게 계획된 마이그레이션조차도 예상했던 것보다 오래 걸릴 수 있습니다. 시간 계획을 짤 때는 예기치 못한 지연과 외부적 요인으로 인한 일시적 작업 중단 가능성을 고려해야 합니다. 마이그레이션 프로젝트 소요 시간을 처음부터 충분히 잡음으로써, 일정을 지키지 못하는 것보다는 일정 내에 일찍 마치는 것이 낫습니다.

시범적으로 마이그레이션을 수행할 것

최종 작업을 수행하기 전에 데이터 마이그레이션을 시범적으로 운영해 보십시오. 시범 운영 중에 발생하는 문제를 해결할 수 있는 시간을 벌기 위해 마감시한 전 최소한 일주일 이상의 여유를 두는 것이 좋습니다. 아무리 사소한 것이라도 마이그레이션 도구/스크립트 또는 클라이언트 애플리케이션을 변경하면 이후에 변환이 완료된 후 실제로 운영할 때 그 조그마한 변화가 엄청난 결과를 초래할 수 있으므로, 최종적으로 성공한 시범 운영과 실제 마이그레이션 작업 사이에 변경 사항이 있을 경우 특히 주의를 기울이십시오.

가능하다면 제한적인 롤아웃을 수행할 것

가능한 상황이라면 새로운 시스템을 제한적으로 배포해보는 방안도 고려할 만합니다. 업데이트 버전을 모든 고객에게 배포하기 전에 베타 프로그램에서 작동하는 새로운 MySQL 버전을 한번 써보겠다는 고객이나 지사가 한둘 정도는 있을 것입니다. 이러한 방안이 가능하지 않은 상황이라면 앞서 언급한 마이그레이션 도구의 예약 기능을 사용하여 기존 시스템에서 가져온 실제 데이터를 이용해 테스트 환경에서 한두 대의 터미널을 운영해 볼 수도 있습니다. 어느 경우든, 이런 방법을 이용하면 모든 사용자에게 전체적으로 변경 사항을 적용하기 전에 실제 데이터와 실제 사용자로 시스템을 테스트할 수 있습니다.

유지보수 계획을 세워둘 것

실제 마이그레이션을 시작하기 전에 효과적인 재해 복구 계획이 수립되어 있는지 확인해야 합니다. 백업 하드웨어가 새로운 MySQL 데이터베이스와 호환될 것인지, 데이터 복구를 위한 검증된 계획과 함께 백업 예약을 해두었는지 확인하십시오. 데이터 마이그레이션의 특성 때문에, 변환 후 첫 몇 주일 동안은 정기 백업을 자주 수행하는 것이 좋습니다.

결론

MySQL의 높은 성능, 크로스플랫폼 기능 및 개방적 특성으로 인해, 점점 많은 개발자들이 Microsoft SQL Server와 Microsoft Access에서 MySQL로 애플리케이션을 마이그레이션하고 있습니다. 마이그레이션을 할 때는 마이그레이션이 현재 상황에서 최선의 솔루션인지 결정하고 마이그레이션을 지연시키거나 방해할 수 있는 다양한 요인을 고려하여 미리 계획을 세우는 것이 중요합니다. 데이터 마이그레이션에 도움이 되는 다양한 도구가 있고, 클라이언트 애플리케이션을 변환할 때 고려해야 할 다른 요소들도 많습니다. 변환이 완료된 후에는 배포 작업과 시범 운영을 수행하고, 여건이 허락된다면 제한적 롤아웃까지도 수행할 수 있는 시간을 확보하는 한편, 적절한 재해 복구 대책을 마련하는 것이 중요합니다.

마지막으로, 이미 마이그레이션을 완료한 사람들의 경험을 교훈으로 삼으면 많은 도움이 될 것입니다. MySQL AB는 데이터 및 애플리케이션 마이그레이션에 도움이 될 수 있는 다양한 서비스와 리소스를 제공합니다. MySQL AB는 MySQL로의 마이그레이션을 고려 중인 회사를 위해 배포 컨설팅 서비스를 제공합니다. 자세한 정보를 검토하고 질문을 게시할 수도 있는 다양한 마이그레이션 관련 포럼도 있으니 참고하십시오.