Versions Compared

Key

  • 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
languageen

The following topics describe configuring Xpand as a Slave to a MySQL Master.

Table of Contents

Creating and Maintaining a Slave Configuration

Xpand supports multiple Slave processes, each with its own configuration. Because this functionality exceeds that provided by MySQL, Xpand extends replication syntax to support a named Slave configuration. Each replication Slave operates independently. If one Slave encounters an error and stops, other Slaves are unaffected. Ensure that Slaves do not update the database in a conflicting manner. To determine where replication for a specified slave is running, query the nodeid column in the system.mysql_slave_stats table.

For compatibility with MySQL, the standard syntax operates on a Slave named "default."

For example, operating on the "default" Slave, you can issue the following commands. Use the login information specifically established for the replication process when specifying MASTER_USER and MASTER_PASSWORD.

slave> STOP SLAVE;
slave> CHANGE MASTER TO MASTER_LOG_FILE = 'master_log_name', 
                        MASTER_LOG_POS = 1234, 
                        MASTER_HOST = 'host_name', 
                        MASTER_USER = 'user_name', 
                        MASTER_PASSWORD = 'password', 
                        MASTER_PORT = 3306;
slave> START SLAVE;
slave> SHOW SLAVE STATUS; 
Note

Note the use of the CHANGE MASTER command in the preceding example. This command always refers to the default Slave and is included for compatibility with MySQL. CHANGE MASTER is an alias for CHANGE SLAVE 'default'.

To define named Slaves for multiple Slave instances, use the following syntax. The login information for MASTER_USER and MASTER_PASSWORD should be that of the established replication user.

slave> CREATE SLAVE 'slave_name' MASTER_LOG_FILE = 'master_log_name', 
                                 MASTER_LOG_POS = nnn
                              [, MASTER_HOST = 'string'] 
                              [, MASTER_USER = 'string'] 
                              [, MASTER_PASSWORD = 'string'] 
                              [, MASTER_PORT = nnn]; 

The following code creates a new slave configuration entry with the specified Master settings. You use the specified slave_name in commands that you issue to control or monitor this slave instance.

slave> STOP SLAVE 'foo'; (if applicable)
slave> CREATE SLAVE 'foo' MASTER_LOG_FILE = 'my_master_log', 
                          MASTER_LOG_POS = 1234, 
                          MASTER_HOST = 'myhost', 
                          MASTER_USER = 'replication', 
                          MASTER_PASSWORD = 'clustrix', 
                          MASTER_PORT = 3306;
slave> START SLAVE 'foo';
slave> SHOW SLAVE STATUS 'foo';

To update the configuration of the Slave, specifying settings such as hostname, port, log sequence, and log filename, issue the following command:

slave> CHANGE SLAVE 'slave_name' TO {master_option} [,{master_option}];  

Anchor
Starting_and_Stopping_a_Slave_Process
Starting_and_Stopping_a_Slave_Process
Starting and Stopping a Slave Process

To start a specified Slave, issue the following command:

slave> START SLAVE 'slave_name'; 

If the Slave is already running, this command has no effect. To start any Slaves that are configured on this cluster and not already running, issue the following command. To load-balance replication traffic, Slaves are started in a round-robin fashion across the nodes in the cluster which means that the slaves are not consistently bound to one specific node.  This doesn't have an impact to replication as the slave is configured to communicate to a specific master host, but replication errors are logged on the node that the slave process is running from.

slave> START SLAVE ALL; 

To stop a specified Slave, issue the following command:

slave> STOP SLAVE 'slave_name';

If the Slave is not running, this command has no effect.

To stop all running Slaves, issue the following command:

slave> STOP SLAVE ALL;

Alternatively, Xpand also supports the legacy MySQL Syntax for SLAVE START and SLAVE STOP.

Displaying the Status of a Slave

To display the status of a specified Slave, issue the following command.

slave> SHOW SLAVE STATUS 'slave_name'; 

To display the status of all Slaves, issue the following command.

slave> SHOW SLAVE STATUS;

Skipping Statements for a Stopped Slave

To skip one or more pending replication statements (for example, when dealing with a bad query), issue the following command:

slave> START SLAVE ['slave_name'] SKIP N;

where N is the number of statements to skip. The Slave skips the specified number of statements and attempts to execute the following statements. If the statement after N+1 fails for any reason, the Slave remains in the same state as before the SKIP command was issued. For example, if there are three consecutive failing queries in a row, SKIP 1 or SKIP 2 has no effect on the Slave position, but SKIP 3 enables replication to resume.

Anchor
Specifying_Ignored_and_Included_Databases
Specifying_Ignored_and_Included_Databases
Specifying Ignored and Included Databases

The Xpand replication Slave supports the following modes:

  • Replicate everything, skipping specified databases (default)
  • Replicate only specified databases, skipping everything else

The following examples, using databases named "one", "two" and "three", illustrate the modes. In the following example, statements for database "one" and "three" are executed. Statements for database "two" are skipped.

slave> SET GLOBAL mysql_default_db_replication_policy = true;
slave> INSERT INTO system.mysql_slave_db_replication_policy (slave_name, dbname, allow) VALUES ('foo', 'one', true);
slave> INSERT INTO system.mysql_slave_db_replication_policy (slave_name, dbname, allow) VALUES ('foo', 'two', false); 

In the following example, statements for database "one" are executed. Statements for databases "two" and "three" are skipped.

slave> SET GLOBAL mysql_default_db_replication_policy = false;
slave> INSERT INTO system.mysql_slave_db_replication_policy (slave_name, dbname, allow) VALUES ('foo', 'one', true);
slave> INSERT INTO system.mysql_slave_db_replication_policy (slave_name, dbname, allow) VALUES ('foo', 'two', false); 
Note
  • These "ignore" and "include" directives affect named Slave instances globally.
  • Only the current database of a statement determines whether it is executed or skipped as part of this policy.
  • Rows in which the allow column matches the policy variable are treated as if they are not present (that is, according to the policy).
  • Stop the Slave manually before changing policies. This configuration is read when the Slave starts (and periodically when its buffer fills).

Anchor
Controlling_Slave_Behavior_on_Errors
Controlling_Slave_Behavior_on_Errors
Controlling Slave Behavior on Errors

Xpand offers two ways to control slave behavior on errors:

  • Inserting error codes into system.mysql_slave_skip_errors
  • Setting the slave_exec_mode global variable
Inserting error codes into system.mysql_slave_skip_errors

You can configure the slave not stop on certain errors by inserting the desired error code into the table system.mysql_slave_skip_errors. This applies to all slaves: it cannot be configured per-slave.
Note: Insert the mysql_error_code, NOT the result_code into mysql_slave_skip_errors.

To obtain a list of available error codes, run the following query:

slave> select * from system.mysql_error_codes natural join error_codes;  
+-------------+------------------+---------+-----------------------+--------------------------------------------------+
| result_code | mysql_error_code | family  | code                  | message                                          |
+-------------+------------------+---------+-----------------------+--------------------------------------------------+
|        7168 |             1452 | dml     | DML_FK_INSERT_ERR     | Foreign key constraint violation on insert       | 
|       60417 |             1213 | lockman | LOCKMAN_RC_DEADLOCK   | Lock manager deadlock detected                   | 
|       26645 |             1062 | rigr    | RIGR_RC_DUPLICATE_KEY | Duplicate key in representation                  | 
|       12309 |             1061 | ddl     | DDL_RC_INDEX_CONFLICT | Index name conflict                              | 
|        7172 |             1701 | dml     | DML_FK_TRUNCATE_ERR   | Foreign key contraint on truncate                | 
|       11267 |             1049 | trans   | NO_SUCH_DATABASE      | No such database                                 | 
|       11281 |             1044 | trans   | DB_PERMISSION_DENIED  | Insufficient user permissions to access database | 
|       12307 |             1007 | ddl     | DDL_RC_DB_CONFLICT    | Database name conflict                           | 
|       34816 |             1064 | parser  | ERRCODE_SYNTAX_ERROR  | syntax error                                     | 
|        7171 |             1048 | dml     | DML_NOTNULL_ERR       | NOT NULL constraint violation                    | 
... 
Note

 The only errors supported for Row-Based_Replication (RBR) are 1451 and 1452 (Cannot delete or update parent row, Cannot add or update child row, respectively).

To insert an error code into system.mysql_slave_skip_errors, stop the slaves and then run a query such as the following that inserts error code 1062 into the table:

slave> insert into system.mysql_slave_skip_errors values (1062);
Query OK, 1 row affected (0.02 sec) 
Setting the slave_exec_mode global variable

MySQL row-based replication specifies the expected (pre-update) contents of each row to be updated or deleted. In case the row specified does not exactly match the row present on Xpand, there are two modes of operation, determined by the setting of the global variable slave_exec_mode:

  • STRICT: In this mode, as long as the PRIMARY KEY or first UNIQUE key of the row matches, the update/delete is applied. This is the default setting, and also matches MySQL's default behavior.
  • EXACT: In this mode, if the row specified does not exactly match (for all columns) a row present in the table, the slave will error (with "Row Not Found"), and stop. Note that this mode is unique to Xpand.
Replicating Identically-Named Databases

To replicate identically-named databases from different Masters, you can create rewrite rules that map one database name to another. To remap database names, add a rule of the form (slave_name, from_db, to_db) to the table system.mysql_slave_rewrite_db. The following example remaps "db1234" to "otherdb."

slave> INSERT INTO system.mysql_slave_rewrite_db VALUES('slaveA','db1234','otherdb');
Query OK, 1 row affected (0.02 sec) 
Note
  • You can define only one remapping for any Slave/database combination.
  • You must stop the Slave before creating or modifying a rule for it.
  • You cannot perform cross-database updates.

Deleting a Slave Configuration

To delete a previously configured Slave, issue the following command:

slave> DROP SLAVE 'slave_name'; 
Note

You must stop the Slave before deleting it.

Changing a Slave's Location

Use the following syntax to assign a slave to a different node. This may be useful to experiment with the effects of slave load on the cluster by manually moving a slave without causing a group change. (See Group Changes for more information.)

slave> CHANGE SLAVE 'slave_name' to nodeid=nodeid; 

Replicating from MariaDB

Xpand does not provide support for MariaDB GTIDs, but can replicate from MariaDB 10.2+ using its support for old-style replication. The normal syntax for creating a replication slave can be used to set Xpand up as a replication slave.  

Replicating from MySQL 5.7

Xpand does not provide support for MySQL GTIDs and ignores GTID info it encounters in binlogs.

When replicating from MySQL 5.7, the gtid and server_uuid variables will be ignored when encountered in the binlog.

Additional information is available at MySQL 5.7 Replication and GTIDs.


Sv translation
languageko

다음 항목에서는 ClustrixDB를 MySQL 마스터의 슬레이브로 구성하는 방법을 설명합니다.

Table of Contents

슬레이브 구성 생성 및 관리

ClustrixDB는 각 슬레이브 프로세스마다 고유한 구성을 가지는 다수의 슬레이브 프로세스를 지원합니다. 이 기능이 MySQL에서 지원하는 기능보다 낫기 때문에 ClustrixDB는 복제 구문을 확장하여 명명된 슬레이브 구성을 지원합니다. 각 복제 슬레이브는 독립적으로 동작합니다. 하나의 슬레이브에 오류가 발생하여 중지돼도 다른 슬레이브는 영향을 받지 않습니다. 슬레이브가 데이터베이스를 업데이트하면서 서로 충돌하지 않도록 주의하십시오. 지정된 슬레이브가 실행 중인지 확인하려면 system.mysql_slave_stats 테이블의 nodeid 열을 조회합니다.

MySQL과의 호환성을 위해 표준 구문은 "default"로 명명된 슬레이브에서 작동합니다.

예를 들어 "default" 슬레이브에서 다음의 명령을 실행할 수 있습니다. MASTER_USERMASTER_PASSWORD를 지정할 때 복제 프로세스를 위해 특별히 설정된 로그온 정보를 사용하십시오.

