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

Table of Contents
maxLevel4

About Binary Logs

Xpand implements MySQL compatible binlogs that with the following additional features:

  • Xpand can maintain multiple independent binary logs (for example, binlogs per table, per database, or for a set of tables and databases).
  • The binary logs are fault-tolerant, with the same guarantees as the rest of the Xpand system.
  • Writes to the binlog are transactional, consistent, and durable (full ACID guarantee).
  • Binary logs can be created and dropped online.

To configure a Xpand system with a single row-based binary log, issue the following commands:

master> CREATE BINLOG 'clustrix-bin' FORMAT='ROW';
master> SHOW MASTER STATUS;

To disable binary logging and drop (permanently) an existing binlog:

master> DROP BINLOG 'clustrix-bin';
Note

When running MySQL database as a slave to a Xpand master, Xpand does not support the variable binlog_checksum, which causes the master to write checksums for events written to the binary log.

Anchor
MySQL_5.7_Replication_and_GTIDs
MySQL_5.7_Replication_and_GTIDs
MySQL 5.7 Replication and GTIDs

MySQL produces global transaction identifiers (GTIDs) beginning with MySQL 5.6 (optional) and MySQL 5.7 (required). Xpand does not implement nor support GTIDs. To enable replication between Xpand and MySQL with GTID, use the following settings:

For Xpand (Master) to MySQL 5.7 (Slave) Replication
  • The MySQL slave must have the global gtid_mode set to OFF, OFF_PERMISSIVE, or ON_PERMISSIVE.
  • The MySQL startup option enforce-gtid-consistency should be set to OFF on the slave. See Startup Options Used with GTID Replication.
For MySQL 5.7 (Master) to Xpand (Slave) Replication
Note

Xpand does not pass GTID events to its binlogs. This is similar to the behavior of a MySQL 5.6 slave with gtid_mode set to OFF.

Create Replication User

The user name and password used for replication are stored as plain text within the binlogs. As such, Xpand recommends establishing a separate account for exclusive use with replication to prevent compromising the security of regularly used accounts.

Follow this sample to create an account that will be used when setting up a slave. You must have privileges to CREATE USER and GRANT to perform this step.

master> CREATE USER 'replication'@'%' IDENTIFIED BY 'clustrix';
master> GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%';

Creating a Binary Log File

To create a binary log, issue the following command:

CREATE BINLOG Syntax
master> CREATE BINLOG 'binlog_name' [LOG (target1, target2, ...),] [IGNORE (target3, target4, ...),] [FORMAT='STATEMENT'|'ROW']
Example
master> CREATE BINLOG 'mybinlog' FORMAT='ROW';

Optional attributes are:

  • LOG: A list of specific tables or databases to log
  • IGNORE: A list of specific tables or databases to ignore
  • FORMAT: Format specifier (STATEMENT or ROW).

By default, this command creates a binary log file for the entire cluster in STATEMENT format, which is the most common format in MySQL environments. Alternatively, you can create binlogs that scope a database or a list of tables. For more information, please see the section on Binlog scope.

For most workloads, row-based replication (FORMAT ='ROW') provides better performance than statement-based replication. If you are unsure what is most appropriate for your environment, contact Xpand Support.

Note

If a database is set to both LOG and IGNORE, Xpand will IGNORE. This deviates from MySQL, which will log and not ignore.

Setting Binary Logging Options

To configure binary logging options, issue the ALTER BINLOG command. Options for the ALTER BINLOG logfile command are as follows.

FlagDescription
LOG (db1, db2)Only log updates to databases db1 and db2
IGNORE (db3)Ignore updates to db3
ADD LOG (db4)Log updates to db4, in addition to others
ADD IGNORE (db5)Ignore updates to db5, in addition to others
DROP LOG (db6)Stop logging to db6
LOG ALLLog updates to all databases, as opposed to specific databases. Does not reset the IGNORE list.
DISABLEDisable logging to this binlog
ENABLEEnable logging to this binlog
RENAME barRename specified binlog to "bar"
FORMAT='row' or 'statement'Configure log format (row-based or statement-based)

Displaying Binary Log Information

If only one binary log exists, you can display its filename, segment number and position by issuing the following command:

master> SHOW MASTER STATUS;

If more than one binary log exists, the log configured by the global variable master_status_binlog is displayed. If master_status_binlog is unset, an error is returned. This behavior is compatible with behavior of the MySQL mysqldump --master-data command.

master> SET GLOBAL master_status_binlog = 'foo';
master> SHOW MASTER STATUS;

To display status for all binary logs, issue the following command:

master> SHOW ALL MASTER STATUS;

To display detailed information about binary logs, issue the following command:

master> SHOW BINLOGS;

Most of this information is not directly useful, though log size can help you decide whether to trim the log.

Anchor
Trim_Binlog
Trim_Binlog
Trimming a Binary Log

You can trim a binary log using either of the following methods:

  • TRIM BINLOG command
  • trim-binlog script
Trimming using the TRIM BINLOG Command

Back up your database regularly using the mysqldump --master-data command, which records the binary log filename at the start of the dump. To keep the size of the binary log under control, use this value to trim older data after it is backed up. The extent to which you trim is a matter of policy: you can choose to retain a week's history, or you might prefer to minimize disk consumption as much as possible by trimming all but the current file. To minimize the amount of space being used by your binary log, trim according to the Slave that is farthest behind in replication.

To list the files that compose the binary log, issue the following:

master> SHOW BINLOG FILES;
+-----------------+-----------+-----------------------+
| File            | Size      | First Event Timestamp |
+-----------------+-----------+-----------------------+
| eukanuba.000001 | 104857600 | 2016-01-09 19:51:08   | 
| eukanuba.000002 | 104857600 | 2016-01-09 20:02:09   | 
| eukanuba.000003 | 104857600 | 2016-01-09 22:22:27   | 
| eukanuba.000004 | 104857600 | 2016-01-09 22:30:37   | 
| eukanuba.000005 | 104857600 | 2016-01-09 22:38:11   | 
| eukanuba.000006 | 104857600 | 2016-01-09 22:45:44   | 
| eukanuba.000007 | 104857600 | 2016-01-09 22:53:03   | 
| eukanuba.000008 | 104857600 | 2016-01-09 23:00:44   | 
| eukanuba.000009 | 104857600 | 2016-01-09 23:07:46   | 
| eukanuba.000010 | 104857600 | 2016-01-09 23:15:00   | 
...

To display current Slave locations, issue the SHOW SLAVE STATUS command, which displays status as follows:

master> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
            Slave_Name: default
          Slave_Status: Running
           Master_Host: alpo
           Master_Port: 3306
           Master_User: root
       Master_Log_File: alpo
         Slave_Enabled: Enabled
          Log_File_Seq: 3383
          Log_File_Pos: 58790712
            Last_Error: no error
     Connection_Status: Connected
  Relay_Log_Bytes_Read: 0
Relay_Log_Current_Size: 0
 Seconds_Behind_Master: 0
1 row in set (0.00 sec)

The filename argument is the filename returned by the SHOW MASTER STATUS command. The sequence number (Log_File_Seq) indicates the binary log file currently in use (it's the numeric portion of the file name). To delete old binary data without dropping the entire log, issue the following command (nnnnn represents the sequence number):

master> TRIM BINLOG 'binlog_name' BEFORE FILE 'binlog_name.nnnnn';

For example, if the clx001.000283 file is timestamped at 7:15 PM on September 28, 2016, the following sample would delete all log files before that time.

master> TRIM BINLOG 'clx001' BEFORE FILE 'clx001.000283';
Trimming Using the binlog-trim Script

You can find the binlog-trim script in /opt/clustrix/bin/binlog-trim of your system.
Usage
binlog-trim [options]
Options

OptionDescription
-h, --helpShow this help message and exit
-H HOST, --host=HOSTSpecifies the host
-P PORT, --port=PORTSQL port, default is mysql port: 3306
-u USER, --user=USERUsername, default is root
-p PASSWD, --passwd=PASSWDSpecifies the password
-n NUM_FILES, --num-files=NUM_FILESNumber of files to trim a time
-d, --dryDo not perform any actual trims
-k KEEP_DAYS, --days=KEEP_DAYSKeep this many days of binlogs
-i INTERVAL, --interval=INTERVALSeconds between trims
-b BINLOG_NAME, --binlog_name=BINLOG_NAMEName of binlog to trim; must specify if multiple binlogs exist
-M MAX_RUN_TIME_MINS, --max-run-time-mins=MAX_RUN_TIME_MINSMaximum time (minutes) script may run
-V, --versionIndicates the version

binlog-trim is generally deployed as a cron job on one of the nodes. An example entry to run once a day at 5:35UTC, with a retention policy of 7 days, trimming no more than 50 files at a time, with a minimum 60-second pause between trims, and operating on the binlog called clustrix-bin:

35 5 * * * root /bin/binlog-trim -H localhost -i 60 -k 7 -n 50 -b clustrix-bin 2>&1 >> /var/log/binlog-trim.log
Note

The INTERVAL is a minimum wait between trims; there is additional logic in the script to prevent the trims from building up too much cleanup work (the logs will indicate this with 'waiting for bigc to pass trim').

Backing Up Binary Logs

Because Xpand binary logs (binlogs) aren't stored as plain files, they cannot be backed up as MySQL binlogs can. For backup purposes, Xpand provides the repclient utility, which copies binlogs from a Xpand or MySQL system as if it were a replication slave. The repclient utility can be run on any Xpand node.

To copy all of the binlogs off a Xpand cluster, perform the following steps:

  1. To list the most recent binlog, issue the SHOW MASTER STATUS command. The command returns a filename such as clustrix-bin.001903.
  2. Create a directory in the /clustrix mount on a node and cd to it.
  3. To retrieve all binlog files up to the most recent, issue the following command: 

    shell> node# repclient -addr 10.52.2.20 -dumpbinlog -logname clustrix-bin.000001 -end_logname clustrix-bin.001903
                
Note

By default, the tool outputs decoded binlog messages to stdout. To specify an output file, specify the  -dumpbinlog option. If you intend to archive the binlogs, omit -logpos, which can create gaps in the resulting binlog. By default, the utility stays connected to the master. To specify when it is to disconnect, include the -end_logname or -end_logpos option.

Valid options for the repclient command are as follows:

FlagDescription
-addr hostnameDatabase host (default: 127.0.0.1)
-count nNumber of messages to dump
-dumpbinlogDump binlog
-end_logname pathEnding replication log name
-end_logpos offsetEnding replication log position (default: EOF)
-helpList command options
-help-debugList command options plus debugging output options
-logname pathStarting replication log name
-logpos offsetStarting replication log position (default: 4)
-max-packet-size bytesMaximum packet size (default: 16777216)
-max-retries nMaximum retries after an error (default: 3)
-no-decode-rowsDon't decode row values
-pass passwordDatabase password (default: #undef)
-perfDump performance statistics
-perf-interval secondsDump performance statistics interval (default: 30)
-port portDatabase port (default: 3306)
-retry-timeout seconds Timeout in seconds for retries (default: 10)
-set-variable NAME= VALUESet a variable to the given value
-slave-id nSlave ID (default: 1)
-testconnect Test database connection and display status
-truncateTruncate any existing files
-user username Database username (default: root)
-verboseDisplay debugging messages

Excluding A Session from Binary Logs

To prevent a session's statements from being inserted into any binary log, set sql_log_bin to false by issuing the following command:

master> SET sql_log_bin=false;

This variable inherits the value of the identically-named global variable at the start of each session. To replicate from a Xpand instance, set sql_log_bin to true.

Warning

Be careful using sql_log_bin in production. Improper use can lead to data skew between the master and the slave(s).

Dropping a Binary Log File

To stop logging to the specified binary log and drop it from the system, issue the following command:

master> DROP BINLOG binlog_name;
Warning

You cannot recover a binary log after dropping it.

Global Variables

The following global and session variables control binary log behavior:

NameDescriptionDefault ValueSession Variable
binlog_checksumAlways NONE. Xpand masters do not support generating event checksums.NONE 
binlog_formatForce all binlogs to log in this format, unless set to 'DEFAULT'.DEFAULT 

(tick)

gtid_modeAlways OFF. Xpand masters do not support generating GTID events.OFF 
gtid_purgedDummy variable for compatibility. (Xpand does not support replication with Global Transaction Identifiers.)

master_status_binlogBinlog used in SHOW MASTER STATUS when used without specifying a binlog.

(tick)

sql_log_binLog statements to binary logs. This variable can be set to FALSE on a per-session basis.true

(tick)

sync_binlogDummy variable for compatibility.
Warning

Exercise extreme care when changing these settings. The defaults may not be ideal for your system, but they should be reasonable. The product will not warn you if you configure inadvisable settings.

The following pages describe areas that should be understood when using Xpand as a Replication Master

  1. Online Schema Changes
  2. Replicating User Account Management Statements
  3. Using Xpand with Multiple Slaves


Sv translation
languageko

Table of Contents
maxLevel4

바이너리 로그 정보

MySQL은 쿼리를 일련의 바이너리 로그 파일에 기록하여 복제를 구현합니다. 해당 파일은 서버의 로컬 파일 시스템에 기록됩니다. 슬레이브는 MySQL 인스턴스에 연결하고 특정 파일 및 오프셋에서 시작하는 파일을 요청합니다.

MySQL의 바이너리 로깅에는 다음과 같은 단점이 있습니다.

  • 전체 시스템에 대해 하나의 바이너리 로그만 가집니다.
  • 내결함성은 기본 파일 시스템에 의해 제공됩니다.
  • 서버가 시작되면 정적 구성은 읽기 전용이 되므로 /etc/my.cnf를 변경하면 서버를 재시작해야 합니다.

ClustrixDB는 다음과 같은 추가 기능을 제공하기 때문에 MySQL의 기능보다 뛰어납니다.

  • ClustrixDB는 여러 개의 독립적인 바이너리 로그를 가질 수 있습니다 (예를 들어, 테이블 별, 테이터베이스 별, 여러 테이블 또는 데이터베이스별 바이너리 로그).
  • 바이너리 로그는 나머지 ClustrixDB 시스템이 보장하는 것과 동일한 정도의 내결함성을 가지고 있습니다.
  • 바이너리 로그 쓰기는 ACID를 지원합니다.
  • 온라인으로 바이너리 로그를 생성 또는 삭제할 수 있습니다.

ClustrixDB가 하나의 행 기반 바이너리 로그만 갖도록 구성하려면 다음 명령을 실행합니다.

master> CREATE BINLOG 'clustrix-bin' FORMAT='ROW';
master> SHOW MASTER STATUS;

바이너리 로깅을 비활성화하고 기존의 바이너리 로그를 삭제하려면 다음을 실행합니다.

master> DROP BINLOG 'clustrix-bin';
Note

MySQL 데이터베이스를 ClustrixDB 마스터의 슬레이브로 실행하는 경우 ClustrixDB는 마스터가 바이너리 로그에 기록되는 이벤트에 대한 체크섬을 작성하는 binlog_checksum 변수를 지원하지 않습니다.

Anchor
MySQL_5.7_Replication_and_GTIDs
MySQL_5.7_Replication_and_GTIDs
MySQL 5.7 복제 및 GTID

MySQL은 버전 5.6에서 옵션이고 버전 5.7에서는 필수인 GTID(Global Transaction Identifier)를 생성합니다. ClustrixDB는 GTID를 생성하거나 지원하지 않습니다. ClustrixDB와 GTID를 생성하는 MySQL 인스턴스 간에 복제하려면 복제 방향에 따라 다른 설정을 해야 합니다.

ClustrixDB 마스터에서 MySQL 5.7 슬레이브로 복제
  • MySQL 슬레이브는 gtid_modeOFF, OFF_PERMISSIVE 또는 ON_PERMISSIVE로 설정해야 합니다.
  • MySQL 슬레이브는 GTID 복제와 함께 사용하는 시작 옵션에 설명된 대로 enforce-gtid-consistencyOFF로 설정해야 합니다.
Note

Clustrix 로그에서 server_uuid 관련 오류는 무시해도 됩니다.

MySQL 5.7 마스터에서 ClustrixDB 슬레이브로 복제
  • ClustrixDB 버전 7.6 이상을 실행합니다. 
  • MySQL 마스터의 설정은 중요하지 않으며 특별한 변경이 필요하지 않습니다.
  • 자세한 내용은 Using ClustrixDB as a Slave를 참조하십시오.
Note

ClustrixDB는 GTID 이벤트를 binlog에 전달하지 않습니다. 이것은 gtid_modeOFF로 설정된 MySQL 5.6 슬레이브의 동작과 유사합니다.

복제 사용자 생성

복제에 사용되는 사용자 이름과 암호는 binlog에 일반 텍스트로 저장됩니다. 따라서, Clustrix는 보안을 위해서 별도의 복제 계정을 생성하는 것을 권장합니다.

아래의 예제를 따라 슬레이브 설정 시 사용할 계정을 만듭니다. 이 단계를 수행하려면 CREATE USERGRANT 실행 권한이 필요합니다.

master> CREATE USER 'replication'@'%' IDENTIFIED BY 'clustrix';
master> GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%';

바이너리 로그 파일 생성

바이너리 로그를 생성하려면 다음 명령을 실행하십시오.

CREATE BINLOG Syntax
master> CREATE BINLOG 'binlog_name' [LOG (target1, target2, ...),] [IGNORE (target3, target4, ...),] [FORMAT='STATEMENT'|'ROW']
Example
master> CREATE BINLOG 'mybinlog' FORMAT='ROW';

선택적 속성:

  • LOG: 로깅할 특정 테이블 또는 데이터베이스 목록
  • IGNORE: 무시할 특정 테이블 또는 데이터베이스 목록
  • FORMAT: 포맷 지정자 (STATEMENT 또는 ROW)

기본적으로 이 명령은 클러스터 전체에 대한 바이너리 로그 파일을 STATEMENT 형식으로 생성합니다. 이 형식은 MySQL 환경에서 가장 일반적인 형태입니다. 또는 데이터베이스나 테이블 목록을 범위로 하는 binlog를 만들 수 있습니다. 더 자세한 내용은 Binlog scope 섹션을 참조하십시오.

대부분의 워크로드에서 row 기반 복제(FORMAT ='ROW')가 statement 기반 복제보다 높은 성능을 제공합니다. 자신의 환경에 어떤 방식이 가장 적합한지 확실하지 않은 경우 Clustrix 지원팀에 문의하십시오.

Note

데이터베이스가 LOGIGNORE 둘 다 설정된 경우 ClustrixDB는 IGNORE를 적용합니다. 이것은 LOG를 적용하는 MySQL과 다릅니다.

바이너리 로깅 옵션 설정

바이너리 로깅 옵션을 설정하려면 ALTER BINLOG를 사용하십시오. ALTER BINLOG logfile 명령 옵션은 다음과 같습니다.

플래그

설명

LOG (db1, db2)

데이터베이스 db1 및 db2에 대한 업데이트만 로깅

IGNORE (db3)

db3에 대한 업데이트 무시

ADD LOG (db4)

다른 데이터베이스와 함께 db4에 대한 업데이트도 로깅

ADD IGNORE (db5)

다른 데이터베이스와 더불어 db5에 대한 업데이트 무시

DROP LOG (db6)

db6에 대한 로깅 중지

LOG ALL

특정 데이터베이스가 아닌 모든 데이터베이스에 대한 업데이트 기록. IGNORE 목록을 재설정하지 마십시오.

DISABLE

이 binlog에 로깅 사용 안 함

ENABLE

이 binlog에 로깅 활성화

RENAME bar

특정 binlog의 이름을 "bar"로 변경

FORMAT='row' or 'statement'

로그 형식 설정 (row-based 또는 statement-based)

바이너리 로그 정보 표시

하나의 바이너리 로그만 있는 경우 다음 명령을 실행하여 파일 이름, 세그먼트 번호 및 위치를 표시할 수 있습니다.

master> SHOW MASTER STATUS;

둘 이상의 바이너리 로그가 존재하는 경우 전역 변수 master_status_binlog로 설정된 로그가 표시됩니다. master_status_binlog 변수가 설정되어 있지 않으면 오류가 반환됩니다. 이 동작은 MySQL mysqldump --master-data 명령의 동작과 호환됩니다.

master> SET GLOBAL master_status_binlog = 'foo';
master> SHOW MASTER STATUS;

모든 바이너리 로그의 상태를 표시하려면 다음 명령을 실행하십시오.

master> SHOW ALL MASTER STATUS;

바이너리 로그에 대한 상세 정보를 표시하려면 다음 명령을 실행하십시오.

master> SHOW BINLOGS;

이 정보의 대부분이 직접적으로 유용하지는 않지만, 로그 사이즈는 로그 트림의 여부를 결정하는 데 도움이 됩니다.

Anchor
Trim_Binlog
Trim_Binlog
바이너리 로그 트리밍

다음 방법 중 하나를 사용하여 바이너리 로그를 트리밍 할 수 있습니다.

  • TRIM BINLOG 명령
  • trim-binlog 스크립트
TRIM BINLOG 명령을 사용한 트리밍

mysqldump --master-data 명령을 사용하여 데이터베이스를 정기적으로 백업하십시오. 이 명령은 덤프 시작 시 바이너리 로그 파일 이름을 기록합니다. 바이너리 로그의 크기를 제어하려면 이 값을 사용하여 백업 후 이전 데이터를 트리밍하십시오. 어디까지 트리밍 할 것인지는 정책의 문제입니다. 1주일의 기록을 보존하거나 현재 파일을 제외한 모든 파일을 트리밍하여 디스크 사용을 최소화하는 정책을 선택할 수 있습니다. 바이너리 로그가 사용하는 공간을 최소화하려면 복제 시 가장 느린 슬레이브를 기준으로 제거합니다.

바이너리 로그를 구성하는 파일을 나열하려면 다음 명령을 실행하십시오.

master> SHOW BINLOG FILES;
+-----------------+-----------+-----------------------+
| File            | Size      | First Event Timestamp |
+-----------------+-----------+-----------------------+
| eukanuba.000001 | 104857600 | 2016-01-09 19:51:08   | 
| eukanuba.000002 | 104857600 | 2016-01-09 20:02:09   | 
| eukanuba.000003 | 104857600 | 2016-01-09 22:22:27   | 
| eukanuba.000004 | 104857600 | 2016-01-09 22:30:37   | 
| eukanuba.000005 | 104857600 | 2016-01-09 22:38:11   | 
| eukanuba.000006 | 104857600 | 2016-01-09 22:45:44   | 
| eukanuba.000007 | 104857600 | 2016-01-09 22:53:03   | 
| eukanuba.000008 | 104857600 | 2016-01-09 23:00:44   | 
| eukanuba.000009 | 104857600 | 2016-01-09 23:07:46   | 
| eukanuba.000010 | 104857600 | 2016-01-09 23:15:00   | 
...

현재 슬레이브 위치를 표시하려면 SHOW SLAVE STATUS 명령을 실행합니다. 그러면 다음과 같이 상태가 표시됩니다.

master> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
            Slave_Name: default
          Slave_Status: Running
           Master_Host: alpo
           Master_Port: 3306
           Master_User: root
       Master_Log_File: alpo
         Slave_Enabled: Enabled
          Log_File_Seq: 3383
          Log_File_Pos: 58790712
            Last_Error: no error
     Connection_Status: Connected
  Relay_Log_Bytes_Read: 0
Relay_Log_Current_Size: 0
 Seconds_Behind_Master: 0
1 row in set (0.00 sec)

filename 인수는 SHOW MASTER STATUS 명령에서 반환된 파일 이름입니다. 시퀀스 번호(Log_File_Seq)는 현재 사용 중인 바이너리 로그 파일을 나타냅니다 (파일 이름의 숫자 부분). 전체 로그를 삭제하지 않고 오래된 바이너리 데이터를 삭제하려면 다음 명령을 실행합니다 (nnnnn는 시퀀스 번호):

master> TRIM BINLOG binlog_name BEFORE FILE 'binlog_name.nnnnn';

예를 들어, clx001.000283 파일에 2016년 9월 28일 오후 7시 15분에 타임스탬프가 지정된 경우 다음 예제에서는 해당 시간 전의 모든 로그 파일을 삭제하게 됩니다.

master> TRIM BINLOG clx001 BEFORE FILE 'clx001.000283';
binlog-trim 스크립트를 사용한 트리밍

binlog-trim 스크립트는 시스템의 /bin/binlog-trim에 있습니다.
사용법
binlog-trim [options]
옵션

옵션설명
-h, --help이 도움말 메시지를 표시하고 종료됩니다.
-H HOST, --host=HOST호스트를 지정합니다.
-P PORT, --port=PORTSQL 포트. 기본값은 mysql port: 3306입니다.
-u USER, --user=USER사용자 이름. 기본값은 root입니다.
-p PASSWD, --passwd=PASSWD암호를 지정합니다.
-n NUM_FILES, --num-files=NUM_FILES한 번에 트림하는 파일 수
-d, --dry실제 트림을 실행하지 않습니다.
-k KEEP_DAYS, --days=KEEP_DAYSbinlogs를 보관할 일수
-i INTERVAL, --interval=INTERVAL트림 간격 (초)
-b BINLOG_NAME, --binlog_name=BINLOG_NAME트림 대상 binlog 이름. binlog 존재 시 반드시 지정해야 함.
-M MAX_RUN_TIME_MINS, --max-run-time-mins=MAX_RUN_TIME_MINS스크립트가 실행할 수 있는 최대 시간 (분)
-V, --version버전 정보를 표시합니다.

binlog-trim은 일반적으로 노드 중 하나에서 cron 작업으로 실행합니다. 아래의 예는 clustrix-bin binlog에 대해 7일간의 보존 정책을 가지고 1일 1회 UTC 시간으로 5:35에 실행되며 최소 60초 간격으로 한 번에 최대 50개의 파일까지 트리밍합니다.

35 5 * * * root /bin/binlog-trim -H localhost -i 60 -k 7 -n 50 -b clustrix-bin 2>&1 >> /var/log/binlog-trim.log
Note

INTERVAL은 트리밍 사이의 최소 대기 시간입니다. 트리밍이 너무 많은 정리 작업을 하지 않도록 하기 위해서 로직이 추가되었습니다 (로그에는 ''waiting for bigc to pass trim”으로 표시됨).

바이너리 로그 백업

ClustrixDB 바이너리 로그(binlogs)는 일반 파일로 저장되지 않기 때문에 MySQL의 바이너리 로그처럼 백업할 수 없습니다. ClustrixDB는 백업을 위해서 repclient 유틸리티를 제공합니다. 이 유틸리티는 복제 슬레이브인 것처럼 ClustrixDB 또는 MySQL 시스템에서 binlog를 복사합니다. ClustrixDB의 모든 노드에서 repclient 유틸리티를 실행할 수 있습니다.

모든 binlogs를 ClustrixDB 클러스터에서 복사하려면 다음 단계를 수행하십시오.

  1. 가장 최근의 binlog를 나열하려면 SHOW MASTER STATUS 명령을 실행하십시오. 이 명령은 clustrix-bin.001903와 같은 파일 이름을 반환합니다.
  2. 하나의 노드에서 /clustrix로 마운트한 드라이브에 디렉토리를 만들고 해당 디렉토리로 이동합니다.
  3. 가장 최근의 binlog 파일까지 모두 조회하려면 다음 명령을 실행하십시오.

    shell> node# repclient -addr 10.52.2.20 -dumpbinlog -logname clustrix-bin.000001 -end_logname clustrix-bin.001903 
Note

기본적으로 디코딩된 binlog 메시지는 stdout으로 출력됩니다. 출력 파일을 지정하려면 -dumpbinlog 옵션을 지정하십시오. binlogs를 아카이브하려면 -logpos 옵션을 생략하십시오. 그러면 생성된 binlog에 간격이 생길 수 있습니다. 기본적으로 유틸리티는 계속해서 마스터에 연결되어 있습니다. 언제 연결을 끊을지 지정하려면 -end_logname 또는 -end_logpos 옵션을 사용하십시오.

repclient 명령에는 다음과 같은 옵션이 있습니다.

플래그설명
-addr hostname데이터베이스 호스트 (기본값: 127.0.0.1)
-count n덤프할 메시지 수
-dumpbinlogbinlog를 덤프합니다.
-end_logname path종료할 복제 로그 이름
-end_logpos offset종료할 복제 로그 위치 (기본값: EOF)
-help명령 옵션을 나열합니다.
-help-debug명령 옵션 및 디버깅 출력 옵션을 나열합니다.
-logname path시작할 복제 로그 이름
-logpos offset시작할 복제 로그 위치 (기본값: 4)
-max-packet-size bytes최대 패킷 크기 (기본값: 16777216)
-max-retries n에러 발생 후 재시도 횟수 (기본값: 3)
-no-decode-rows행 값을 디코딩하지 않습니다.
-pass password데이터베이스 암호 (기본값: #undef)
-perf성능 통계를 덤프합니다.
-perf-interval seconds성능 통계 덤프 간격 (기본값: 30)
-port port데이터베이스 포트 (기본값: 3306)
-retry-timeout seconds 재시도 시간 초과 (초) (기본값: 10)
-set-variable NAME= VALUE변수를 지정된 값으로 설정합니다.
-slave-id n슬레이브 ID (기본값: 1)
-testconnect 데이터베이스 연결 테스트하고 상태를 표시합니다.
-truncate모든 기존 파일을 삭제합니다.
-user username 데이터베이스 사용자 이름 (기본값: root)
-verbose디버그 메시지를 표시합니다.

바이너리 로그에서 세션 제외

세션의 명령문이 모든 바이너리 로그에 삽입되지 않도록 하려면 다음 명령을 실행하여 sql_log_binfalse로 설정하십시오.

master> SET sql_log_bin=false;

이 변수는 각 세션이 시작될 때 같은 이름의 전역 변수의 값을 상속받습니다. ClustrixDB 인스턴스에서 복제하려면 sql_log_bintrue로 설정합니다.

Warning

프로덕션 환경에서는 sql_log_bin을 사용할 때 주의하십시오. 부적절하게 사용하면 마스터와 슬레이브 간의 데이터 왜곡이 발생할 수 있습니다.

바이너리 로그 파일 삭제

지정된 바이너리 로그에 로깅을 중지하고 시스템에서 이를 제거하려면 다음 명령을 실행하십시오.

master> DROP BINLOG binlog_name;
Warning

바이너리 로그를 삭제한 후에는 복구할 수 없습니다.

글로벌 변수

다음 글로벌 및 세션 변수는 바이너리 로그 동작을 제어합니다.

변수설명기본값세션 변수
binlog_checksum항상 NONE입니다. Clustrix 마스터는 이벤트 체크섬 생성을 지원하지 않습니다.NONE  
binlog_format'DEFAULT'로 설정되어 있지 않은 한, 모든 바이너리 로그는 강제로 이 형식으로 기록합니다.DEFAULT 

(tick)

binlog_trimbinlog-trim이 실행되는 경우 TRUE. 변경하지 마십시오.false 

(tick)

gtid_mode항상 OFF. Clustrix 마스터는 GTID 이벤트 생성을 지원하지 않습니다.OFF  
gtid_purged호환성을 위한 더미 변수. Clustrix는 GTI(Global Transaction Identifiers)를 통한 복제를 지원하지 않습니다.  
master_status_binlog바이너리 로그를 지정하지 않고 사용할 때 SHOW MASTER STATUS에서 사용된 Binlog. 

(tick)

rebalancer_split_binlogsbinlog 문장의 세그먼트 분할을 허용합니다.false  
sql_log_bin문을 바이너리 로그에 기록합니다. 이 변수는 세션 별로 FALSE로 설정할 수 있습니다.true

(tick)

sync_binlog호환성을 위한 더미 변수 
task_binlog_rotate_interval_ms정기적인 "binlog_rotate" 작업의 실행 간격 (ms). 정기적인 작업을 비활성화하려면 0을 지정하십시오.120000  
Warning

이러한 설정을 변경할 때는 특별히 주의하십시오. 기본값들은 시스템에 이상적이지 않을지도 모르지만, 합리적이어야 합니다. 권장되지 않는 설정을 구성해도 ClusrixDB는 경고를 표시하지 않습니다.

관련 링크

다음 페이지에서는 ClustrixDB를 복제 마스터로 사용할 때 이해가 필요한 부분에 대해 설명합니다.

  1. Online Schema Changes
  2. Replicating User Account Management Statements
  3. Using Xpand with Multiple Slaves