base de données
tutoriel mysql
Explication détaillée de la méthode MySQL PXC pour créer un nouveau nœud qui ne nécessite que la transmission IST
Explication détaillée de la méthode MySQL PXC pour créer un nouveau nœud qui ne nécessite que la transmission IST
L'éditeur ci-dessous vous proposera un article MySQL Méthode PXC pour construire un nouveau nœud qui ne nécessite que la transmission IST (recommandé). L'éditeur le trouve plutôt bon, je vais donc le partager avec vous maintenant et le donner comme référence pour tout le monde. Suivons l'éditeur et jetons un coup d'œil.
Scénario de demande : l'environnement pxc d'origine contient une quantité de données relativement importante. Le serveur nouvellement acheté doit être ajouté à ce cluster. Comment le faire transmettre à l'aide d'IST. de SST ? .
PXC dispose de deux façons de transférer des données :
IST : synchronisation incrémentielle de transfert d'état incrémentiel
SST : instantané d'état Transférer le montant total Conditions pour que la synchronisation
IST se produise : ceci est effectué à l'aide d'un mécanisme de mise en cache sur les nœuds (c'est-à-dire que seules les données de nœud survenues dans le cluster précédent sont toujours dans le cache )
Méthode de jugement :
mysql> show global status like 'wsrep_local_cached_downto'; +---------------------------+-------+ | Variable_name | Value | +---------------------------+-------+ | wsrep_local_cached_downto | 1 | +---------------------------+-------+ 1 row in set (0.00 sec)
Cette valeur est inférieure au numéro de séquence du nœud nouvellement ouvert :
[root@zejin241 I6000]# cat grastate.dat # GALERA saved state version: 2.1 uuid: 6c86dc17-246f-11e6-9955-ae4d7e89eed2 seqno: 4 cert_index:
Notre idée est donc de sauvegarder un cluster, de restaurer les données du nœud central sur le nouveau nœud et de forger un grastate.dat pour enregistrer le numéro de séquence des données de sauvegarde, de sorte que lorsque le nouveau nœud démarre, il utilise automatiquement le Méthode IST au lieu de SST (notez que gcache.size devrait avoir une capacité suffisante pour garantir que toutes les données nouvellement générées sont mises en cache pendant la sauvegarde et la récupération)
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.
Voici les étapes suivantes pour cette opération :
node240 : 192.168.1.240 -- Nœud de cluster déjà existant
node241 : 192.168.1.241 -- Nœud de cluster à ajouter
étape 1 : Démarrer le premier nœud du nouveau cluster
/usr/local/pxc_56/bin/mysqld_safe --defaults-file=/home/mysql/pxc6000.cnf --ledir=/usr/local/pxc_56/bin/ --wsrep-new-cluster &
Le fichier de configuration est le suivant :
[root@zejin240 I6000] # cat /home/mysql/pxc6000.cnf [client] port = 6000socket = /home/mysql/I6000/mysql.sockdefault-character-set=utf8 [mysqld]basedir = /usr/local/pxc_56datadir = /home/mysql/I6000pid-file = /home/mysql/I6000/mysql. pidcharacter-set-server=utf8init_connect = 'SET NAMES utf8'log-bin=/home/mysql/I6000/log_binserver-id = 9816000innodb_buffer_pool_size = 100Minnodb_data_file_path = ibdata1:10M:autoextendinnodb_data_home_dir = /home/mysql/I6000innodb_file_per_table=1skip-name-resolveport = 6000socket = /home/mysql/I6000/mysql.sockuser=mysqllog_error=/home/mysql/I6000/mysql_error.log #pxcuser=mysqllog_error=error.logbinlog_format=ROW#6000 for mysqld port, 6020 for sst port, 6031 for ist port, 6030 for cluster communication portwsrep_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.sowsrep_sst_receive_address=192.168.1.240:6020wsrep_node_incoming_address=192.168.1.240:6000 wsrep_node_address=192.168.1.240:6000wsrep_provider_options = "gmcast.listen_addr=tcp://192.168.1.240:6030;ist.recv_addr=192.168.1.240:6031; "wsrep_slave_threads=2wsrep_cluster_name=pxc_zejinwsrep_sst_method=xtrabackup-v2wsrep_node_name=node6000_240innodb_autoinc_lock_mode=2wsrep_sst_auth="sstuser:123" log-slave-updates[mysql]no-auto-rehashdefault-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)
étape 2 : utilisez innobackupex pour sauvegarder les données de 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 Oyand Percona LLC and/or its affiliates 2009-2013. All Rights Reserved.This software is published
underthe GNU GENERAL PUBLIC LICENSE Version 2, June 1991.Get the latest version of Percona XtraBackup, documentation, and help
resources:percona.com/xb/p160528 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 server160528 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 server160528 09:39:07 innobackupex: Starting the backup operationIMPORTANT:
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-loginnobackupex:
Created backup directory /home/mysql/2016-05-28_09-39-07160528 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 suspendinnobackupex:
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/I6000xtrabackup: open files limit requested 0, set to 1024xtrabackup:
using the following InnoDB configuration:xtrabackup: innodb_data_home_dir = /home/mysql/I6000xtrabackup:
innodb_data_file_path = ibdata1:10M:autoextendxtrabackup: innodb_log_group_home_dir = ./xtrabackup:
innodb_log_files_in_group = 2xtrabackup: 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 suspended160528 09:39:10
innobackupex: Executing LOCK TABLES FOR BACKUP...160528 09:39:10 innobackupex: Backup tables lock acquired160528 09:39:10
innobackupex: Starting to backup non-InnoDB tables and filesinnobackupex: 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 files160528 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
finishxtrabackup: 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 BINLOG160528
09:39:12 innobackupex: Executing UNLOCK TABLES160528 09:39:12 innobackupex: All tables unlockedinnobackupex: Backup
created in directory '/home/mysql/2016-05-28_09-39-07'innobackupex: MySQL binlog position: filename 'log_bin.000003',
position 2772160528 09:39:12 innobackupex: Connection to database server closed160528 09:39:12 innobackupex: completed OK!
[root@zejin240 2016-05-28_09-39-07]
# lltotal 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 ibdata1drwx------.
2 root root 4096 May 28 09:39 mysqldrwxr-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_logfiledrwx------.
2 root root 4096 May 28 09:39 zejinétape 3 : à ce stade, nous ajoutons quelques données supplémentaires sur 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)
étape 4 : Transférez les données sauvegardées vers node241 et restaurez :
[root@zejin241 mysql] # innobackupex --apply-log 2016-05-28_09-39-07/InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oyand Percona LLC and/or its affiliates 2009-2013. All Rights Reserved.This software is published underthe GNU GENERAL PUBLIC LICENSE Version 2, June 1991.Get the latest version of Percona XtraBackup, documentation, and help resources:percona.com 09:54:01 innobackupex: Starting the apply-log operationIMPORTANT: 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-07xtrabackup 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-07xtrabackup: 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:autoextendxtrabackup: innodb_log_group_home_dir = ./xtrabackup: innodb_log_files_in_group = 1xtrabackup: innodb_log_file_size = 2097152xtrabackup: using the following InnoDB configuration for recovery:xtrabackup: innodb_data_home_dir = ./xtrabackup: innodb_data_file_path = ibdata1:10M:autoextendxtrabackup: innodb_log_group_home_dir = ./xtrabackup: innodb_log_files_in_group = 1xtrabackup: innodb_log_file_size = 2097152xtrabackup: 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 pagesInnoDB: The InnoDB memory heap is disabledInnoDB: Mutexes and rw_locks use GCC atomic builtinsInnoDB: Memory barrier is not usedInnoDB: Compressed tables use zlib 1.2.3InnoDB: Using CPU crc32 instructionsInnoDB: Initializing buffer pool, size = 100.0MInnoDB: Completed initialization of buffer poolInnoDB: Highest supported file format is Barracuda.InnoDB: Log scan progressed past the checkpoint lsn 1637591InnoDB: 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.000003InnoDB: 128 rollback segment(s) are active.InnoDB: Waiting for purge to startInnoDB: 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.000003xtrabackup: Recovered WSREP position: 6c86dc17-246f-11e6-9955-ae4d7e89eed2:8xtrabackup: starting shutdown with innodb_fast_shutdown = 1InnoDB: FTS optimize thread exiting.InnoDB: Starting shutdown...InnoDB: Shutdown completed; log sequence number 1637608160528 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-07for 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-07xtrabackup: 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:autoextendxtrabackup: innodb_log_group_home_dir = ./xtrabackup: innodb_log_files_in_group = 2xtrabackup: innodb_log_file_size = 50331648xtrabackup: using the following InnoDB configuration for recovery:xtrabackup: innodb_data_home_dir = ./xtrabackup: innodb_data_file_path = ibdata1:10M:autoextendxtrabackup: innodb_log_group_home_dir = ./xtrabackup: innodb_log_files_in_group = 2xtrabackup: innodb_log_file_size = 50331648xtrabackup: 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 pagesInnoDB: The InnoDB memory heap is disabledInnoDB: Mutexes and rw_locks use GCC atomic builtinsInnoDB: Memory barrier is not usedInnoDB: Compressed tables use zlib 1.2.3InnoDB: Using CPU crc32 instructionsInnoDB: Initializing buffer pool, size = 100.0MInnoDB: Completed initialization of buffer poolInnoDB: Setting log file ./ib_logfile101 size to 48 MBInnoDB: Setting log file ./ib_logfile1 size to 48 MBInnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0InnoDB: New log files created, LSN=1637608InnoDB: Highest supported file format is Barracuda.InnoDB: 128 rollback segment(s) are active.InnoDB: Waiting for purge to startInnoDB: 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.000003xtrabackup: starting shutdown with innodb_fast_shutdown = 1InnoDB: FTS optimize thread exiting.InnoDB: Starting shutdown...InnoDB: Shutdown completed; log sequence number 1637910160528 09:54:06 innobackupex: completed OK! [root@zejin240 2016-05-28_09-39-07]# lltotal 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_logfile1drwx------. 2 root root 4096 May 28 09:39 mysqldrwxr-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_logfiledrwx------. 2 root root 4096 May 28 09:39 zejin
étape 5 : Trouvez l'emplacement du fichier Afficher xtrabackup_galera_info
[root@zejin241 I6000]# cat xtrabackup_galera_info6c86dc17-246f-11e6-9955-ae4d7e89eed2:8
Méthode 2 : Rechercher par emplacement du journal binaire :[root@zejin241 I6000]# cat xtrabackup_binlog_infolog_bin.000003 2772That c'est-à-dire que l'emplacement du point de sauvegarde lors de la sauvegarde est log_bin.000003 2772
Allons dans la base de données principale pour trouver le xid correspondant à ce binlog
J'ai trouvé qu'il n'y avait rien de tel. La raison du xid de la position est que nous avons mis à jour la table mysql.user en haut , et cette table est une table myisam et il n'y aura pas d'enregistrement Xid Dans ce cas, on fixe le Xid à 8 selon les positions haute et basse
#GALERA version enregistrée : 2.1uuid : 6c86dc17-246f-11e6-9955-ae4d7e89eed2seqno : 8cert_index :
Restauré avec succès à l'aide d'IST.
étape 8 Connectez-vous au nouveau nœud node241 et vérifiez si les données sont normales :
启动node241:[root@zejin241 mysql]# /usr/local/pxc_56/bin/mysqld_safe --defaults-file=/home/mysql/pxc6000.cnf --ledir=/usr/local/pxc_56/bin/ &
[1] 56425[root@zejin241 mysql]# 160528 11:06:03 mysqld_safe Logging to '/home/mysql/I6000/error.log'.160528 11:06:03
mysqld_safe Starting mysqld daemon with databases from /home/mysql/I6000160528 11:06:03 mysqld_safe Skipping wsrep-recover
for 6c86dc17-246f-11e6-9955-ae4d7e89eed2:8 pair160528 11:06:03 mysqld_safe Assigning 6c86dc17-246f-11e6-9955-ae4d7e89eed2:8 to
wsrep_start_position查看下启动过程的日志：[root@zejin241 I6000]# cat error.log 160528 11:06:03 mysqld_safe Starting mysqld daemon
with databases from /home/mysql/I6000160528 11:06:03 mysqld_safe Skipping wsrep-recover for 6c86dc17-246f-11e6-9955-ae4d7e89eed2:8
pair160528 11:06:03 mysqld_safe Assigning 6c86dc17-246f-11e6-9955-ae4d7e89eed2:8 to wsrep_start_position2016-05-28 11:06:19 0
[Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option
(see documentation for more details).2016-05-28 11:06:19 0 [Note] /usr/local/pxc_56/bin//mysqld (mysqld 5.6.26-74.0-25.12-log)
starting as process 56931 ...2016-05-28 11:06:19 56931 [Note] WSREP: Read nil XID from storage engines, skipping position
init2016-05-28 11:06:19 56931 [Note] WSREP: wsrep_load(): loading provider library '/usr/local/pxc_56/lib/libgalera_smm.so'2016-05-28
11:06:20 56931 [Note] WSREP: wsrep_load(): Galera 3.12.2(rf3e626d) by Codership Oy <info@codership.com> loaded successfully.2016-05-28
11:06:20 56931 [Note] WSREP: CRC-32C: using hardware acceleration.2016-05-28 11:06:20 56931 [Note] WSREP: Found saved state:
6c86dc17-246f-11e6-9955-ae4d7e89eed2:82016-05-28 11:06:20 56931 [Note] WSREP: Passing config to GCS: base_dir = /home/mysql/I6000/;
base_host = 192.168.1.241; base_port = 6000; cert.log_conflicts = no; debug = no; evs.auto_evict = 0; evs.delay_margin = PT1S;
evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.join_retrans_period = PT1S;
evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S;
evs.user_send_window = 2; evs.view_forget_timeout = PT24H; gcache.dir = /home/mysql/I6000/; gcache.keep_pages_count = 0;
gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /home/mysql/I6000//galera.cache; gcache.page_size = 128M;
gcache.size = 128M; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no;
gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807;
gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.listen_addr = tcp://192.168.1.241:6030;
gmcast.segment = 0; gmcast.version = 0;
ist.recv_a2016-05-28 11:06:21 56931 [Note] WSREP: Service thread queue flushed.2016-05-28 11:06:21 56931 [Note] WSREP:
Assign initial position for certification: 8, protocol version: -12016-05-28 11:06:21 56931 [Note] WSREP:
wsrep_sst_grab()2016-05-28 11:06:21 56931 [Note] WSREP: Start replication2016-05-28 11:06:21 56931 [Note] WSREP:
Setting initial position to 6c86dc17-246f-11e6-9955-ae4d7e89eed2:82016-05-28 11:06:21 56931 [Note] WSREP: protonet
asio version 02016-05-28 11:06:21 56931 [Note] WSREP: Using CRC-32C for message checksums.2016-05-28 11:06:21 56931
[Note] WSREP: backend: asio2016-05-28 11:06:21 56931 [Warning] WSREP: access file(/home/mysql/I6000//gvwstate.dat)
failed(No such file or directory)2016-05-28 11:06:21 56931 [Note] WSREP: restore pc from disk failed2016-05-28
11:06:21 56931 [Note] WSREP: GMCast version 02016-05-28 11:06:21 56931 [Note] WSREP: (275a2ebd, 'tcp://192.168.1.241:6030')
listening at tcp://192.168.1.241:60302016-05-28 11:06:21 56931 [Note] WSREP: (275a2ebd, 'tcp://192.168.1.241:6030') multicast: ,
ttl: 12016-05-28 11:06:21 56931 [Note] WSREP: EVS version 02016-05-28 11:06:21 56931 [Note] WSREP:
gcomm: connecting to group 'pxc_zejin', peer '192.168.1.240:6030,192.168.1.241:6030,192.168.1.242:6030'2016-05-28
11:06:21 56931 [Note] WSREP: (275a2ebd, 'tcp://192.168.1.241:6030') turning message relay requesting on,
nonlive peers: 2016-05-28 11:06:21 56931 [Note] WSREP: declaring 6c48c86c at tcp://192.168.1.240:6030
stable2016-05-28 11:06:21 56931 [Note] WSREP: Node 6c48c86c state prim2016-05-28 11:06:21 56931 [Note]
WSREP: view(view_id(PRIM,275a2ebd,2) memb { 275a2ebd,0 6c48c86c,0} joined {} left {} partitioned {})2016-05-28
11:06:21 56931 [Note] WSREP: save pc into disk2016-05-28 11:06:21 56931 [Note] WSREP: discarding pending addr
without UUID: tcp://192.168.1.242:60302016-05-28 11:06:22 56931 [Note] WSREP: gcomm: connected2016-05-28 11:06:22
56931 [Note] WSREP: Changing maximum packet size to 64500, resulting msg size: 326362016-05-28 11:06:22 56931
[Note] WSREP: Shifting CLOSED -> OPEN (TO: 0)2016-05-28 11:06:22 56931 [Note] WSREP: Opened channel
'pxc_zejin'2016-05-28 11:06:22 56931 [Note] WSREP: Waiting for SST to complete.2016-05-28 11:06:22 56931
[Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 22016-05-28
11:06:22 56931 [Note] WSREP: STATE_EXCHANGE: sent state UUID: 2800468f-2481-11e6-8c7c-de1ade51709a2016-05-28
11:06:22 56931 [Note] WSREP: STATE EXCHANGE: sent state msg: 2800468f-2481-11e6-8c7c-de1ade51709a2016-05-28 11:06:22
56931 [Note] WSREP: STATE EXCHANGE: got state msg: 2800468f-2481-11e6-8c7c-de1ade51709a from 0 (node6000_241)2016-05-28 11:06:22 56931 [Note] WSREP: STATE EXCHANGE: got state msg: 2800468f-2481-11e6-8c7c-de1ade51709a from 1 (node6000_240)2016-05-28 11:06:22 56931 [Note] WSREP: Quorum results: version = 3, component = PRIMARY, conf_id = 1, members = 1/2 (joined/total), act_id = 10, last_appl. = -1, protocols = 0/7/3 (gcs/repl/appl), group UUID = 6c86dc17-246f-11e6-9955-ae4d7e89eed22016-05-28 11:06:22 56931 [Note] WSREP: Flow-control interval: [23, 23]2016-05-28 11:06:22 56931 [Note] WSREP: Shifting OPEN -> PRIMARY (TO: 10)2016-05-28 11:06:22 56931 [Note] WSREP: State transfer required: Group state: 6c86dc17-246f-11e6-9955-ae4d7e89eed2:10 Local state: 6c86dc17-246f-11e6-9955-ae4d7e89eed2:82016-05-28 11:06:22 56931 [Note] WSREP: New cluster view: global state: 6c86dc17-246f-11e6-9955-ae4d7e89eed2:10, view# 2: Primary, number of nodes: 2, my index: 0, protocol version 32016-05-28 11:06:22 56931 [Warning] WSREP: Gap in state sequence. Need state transfer.2016-05-28 11:06:22 56931 [Note] WSREP: Running: 'wsrep_sst_xtrabackup-v2 --role 'joiner' --address '192.168.1.241:6020' --datadir '/home/mysql/I6000/' --defaults-file '/home/mysql/pxc6000.cnf' --defaults-group-suffix '' --parent '56931' '' '2016-05-28 11:06:24 56931 [Note] WSREP: (275a2ebd, 'tcp://192.168.1.241:6030') turning message relay requesting offWSREP_SST: [INFO] Streaming with xbstream (20160528 11:06:25.322)WSREP_SST: [INFO] Using socat as streamer (20160528 11:06:25.324)WSREP_SST: [INFO] Evaluating timeout -s9 100 socat -u TCP-LISTEN:6020,reuseaddr stdio | xbstream -x; RC=( ${PIPESTATUS[@]} ) (20160528 11:06:25.891)2016-05-28 11:06:27 56931 [Note] WSREP: Prepared SST request: xtrabackup-v2|192.168.1.241:6020/xtrabackup_sst//12016-05-28 11:06:27 56931 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.2016-05-28 11:06:27 56931 [Note] WSREP: REPL Protocols: 7 (3, 2)2016-05-28 11:06:27 56931 [Note] WSREP: Service thread queue flushed.2016-05-28 11:06:27 56931 [Note] WSREP: Assign initial position for certification: 10, protocol version: 32016-05-28 11:06:27 56931 [Note] WSREP: Service thread queue flushed.2016-05-28 11:06:27 56931 [Note] WSREP: Prepared IST receiver, listening at: tcp://192.168.1.241:60312016-05-28 11:06:27 56931 [Note] WSREP: Member 0.0 (node6000_241) requested state transfer from '*any*'. Selected 1.0 (node6000_240)(SYNCED) as donor.2016-05-28 11:06:27 56931 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 10)2016-05-28 11:06:27 56931 [Note] WSREP: Requesting state transfer: success, donor: 12016-05-28 11:06:31 56931 [Note] WSREP: 1.0 (node6000_240): State transfer to 0.0 (node6000_241) complete.2016-05-28 11:06:31 56931 [Note] WSREP: Member 1.0 (node6000_240) synced with group.WSREP_SST: [INFO] xtrabackup_ist received from donor: Running IST (20160528 11:06:31.257)WSREP_SST: [INFO] Galera co-ords from recovery: 6c86dc17-246f-11e6-9955-ae4d7e89eed2:8 (20160528 11:06:31.261)WSREP_SST: [INFO] Total time on joiner: 0 seconds (20160528 11:06:31.265)WSREP_SST: [INFO] Removing the sst_in_progress file (20160528 11:06:31.268)2016-05-28 11:06:31 56931 [Note] WSREP: SST complete, seqno: 82016-05-28 11:06:31 56931 [Note] Plugin 'FEDERATED' is disabled.2016-05-28 11:06:31 56931 [Note] InnoDB: Using atomics to ref count buffer pool pages2016-05-28 11:06:31 56931 [Note] InnoDB: The InnoDB memory heap is disabled2016-05-28 11:06:31 56931 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins2016-05-28 11:06:31 56931 [Note] InnoDB: Memory barrier is not used2016-05-28 11:06:31 56931 [Note] InnoDB: Compressed tables use zlib 1.2.32016-05-28 11:06:31 56931 [Note] InnoDB: Using Linux native AIO2016-05-28 11:06:31 56931 [Note] InnoDB: Using CPU crc32 instructions2016-05-28 11:06:31 56931 [Note] InnoDB: Initializing buffer pool, size = 100.0M2016-05-28 11:06:31 56931 [Note] InnoDB: Completed initialization of buffer pool2016-05-28 11:06:32 56931 [Note] InnoDB: Highest supported file format is Barracuda.2016-05-28 11:06:32 56931 [Note] InnoDB: 128 rollback segment(s) are active.2016-05-28 11:06:32 56931 [Note] InnoDB: Waiting for purge to start2016-05-28 11:06:33 56931 [Note] InnoDB: Percona XtraDB (percona.com) 5.6.26-74.0 started; log sequence number 16379102016-05-28 11:06:33 56931 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 2e7b3e12-2481-11e6-8fe4-000c2973aa48.2016-05-28 11:06:33 56931 [Note] RSA private key file not found: /home/mysql/I6000//private_key.pem. Some authentication plugins will not work.2016-05-28 11:06:33 56931 [Note] RSA public key file not found: /home/mysql/I6000//public_key.pem. Some authentication plugins will not work.2016-05-28 11:06:33 56931 [Note] Server hostname (bind-address): '*'; port: 60002016-05-28 11:06:33 56931 [Note] IPv6 is available.2016-05-28 11:06:33 56931 [Note] - '::' resolves to '::';2016-05-28 11:06:33 56931 [Note] Server socket created on IP: '::'.2016-05-28 11:06:33 56931 [Warning] 'user' entry 'root@zejin240' ignored in --skip-name-resolve mode.2016-05-28 11:06:33 56931 [Warning] 'user' entry '@zejin240' ignored in --skip-name-resolve mode.2016-05-28 11:06:33 56931 [Warning] 'proxies_priv' entry '@ root@zejin240' ignored in --skip-name-resolve mode.2016-05-28 11:06:33 56931 [Note] Event Scheduler: Loaded 0 events2016-05-28 11:06:33 56931 [Note] WSREP: Signalling provider to continue.2016-05-28 11:06:33 56931 [Note] WSREP: Initialized wsrep sidno 22016-05-28 11:06:33 56931 [Note] WSREP: SST received: 6c86dc17-246f-11e6-9955-ae4d7e89eed2:82016-05-28 11:06:33 56931 [Note] WSREP: Receiving IST: 2 writesets, seqnos 8-102016-05-28 11:06:33 56931 [Note] /usr/local/pxc_56/bin//mysqld: ready for connections.Version: '5.6.26-74.0-25.12-log' socket: '/home/mysql/I6000/mysql.sock' port: 6000 Percona XtraDB Cluster binary (GPL) 5.6.26-25.12, Revision 624ef81, wsrep_25.122016-05-28 11:06:33 56931 [Note] WSREP: IST received: 6c86dc17-246f-11e6-9955-ae4d7e89eed2:102016-05-28 11:06:33 56931 [Note] WSREP: 0.0 (node6000_241): State transfer from 1.0 (node6000_240) complete.2016-05-28 11:06:33 56931 [Note] WSREP: Shifting JOINER -> JOINED (TO: 10)2016-05-28 11:06:33 56931 [Note] WSREP: Member 0.0 (node6000_241) synced with group.2016-05-28 11:06:33 56931 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 10)2016-05-28 11:06:33 56931 [Note] WSREP: Synchronized with group, ready for connections2016-05-28 11:06:33 56931 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
Il a été constaté que toutes les données ont été synchronisées.
étape 9 : Sortie du journal lors de la comparaison de SST :
[root@zejin241 I6000]# /usr/local/pxc_56/bin/mysql -uroot -p -h127.0.0.1 -P6000Enter password: Welcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 4Server version: 5.6.26-74.0-25.12-log Percona XtraDB Cluster binary (GPL) 5.6.26-25.12, Revision 624ef81, wsrep_25.12Copyright (c) 2009-2015 Percona LLC and/or its affiliatesCopyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or itsaffiliates. Other names may be trademarks of their respectiveowners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql> show databases;+--------------------+| Database |+--------------------+| information_schema || mysql || performance_schema || zejin |+--------------------+4 rows in set (0.12 sec)mysql> use zejin;Reading table information for completion of table and column namesYou can turn off this feature to get a quicker startup with -ADatabase changedmysql> select * from t1;+----+-------+| id | name |+----+-------+| 1 | chen || 2 | li || 3 | zhang || 4 | lin || 5 | liang |+----+-------+5 rows in set (0.01 sec)
dossier de données, puis obtiendra les données du nœud maître via SST Instructions officielles :
À ce stade, nous avons terminé le pxc. environnement pour éviter la nécessité de rejoindre de nouveaux nœuds. La méthode SST consommera beaucoup de ressources lorsque la quantité de données est importante. Le fichier gcache.size configuré est suffisant pour accueillir la quantité de données générées par le nœud maître pendant la période. de la sauvegarde à la restauration. Il est recommandé d'utiliser un script pendant les périodes creuses de l'activité.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Outils d'IA chauds
Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes
AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.
Undress AI Tool
Images de déshabillage gratuites
Clothoff.io
Dissolvant de vêtements AI
AI Hentai Generator
Générez AI Hentai gratuitement.
Article chaud
Outils chauds
Bloc-notes++7.3.1
Éditeur de code facile à utiliser et gratuit
SublimeText3 version chinoise
Version chinoise, très simple à utiliser
Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP
Dreamweaver CS6
Outils de développement Web visuel
SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)
Sujets chauds
Compétences de traitement de structures de données volumineuses de PHP
May 08, 2024 am 10:24 AM
Compétences en matière de traitement de la structure des Big Data : Chunking : décomposez l'ensemble de données et traitez-le en morceaux pour réduire la consommation de mémoire. Générateur : générez des éléments de données un par un sans charger l'intégralité de l'ensemble de données, adapté à des ensembles de données illimités. Streaming : lisez des fichiers ou interrogez les résultats ligne par ligne, adapté aux fichiers volumineux ou aux données distantes. Stockage externe : pour les ensembles de données très volumineux, stockez les données dans une base de données ou NoSQL.
Comment optimiser les performances des requêtes MySQL en PHP ?
Jun 03, 2024 pm 08:11 PM
Les performances des requêtes MySQL peuvent être optimisées en créant des index qui réduisent le temps de recherche d'une complexité linéaire à une complexité logarithmique. Utilisez PreparedStatements pour empêcher l’injection SQL et améliorer les performances des requêtes. Limitez les résultats des requêtes et réduisez la quantité de données traitées par le serveur. Optimisez les requêtes de jointure, notamment en utilisant des types de jointure appropriés, en créant des index et en envisageant l'utilisation de sous-requêtes. Analyser les requêtes pour identifier les goulots d'étranglement ; utiliser la mise en cache pour réduire la charge de la base de données ; optimiser le code PHP afin de minimiser les frais généraux.
Comment utiliser la sauvegarde et la restauration MySQL en PHP ?
Jun 03, 2024 pm 12:19 PM
La sauvegarde et la restauration d'une base de données MySQL en PHP peuvent être réalisées en suivant ces étapes : Sauvegarder la base de données : Utilisez la commande mysqldump pour vider la base de données dans un fichier SQL. Restaurer la base de données : utilisez la commande mysql pour restaurer la base de données à partir de fichiers SQL.
Comment insérer des données dans une table MySQL en utilisant PHP ?
Jun 02, 2024 pm 02:26 PM
Comment insérer des données dans une table MySQL ? Connectez-vous à la base de données : utilisez mysqli pour établir une connexion à la base de données. Préparez la requête SQL : Écrivez une instruction INSERT pour spécifier les colonnes et les valeurs à insérer. Exécuter la requête : utilisez la méthode query() pour exécuter la requête d'insertion en cas de succès, un message de confirmation sera généré.
Comment corriger les erreurs mysql_native_password non chargé sur MySQL 8.4
Dec 09, 2024 am 11:42 AM
L'un des changements majeurs introduits dans MySQL 8.4 (la dernière version LTS en 2024) est que le plugin « MySQL Native Password » n'est plus activé par défaut. De plus, MySQL 9.0 supprime complètement ce plugin. Ce changement affecte PHP et d'autres applications
Comment utiliser les procédures stockées MySQL en PHP ?
Jun 02, 2024 pm 02:13 PM
Pour utiliser les procédures stockées MySQL en PHP : Utilisez PDO ou l'extension MySQLi pour vous connecter à une base de données MySQL. Préparez l'instruction pour appeler la procédure stockée. Exécutez la procédure stockée. Traitez le jeu de résultats (si la procédure stockée renvoie des résultats). Fermez la connexion à la base de données.
Comment créer une table MySQL en utilisant PHP ?
Jun 04, 2024 pm 01:57 PM
La création d'une table MySQL à l'aide de PHP nécessite les étapes suivantes : Connectez-vous à la base de données. Créez la base de données si elle n'existe pas. Sélectionnez une base de données. Créer un tableau. Exécutez la requête. Fermez la connexion.
La différence entre la base de données Oracle et MySQL
May 10, 2024 am 01:54 AM
La base de données Oracle et MySQL sont toutes deux des bases de données basées sur le modèle relationnel, mais Oracle est supérieur en termes de compatibilité, d'évolutivité, de types de données et de sécurité ; tandis que MySQL se concentre sur la vitesse et la flexibilité et est plus adapté aux ensembles de données de petite et moyenne taille. ① Oracle propose une large gamme de types de données, ② fournit des fonctionnalités de sécurité avancées, ③ convient aux applications de niveau entreprise ; ① MySQL prend en charge les types de données NoSQL, ② a moins de mesures de sécurité et ③ convient aux applications de petite et moyenne taille.