slave> STOP SLAVE;
slave> CHANGE MASTER TO MASTER_LOG_FILE = 'master_log_name', MASTER_LOG_POS = 1234, MASTER_HOST = 'host_name', MASTER_USER = 'user_name', MASTER_PASSWORD = 'password', MASTER_PORT = 3306;
slave> START SLAVE;
slave> SHOW SLAVE STATUS; 
Note

이전 예제에서 CHANGE MASTER 명령사용에 주목하십시오. 이 명령은 항상 기본(default) 슬레이브를 참조하며 MySQL과의 호환성을 위해 포함되었습니다. CHANGE MASTERCHANGE SLAVE 'default'의 별칭입니다.

여러 개의 슬레이브 인스턴스에 명명된 슬레이브를 정의하려면 다음 구문을 사용하십시오. MASTER_USERMASTER_PASSWORD의 로그온 정보는 설정된 복제 사용자의 로그온 정보여야 합니다.

slave> CREATE SLAVE 'slave-name' MASTER_LOG_FILE = 'master_log_name', MASTER_LOG_POS = nnn [, MASTER_HOST = 'string'] [, MASTER_USER = 'string'] [, MASTER_PASSWORD = 'string'] [, MASTER_PORT = nnn]; 

다음 코드는 지정된 마스터 설정을 사용하여 새 슬레이브 구성을 만듭니다. 실행할 명령문에 지정된 슬레이브 이름을 사용하여 슬레이브 인스턴스를 제어하거나 모니터할 수 있습니다.

slave> STOP SLAVE 'foo'; (if applicable)
slave> CREATE SLAVE 'foo' MASTER_LOG_FILE = 'my_master_log', MASTER_LOG_POS = 1234, MASTER_HOST = 'myhost', MASTER_USER = 'replication', MASTER_PASSWORD = 'clustrix', MASTER_PORT = 3306;
slave> START SLAVE 'foo';
slave> SHOW SLAVE 'foo' STATUS;

호스트 이름, 포트, 로그 시퀀스, 로그 파일 이름과 같은 설정을 지정하여 슬레이브 구성을 업데이트하려면 다음 명령을 실행하십시오.

slave> CHANGE SLAVE 'slave-name' TO {master_option} [, {master_option}];  

Anchor
Starting_and_Stopping_a_Slave_Process
Starting_and_Stopping_a_Slave_Process
슬레이브 프로세스 시작 및 중지

지정된 슬레이브를 시작하려면 다음 명령을 실행하십시오.

slave> START SLAVE 'slave-name'; 

슬레이브가 이미 실행 중이면 이 명령은 아무 효과가 없습니다. 이 클러스터에 구성되어 있고 아직 실행 중이 아닌 슬레이브를 시작하려면 다음 명령을 실행하십시오. 복제 트래픽 부하를 분산하기 위해서 슬레이브는 클러스터 노드 간에 라운드 로빈 방식으로 시작됩니다.

slave> START SLAVE ALL; 

지정된 슬레이브를 중지하려면 다음 명령을 실행하십시오.

slave> STOP SLAVE 'slave-name'; 

슬레이브가 실행 중이 아니라면 아무 효과가 없습니다.

실행 중인 모든 슬레이브를 중지하려면 다음 명령을 실행하십시오.

slave> STOP SLAVE ALL;

ClustrixDB는 SLAVE STARTSLAVE STOP에 대한 레거시 MySQL 구문도 지원합니다.

슬레이브 상태 표시

지정된 슬레이브의 상태를 표시하려면 다음 명령을 실행하십시오.

slave> SHOW SLAVE STATUS 'slave-name'; 

모든 슬레이브의 상태를 표시하려면 다음의 명령을 실행하십시오.

slave> SHOW SLAVE STATUS;

중지된 슬레이브에 대한 문(statements) 건너뛰기

하나 이상의 보류 중인 복제문을 스킵하려면(예를 들어, 잘못된 쿼리를 처리할 때) 다음 명령을 실행하십시오.

slave> START SLAVE <optional slave name> SKIP N;

N은 스킵할 복제문 개수입니다. 슬레이브는 지정된 수의 명령문을 건너뛰고 다음 문을 실행하려고 시도합니다. 어떤 이유로 N+1번째 다음의 복제문이 실패하면 슬레이브는 SKIP 명령이 실행되기 전의 상태를 유지합니다. 예를 들어, 한 행에 3개의 연속된 실패 쿼리가 있는 경우 SKIP 1 또는 SKIP 2는 슬레이브 위치에 아무런 영향을 주지 않지만, SKIP 3는 복제를 다시 시작합니다.

제외 및 포함 데이터베이스 지정

ClustrixDB 복제 슬레이브는 다음의 두 가지 모드를 지원합니다.

  • 지정된 데이터베이스를 스킵하고 전체를 복제합니다 (기본).
  • 지정된 데이터베이스만 복제하고 모두 스킵합니다.

다음의 예제들은 "one", "two" 및 "three"라고 명명된 데이터베이스를 사용하여 두 가지 모드를 설명합니다. 다음 예제에서는 데이터베이스 "one"과 "three"에 대한 명령문이 실행됩니다. 데이터베이스 "two"에 대한 명령문은 생략됩니다.

slave> SET GLOBAL mysql_default_db_replication_policy = true;
slave> INSERT INTO system.mysql_slave_db_replication_policy (slave_name, dbname, allow) VALUES ('foo', 'one', true);
slave> INSERT INTO system.mysql_slave_db_replication_policy (slave_name, dbname, allow) VALUES ('foo', 'two', false); 

다음 예제에서는 데이터베이스 "one"에 대한 명령문이 실행됩니다. 데이터베이스 "two"와 "three"에 대한 명령문은 스킵됩니다.

slave> SET GLOBAL mysql_default_db_replication_policy = false;
slave> INSERT INTO system.mysql_slave_db_replication_policy (slave_name, dbname, allow) VALUES ('foo', 'one', true);
slave> INSERT INTO system.mysql_slave_db_replication_policy (slave_name, dbname, allow) VALUES ('foo', 'two', false); 
Note
  • "ignore" 및 "include" 지시자는 명명된 슬레이브 인스턴스 전체에 영향을 줍니다.
  • 명령문의 현재 데이터베이스만이 이 정책의 일부로 실행되거나 스킵될지를 판별합니다.
  • allow 열이 정책 변수와 일치하는 행은 마치 존재하지 않는 것처럼 취급됩니다 (즉, 정책에 따라).
  • 정책을 변경하기 전에 슬레이브를 수동으로 중지하십시오. 이 설정은 슬레이브가 시작할 때 (그리고 버퍼가 채워질 때 정기적으로) 이 설정을 읽습니다.

오류 시 슬레이브 동작 제어

ClustrixDB는 오류 시 슬레이브 동작을 제어하는 두 가지 방법을 제공합니다.

  • system.mysql_slave_skip_errors 테이블에 skip 오류 코드 삽입
  • slave_exec_mode 글로벌 변수 설정
system.mysql_slave_skip_errors 테이블에 skip 오류 코드 삽입

적절한 오류 코드를 system.mysql_slave_skip_errors 테이블에 삽입하여 슬레이브가 특정 오류로 중지하지 않도록 설정할 수 있습니다. 이 설정은 모든 슬레이브에 적용됩니다. 슬레이브 별로 구성할 수 없습니다.
주의: mysql_slave_skip_errorsresult_code가 아닌 mysql_error_code를 삽입하십시오.

사용 가능한 오류 코드 목록을 조회하려면 다음 쿼리를 실행하십시오.

