anuário
Um ambiente experimental Galera Cluster
Em segundo lugar, a instalação inicial
1. Instalação Galera-3, mysql-wsrep-5,7, Percona-XtraBackup-2.4.15
2. Modifique o arquivo de configuração
4. Iniciar o outro cluster nós de serviço mysqld
Em terceiro lugar, adicionar nós usando o SST
Em quarto lugar, o aumento do uso de nó IST
Um ambiente experimental Galera Cluster
Esta parte para construir um de três nós Galera Cluster para MySQL 5.7 como um exemplo, a configuração de cluster Galera básico passo de instalação, o ambiente seguinte experimento.
nome do host IP:
172.16.1.125 hdp2
172.16.1.126 hdp3
172.16.1.127 hdp4
Software Ambiente:
CentOS Linux Lançamento 1511/02/07 (Core)
Galera-3,28
MySQL-5.7.27-wsrep
Percona-XtraBackup-2.4.15
Hardware Ambiente:
três máquinas virtuais, cada configuração básica:
dual-core dobrar a CPU, Intel (R) Xeon (R) E5-2420 0 a CPU @ 1,90 GHz
. 8G de memória física, 8G Trocar
. Disco rígido físico 100G
Em segundo lugar, a instalação inicial
Partimos do cenário mais simples, suponha que, na ausência de quaisquer dados e aplicação de acesso, a instalação do zero Galera Cluster.
1. Instalação Galera-3, mysql-wsrep-5,7, Percona-XtraBackup-2.4.15
Os passos seguintes são realizados três hospedeiros como root.
(1) dependências de instalação
yum install perl-Time-HiRes
yum -y install perl-DBD-MySQL.x86_64
yum -y install libaio*(2) criar arquivo de origem yum
cat > /etc/yum.repos.d/galera.repo <<-END
[galera]
name = Galera
baseurl = https://releases.galeracluster.com/galera-3.28/centos/7/x86_64
gpgkey = https://releases.galeracluster.com/galera-3.28/GPG-KEY-galeracluster.com
gpgcheck = 1
[mysql-wsrep]
name = MySQL-wsrep
baseurl = https://releases.galeracluster.com/mysql-wsrep-5.7.27-25.19/centos/7/x86_64
gpgkey = https://releases.galeracluster.com/mysql-wsrep-5.7.27-25.19/GPG-KEY-galeracluster.com
gpgcheck = 1
END(3) montado Galera-3 e mysql-wsrep-5,7
yum install -y galera-3 mysql-wsrep-5.7(4) e reconhece o número de rotações do pacote
[root@hdp2~]#rpm -qa | grep -E 'galera|wsrep'
mysql-wsrep-client-5.7-5.7.27-25.19.el7.x86_64
galera-3-25.3.28-1.el7.x86_64
mysql-wsrep-common-5.7-5.7.27-25.19.el7.x86_64
mysql-wsrep-libs-5.7-5.7.27-25.19.el7.x86_64
mysql-wsrep-server-5.7-5.7.27-25.19.el7.x86_64
mysql-wsrep-5.7-5.7.27-25.19.el7.x86_64
mysql-wsrep-libs-compat-5.7-5.7.27-25.19.el7.x86_64
[root@hdp2~]#(5) xtrabackup Instalação
Se utilizar necessidade SST xtrabackup para realizar esta etapa. Nota compatibilidade xtrabackup com o servidor MySQL, se um erro de incompatibilidade de versão semelhante à seguinte será relatado no log xtrabackup:
innobackupex: Error: Unsupported server version: '5.7.27' Please report a bug at https://bugs.launchpad.net/percona-xtrabackupPara o MySQL 5.7.27, a partir https://www.percona.com/downloads/Percona-XtraBackup-2.4/LATEST/ baixar xtrabackup 2.4.15 versão.
# 安装xtrabackup
rpm -ivh percona-xtrabackup-24-2.4.15-1.el7.x86_64.rpmNeste ponto, a instalação do pacote está completo. Inicie o cluster deve ser configurado enquanto um pouco alguns.
2. Modifique o arquivo de configuração
/Etc/my.cnf editar arquivos, adicione o seguinte:
[mysqld]
log-error=/var/log/mysqld.log
wsrep_provider=/usr/lib64/galera-3/libgalera_smm.so
wsrep_cluster_name="mysql_galera_cluster"
wsrep_cluster_address="gcomm://172.16.1.125,172.16.1.126,172.16.1.127"
wsrep_sst_method=xtrabackup
wsrep_sst_auth=root:P@sswo2d
wsrep_node_name=node1 # 另外两个节点分别为node2、node3
wsrep_node_address="172.16.1.125" # 另外两个节点分别为172.16.1.126、172.16.1.127As variáveis do sistema:
- log-erro: arquivo de log de erro MySQL, depois que o cluster inicial de inicialização descobrir a senha do arquivo.
- wsrep_provider: Galera arquivos de biblioteca.
- wsrep_cluster_name: nome do cluster.
- wsrep_cluster_address: cluster de nó endereço IP.
- wsrep_sst_method: método SST.
- wsrep_sst_auth: informações de autenticação SST, xtrabackup este nome de usuário e senha usando uma instância de conexão de banco de dados.
- wsrep_node_name: o nome do nó atual.
- wsrep_node_address: O endereço do nó atual.
3. Inicializar Cluster
Abaixo o usuário root. Em ambos os execução host.
(1) Inicie o primeiro nó
/usr/bin/mysqld_bootstrapEste comando irá iniciar o mysqld serviço da máquina, MySQL o diretório de instalação padrão é / var / lib / mysql. Note, comando / usr / bin / mysqld_bootstrap é usado somente quando o primeiro nó de cluster é iniciado, porque o script com um argumento: -wsrep-new-cluster, em nome do novo cluster.
# 查看mysqld服务状态
systemctl status mysqld(2) Procurar e modificar a senha inicial
# 查找初始密码
grep -i 'temporary password' /var/log/mysqld.log
# 修改mysql root用户密码，需要根据提示输入上一步输出的初始密码
mysqladmin -uroot -p password 'P@sswo2d'(3) criar uma gestão de conta não-root
create user wxy identified by 'P@sswo2d';
grant all on *.* to wxy with grant option;4. Iniciar o outro cluster nós de serviço mysqld
# O usuário root em outros dois hosts
systemctl start mysqld5. Verifique a instalação
(1) vá ao número de nós do cluster
mysql> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+
1 row in set (0.00 sec)(2) na tabela foram construídos três nós de inserção dos dados, visualizar a replicação
-- node1
create database test;
use test;
create table t1(a int);
insert into t1 values(1);
-- node2
use test;
create table t2(a int);
insert into t2 values(2);
-- node2
use test;
create table t3(a int);
insert into t3 values(3);Nos dados os três nós de consulta, os resultados foram consistentes:
mysql> select t1.a,t2.a,t3.a from test.t1,test.t2,test.t3;
+------+------+------+
| a | a | a |
+------+------+------+
| 1 | 2 | 3 |
+------+------+------+
1 row in set (0.00 sec)6. Resolução de Problemas
Se o cluster durante a inicialização ou iniciar o serviço mysqld, ingresse semelhante o erro ocorre o seguinte erro:
2019-10-05T10:25:29.729981Z 0 [ERROR] WSREP: wsrep_load(): dlopen(): /usr/lib64/galera-3/libgalera_smm.so: symbol SSL_COMP_free_compression_methods, version libssl.so.10 not defined in file libssl.so.10 with link time referenceDescrição galera plugin não carregar com êxito. Neste ponto, você ainda pode iniciar com êxito mysqld, mas para fornecer ler e escrever serviço de instância única não executa a replicação de dados entre os nós. Atualizar pacote OpenSSL para resolver este problema. Por exemplo:
cd /etc/yum.repos.d/
wget http://mirrors.163.com/.help/CentOS7-Base-163.repo
yum -y upgrade opensslEm terceiro lugar, adicionar nós usando o SST
Suponha node1, Galera cluster de nó nó 2 está sendo usado agora para adicionar uma terceira node3 nó. O objetivo é a premissa do nó sem bloqueio existente, sincronização de dados é realizada SST novo nó.
(1) O hdp4 inicializado para um novo nó
# 在hdp4上执行
systemctl stop mysqld
rm -rf /var/lib/mysql
rm -rf /var/log/mysqld.log(2) usando-TPCC mysql hdp2 realizar a medição da pressão, a carga aplicada ao análogo
# 安装tpcc-mysql
tar -zxvf tpcc-mysql.tar.gz
cd tpcc-mysql/src
make
cd ..
# 创建压测库表
mysql -uwxy -pP@sswo2d -h172.16.1.125 -e "create database tpcc_test;"
mysql -uwxy -pP@sswo2d -h172.16.1.125 -Dtpcc_test < create_table.sql
mysql -uwxy -pP@sswo2d -h172.16.1.125 -Dtpcc_test < add_fkey_idx.sql
# 准备数据
tpcc_load 172.16.1.125 tpcc_test wxy P@sswo2d 10
# 备份测试库用于重复测试
mysqldump --databases tpcc_test -uwxy -pP@sswo2d -h172.16.1.125 > tpcc_test.sql
# 执行压测
tpcc_start -h172.16.1.125 -d tpcc_test -u wxy -p "P@sswo2d" -w 10 -c 32 -r 60 -l 300Os detalhes sobre a instalação e utilização de descrição TPCC-mysql ver https://wxy0327.blog.csdn.net/article/details/94614149#1.%20%E6%B5%8B%E8%AF%95%E8%A7% E5% 88 %% 84 92 .
(3) durante a medição de pressão feito de partida MySQL exemplo hdp4
systemctl start mysqldNo arranque hdp4, hdp2, hdp3 são non-blocking, mas será relatado o seguinte bloqueio de erro:
Deadlock found when trying to get lock; try restarting transaction
Lock wait timeout exceeded; try restarting transactionTemos de nos concentrar sobre esta questão quando os sistemas de produção Galera Cluster adicionar um nó online. Quando o exemplo hdp4 MySQL iniciado com êxito, não será dado processo de medição de pressão subsequente. arquivo /var/log/mysqld.log hdp2 as seguintes informações sobre a SST:
2019-10-16T02:04:07.877299Z 2 [Note] WSREP: Assign initial position for certification: 106026, protocol version: 4
2019-10-16T02:04:07.877385Z 0 [Note] WSREP: Service thread queue flushed.
2019-10-16T02:04:08.307002Z 0 [Note] WSREP: Member 0.0 (node3) requested state transfer from '*any*'. Selected 1.0 (node1)(SYNCED) as donor.
2019-10-16T02:04:08.307028Z 0 [Note] WSREP: Shifting SYNCED -> DONOR/DESYNCED (TO: 106177)
2019-10-16T02:04:08.377506Z 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2019-10-16T02:04:08.377644Z 0 [Note] WSREP: Running: 'wsrep_sst_xtrabackup --role 'donor' --address '172.16.1.127:4444/xtrabackup_sst' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix '' '' --gtid 'cada8d04-ef2b-11e9-a196-1ea90518b418:106177''
2019-10-16T02:04:08.380201Z 2 [Note] WSREP: sst_donor_thread signaled with 0
WSREP_SST: [INFO] Streaming with tar (20191016 10:04:08.542)
WSREP_SST: [INFO] Using socat as streamer (20191016 10:04:08.544)
WSREP_SST: [INFO] Streaming the backup to joiner at 172.16.1.127 4444 (20191016 10:04:08.552)
WSREP_SST: [INFO] Evaluating innobackupex --defaults-file=/etc/my.cnf $INNOEXTRA --galera-info --stream=$sfmt ${TMPDIR} 2>${DATA}/innobackup.backup.log | socat -u stdio TCP:172.16.1.127:4444; RC=( ${PIPESTATUS[@]} ) (20191016 10:04:08.555)
2019-10-16T02:04:10.586433Z 0 [Note] WSREP: (cad9d0f0, 'tcp://0.0.0.0:4567') turning message relay requesting off
2019-10-16T02:05:11.408356Z 89 [Note] WSREP: Provider paused at cada8d04-ef2b-11e9-a196-1ea90518b418:108094 (111402)
2019-10-16T02:05:11.679454Z 89 [Note] WSREP: resuming provider at 111402
2019-10-16T02:05:11.679485Z 89 [Note] WSREP: Provider resumed.
2019-10-16T02:05:12.057568Z 0 [Note] WSREP: 1.0 (node1): State transfer to 0.0 (node3) complete.
2019-10-16T02:05:12.057596Z 0 [Note] WSREP: Shifting DONOR/DESYNCED -> JOINED (TO: 108185)
WSREP_SST: [INFO] Total time on donor: 0 seconds (20191016 10:05:12.057)
2019-10-16T02:05:12.058281Z 0 [Note] WSREP: Member 1.0 (node1) synced with group.
2019-10-16T02:05:12.058296Z 0 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 108185)
2019-10-16T02:05:12.127179Z 2 [Note] WSREP: Synchronized with group, ready for connections
2019-10-16T02:05:12.127215Z 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2019-10-16T02:05:20.968604Z 0 [Note] WSREP: 0.0 (node3): State transfer from 1.0 (node1) complete.
2019-10-16T02:09:34.556227Z 0 [Note] WSREP: Member 0.0 (node3) synced with group.Quando a execução systemctl iniciar o mysqld em hdp4, transações para todos os nós do cluster será apresentado pela primeira vez liberadas para o disco, e em seguida, selecione um novo doador a toda a quantidade de nó de dados síncrona, neste caso, os seleciona sistema do node1 como doadores. Então xtrabackup chamada node1 a cópia de arquivo físico node3, sets de gravação gerado durante o cache. Quando NODE1 se tornarem doadores, o estado sincronizado em DOADOR / DESYNCED; xtrabackup quando o backup for concluído, seu status muda para aderir; finalmente terminou quando o conjunto de aplicativos gravação em cache, e do estado juntou tornar sincronizados. O mesmo pode ser encontrado a partir hdp4 arquivo /var/log/mysqld.log, o processo de mudança de estado node3 é: OPEN -> PRIMÁRIA -> JOINER -> JUNTADO -> sincronizados.
Em quarto lugar, o aumento do uso de nó IST
SST método, a quantidade total de dados copiados a partir do nó de dador para um novo nó é adicionada, semelhante ao fazer uma base de dados mestre MySQL backup completo, e depois restaurar a base de dados, mas em conjunto Galera, o processo depende do estado do nodo recém-acrescentado disparador automático. Para o novo nó sob alta concorrência ambiente grande banco de dados, SST caminho pode ser muito doloroso. Primeiro de tudo, se você usar mysqldump ou rsync fazer SST, é bloqueada quando o nó doador. Em segundo lugar, várias centenas de GB ou mais de conjuntos de dados, mesmo se a rede é rápido o suficiente, o processo de sincronização também pode levar várias horas para ser concluído. Então, quando o novo nó ambiente de produção é melhor evitar o uso de SST, mas em vez IST.
IST única enviá-lo em menos de um doador Gcache definido para escrever um novo nó. Gcache está definido para escrever um arquivo para salvar uma cópia do nó Galera. IST é muito mais rápido do que o SST, não-bloqueio, nenhum efeito significativo sobre os doadores. Sempre que possível, esta deve ser a primeira escolha para o novo nó.
SST é às vezes inevitável, quando o novo status do nó não pode ser determinado Galera Isso acontece. Estado Grastate.dat é armazenado em um arquivo, se ocorre o seguinte irá desencadear SST:
- arquivo Grastate.dat não existe no diretório de dados MySQL - nó poderia ser um "limpa" o novo nó.
- Nenhum arquivo SEQNO grastate.dat ou grupo id-- nó pode falhar durante DDL.
- Devido à falta de permissões ou corrupção do sistema de arquivos, grastate.dat ilegível.
1. Defina gcache.size
Nós mencionado no artigo sobre o IST, o uso do IST necessidade de cumprir duas condições precedentes: a mesma novo nó UUID no cluster; Gcache suficiente para armazenar um conjunto de gravação incremental. O primeiro ponto muito satisfeito, irá manter automaticamente o UUID para o novo nó de cluster xtrabackup fazer com instância de cluster de backup físico. Para satisfazer a segunda condição, que requer alguns cálculos para estimar o tamanho necessário Gcache. Por exemplo, para a medição da pressão TPCC-mysql pode ser estimado através do método seguinte.
(1) realizar a medida da pressão
tpcc_start -h172.16.1.125 -d tpcc_test -u wxy -p "P@sswo2d" -w 10 -c 32 -r 60 -l 300(2) a medição de pressão feito durante a consulta
set global show_compatibility_56=on;
set @start := (select sum(variable_value/1024/1024) from information_schema.global_status where variable_name like 'wsrep%bytes');
do sleep(60);
set @end := (select sum(variable_value/1024/1024) from information_schema.global_status where variable_name like 'wsrep%bytes');
select round((@end - @start),2) as `Mb/min`, round((@end - @start),2) * 60 as `Mb/hour`;A contagem de consulta bytes escritos por minuto, os seguintes resultados:
+--------+---------+
| Mb/min | Mb/hour |
+--------+---------+
| 116.66 | 6999.60 |
+--------+---------+Pressão medir o tempo total de execução 6 minutos (um minuto de pré-aquecimento, realizada 5 minutos), enquanto conjunto gcache.size para ser maior do que 117 * 6MB, portanto aqui o gcache.size são definidas para 1G, a sincronização dos dados de apresentação suficiente IST. Adicione os seguintes parâmetros no arquivo de configuração /etc/my.cnf três nós e reinicie o efeito instância take.
wsrep_provider_options="gcache.size=1073741824"2. Teste IST
Também assumem que node1, node2 nós do cluster Galera estão sendo usados agora para adicionar uma terceira node3 nó. Para evitar SST, do uso node1 xtrabackup criar um backup completo, restaurar e criar backup no arquivo de estado node3 Galera para que o estado pode determinar nó Galera e pular SST. O mais próximo possível com os últimos dados antes IST, você irá criar um backup incremental.
(1) O hdp4 inicializado para um novo nó
# 在hdp4上用root用户执行
systemctl stop mysqld
rm -rf /var/lib/mysql/*
rm -rf /var/log/mysqld.log
rm -rf /tmp/incremental/*(2) re-introduzindo a pressão medida a uma biblioteca de cluster
mysql -uwxy -pP@sswo2d -h172.16.1.125 -Dtpcc_test < tpcc_test.sql(3) realizar a medição da pressão de carga simulado de produção
tpcc_start -h172.16.1.125 -d tpcc_test -u wxy -p "P@sswo2d" -w 10 -c 32 -r 60 -l 300A secção seguinte (4), (5), (6), (7) são realizados durante o passo (3) de operação do passo.
(4) a efectuar cópia de segurança manual de xtrabackup aglomerado
# 在hdp2上用mysql用户执行下面的命令进行全量备份（已经事先配置好了hdp2到hdp4的免密登录）
innobackupex --defaults-file=/etc/my.cnf --user=wxy --password=P@sswo2d --socket=/var/lib/mysql/mysql.sock --galera-info --no-lock --stream=xbstream ./ | ssh [email protected] "xbstream -x -C /var/lib/mysql"
# 再执行一个增量备份，这里仅用于演示
scp [email protected]:/var/lib/mysql/xtrabackup_checkpoints /home/mysql/
innobackupex --defaults-file=/etc/my.cnf --user=wxy --password=P@sswo2d --socket=/var/lib/mysql/mysql.sock --incremental --incremental-basedir=/home/mysql --galera-info --no-lock --stream=xbstream ./ | ssh [email protected] "xbstream -x -C /tmp/incremental"arquivos de dados (5) Recuperação de hdp4
(4) Após a conclusão da execução passo, o seguinte usuário comando mysql em hdp4:
# 恢复全量
innobackupex --apply-log --redo-only /var/lib/mysql/
# 恢复增量
innobackupex --apply-log --redo-only /var/lib/mysql/ --incremental-dir=/tmp/incremental(6) gerando arquivo grastate.dat
gerado com base no conteúdo xtrabackup_galera_info ficheiro documento para grastate.dat IST sincronização incremental. Execute o seguinte usuário mysql comando em hdp4:
# 查看xtrabackup_galera_info
cat /var/lib/mysql/xtrabackup_galera_info
# 生成grastate.dat文件，uuid和seqno的值来自xtrabackup_galera_info
tee /var/lib/mysql/grastate.dat <<EOF
# GALERA saved state
version: 2.1
uuid: 650c3acb-eff8-11e9-9905-c73959fd46ca
seqno: 743544
safe_to_bootstrap: 0
EOF(7) iniciar uma nova instância nó
# 用root用户在hdp4上执行
systemctl start mysqldarquivo hdp2 /var/log/mysqld.log as seguintes informações sobre o IST:
2019-10-17T06:37:00.517675Z 1 [Note] WSREP: Assign initial position for certification: 758430, protocol version: 4
2019-10-17T06:37:00.517777Z 0 [Note] WSREP: Service thread queue flushed.
2019-10-17T06:37:00.961803Z 0 [Note] WSREP: Member 2.0 (node3) requested state transfer from '*any*'. Selected 1.0 (node2)(SYNCED) as donor.
2019-10-17T06:37:01.223935Z 0 [Note] WSREP: 1.0 (node2): State transfer to 2.0 (node3) complete.
2019-10-17T06:37:01.224331Z 0 [Note] WSREP: Member 1.0 (node2) synced with group.
2019-10-17T06:37:02.301018Z 0 [Note] WSREP: (4ce6e1a5, 'tcp://0.0.0.0:4567') turning message relay requesting off
2019-10-17T06:38:14.740957Z 0 [Note] WSREP: 2.0 (node3): State transfer from 1.0 (node2) complete.
2019-10-17T06:39:31.183193Z 0 [Note] WSREP: Member 2.0 (node3) synced with group.Você pode ver, as seleciona sistema NODE2 como um doador, é /var/log/mysqld.log arquivo tem as seguintes informações sobre o IST:
2019-10-17T06:37:00.991588Z 0 [Note] WSREP: Shifting SYNCED -> DONOR/DESYNCED (TO: 758624)
2019-10-17T06:37:01.045666Z 2 [Note] WSREP: IST request: 650c3acb-eff8-11e9-9905-c73959fd46ca:743544-758430|tcp://172.16.1.127:4568
2019-10-17T06:37:01.045701Z 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2019-10-17T06:37:01.045885Z 0 [Note] WSREP: Running: 'wsrep_sst_xtrabackup --role 'donor' --address '172.16.1.127:4444/xtrabackup_sst' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix '' '' --gtid '650c3acb-eff8-11e9-9905-c73959fd46ca:743544' --bypass'
2019-10-17T06:37:01.046440Z 2 [Note] WSREP: sst_donor_thread signaled with 0
2019-10-17T06:37:01.048205Z 0 [Note] WSREP: async IST sender starting to serve tcp://172.16.1.127:4568 sending 743545-758430Mostrador transmite uma corrente de gravação entre o hdp4 743.545-758.430 de hdp3.
IST podem ser encontradas no /var/log/mysqld.log node3 hdp4 arquivo incremental no processo de sincronização e mudança de status:
2019-10-17T06:37:01.445113Z 0 [Note] WSREP: Signalling provider to continue.
2019-10-17T06:37:01.445151Z 0 [Note] WSREP: Initialized wsrep sidno 2
2019-10-17T06:37:01.445185Z 0 [Note] WSREP: SST received: 650c3acb-eff8-11e9-9905-c73959fd46ca:743544
2019-10-17T06:37:01.445588Z 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.7.27' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server - (GPL), wsrep_25.19
2019-10-17T06:37:01.446278Z 2 [Note] WSREP: Receiving IST: 14886 writesets, seqnos 743544-758430
2019-10-17T06:37:01.446519Z 0 [Note] WSREP: Receiving IST... 0.0% ( 0/14886 events) complete.
2019-10-17T06:37:02.539991Z 0 [Note] WSREP: (852308ca, 'tcp://0.0.0.0:4567') turning message relay requesting off
2019-10-17T06:37:11.453604Z 0 [Note] WSREP: Receiving IST... 11.1% ( 1648/14886 events) complete.
2019-10-17T06:37:21.485718Z 0 [Note] WSREP: Receiving IST... 23.5% ( 3504/14886 events) complete.
2019-10-17T06:37:31.686873Z 0 [Note] WSREP: Receiving IST... 37.8% ( 5632/14886 events) complete.
2019-10-17T06:37:31.751232Z 24 [Note] Got an error writing communication packets
2019-10-17T06:37:41.721891Z 0 [Note] WSREP: Receiving IST... 56.2% ( 8368/14886 events) complete.
2019-10-17T06:37:51.733818Z 0 [Note] WSREP: Receiving IST... 67.3% (10016/14886 events) complete.
2019-10-17T06:37:54.160644Z 39 [Note] Got an error writing communication packets
2019-10-17T06:38:01.739171Z 0 [Note] WSREP: Receiving IST... 80.0% (11904/14886 events) complete.
2019-10-17T06:38:03.165189Z 45 [Note] Got an error reading communication packets
2019-10-17T06:38:11.778534Z 0 [Note] WSREP: Receiving IST... 94.9% (14128/14886 events) complete.
2019-10-17T06:38:14.765552Z 0 [Note] WSREP: Receiving IST...100.0% (14886/14886 events) complete.
2019-10-17T06:38:14.765871Z 2 [Note] WSREP: IST received: 650c3acb-eff8-11e9-9905-c73959fd46ca:758430
2019-10-17T06:38:14.766840Z 0 [Note] WSREP: 2.0 (node3): State transfer from 1.0 (node2) complete.
2019-10-17T06:38:14.766873Z 0 [Note] WSREP: Shifting JOINER -> JOINED (TO: 777023)
2019-10-17T06:39:31.208799Z 0 [Note] WSREP: Member 2.0 (node3) synced with group.
2019-10-17T06:39:31.208825Z 0 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 777023)
2019-10-17T06:39:31.241137Z 2 [Note] WSREP: Synchronized with group, ready for connections
2019-10-17T06:39:31.241155Z 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.referência:
