Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space ML1 and version 5.3
Sv translation

This section discusses steps and some of the best practices recommendations for migrating an application or set of applications that are currently deployed on MySQL database(s) to Xpand. 

Table of Contents

Migration Overview

There are essentially three basic steps to achieve successful migration from MySQL environment:

  • Dump the MySQL database with mysqldump and import into Xpand with clustrix_import
  • Use MySQL replication to sync Xpand with the production MySQL database
  • Cut over application servers to Xpand

There are several additional steps which may be taken to minimize risk:

  • Validate that Xpand responds to all read queries appropriately
  • Configure Xpand slave to facilitate switching back to MySQL as a roll back process

Migration Prerequisites

In order to migrate your application from MySQL to Xpand, the following must be true:

  • MySQL server has binary logging enabled (--log-bin and other supporting arguments)
  • Using SBR mode replication during the migration process has the benefit of validating that write queries are handled properly by Xpand. However, if the application workload is characterized to be extremely busy and/or exhibits many write heavy transactions, Xpand recommends using RBR mode to achieve better replication throughput.
  • Check whether tables being migrated are InnoDB or MyISAM. MyISAM requires some special care to get a consistent dump. All tables must be locked or the database must be quiesced completely since MyISAM provides no transaction isolation.

Migration Steps

Take a consistent dump of the database

  • It is important to note that database dump would need to be taken using mysqldump utility. No other existing backup methods e.g.  LVM snapshots, xtrabackup, etc. may be used for migrating the database.
  • mysqldump command to be used for dumping MySQL database is provided below
mysql> mysqldump -u user -h mysql_host --single-transaction --master-data=2 --all-databases > mydumpfile.dump

Please note that --single-transaction argument is important in order to get a consistent snapshot from where to start the replication slave. Additionally, --master-data argument stores the binlog position corresponding to the snapshot in the dump file.

It is recommended to use the linux screen window manager to insure that the session is not killed before the backup finishes (better than the & and nohup alternative). For monitoring the dump and ensure successful completion, the tail command may be used. Using tail on the dump file should show something like:

-- Dump completed on 2016-08-02 19:50:56 

If the dump is incomplete or incorrect due to wrong usage of mysqldump arguments, lots of time may be wasted before finding out that replication won’t work. Correctness of mysqldump command is critical.

Import the database dump using clustrix_import utility

  • clustrix_import command to be used for importing the dump file is provided below
shell> clustrix_import -i dumpfile.sql -H clustrix_ip  
  • A few best practices recommended for using clustrix_import command line tool

- Use screen

tee the output

- Pay close attention to the final output indicating success or failure

clustrix_import has many advantages over mysql client in loading data as it imports data in parallel, taking full advantage of cluster resources. This tool is also designed to optimally distribute the data across all Xpand nodes and automatically retries transient errors.

Migrate Permissions with clustrix_clone_users

  • mysqldump --all-databases will dump the mysql database but Xpand cannot use this data to instantiate users
  • Use clustrix_clone_users instead, available at /opt/clustrix/bin/.

clustrix_clone_users utility will query a MySQL (or Xpand) database to dump the users and permissions, generating SQL which can then be imported, per this example. 

shell> ./clustrix_clone_users -H localhost > /tmp/grants.sql  
shell> head /tmp/grants.sql
-- Clustrix Users dumpfile ver: 113:82f8694c98db
-- Host: localhost
GRANT ALL PRIVILEGES ON `statd`.* TO 'statd'@'%' IDENTIFIED BY PASSWORD '*58D9255AEB513581F38430D559A1455461E6B74E';
shell>  mysql -h mogwai -u root < /tmp/grants.sql     

Start Replication Slave on Xpand

Once the import is complete, the slave can be created on Xpand using the following command:

sql> CREATE SLAVE 'slave1' MASTER_LOG_FILE = 'foo.000001'
, MASTER_HOST = 'host_name'
, MASTER_USER = 'user_name'
, MASTER_PASSWORD = 'password';

sql> START SLAVE 'slave1';

The proper log file and position are obtained from the beginning of the mysqldump (as generated by --master-data=2 argument).

Please refer to Configuring Replication module for obtaining information on monitoring slave status. 

