MySQL PXC构建一个新节点只需IST传输的方法
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL PXC构建一个新节点只需IST传输的方法相关的知识,希望对你有一定的参考价值。
需求场景:原有的pxc环境数据量已经比较大,新买的服务器要加入此集群中,如何让其用IST的方式传输,而不是SST.
PXC传输数据有两种方式:
IST: Incremental State Transfer 增量同步
SST:State Snapshot Transfer 全量同步
IST 发生的条件:This is done using caching mechanism on nodes (即只发生在之前集群里的节点数据还有在缓存中)
判断方法:
mysql> show global status like \'wsrep_local_cached_downto\';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| wsrep_local_cached_downto | 1 |
+---------------------------+-------+
1 row in set (0.00 sec)
此值小于新开节点的seqno:
[root@zejin241 I6000]# cat grastate.dat
# GALERA saved state
version: 2.1
uuid: 6c86dc17-246f-11e6-9955-ae4d7e89eed2
seqno: 4
cert_index:
所以我们的思路即通过备份一个集群中节点的数据,恢复到新节点上,并伪造一个grastate.dat,来记录备份数据的seqno,这样当新节点启动时就会自动用IST的方法来进行,而不是SST(注意gcache.size应该有足够的容量来保证在备份及恢复这段时间内新产生的数据都被缓存到)
galera.cache: This file is used as a main writeset store. It’s implemented as a permanent ring-buffer file
that is preallocated on disk when the node is initialized. File size can be controlled with the variable
gcache.size. If this value is bigger, more writesets are cached and chances are better that the rejoining node will get IST instead of SST. Filename can be changed with the gcache.name variable.
关于如何搭建一个pxc环境请看:http://www.cnblogs.com/zejin2008/p/5475285.html
如下为这次的操作步骤:
node240:192.168.1.240 --已经存在的集群节点
node241:192.168.1.241 --将要加入的集群节点
step1:启动新的集群中的第一个节点
/usr/local/pxc_56/bin/mysqld_safe --defaults-file=/home/mysql/pxc6000.cnf --ledir=/usr/local/pxc_56/bin/ --wsrep-new-cluster &
配置文件如下:
[root@zejin240 I6000]# cat /home/mysql/pxc6000.cnf [client] port = 6000 socket = /home/mysql/I6000/mysql.sock default-character-set=utf8 [mysqld] basedir = /usr/local/pxc_56 datadir = /home/mysql/I6000 pid-file = /home/mysql/I6000/mysql.pid character-set-server=utf8 init_connect = \'SET NAMES utf8\' log-bin=/home/mysql/I6000/log_bin server-id = 9816000 innodb_buffer_pool_size = 100M innodb_data_file_path = ibdata1:10M:autoextend innodb_data_home_dir = /home/mysql/I6000 innodb_file_per_table=1 skip-name-resolve port = 6000 socket = /home/mysql/I6000/mysql.sock user=mysql log_error=/home/mysql/I6000/mysql_error.log #pxc user=mysql log_error=error.log binlog_format=ROW #6000 for mysqld port, 6020 for sst port, 6031 for ist port, 6030 for cluster communication port wsrep_cluster_address=\'gcomm://192.168.1.240:6030,192.168.1.241:6030,192.168.1.242:6030\' wsrep_provider=/usr/local/pxc_56/lib/libgalera_smm.so wsrep_sst_receive_address=192.168.1.240:6020 wsrep_node_incoming_address=192.168.1.240:6000 wsrep_node_address=192.168.1.240:6000 wsrep_provider_options = "gmcast.listen_addr=tcp://192.168.1.240:6030;ist.recv_addr=192.168.1.240:6031;" wsrep_slave_threads=2 wsrep_cluster_name=pxc_zejin wsrep_sst_method=xtrabackup-v2 wsrep_node_name=node6000_240 innodb_autoinc_lock_mode=2 wsrep_sst_auth="sstuser:123" log-slave-updates [mysql] no-auto-rehash default-character-set=utf8
连接进去并创造更改一些数据:
mysql> use zejin; mysql> select * from t1; +----+-------+ | id | name | +----+-------+ | 1 | chen | | 2 | li | | 3 | zhang | +----+-------+ 3 rows in set (0.01 sec) mysql> update mysql.user set password=password(\'123\'); mysql> flush privileges;
mysql> show master status;
+----------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------+----------+--------------+------------------+-------------------+
| log_bin.000003 | 2772 | | | |
+----------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
step2:用innobackupex备份node240数据:
[root@zejin240 mysql]# innobackupex --user=root --password=123 --port=6000 --host=127.0.0.1 --defaults-file=/home/mysql/pxc6000.cnf /home/mysql/ InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved. This software is published under the GNU GENERAL PUBLIC LICENSE Version 2, June 1991. Get the latest version of Percona XtraBackup, documentation, and help resources: http://www.percona.com/xb/p 160528 09:39:07 innobackupex: Executing a version check against the server... 160528 09:39:07 innobackupex: Connecting to MySQL server with DSN \'dbi:mysql:;mysql_read_default_file=/home/mysql/pxc6000.cnf;mysql_read_default_group=xtrabackup;host=127.0.0.1;port=6000\' as \'root\' (using password: YES). 160528 09:39:07 innobackupex: Connected to MySQL server 160528 09:39:07 innobackupex: Done. 160528 09:39:07 innobackupex: Connecting to MySQL server with DSN \'dbi:mysql:;mysql_read_default_file=/home/mysql/pxc6000.cnf;mysql_read_default_group=xtrabackup;host=127.0.0.1;port=6000\' as \'root\' (using password: YES). 160528 09:39:07 innobackupex: Connected to MySQL server 160528 09:39:07 innobackupex: Starting the backup operation IMPORTANT: Please check that the backup run completes successfully. At the end of a successful backup run innobackupex prints "completed OK!". innobackupex: Using server version 5.6.26-74.0-25.12-log innobackupex: Created backup directory /home/mysql/2016-05-28_09-39-07 160528 09:39:07 innobackupex: Starting ibbackup with command: xtrabackup --defaults-file="/home/mysql/pxc6000.cnf" --defaults-group="mysqld" --backup --suspend-at-end --target-dir=/home/mysql/2016-05-28_09-39-07 --innodb_log_file_size="50331648" --tmpdir=/tmp --extra-lsndir=\'/tmp\' innobackupex: Waiting for ibbackup (pid=30280) to suspend innobackupex: Suspend file \'/home/mysql/2016-05-28_09-39-07/xtrabackup_suspended_2\' xtrabackup version 2.2.11 based on MySQL server 5.6.24 Linux (x86_64) (revision id: ) xtrabackup: uses posix_fadvise(). xtrabackup: cd to /home/mysql/I6000 xtrabackup: open files limit requested 0, set to 1024 xtrabackup: using the following InnoDB configuration: xtrabackup: innodb_data_home_dir = /home/mysql/I6000 xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 2 xtrabackup: innodb_log_file_size = 50331648 >> log scanned up to (1637591) xtrabackup: Generating a list of tablespaces [01] Copying /home/mysql/I6000/ibdata1 to /home/mysql/2016-05-28_09-39-07/ibdata1 >> log scanned up to (1637591) [01] ...done [01] Copying ./zejin/t1.ibd to /home/mysql/2016-05-28_09-39-07/zejin/t1.ibd [01] ...done [01] Copying ./mysql/innodb_table_stats.ibd to /home/mysql/2016-05-28_09-39-07/mysql/innodb_table_stats.ibd [01] ...done [01] Copying ./mysql/slave_master_info.ibd to /home/mysql/2016-05-28_09-39-07/mysql/slave_master_info.ibd [01] ...done [01] Copying ./mysql/slave_relay_log_info.ibd to /home/mysql/2016-05-28_09-39-07/mysql/slave_relay_log_info.ibd [01] ...done [01] Copying ./mysql/slave_worker_info.ibd to /home/mysql/2016-05-28_09-39-07/mysql/slave_worker_info.ibd [01] ...done [01] Copying ./mysql/innodb_index_stats.ibd to /home/mysql/2016-05-28_09-39-07/mysql/innodb_index_stats.ibd [01] ...done >> log scanned up to (1637591) xtrabackup: Creating suspend file \'/home/mysql/2016-05-28_09-39-07/xtrabackup_suspended_2\' with pid \'30280\' 160528 09:39:10 innobackupex: Continuing after ibbackup has suspended 160528 09:39:10 innobackupex: Executing LOCK TABLES FOR BACKUP... 160528 09:39:10 innobackupex: Backup tables lock acquired 160528 09:39:10 innobackupex: Starting to backup non-InnoDB tables and files innobackupex: in subdirectories of \'/home/mysql/I6000/\' innobackupex: Backing up files \'/home/mysql/I6000//performance_schema/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}\' (53 files) >> log scanned up to (1637598) innobackupex: Backing up file \'/home/mysql/I6000//zejin/db.opt\' innobackupex: Backing up file \'/home/mysql/I6000//zejin/t1.frm\' innobackupex: Backing up files \'/home/mysql/I6000//mysql/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}\' (74 files) 160528 09:39:11 innobackupex: Finished backing up non-InnoDB tables and files 160528 09:39:11 innobackupex: Executing LOCK BINLOG FOR BACKUP... 160528 09:39:11 innobackupex: Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS... 160528 09:39:11 innobackupex: Waiting for log copying to finish xtrabackup: The latest check point (for incremental): \'1637598\' xtrabackup: Stopping log copying thread. .>> log scanned up to (1637598) xtrabackup: Creating suspend file \'/home/mysql/2016-05-28_09-39-07/xtrabackup_log_copied\' with pid \'30280\' xtrabackup: Transaction log of lsn (1637591) to (1637598) was copied. 160528 09:39:12 innobackupex: Executing UNLOCK BINLOG 160528 09:39:12 innobackupex: Executing UNLOCK TABLES 160528 09:39:12 innobackupex: All tables unlocked innobackupex: Backup created in directory \'/home/mysql/2016-05-28_09-39-07\' innobackupex: MySQL binlog position: filename \'log_bin.000003\', position 2772 160528 09:39:12 innobackupex: Connection to database server closed 160528 09:39:12 innobackupex: completed OK!
[root@zejin240 2016-05-28_09-39-07]# ll total 75812 -rw-r--r--. 1 root root 358 May 28 09:39 backup-my.cnf -rw-r-----. 1 root root 77594624 May 28 09:39 ibdata1 drwx------. 2 root root 4096 May 28 09:39 mysql drwxr-xr-x. 2 root root 4096 May 28 09:39 performance_schema -rw-r--r--. 1 root root 20 May 28 09:39 xtrabackup_binlog_info -rw-r-----. 1 root root 89 May 28 09:39 xtrabackup_checkpoints -rw-r--r--. 1 root root 635 May 28 09:39 xtrabackup_info -rw-r-----. 1 root root 2560 May 28 09:39 xtrabackup_logfile drwx------. 2 root root 4096 May 28 09:39 zejin
step3:此时我们在node240上再加入一些数据:
此时我们再在node240上插入一些数据: mysql> use zejin; mysql> insert into t1(name) values(\'lin\'); Query OK, 1 row affected (0.06 sec) mysql> insert into t1(name) values(\'liang\'); Query OK, 1 row affected (0.00 sec) mysql> select * from t1; +----+-------+ | id | name | +----+-------+ | 1 | chen | | 2 | li | | 3 | zhang | | 4 | lin | | 5 | liang | +----+-------+ 5 rows in set (0.00 sec)
step4:将备份的数据传输到node241上并恢复:
[root@zejin241 mysql]# innobackupex --apply-log 2016-05-28_09-39-07/
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved.
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
Get the latest version of Percona XtraBackup, documentation, and help resources:
http://www.percona.com/xb/p
160528 09:54:01 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
160528 09:54:01 innobackupex: Starting ibbackup with command: xtrabackup --defaults-file="/home/mysql/2016-05-28_09-39-07/backup-my.cnf" --defaults-group="mysqld" --prepare --target-dir=/home/mysql/2016-05-28_09-39-07
xtrabackup version 2.2.11 based on MySQL server 5.6.24 Linux (x86_64) (revision id: )
xtrabackup: cd to /home/mysql/2016-05-28_09-39-07
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1637591)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 1637591
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1637598 (0%)
InnoDB: Last MySQL binlog file position 0 2772, file name log_bin.000003
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.24 started; log sequence number 1637598
[notice (again)]
If you use binary log and don\'t use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 2772, file name log_bin.000003
xtrabackup: Recovered WSREP position: 6c86dc17-246f-11e6-9955-ae4d7e89eed2:8
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 1637608
160528 09:54:03 innobackupex: Restarting xtrabackup with command: xtrabackup --defaults-file="/home/mysql/2016-05-28_09-39-07/backup-my.cnf" --defaults-group="mysqld" --prepare --target-dir=/home/mysql/2016-05-28_09-39-07
for creating ib_logfile*
xtrabackup version 2.2.11 based on MySQL server 5.6.24 Linux (x86_64) (revision id: )
xtrabackup: cd to /home/mysql/2016-05-28_09-39-07
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to \'--prepare\'.
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Setting log file ./ib_logfile101 size to 48 MB
InnoDB: Setting log file ./ib_logfile1 size to 48 MB
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=1637608
InnoDB: Highest supported file format is Barracuda.
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.24 started; log sequence number 1637900
[notice (again)]
If you use binary log and don\'t use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 2772, file name log_bin.000003
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 1637910
160528 09:54:06 innobackupex: completed OK!
[root@zejin240 2016-05-28_09-39-07]# ll
total 176168
-rw-r--r--. 1 root root 358 May 28 09:39 backup-my.cnf
-rw-r-----. 1 root root 77594624 May 28 09:54 ibdata1
-rw-r--r--. 1 root root 50331648 May 28 09:54 ib_logfile0
-rw-r--r--. 1 root root 50331648 May 28 09:54 ib_logfile1
drwx------. 2 root root 4096 May 28 09:39 mysql
drwxr-xr-x. 2 root root 4096 May 28 09:39 performance_schema
-rw-r--r--. 1 root root 20 May 28 09:39 xtrabackup_binlog_info
-rw-r--r--. 1 root root 20 May 28 09:54 xtrabackup_binlog_pos_innodb
-rw-r-----. 1 root root 89 May 28 09:54 xtrabackup_checkpoints
-rw-r--r--. 1 root root 38 May 28 09:54 xtrabackup_galera_info
-rw-r--r--. 1 root root 635 May 28 09:39 xtrabackup_info
-rw-r-----. 1 root root 2097152 May 28 09:54 xtrabackup_logfile
drwx------. 2 root root 4096 May 28 09:39 zejin
step5:找出Xid的位置
有两种方法
方法一:查看文件xtrabackup_galera_info
[root@zejin241 I6000]# cat xtrabackup_galera_info 6c86dc17-246f-11e6-9955-ae4d7e89eed2:8
方法二:通过binlog位置来查找:
[root@zejin241 I6000]# cat xtrabackup_binlog_info log_bin.000003 2772
即备份时的备份点位置为log_bin.000003 2772
我们再去主库查找此binlog对应的xid
[root@zejin240 I6000]# mysqlbinlog -vv log_bin.000003 | grep Xid #160528 9:02:59 server id 9816000 end_log_pos 947 CRC32 0x37371b3e Xid = 7 #160528 10:03:04 server id 9816000 end_log_pos 2969 CRC32 0xf7973829 Xid = 9 #160528 10:03:13 server id 9816000 end_log_pos 3168 CRC32 0x8db2aa41 Xid = 10
发现竟然没有此位置的xid,原因在于我们在最上面更新mysql.user表了,而此表是myisam表,不会有Xid的记录,这种情况时我们根据上下位置把Xid设置为8
step6:在node241上伪造一个grastate.dat文件(从node240上复制过来,更改下seqno即可):
# GALERA saved state version: 2.1 uuid: 6c86dc17-246f-11e6-9955-ae4d7e89eed2 seqno: 8 cert_index:
step7:启动新节点:
启动node241:
[root@zejin241 mysql]# 以上是关于MySQL PXC构建一个新节点只需IST传输的方法的主要内容,如果未能解决你的问题,请参考以下文章