slave> select * from system.mysql_error_codes natural join error_codes;  
+-------------+------------------+---------+-----------------------+--------------------------------------------------+
| result_code | mysql_error_code | family  | code                  | message                                          |
+-------------+------------------+---------+-----------------------+--------------------------------------------------+
|        7168 |             1452 | dml     | DML_FK_INSERT_ERR     | Foreign key constraint violation on insert       | 
|       60417 |             1213 | lockman | LOCKMAN_RC_DEADLOCK   | Lock manager deadlock detected                   | 
|       26645 |             1062 | rigr    | RIGR_RC_DUPLICATE_KEY | Duplicate key in representation                  | 
|       12309 |             1061 | ddl     | DDL_RC_INDEX_CONFLICT | Index name conflict                              | 
|        7172 |             1701 | dml     | DML_FK_TRUNCATE_ERR   | Foreign key contraint on truncate                | 
|       11267 |             1049 | trans   | NO_SUCH_DATABASE      | No such database                                 | 
|       11281 |             1044 | trans   | DB_PERMISSION_DENIED  | Insufficient user permissions to access database | 
|       12307 |             1007 | ddl     | DDL_RC_DB_CONFLICT    | Database name conflict                           | 
|       34816 |             1064 | parser  | ERRCODE_SYNTAX_ERROR  | syntax error                                     | 
|        7171 |             1048 | dml     | DML_NOTNULL_ERR       | NOT NULL constraint violation                    | 
... 
Note

RBR(Row-Based Replication)에 대해 1451 및 1452 오류만 지원됩니다 (1451 - Cannot delete or update parent row, 1452 - Cannot add or update child row).

system.mysql_slave_skip_errors에 오류 코드를 삽입하려면 슬레이브를 중지한 다음과 같이 오류 코드 1062를 삽입하는 쿼리를 실행하십시오.

slave> insert into system.mysql_slave_skip_errors values (1062);
Query OK, 1 row affected (0.02 sec) 
slave_exec_mode 글로벌 변수 설정

MySQL의 행 기반 복제는 업데이트되거나 삭제될 각 행의 예상(사전 업데이트) 내용을 지정합니다. 만약에 지정된 행이 ClustrixDB에 존재하는 행과 정확히 일치하지 않는 경우 글로벌 변수 slave_exec_mode 설정에 따라 다음 두 가지 작업 모드가 결정됩니다.

  • STRICT: 이 모드에서 행의 기본 키(PRIMARY KEY) 또는 첫 번째 고유 키(UNIQUE key)가 일치하는 한 update/delete가 적용됩니다. 이것이 기본 설정이며 MySQL의 기본 동작과 일치합니다.
  • EXACT: 이 모드에서 지정된 행이 테이블에 있는 행의 모든 열에 대해 정확히 일치하지 않으면 슬레이브는 “Row Not Found” 오류를 발생하고 중지됩니다. 이 모드는 ClustrixDB에서만 지원됩니다.
동일한 이름의 데이터베이스 복제

서로 다른 마스터에서 동일한 이름의 데이터베이스를 복제하려면 하나의 데이터베이스 이름을 다른 이름으로 매핑하는 재매핑 규칙을 만들 수 있습니다. 데이터베이스 이름을 재매핑 하려면 system.mysql_slave_rewrite_db 테이블에 규칙 (slave_name, from_db, to_db)을 추가합니다. 다음 예제에서는 "db1234"를 "otherdb"에 재매핑합니다.

slave> INSERT INTO system.mysql_slave_rewrite_db VALUES('slaveA','db1234','otherdb');
Query OK, 1 row affected (0.02 sec) 
Note
  • 슬레이브 / 데이터베이스 조합에 대해 하나의 매핑만 정의할 수 있습니다.
  • 규칙을 만들거나 수정하기 전에 슬레이브를 중지하십시오.
  • 데이터베이스 간 업데이트는 수행할 수 없습니다.

슬레이브 구성 삭제

이전에 구성한 슬레이브를 삭제하려면 다음 명령을 실행하십시오.

slave> DROP SLAVE 'slave-name'; 
Note

삭제하기 전에 슬레이브를 중지해야 합니다.

MySQL 5.7에서 복제

ClustrixDB는 MySQL GTID를 지원하지 않고 binlog에 GTID가 있으면 GTID 정보를 무시합니다. 

MySQL 5.7에서 복제할 때 binlog에 있는 gtid 및 server_uuid 변수는 무시됩니다.

server_uuid와 관련된 clustrix.log의 오류는 무시됩니다. 

MySQL 5.7 복제 및 GTID에서 추가 정보를 확인하실 수 있습니다.