Application Server Cutover

Methods to cut over application servers

There are two common methods for switching app servers from MySQL to Xpand:

  1. Reconfiguring application servers to point to Xpand instead of MySQL
  2. Using an external load balancer e.g. HAProxy to direct traffic to Xpand instead of MySQL. Please refer Load Balancing Xpand with HAProxy.

Risk Mitigation

Validating Xpand Compatibility

To reduce cutover surprises, ensure that Xpand properly handles all queries generated by the application

  • To validate write statements, SBR mode of replication ensures Xpand slave's ability to handle write queries. Although RBR will provide better performance for write heavy workloads, it is recommended to use SBR initially for validation of write queries. SBR mode also comes handy in troubleshooting replication issues during initial adoption. Once all statements are validated, SBR mode can be converted to RBR for better replication performance.
  • To validate read statements, SQL queries may be captured either using tcpdump utility or enabling full query logging. For tcpdump output, Xpand support can help converting it into valid SQL sessions. Thereafter, these queries can be replayed using MySQL client for validation. 

Enable failing back to MySQL

The ability to switch back to MySQL greatly minimizes the risk of impact to production. Configuring MySQL to slave from Xpand beforehand ensures a smooth transition should the need arise.

Steps to fail over are discussed under Configuring Replication Failover section and also outlined below:

  1. Retain privileges for all application logins on the MySQL slave instance, but keep the instance read only, by setting read_only global:

    slave> SET GLOBAL read_only = true;
  2. Enable binlogging on Xpand, ensuring format is same as MySQL master.  To enable failing back to MySQL, the binlog must be created on Xpand before application writes are allowed.

    CREATE BINLOG binlog_name [format='row']
  3. Once application servers have been cut over to Xpand, the slave on Xpand (from MySQL master) can be stopped.  Alternatively, bi-directional, or master-master replication can be configured, where Xpand continues to replicate from MySQL, while MySQL also replicates from Xpand.  This is a more complex configuration, with some caveats, as discussed in Configuring Replication Failover.
  4. Configure MySQL as a slave from Xpand, using MySQL's CHANGE MASTER TO syntax, specifying the beginning (position 4) of the binlog created in step 2.
Reverting to MySQL

In the event that it becomes necessary to revert to MySQL, given the steps above have been taken, the following steps are necessary:

  1. Change Xpand to read only mode:

    master> SET GLOBAL read_only = true;
  2. Ensure slave has caught up by comparing binlog file and position shown by SHOW MASTER STATUS on Xpand and SHOW SLAVE STATUS on MySQL
  3. Recreate or re-enable Xpand slave from MySQL, specifying current binlog file and position shown in MySQL's SHOW MASTER STATUS
  4. Enable MySQL to take writes again:

    slave> SET GLOBAL read_only = false;
  5. Application servers can now be pointed back to MySQL.

Best practice during cutover

Configure read-only on the inactive side (slave and root users are exempted):

sql>   SET GLOBAL read_only = true;  

Cutover Caveats

Replication lag

Make sure that replication is caught up before cutting over. If Xpand is significantly behind, an auto-increment INSERT coming from the newly cut-over app server will conflict with a prior INSERT in the replication stream. In order to avoid getting into such issues, it may be necessary to quiesce the MySQL server for some period of time to ensure that the Xpand slave is caught up before cutting over.

Rogue servers/scripts

Post cutover there could still be some applications or scripts that are still attempting to write to the MySQL database.  These would be either failing as MySQL instance is set to read_only mode or silently manipulating data as root. Examples of such possibilities could be admin application deployed locally on MySQL server or some of the database admin kind of shell scripts that are executed locally as root by the DBAs and manipulates data. It is necessary to review and migrate those scripts to Xpand instance going forward as otherwise it would introduce data mismatch between Xpand and MySQL

Sv translation

이 섹션에서는 현재 MySQL 데이터베이스에 배포된 일련의 응용 프로그램을 ClustrixDB로 마이그레이션 하기 위한 권장 사항 및 모범 사례에 대해 설명합니다.

Table of Contents

마이그레이션 개요

MySQL 환경에서 성공적인 마이그레이션을 수행하려면 기본적으로 세 가지 기본 단계가 필요합니다.

  • mysqldump를 사용해서 MySQL 데이터베이스를 덤프하고 clustrix_import를 사용해서 ClustrixDB에 가져옵니다.
  • MySQL 복제를 사용해서 ClustrixDB를 프로덕션 MySQL 데이터베이스와 동기화합니다.
  • 응용 프로그램 서버를 ClustrixDB에 절체(cutover)합니다.

리스크를 최소화하기 위해 몇 가지 추가 단계가 있습니다.

  • ClustrixDB가 모든 읽기 쿼리에 적절하게 응답하는지 확인합니다.
  • 롤백 프로세스의 일환으로 MySQL로 다시 전환할 수 있도록 ClustrixDB 슬레이브를 구성합니다.

마이그레이션 전제 조건

응용 프로그램을 MySQL에서 ClustrixDB로 마이그레이션 하려면 다음의 조건을 충족해야 합니다.

  • MySQL 서버는 바이너리 로그가 활성화되어야 합니다 (--log-bin 및 기타 인수 지원).
  • 마이그레이션 프로세스 중에 SBR 모드 복제를 사용하면 쓰기 쿼리가 ClustrixDB에서 올바르게 처리되는지 확인할 수 있다는 장점이 있습니다. 그러나 애플리케이션 워크로드가 매우 높거나 많은 쓰기 트랜잭션이 있는 경우 RBR 모드를 사용하여 복제 처리량을 향상시킬 것을 권장합니다.
  • 마이그레이션 하는 테이블이 InnoDB 또는 MyISAM인지 확인하십시오. MyISAM은 일관된 덤프를 얻기 위해 특별한 주의가 필요로 합니다. MyISAM은 트랜잭션 격리를 제공하지 않기 때문에 모든 테이블을 잠그거나 데이터베이스를 완전히 정지해야 합니다.

마이그레이션 단계

일관된 데이터베이스 덤프

  • mysqldump 유틸리티를 사용하여 데이터베이스를 덤프해야 한다는 점에 유의하십시오. 예를 들어, LVM 스냅샷, xtrabackup 등과 같은 기존 백업 방법은 데이터베이스를 마이그레이션 하는데 사용할 수 없습니다.
  • MySQL 데이터베이스를 덤프하는 데 사용되는 mysqldump 명령은 다음과 같습니다.
mysql> mysqldump -u user -h mysql_host --single-transaction --master-data=2 --all-databases > mydumpfile.dump

복제 슬레이브를 시작할 위치에서 일관된 스냅샷을 얻으려면 --single-transaction 인수가 중요합니다. 또한, --master-data 인수는 스냅샷에 대응하는 binlog 위치를 덤프 파일에 저장합니다.

Linux의 screen 창 관리자를 사용하여 백업이 완료되기 전에 세션이 종료되지 않도록 하는 것이 좋습니다 (&nohup 보다 나은 방법입니다). 덤프를 모니터링하고 성공적으로 완료되었는지 확인하려면 tail 명령을 사용할 수 있습니다. 덤프 파일에 tail을 사용하면 다음과 같이 표시됩니다.

-- Dump completed on 2016-08-02 19:50:56 

mysqldump 인수를 잘못 사용하여 덤프가 불완전하거나 제대로 동작하지 않는다는 것을 발견하기까지 많은 시간이 낭비될 수 있습니다. 그래서 정확한 mysqldump 명령은 굉장히 중요합니다.

clustrix_import 유틸리티를 사용하여 데이터베이스 덤프 가져오기

  • 덤프 파일을 가져오는 데 사용되는 clustrix_import 명령은 다음과 같습니다.
shell> clustrix_import -i dumpfile.sql -H clustrix_ip  
  • clustrix_import 명령줄 도구 사용에 권장되는 몇 가지 모범 사례

- screen 유틸리티 사용

- output 출력에 tee 유틸리티 사용

- 성공 또는 실패를 나타내는 최종 출력에 세심한 주의를 기울이십시오

clustrix_import는 클러스터 자원을 최대한 활용하여 데이터를 병렬로 가져오기 때문에 MySQL 클라이언트보다 많은 이점을 제공합니다. 또한, 이 도구는 모든 ClustrixDB 노드에 데이터를 최적으로 분산하고 일시적인 오류 클라이언트보다 많은 이점을 제공합니다. 자동으로 재시도하도록 설계되었습니다.

clustrix_clone_users를 사용하여 권한 마이그레이션

  • mysqldump --all-databases는 MySQL 데이터베이스를 덤프하지만 ClustrixDB는 이 데이터를 사용하여 사용자를 생성할 수 없습니다.
  • 대신 지원 사이트에서 제공되는 clustrix_clone_users를 사용하십시오.

clustrix_clone_users 유틸리티는 MySQL (또는 ClustrixDB) 데이터베이스를 쿼리하여 사용자와 권한을 덤프하며 SQL을 생성하여 가져올 수 있습니다. clustrix_clone_users 유틸리티의 사용 예는 다음과 같습니다.

shell> ./clustrix_clone_users -H localhost > /tmp/grants.sql  
shell> head /tmp/grants.sql
-- Clustrix Users dumpfile ver: 113:82f8694c98db
-- Host: localhost
GRANT ALL PRIVILEGES ON `statd`.* TO 'statd'@'%' IDENTIFIED BY PASSWORD '*58D9255AEB513581F38430D559A1455461E6B74E';
shell>  mysql -h mogwai -u root < /tmp/grants.sql     

ClustrixDB에서 복제 슬레이브 시작

가져오기가 완료되면 다음 명령을 사용하여 슬레이브를 생성할 수 있습니다.

sql> CREATE SLAVE 'slave1' MASTER_LOG_FILE = 'foo.000001'
, MASTER_HOST = 'host_name'
, MASTER_USER = 'user_name'
, MASTER_PASSWORD = 'password';

sql> START SLAVE 'slave1';

적절한 로그 파일과 위치는 mysqldump 파일의 시작 부분에서 복제 구성 (--master-data=2 인수로 생성).

슬레이브 상태 모니터링에 대한 자세한 내용은 Configuring Replication을 참조하십시오.

응용 프로그램 서버 절체

응용 프로그램 서버를 절체하는 방법

응용 프로그램 서버를 MySQL에서 ClustrixDB로 전환하는 일반적인 두 가지 방법이 있습니다.

  1. 응용 프로그램 서버가 MySQL 대신 ClustrixDB을 가리키도록 다시 구성
  2. 트래픽을 MySQL 대신 ClustrixDB로 보내기 위한 HAProxy와 같은 외부 로드 밸런서 사용. Load Balancing Xpand with HAProxy을 참조하십시오.

리스크 완화

ClustrixDB 호환성 검증

절체 리스크를 줄이려면 ClustrixDB가 응용 프로그램에서 생성된 모든 쿼리를 적절하게 처리하도록 합니다.

  • 쓰기문 검증을 위해서 SBR 모드의 복제는 ClustrixDB 슬레이브가 쓰기 쿼리를 처리할 수 있도록 보장합니다. RBR은 쓰기가 많은 워크로드에서 더 나은 성능을 제공하지만, 처음에는 SBR을 사용해서 쓰기 쿼리를 검증하는 것이 좋습니다. SBR 모드는 초기에 복제 문제를 해결하는 데 유용합니다. 모든 문이 검증되면 더 나은 복제 성능을 위해 SBR 모드를 RBR로 변환할 수 있습니다.
  • 읽기문 검증을 위해서 tcpdump 유틸리티를 또는 전체 쿼리 로깅을 활성화해서 SQL 쿼리를 캡처할 수 있습니다. Clustrix 지원팀이 tcpdump 출력을 유효한 SQL 세션으로 변환하는 데 도움을 줄 수 있습니다. 그런 다음 변환된 쿼리는 검증을 위해서 MySQL 클라이언트를 사용하여 재생할 수 있습니다. tcpdump에서 가져온 SQL 세션을 사용하여 동시성 성능을 테스트하려면 stest 유틸리티를 사용하십시오. Clustrix 지원팀은 stest 초기 설치 및 실행에 필요한 도움을 제공할 수 있습니다.

MySQL로 장애 복구(failback)

MySQL로 다시 전환하는 기능은 프로덕션 서비스에 미치는 리스크를 최소화할 수 있습니다. 사전에 ClustrixDB에서 MySQL을 슬레이브로 구성하면 필요시 원활하게 서비스를 전환할 수 있습니다.

장애 복구 단계는 Configuring Replication Failover 섹션 및 아래에 설명되어 있습니다.

  1. MySQL 슬레이브 인스턴스에서 모든 응용 프로그램의 로그인 권한을 유지하십시오. 그러나, read_only 글로벌 변수를 설정하여 인스턴스를 읽기 전용으로 유지합니다.

    slave> SET GLOBAL read_only = true;
  2. ClustrixDB에서 binlog 로깅을 활성화하여 포맷이 MySQL 마스터와 동일하도록 하십시오. MySQL로 장애 복구를 가능하게 하려면 응용 프로그램의 쓰기가 허용되기 전에 ClustrixDB에서 binlog를 만들어야 합니다.

    CREATE BINLOG binlog_name [format='row']
  3. 응용 프로그램 서버가 ClustrixDB로 전환되면, ClustrixDB의 슬레이브(MySQL 마스터에서)를 중지할 수 있습니다. 또는 MySQL이 ClustrixDB에서 복제하는 동안 양방향 또는 마스터-마스터 복제를 구성하고 거기서 ClustrixDB가 MySQL에서 계속 복제합니다. 이 설정은 Configuring Replication Failover에서 설명한 바와 같이 몇 가지 주의를 요하는 복잡한 구성입니다.
  4. MySQL의 CHANGE MASTER TO 구문을 사용하여 2 단계에서 만든 binlog의 시작 위치 (위치 4)를 지정하여 MySQL을 ClustrixDB에서 슬레이브로 구성합니다.
MySQL로 되돌리기

위의 단계를 수행한 후에 MySQL로 되돌려야 하는 경우 다음 단계가 필요합니다.

  1. ClustrixDB를 읽기 전용 모드로 변경합니다.

    master> SET GLOBAL read_only = true;
  2. Binlog 파일과 ClustrixDB의 SHOW MASTER STATUS와 MySQL의 SHOW SLAVE STATUS에 표시된 위치를 비교하여 슬레이브 동기화 상태를 확인합니다.
  3. 현재 binlog 파일과 MySQL의 SHOW MASTER STATUS에 표시된 위치를 지정해서 MySQL에서 ClustrixDB 슬레이브를 재생성 또는 재활성화합니다.
  4. MySQL이 쓰기를 다시 처리하도록 설정합니다.

    slave> SET GLOBAL read_only = false;
  5. 응용 프로그램 서버가 MySQL을 가리킬 수 있게 되었습니다.

절체 모범 사례

비활성화된 서버는 읽기 전용으로 설정합니다 (슬레이브 및 루트 사용자는 면제됩니다).

sql>   SET GLOBAL read_only = true;  

절체 경고

복제 지연

절체 이전에 복제가 최신인지 확인하십시오. ClustrixDB가 많이 지연되어 있는 경우 새로 절체된 응용 프로그램 서버의 자동 증가(auto-increment) INSERT가 복제 스트림의 이전 INSERT와 충돌합니다. 이러한 문제가 발생하지 않도록 하려면 절체 전에 ClustrixDB 복제가 마스터와 동기화가 완료되도록 MySQL 서버를 일정 기간 정지시킬 필요가 있습니다.

잘못된 서버 / 스크립트

절체 이후 여전히 MySQL 데이터베이스에 쓰기를 하려고 하는 응용 프로그램이나 스크립트가 있을 수 있습니다. 이들은 MySQL 인스턴스가 read_only 모드로 설정되어 있어 실패하거나 루트(root) 계정으로 데이터를 조작할 수 있습니다. 이러한 예로는 MySQL 서버에 로컬로 배포된 관리 응용 프로그램 또는 DBA에 의해 루트 계정으로 실행되어 데이터를 조작하는 일부 데이터베이스 관리 셸 스크립트가 있습니다. 이러한 스크립트를 사전에 검토하고 ClustrixDB 인스턴스로 마이그레이션 해야 합니다. 그렇지 않으면, ClustrixDB와 MySQL 사이에서 데이터 불일치가 발생합니다.