AskOverflow.Dev

AskOverflow.Dev Logo AskOverflow.Dev Logo

AskOverflow.Dev Navigation

  • Início
  • system&network
  • Ubuntu
  • Unix
  • DBA
  • Computer
  • Coding
  • LangChain

Mobile menu

Close
  • Início
  • system&network
    • Recentes
    • Highest score
    • tags
  • Ubuntu
    • Recentes
    • Highest score
    • tags
  • Unix
    • Recentes
    • tags
  • DBA
    • Recentes
    • tags
  • Computer
    • Recentes
    • tags
  • Coding
    • Recentes
    • tags
Início / user-325117

Nikita Kipriyanov's questions

Martin Hope
Nikita Kipriyanov
Asked: 2024-10-07 20:42:57 +0800 CST

PVE: LVM inicializa usando dispositivos de backend errados (componentes não multipath de um dispositivo multipath)

  • 8
Esta recompensa terminou . Respostas a esta pergunta são elegíveis para uma recompensa de reputação de +100 . O período de carência da recompensa termina em 5 horas . Nikita Kipriyanov quer chamar mais atenção para esta pergunta:
Idealmente, quero tanto uma explicação sobre o assunto de trabalhar com LVM multipathed quanto uma solução para o problema específico que estou enfrentando. Estou pronto para fazer alguma experimentação, mas não muito.

Tenho um servidor que roda o Proxmox VE 8.2 (baseado no Debian 12), totalmente atualizado, que usa SAN multipath. Lá temos um espaço alocado, dez dispositivos de 2T cada, que são vistos 16 vezes cada (o número de caminhos) e que são mapeados em 10 dispositivos virtuais multipathed e coletados em um único grupo LVM, onde um volume lógico é esculpido. Sem problemas nesta parte.

Ele foi inicializado "on the fly" e estava funcionando bem, até que o host foi reiniciado. Depois disso, notei que sempre que alguém executa qualquer comando relacionado ao LVM ( lvs, etc.) no shell do sistema, ele emite o aviso no formato:

WARNING: Device mismatch detected for <LV> which is accessing <list of devices like
 /dev/sdak, /dev/sdaz, /dev/sdbn, ...> instead of <list of the devices
 like /dev/mapper/oamdwhdg-01, /dev/mapper/oamdwhdg-02, ...>

Na realidade, estes /dev/mapper/oamdwhdg-XXsão os dispositivos multipercurso, eles foram nomeados dessa forma por razões operacionais em /etc/multipath.conf:

multipaths {
...
    multipath {
        wwid 36...
        alias oamdwhdg-04
    }
...
}

Ou seja, por qualquer motivo, o LV é mapeado usando dispositivos de backend, em vez de usar dispositivos virtuais multicaminho.

Então atualizei o filtro em /etc/lvm/lvm.conf, que agora se parece com isto:

global_filter=[ "a|/dev/sda3|", "a|/dev/mapper/oamdwhdg|", "r|.*|" ]

(Eu atualizei , não adicionei, estava global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|"]antes com o comentário added by pve-manager to avoid scanning ZFS zvols and Ceph rbds. Acredito que meu filtro seja muito mais rigoroso que esse.)

/dev/sda3é o disco local onde o PVE está instalado e contém o VG pveque não depende do SAN, então é o único /dev/sd...que não usa multipath e foi incluído na lista de permissões.

Testei esse filtro usando vgscane ele mostra que ambos os grupos podem ser encontrados.

Então eu executei update-initramfse reiniciei. Durante a inicialização, o servidor falhou no shell de emergência . Quando eu cheguei Ctrl+Dlá, ele, no entanto, inicializou quase normalmente: o VG multipathed é visto, mas não ativado (como se vgchange -an oamdwhdgainda não tivesse sido executado). Mas então eu o ativei manualmente perfeitamente normalmente com o comando dito e ele funcionou perfeitamente.


Suspeito que isso seja porque o multipath não foi inicializado corretamente antes do LVM no initramfs, então ele tentou configurar mapeamentos usando dispositivos /dev/sdXX. Mas por que ele falhou no shell de emergência quando adicionei o filtro, eu não entendo.

Duas perguntas (muito relacionadas) aqui: por que o shell de emergência, também conhecido como o que está errado, e como fazê-lo funcionar conforme o esperado?

debian
  • 1 respostas
  • 85 Views
Martin Hope
Nikita Kipriyanov
Asked: 2019-12-04 22:53:12 +0800 CST

Trabalho BareOS BackupCatalog preso no Director como encerrado, RunAfterJob não foi executado

  • 1

Isso parece muito estranho. Eu uso o Bacula e agora o BareOS há mais de 10 anos, mas agora um sistema apresenta um comportamento estranho e não consigo descobrir por que e como corrigir.

Quando executa backups diários, funciona bem, até chegar ao trabalho BackupCatalog, que está configurado para ser executado após todo o resto.

Este trabalho parece ter sido finalizado com sucesso (JobStatus=T na list jobstabela):

*list jobs
...
+-------+---------------+--------------+---------------------+------+-------+----------+-----------------+-----------+
| JobId | Name          | Client       | StartTime           | Type | Level | JobFiles | JobBytes        | JobStatus |
+-------+---------------+--------------+---------------------+------+-------+----------+-----------------+-----------+
...
| 5,475 | BackupCatalog | kantor-fd    | 2019-12-04 02:56:40 | B    | F     |       21 |      27,364,860 | T         |
+-------+---------------+--------------+---------------------+------+-------+----------+-----------------+-----------+

No entanto, no messagesarquivo de log não vejo o resumo usual para este último trabalho. O arquivo de log termina assim:

19-Nov 02:32 kantor-dir JobId 5398: shell command: run BeforeJob "/usr/lib/bareos/scripts/make_catalog_backup.pl Kantor"
19-Nov 02:33 kantor-dir JobId 5398: Start Backup JobId 5398, Job=BackupCatalog.2019-11-18_23.10.00_10
19-Nov 02:33 kantor-dir JobId 5398: Using Device "FileStorage" to write.
19-Nov 02:33 kantor-sd JobId 5398: Volume "Kantor-2018-01-08_08:48:50" previously written, moving to end of data.
19-Nov 02:33 kantor-sd JobId 5398: Ready to append to end of Volume "Kantor-2018-01-08_08:48:50" size=4716094462
19-Nov 02:33 kantor-sd JobId 5398: Elapsed time=00:00:05, Transfer rate=5.663 M Bytes/second

E isso é tudo. Observe que o script RunAfterJob parece não ter sido executado. Mas se eu executá-lo manualmente, ele funciona (o arquivo de banco de dados do catálogo exportado é removido). No entanto, este não é o único trabalho com o script RunAfterJob.

Eu esperava que ele mostrasse algo assim no final. Todos os outros trabalhos têm:

19-Nov 02:32 kantor-dir JobId 5397: Bareos kantor-dir 16.2.6 (02Jun17):
  Build OS:               x86_64-pc-linux-gnu debian Debian GNU/Linux buster/sid
  JobId:                  5397
  Job:                    FTP.2019-11-18_23.05.00_09
...
  FD termination status:  OK
  SD termination status:  OK
  Termination:            Backup OK

19-Nov 02:32 kantor-dir JobId 5397: Begin pruning Jobs older than 1 month 10 days .
...

Além disso, o status do diretor parece estranho:

*status dir
kantor-dir Version: 16.2.6 (02 June 2017) x86_64-pc-linux-gnu debian Debian GNU/Linux buster/sid
Daemon started 03-Dec-19 11:10. Jobs: run=4, running=1 mode=0 db=mysql
 Heap: heap=135,168 smbytes=222,459 max_bytes=236,758 bufs=543 max_bufs=594

Scheduled Jobs:
...
====

Running Jobs:
Console connected at 04-Dec-19 09:03
 JobId Level   Name                       Status
======================================================================
  5475 Full    BackupCatalog.2019-12-03_23.10.00_08 has terminated
====

Terminated Jobs:

 JobId  Level    Files      Bytes   Status   Finished        Name 
====================================================================
...
  5471  Incr      6,591    7.499 G  OK       03-Dec-19 23:15 termsrv
  5472  Incr        427    11.37 G  OK       03-Dec-19 23:44 1C
  5473  Incr          3    3.198 G  OK       04-Dec-19 02:56 Oracle
  5474  Incr      5,797    2.600 G  OK       04-Dec-19 02:56 FTP


Client Initiated Connections (waiting for jobs):
...
====

ou seja, o referido trabalho listado nos "trabalhos em execução", mas diz que foi encerrado. Não está listado nos "trabalhos encerrados", como se o diretor ainda tivesse algo para terminar.

Ele ficou pendurado neste estado por seis horas. Também vejo alguma estranheza com os tempos (StartTime para ele na tabela e no arquivo de log difere em meia hora, porém, o sistema datee o MySQL select NOW();estão em sincronia).

Após a reinicialização do diretor, o status do diretor parece mais apropriado:

Running Jobs:
Console connected at 04-Dec-19 09:06
No Jobs running.
====
No Terminated Jobs.

Tudo isso começou há duas semanas. Se eu deixá-lo suspenso, todos os trabalhos agendados a seguir aguardarão indefinidamente por esse trabalho travado, ou seja, nenhum backup será executado.

Eu sinto que isso pode ser um problema com o script RunAfterJob deste trabalho, mas é um script enviado padrão. Se eu correr pela mão, funciona. A definição do trabalho em si também é enviada padrão, a única modificação é que adicionei compressão=GZIP no FileSet, mas faço isso sempre e isso nunca causou problemas.

O que procurar? Como consertar?


Atualizar:

O problema desapareceu. Não entendo, por quê. Os backups funcionam por pelo menos dois dias. Nada parece estar preso.

bareos
  • 1 respostas
  • 83 Views
Martin Hope
Nikita Kipriyanov
Asked: 2019-11-26 03:44:06 +0800 CST

Debian no HP Gen9 — o hpssacli mais recente parece ser muito antigo

  • 0

Instalei um sistema Debian 10 Buster recente no servidor, que é o HPE DL360 Gen9. Possui adaptador P440ar, que funciona com o "novo" hpsadriver. Tanto quanto me lembro, os RAIDs foram configurados com o utilitário GUI "pré-inicialização" integrado. Todos os firmwares foram atualizados para suas versões mais recentes, então acredito que esse utilitário também tenha sido a versão mais recente.

Agora eu tenho que configurar o monitoramento do estado RAID para um servidor Zabbix.

hpsaarrays são gerenciados com o hpssacliutilitário (o antigo hpacuclisuporta um ccissdriver, que não é aplicável para mim). Eu tenho um script wrapper que é executado a partir do agente Zabbix, ele é capaz de descobrir e consultar o estado de cada array no sistema, esse script apenas chama hpssacli, analisa e adapta sua saída para o Zabbix. Faço isso há séculos.

Neste sistema recém-configurado, eu tenho um problema. Eu tentei o próprio repositório SDR MCP da HPe , ele não suporta buster sim (a HPe é notoriamente lenta na atualização de seus repositórios), então acabei de encontrar um hpssaclideb mais recente e o instalei. Parecia ser hpssacli-2.40-13.0_amd64.deb, datado de 28/06/2016 17:55.

No entanto, quando tentei executá-lo, ele diz: meu array foi criado com a versão mais recente do utilitário e minha versão é muito antiga para gerenciá-lo:

root@vh3:~# wget https://downloads.linux.hpe.com/SDR/repo/mcp/pool/non-free/hpssacli-2.40-13.0_amd64.deb
--2019-11-25 14:13:38--  https://downloads.linux.hpe.com/SDR/repo/mcp/pool/non-free/hpssacli-2.40-13.0_amd64.deb
Распознаётся downloads.linux.hpe.com (downloads.linux.hpe.com)… 15.249.152.85
Подключение к downloads.linux.hpe.com (downloads.linux.hpe.com)|15.249.152.85|:443... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа… 200 OK
Длина: 8237034 (7,9M)
Сохранение в: «hpssacli-2.40-13.0_amd64.deb»

hpssacli-2.40-13.0_amd64.deb                    100%[====================================================================================================>]   7,85M   394KB/s    за 22s     

2019-11-25 14:14:01 (363 KB/s) - «hpssacli-2.40-13.0_amd64.deb» сохранён [8237034/8237034]

root@vh3:~# ls
hpssacli-2.40-13.0_amd64.deb
root@vh3:~# dpkg -i hpssacli-2.40-13.0_amd64.deb 
Выбор ранее не выбранного пакета hpssacli.
(Чтение базы данных … на данный момент установлено 57199 файлов и каталогов.)
Подготовка к распаковке hpssacli-2.40-13.0_amd64.deb …
Распаковывается hpssacli (2.40-13.0) …
Настраивается пакет hpssacli (2.40-13.0) …
Обрабатываются триггеры для man-db (2.8.5-2) …
root@vh3:~# hpssacli ctrl all show

Smart Array P440ar in Slot 0 (Embedded) 

APPLICATION UPGRADE REQUIRED: This controller has been configured with a more
                              recent version of software.
                              To prevent data loss, configuration changes to
                              this controller are not allowed.
                              Please upgrade to the latest version to be able
                              to continue to configure this controller.

Embora isso não pareça impedir que meu script monitore o estado de um controlador, também quero poder gerenciá-lo a partir do sistema operacional, adicionar unidades e criar mais matrizes sem interromper um sistema no futuro.

Também tentei usar o repositório hwraid.le-vert.net , mas não há hpssacliutilidade (só tem hpacucli, pelo menos no buster).

O que eu deveria fazer? Onde encontrar esta versão "mais recente" e como descobrir qual versão eu preciso?

monitoring
  • 1 respostas
  • 5203 Views
Martin Hope
Nikita Kipriyanov
Asked: 2019-10-16 01:16:09 +0800 CST

Linux: análogo ZFS do pvmove - como mover dados do vdev?

  • 8

Preciso expandir a capacidade do disco do servidor. O pool foi iniciado com disco de 1 TB, depois foi expandido com disco de 2 TB. Há mais de 1 TB de espaço livre, ou seja, todos os dados cabem facilmente na parte de 2 TB, mas atualmente estão alocados em discos de 1 TB.

Na realidade, esses discos são matrizes RAID1 de hardware (PERC) sobre par de 1Tb e par de 2Tb resp.

Eu quero substituir esses discos de 1 TB por 3 TB. A substituição "um por um" não é realmente uma opção. Em princípio, esse RAID físico pode substituir os discos um por um e, em seguida, aumentar a matriz para preencher os discos. No entanto, quero evitar esse caminho, porque ele deixa alguns períodos de tempo bastante longos em que a redundância de disco é perdida.

Eu quero literalmente mover todos os dados de 1 TB, removê-los e substituí-los por 3 TB. Tudo para ser feito em tempo real, com sistema em execução, com zero tempo de inatividade.

Com o LVM a operação tem que ser muito direta e fácil de entender:

  1. pvmove todos os dados alocados do disco físico de 1 TB (VD em termos de RAID)
  2. vgreduce para remover esse pv de vg e pvremove para remover metadados de pv
  3. remova um array de 1 TB usando megacli (PERC é renomeado LSI/Avago MegaRAID SAS)
  4. substituir discos fisicamente
  5. monte outra matriz novamente usando megacli
  6. faça um novo pv e adicione-o em vg

Este é o procedimento de rotina que eu costumava fazer. Cada passo é muito bem compreendido, em cada passo tenho total controle do que está acontecendo, sempre sei como proceder se algo der errado e assim por diante.

Como fazer o mesmo procedimento com segurança e conhecimento com o ZFS?

Se isso importa:

  • o servidor é Dell PowerEdge R730
  • o sistema operacional é o Proxmox VE 6.0, que é baseado no Debian 10.1. Ele foi instalado a partir da imagem ISO do PVE, ou seja, não foi convertido da instalação do Debian.
  • o sistema não depende deste pool, pois roda a partir de um conjunto de SSDs montados em outro pool
  • o pool hospeda alguns discos virtuais de VM que não exigem alto desempenho. No entanto, esses dados são valiosos, não posso tolerar se forem perdidos. Portanto, o procedimento deve ser claro e compreensível
  • sistema é usado constantemente pelos usuários, mas eles tolerarão a perda de desempenho durante a migração de dados
lvm
  • 1 respostas
  • 923 Views
Martin Hope
Nikita Kipriyanov
Asked: 2016-04-05 06:01:03 +0800 CST

Não foi possível unir o nó MariaDB Galera Cluster de volta ao cluster após a atualização do software. As opções wsrep_* em my.cnf parecem ser ignoradas

  • 0

Eu rodei um Galera Cluster por um tempo, MariaDB versão 10.0.20, Galera versão 25.3.10, tudo no Gentoo. Esse cluster funcionou bem, os nós foram reiniciados várias vezes para manutenção e assim por diante. Quando iniciei o mysql em qualquer nó, ele carregou a biblioteca wsrep_provider, que iniciou o SST e, eventualmente, ingressou no cluster.

Agora chegou a hora de fazer uma atualização massiva. Eu escolhi um caminho de "atualização contínua" descrito em http://galeracluster.com/documentation-webpages/upgrading.html#id1 , desative o nó escolhido e atualize o software lá.

Para os impacientes, um breve resumo do que se segue: o mariadb inicia e ignora quaisquer opções wsrep_ config e, se eu as especificar manualmente na instância em execução, parece travar.

Duas perguntas: - Por que ignora silenciosamente minhas opções de configuração? Como fazê-lo respeitá-los? - O que fazer para iniciar a replicação, como juntar um nó no cluster?

Tudo bem atualizado. Agora tenho MariaDB 10.1.13, Galera 25.3.15. A configuração em /etc/mysql/my.cnf foi mesclada. Agora parece com isso (somente a seção mysqld):

[mysqld]
character-set-server            = utf8
user                            = mysql
port                            = 3306
socket                          = /var/run/mysqld/mysqld.sock
pid-file                        = /var/run/mysqld/mysqld.pid
log-error                       = /var/log/mysql/mysqld.err
basedir                         = /usr
datadir                         = /var/lib/mysql
skip-external-locking
key_buffer_size                 = 16M
max_allowed_packet              = 4M
table_open_cache                = 400
sort_buffer_size                = 512K
net_buffer_length               = 16K
read_buffer_size                = 256K
read_rnd_buffer_size            = 512K
myisam_sort_buffer_size         = 8M
lc_messages_dir                 = /usr/share/mysql
lc_messages                     = en_US

log-bin
server-id                       = 1

tmpdir                          = /tmp/

innodb_buffer_pool_size = 128M
innodb_data_file_path = ibdata1:10M:autoextend:max:128M
innodb_log_file_size = 48M
innodb_log_buffer_size = 8M
innodb_log_files_in_group=2
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
innodb_file_per_table

binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="www_cluster"
wsrep_cluster_address="gcomm://192.168.4.28,192.168.5.28,192.168.5.29"
wsrep_sst_method=rsync

Eu verifiquei três vezes este arquivo, para ter certeza de que minhas opções wsrep_* estão na seção [mysqld] como estavam. Essas opções são exatamente como eram antes da atualização.

No entanto, o serviço mysql é iniciado agora como um servidor autônomo normal, não em cluster:

2016-04-04 16:30:46 139950286550848 [Warning] No argument was provided to --log-bin and neither --log-basename or --log-bin-index where used;  This may cause repliction to break when this server acts as a master and has its hostname changed! Please use '--log-basename=www1' or '--log-bin=mysqld-bin' to avoid this problem.
2016-04-04 16:30:46 139950286550848 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-04-04 16:30:46 139950286550848 [Note] InnoDB: The InnoDB memory heap is disabled
2016-04-04 16:30:46 139950286550848 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-04-04 16:30:46 139950286550848 [Note] InnoDB: Memory barrier is not used
2016-04-04 16:30:46 139950286550848 [Note] InnoDB: Compressed tables use zlib 1.2.8
2016-04-04 16:30:46 139950286550848 [Note] InnoDB: Using Linux native AIO
2016-04-04 16:30:46 139950286550848 [Note] InnoDB: Using generic crc32 instructions
2016-04-04 16:30:46 139950286550848 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2016-04-04 16:30:46 139950286550848 [Note] InnoDB: Completed initialization of buffer pool
2016-04-04 16:30:46 139950286550848 [Note] InnoDB: Highest supported file format is Barracuda.
2016-04-04 16:30:47 139950286550848 [Note] InnoDB: 128 rollback segment(s) are active.
2016-04-04 16:30:47 139950286550848 [Note] InnoDB: Waiting for purge to start
2016-04-04 16:30:47 139950286550848 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.28-76.1 started; log sequence number 116616176
2016-04-04 16:30:47 139949849761536 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-04-04 16:30:47 139950286550848 [Note] Plugin 'FEEDBACK' is disabled.
2016-04-04 16:30:47 139950286550848 [Note] Server socket created on IP: '0.0.0.0'.
2016-04-04 16:30:47 139950286550848 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.13-MariaDB'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Source distribution

Se eu consultar as variáveis ​​wsrep_*, ele mostra que nenhum provedor foi carregado:

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep%';
+--------------------------+----------------------+
| Variable_name            | Value                |
+--------------------------+----------------------+
| wsrep_cluster_conf_id    | 18446744073709551615 |
| wsrep_cluster_size       | 0                    |
| wsrep_cluster_state_uuid |                      |
| wsrep_cluster_status     | Disconnected         |
| wsrep_connected          | OFF                  |
| wsrep_local_bf_aborts    | 0                    |
| wsrep_local_index        | 18446744073709551615 |
| wsrep_provider_name      |                      |
| wsrep_provider_vendor    |                      |
| wsrep_provider_version   |                      |
| wsrep_ready              | OFF                  |
| wsrep_thread_count       | 0                    |
+--------------------------+----------------------+
12 rows in set (0.00 sec)

Parece que não respeitou as opções wsrep_provider e wsrep_cluster_address (e acredito que todas as outras wsrep_*).

Tentei configurá-los globalmente na execução da instância mariadb manualmente:

MariaDB [(none)]> set global wsrep_provider='/usr/lib/galera/libgalera_smm.so';
Query OK, 0 rows affected (0.02 sec)
MariaDB [(none)]> SHOW STATUS LIKE 'wsrep%';
+------------------------------+-----------------------------------+
| Variable_name                | Value                             |
+------------------------------+-----------------------------------+
| wsrep_apply_oooe             | 0.000000                          |
| wsrep_apply_oool             | 0.000000                          |
| wsrep_apply_window           | 0.000000                          |
| wsrep_causal_reads           | 0                                 |
| wsrep_cert_deps_distance     | 0.000000                          |
| wsrep_cert_index_size        | 0                                 |
| wsrep_cert_interval          | 0.000000                          |
| wsrep_cluster_conf_id        | 18446744073709551615              |
| wsrep_cluster_size           | 0                                 |
| wsrep_cluster_state_uuid     |                                   |
| wsrep_cluster_status         | Disconnected                      |
| wsrep_commit_oooe            | 0.000000                          |
| wsrep_commit_oool            | 0.000000                          |
| wsrep_commit_window          | 0.000000                          |
| wsrep_connected              | OFF                               |
| wsrep_flow_control_paused    | 0.000000                          |
| wsrep_flow_control_paused_ns | 0                                 |
| wsrep_flow_control_recv      | 0                                 |
| wsrep_flow_control_sent      | 0                                 |
| wsrep_incoming_addresses     |                                   |
| wsrep_last_committed         | 18446744073709551615              |
| wsrep_local_bf_aborts        | 0                                 |
| wsrep_local_cached_downto    | 18446744073709551615              |
| wsrep_local_cert_failures    | 0                                 |
| wsrep_local_commits          | 0                                 |
| wsrep_local_index            | 18446744073709551615              |
| wsrep_local_recv_queue       | 0                                 |
| wsrep_local_recv_queue_avg   | 0.000000                          |
| wsrep_local_recv_queue_max   | 0                                 |
| wsrep_local_recv_queue_min   | 0                                 |
| wsrep_local_replays          | 0                                 |
| wsrep_local_send_queue       | 0                                 |
| wsrep_local_send_queue_avg   | 0.000000                          |
| wsrep_local_send_queue_max   | 0                                 |
| wsrep_local_send_queue_min   | 0                                 |
| wsrep_local_state            | 0                                 |
| wsrep_local_state_comment    | Initialized                       |
| wsrep_local_state_uuid       |                                   |
| wsrep_protocol_version       | 18446744073709551615              |
| wsrep_provider_name          | Galera                            |
| wsrep_provider_vendor        | Codership Oy <info@codership.com> |
| wsrep_provider_version       | 3.15(r8459459)                    |
| wsrep_ready                  | OFF                               |
| wsrep_received               | 0                                 |
| wsrep_received_bytes         | 0                                 |
| wsrep_repl_data_bytes        | 0                                 |
| wsrep_repl_keys              | 0                                 |
| wsrep_repl_keys_bytes        | 0                                 |
| wsrep_repl_other_bytes       | 0                                 |
| wsrep_replicated             | 0                                 |
| wsrep_replicated_bytes       | 0                                 |
| wsrep_thread_count           | 0                                 |
+------------------------------+-----------------------------------+
52 rows in set (0.00 sec)

respectivas entradas de log:

2016-04-04 16:45:19 139950170823424 [Note] WSREP: Stop replication
2016-04-04 16:45:19 139950170823424 [Note] WSREP: Provider was not loaded, in stop replication
2016-04-04 16:45:19 139950170823424 [Note] WSREP: Initial position: 913d310a-9360-11e4-9d31-922a1e5d98fe:63026
2016-04-04 16:45:19 139950170823424 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib/galera/libgalera_smm.so'
2016-04-04 16:45:19 139950170823424 [Note] WSREP: wsrep_load(): Galera 3.15(r8459459) by Codership Oy <info@codership.com> loaded successfully.
2016-04-04 16:45:19 139950170823424 [Note] WSREP: CRC-32C: using "slicing-by-8" algorithm.
2016-04-04 16:45:19 139950170823424 [Note] WSREP: Found saved state: 00000000-0000-0000-0000-000000000000:-1
2016-04-04 16:45:19 139950170823424 [Note] WSREP: Passing config to GCS: base_dir = /var/lib/mysql/; base_host = 192.168.4.28; base_port = 4567; 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 = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /var/lib/mysql//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.segment = 0; gmcast.version = 0; pc.announce_timeout = PT3S; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false;
2016-04-04 16:45:19 139949719164672 [Note] WSREP: Service thread queue flushed.
2016-04-04 16:45:19 139950170823424 [Note] WSREP: Assign initial position for certification: -1, protocol version: -1

e preencha os endereços do cluster:

MariaDB [(none)]> set global wsrep_cluster_address='gcomm://192.168.4.28,192.168.5.28,192.168.5.29';    
Query OK, 0 rows affected (3.55 sec)

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep%';
+------------------------------+-------------------------------------------------------+
| Variable_name                | Value                                                 |
+------------------------------+-------------------------------------------------------+
| wsrep_apply_oooe             | 0.000000                                              |
| wsrep_apply_oool             | 0.000000                                              |
| wsrep_apply_window           | 0.000000                                              |
| wsrep_causal_reads           | 0                                                     |
| wsrep_cert_deps_distance     | 0.000000                                              |
| wsrep_cert_index_size        | 0                                                     |
| wsrep_cert_interval          | 0.000000                                              |
| wsrep_cluster_conf_id        | 471                                                   |
| wsrep_cluster_size           | 3                                                     |
| wsrep_cluster_state_uuid     | 913d310a-9360-11e4-9d31-922a1e5d98fe                  |
| wsrep_cluster_status         | Primary                                               |
| wsrep_commit_oooe            | 0.000000                                              |
| wsrep_commit_oool            | 0.000000                                              |
| wsrep_commit_window          | 0.000000                                              |
| wsrep_connected              | ON                                                    |
| wsrep_evs_delayed            |                                                       |
| wsrep_evs_evict_list         |                                                       |
| wsrep_evs_repl_latency       | 0.0456547/0.049131/0.0560754/0.00491047/3             |
| wsrep_evs_state              | OPERATIONAL                                           |
| wsrep_flow_control_paused    | 0.000000                                              |
| wsrep_flow_control_paused_ns | 0                                                     |
| wsrep_flow_control_recv      | 0                                                     |
| wsrep_flow_control_sent      | 0                                                     |
| wsrep_gcomm_uuid             | fd416235-fa6b-11e5-867c-72011d51ce8d                  |
| wsrep_incoming_addresses     | 192.168.5.28:3306,192.168.5.29:3306,192.168.4.28:3306 |
| wsrep_last_committed         | 18446744073709551615                                  |
| wsrep_local_bf_aborts        | 0                                                     |
| wsrep_local_cached_downto    | 18446744073709551615                                  |
| wsrep_local_cert_failures    | 0                                                     |
| wsrep_local_commits          | 0                                                     |
| wsrep_local_index            | 2                                                     |
| wsrep_local_recv_queue       | 0                                                     |
| wsrep_local_recv_queue_avg   | 0.000000                                              |
| wsrep_local_recv_queue_max   | 1                                                     |
| wsrep_local_recv_queue_min   | 0                                                     |
| wsrep_local_replays          | 0                                                     |
| wsrep_local_send_queue       | 0                                                     |
| wsrep_local_send_queue_avg   | 0.000000                                              |
| wsrep_local_send_queue_max   | 1                                                     |
| wsrep_local_send_queue_min   | 0                                                     |
| wsrep_local_state            | 1                                                     |
| wsrep_local_state_comment    | Joining: receiving State Transfer                     |
| wsrep_local_state_uuid       |                                                       |
| wsrep_protocol_version       | 7                                                     |
| wsrep_provider_name          | Galera                                                |
| wsrep_provider_vendor        | Codership Oy <info@codership.com>                     |
| wsrep_provider_version       | 3.15(r8459459)                                        |
| wsrep_ready                  | OFF                                                   |
| wsrep_received               | 1                                                     |
| wsrep_received_bytes         | 266                                                   |
| wsrep_repl_data_bytes        | 0                                                     |
| wsrep_repl_keys              | 0                                                     |
| wsrep_repl_keys_bytes        | 0                                                     |
| wsrep_repl_other_bytes       | 0                                                     |
| wsrep_replicated             | 0                                                     |
| wsrep_replicated_bytes       | 0                                                     |
| wsrep_thread_count           | 2                                                     |
+------------------------------+-------------------------------------------------------+
57 rows in set (0.00 sec)

registro respectivo:

2016-04-04 16:45:19 139949719164672 [Note] WSREP: Service thread queue flushed.
2016-04-04 16:45:19 139950170823424 [Note] WSREP: Assign initial position for certification: -1, protocol version: -1
2016-04-04 16:49:00 139950170520320 [Note] WSREP: Stop replication
2016-04-04 16:49:02 139950170520320 [Note] WSREP: Start replication
2016-04-04 16:49:02 139950170520320 [Note] WSREP: Setting initial position to 00000000-0000-0000-0000-000000000000:-1
2016-04-04 16:49:02 139950170520320 [Note] WSREP: protonet asio version 0
2016-04-04 16:49:02 139950170520320 [Note] WSREP: Using CRC-32C for message checksums.
2016-04-04 16:49:02 139950170520320 [Note] WSREP: backend: asio
2016-04-04 16:49:02 139950170520320 [Warning] WSREP: access file(/var/lib/mysql//gvwstate.dat) failed(No such file or directory)
2016-04-04 16:49:02 139950170520320 [Note] WSREP: restore pc from disk failed
2016-04-04 16:49:02 139950170520320 [Note] WSREP: GMCast version 0
2016-04-04 16:49:02 139950170520320 [Note] WSREP: (fd416235, 'tcp://0.0.0.0:4567') listening at tcp://0.0.0.0:4567
2016-04-04 16:49:02 139950170520320 [Note] WSREP: (fd416235, 'tcp://0.0.0.0:4567') multicast: , ttl: 1
2016-04-04 16:49:02 139950170520320 [Note] WSREP: EVS version 0
2016-04-04 16:49:02 139950170520320 [Note] WSREP: gcomm: connecting to group 'www_cluster', peer '192.168.4.28:,192.168.5.28:,192.168.5.29:'
2016-04-04 16:49:02 139950170520320 [Warning] WSREP: (fd416235, 'tcp://0.0.0.0:4567') address 'tcp://192.168.4.28:4567' points to own listening address, blacklisting
2016-04-04 16:49:02 139950170520320 [Note] WSREP: (fd416235, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers:
2016-04-04 16:49:02 139950170520320 [Note] WSREP: declaring 4c4f4779 at tcp://192.168.5.28:4567 stable
2016-04-04 16:49:02 139950170520320 [Note] WSREP: declaring b75760e5 at tcp://192.168.5.29:4567 stable
2016-04-04 16:49:02 139950170520320 [Note] WSREP: Node 4c4f4779 state prim
2016-04-04 16:49:02 139950170520320 [Note] WSREP: view(view_id(PRIM,4c4f4779,710) memb {
        4c4f4779,0
        b75760e5,0
        fd416235,0
} joined {
} left {
} partitioned {
})
2016-04-04 16:49:02 139950170520320 [Note] WSREP: save pc into disk
2016-04-04 16:49:03 139950170520320 [Note] WSREP: gcomm: connected
2016-04-04 16:49:03 139950170520320 [Note] WSREP: Changing maximum packet size to 64500, resulting msg size: 32636
2016-04-04 16:49:03 139950170520320 [Note] WSREP: Shifting CLOSED -> OPEN (TO: 0)
2016-04-04 16:49:03 139950170520320 [Note] WSREP: Opened channel 'www_cluster'
2016-04-04 16:49:03 139948892088064 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 2, memb_num = 3
2016-04-04 16:49:03 139948892088064 [Note] WSREP: STATE EXCHANGE: Waiting for state UUID.
2016-04-04 16:49:03 139948892088064 [Note] WSREP: STATE EXCHANGE: sent state msg: feddde16-fa6b-11e5-86f6-fb86e3a56ec8
2016-04-04 16:49:03 139948892088064 [Note] WSREP: STATE EXCHANGE: got state msg: feddde16-fa6b-11e5-86f6-fb86e3a56ec8 from 0 (www2)
2016-04-04 16:49:03 139948892088064 [Note] WSREP: STATE EXCHANGE: got state msg: feddde16-fa6b-11e5-86f6-fb86e3a56ec8 from 1 (galera)
2016-04-04 16:49:03 139949710771968 [Warning] WSREP: last inactive check more than PT1.5S ago (PT1.55477S), skipping check
2016-04-04 16:49:03 139948892088064 [Note] WSREP: STATE EXCHANGE: got state msg: feddde16-fa6b-11e5-86f6-fb86e3a56ec8 from 2 ()
2016-04-04 16:49:03 139948892088064 [Note] WSREP: Quorum results:
        version    = 3,
        component  = PRIMARY,
        conf_id    = 470,
        members    = 2/3 (joined/total),
        act_id     = 63180,
        last_appl. = -1,
        protocols  = 0/7/3 (gcs/repl/appl),
        group UUID = 913d310a-9360-11e4-9d31-922a1e5d98fe
2016-04-04 16:49:03 139948892088064 [Note] WSREP: Flow-control interval: [28, 28]
2016-04-04 16:49:03 139948892088064 [Note] WSREP: Shifting OPEN -> PRIMARY (TO: 63180)
2016-04-04 16:49:03 139950170217216 [Note] WSREP: State transfer required:
        Group state: 913d310a-9360-11e4-9d31-922a1e5d98fe:63180
        Local state: 00000000-0000-0000-0000-000000000000:-1
2016-04-04 16:49:03 139950170217216 [Note] WSREP: New cluster view: global state: 913d310a-9360-11e4-9d31-922a1e5d98fe:63180, view# 471: Primary, number of nodes: 3, my index: 2, protocol version 3
2016-04-04 16:49:03 139950170217216 [Warning] WSREP: Gap in state sequence. Need state transfer.
2016-04-04 16:49:03 139948883695360 [Note] WSREP: Running: 'wsrep_sst_rsync --role 'joiner' --address '192.168.4.28' --datadir '/var/lib/mysql/'  --defaults-file '/etc/mysql/my.cnf'  --parent '6067' --binlog 'mysqld-bin' '
2016-04-04 16:49:03 139950170217216 [Note] WSREP: Prepared SST request: rsync|192.168.4.28:4444/rsync_sst
2016-04-04 16:49:03 139950170217216 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2016-04-04 16:49:03 139950170217216 [Note] WSREP: REPL Protocols: 7 (3, 2)
2016-04-04 16:49:03 139949719164672 [Note] WSREP: Service thread queue flushed.
2016-04-04 16:49:03 139950170217216 [Note] WSREP: Assign initial position for certification: 63180, protocol version: 3
2016-04-04 16:49:03 139949719164672 [Note] WSREP: Service thread queue flushed.
2016-04-04 16:49:03 139950170217216 [Warning] WSREP: Failed to prepare for incremental state transfer: Local state UUID (00000000-0000-0000-0000-000000000000) does not match group state UUID (913d310a-9360-11e4-9d31-922a1e5d98fe): 1 (Operation not permitted)
         at galera/src/replicator_str.cpp:prepare_for_IST():482. IST will be unavailable.
2016-04-04 16:49:03 139948892088064 [Note] WSREP: Member 2.0 () requested state transfer from '*any*'. Selected 0.0 (www2)(SYNCED) as donor.
2016-04-04 16:49:03 139948892088064 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 63180)
2016-04-04 16:49:03 139950170217216 [Note] WSREP: Requesting state transfer: success, donor: 0
2016-04-04 16:49:05 139949710771968 [Note] WSREP: (fd416235, 'tcp://0.0.0.0:4567') turning message relay requesting off

E agora o nó continua sentado em "Juntar-se: recebendo transferência de estado".

Nodo doador selecionado (www2), no entanto, diz que concluiu a transferência de estado:

160404 16:49:04 [Note] WSREP: (4c4f4779, 'tcp://0.0.0.0:4567') address 'tcp://192.168.5.28:4567' pointing to uuid 4c4f4779 is blacklisted, skipping
160404 16:49:04 [Note] WSREP: (4c4f4779, 'tcp://0.0.0.0:4567') address 'tcp://192.168.5.28:4567' pointing to uuid 4c4f4779 is blacklisted, skipping
160404 16:49:04 [Note] WSREP: (4c4f4779, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers:
160404 16:49:04 [Note] WSREP: (4c4f4779, 'tcp://0.0.0.0:4567') address 'tcp://192.168.5.28:4567' pointing to uuid 4c4f4779 is blacklisted, skipping
160404 16:49:04 [Note] WSREP: (4c4f4779, 'tcp://0.0.0.0:4567') address 'tcp://192.168.5.28:4567' pointing to uuid 4c4f4779 is blacklisted, skipping
160404 16:49:04 [Note] WSREP: declaring b75760e5 at tcp://192.168.5.29:4567 stable
160404 16:49:04 [Note] WSREP: declaring fd416235 at tcp://192.168.4.28:4567 stable
160404 16:49:04 [Note] WSREP: Node 4c4f4779 state prim
160404 16:49:04 [Note] WSREP: view(view_id(PRIM,4c4f4779,710) memb {
    4c4f4779,0
    b75760e5,0
    fd416235,0
} joined {
} left {
} partitioned {
})
160404 16:49:04 [Note] WSREP: save pc into disk
160404 16:49:04 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 3
160404 16:49:04 [Note] WSREP: STATE_EXCHANGE: sent state UUID: feddde16-fa6b-11e5-86f6-fb86e3a56ec8
160404 16:49:04 [Note] WSREP: STATE EXCHANGE: sent state msg: feddde16-fa6b-11e5-86f6-fb86e3a56ec8
160404 16:49:04 [Note] WSREP: STATE EXCHANGE: got state msg: feddde16-fa6b-11e5-86f6-fb86e3a56ec8 from 0 (www2)
160404 16:49:04 [Note] WSREP: STATE EXCHANGE: got state msg: feddde16-fa6b-11e5-86f6-fb86e3a56ec8 from 1 (galera)
160404 16:49:05 [Note] WSREP: STATE EXCHANGE: got state msg: feddde16-fa6b-11e5-86f6-fb86e3a56ec8 from 2 ()
160404 16:49:05 [Note] WSREP: Quorum results:
    version    = 3,
    component  = PRIMARY,
    conf_id    = 470,
    members    = 2/3 (joined/total),
    act_id     = 63180,
    last_appl. = 63152,
    protocols  = 0/7/3 (gcs/repl/appl),
    group UUID = 913d310a-9360-11e4-9d31-922a1e5d98fe
160404 16:49:05 [Note] WSREP: Flow-control interval: [28, 28]
160404 16:49:05 [Note] WSREP: New cluster view: global state: 913d310a-9360-11e4-9d31-922a1e5d98fe:63180, view# 471: Primary, number of nodes: 3, my index: 0, protocol version 3
160404 16:49:05 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
160404 16:49:05 [Note] WSREP: REPL Protocols: 7 (3, 2)
160404 16:49:05 [Note] WSREP: Service thread queue flushed.
160404 16:49:05 [Note] WSREP: Assign initial position for certification: 63180, protocol version: 3
160404 16:49:05 [Note] WSREP: Service thread queue flushed.
160404 16:49:05 [Note] WSREP: Member 2.0 () requested state transfer from '*any*'. Selected 0.0 (www2)(SYNCED) as donor.
160404 16:49:05 [Note] WSREP: Shifting SYNCED -> DONOR/DESYNCED (TO: 63180)
160404 16:49:06 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
160404 16:49:06 [Note] WSREP: Running: 'wsrep_sst_rsync --role 'donor' --address '192.168.4.28:4444/rsync_sst' --auth '(null)' --socket '/var/run/mysqld/mysqld.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/mysql/my.cnf' --defaults-group-suffix ''  --binlog 'mysqld-bin' --gtid '913d310a-9360-11e4-9d31-922a1e5d98fe:63180''
160404 16:49:06 [Note] WSREP: sst_donor_thread signaled with 0
160404 16:49:06 [Note] WSREP: Flushing tables for SST...
160404 16:49:06 [Note] WSREP: Provider paused at 913d310a-9360-11e4-9d31-922a1e5d98fe:63180 (9555)
160404 16:49:06 [Note] WSREP: Tables flushed.
WSREP_SST: [INFO] Preparing binlog files for transfer: (20160404 16:49:07.005)
mysqld-bin.000033
160404 16:49:07 [Note] WSREP: (4c4f4779, 'tcp://0.0.0.0:4567') turning message relay requesting off
160404 16:51:39 [Note] WSREP: resuming provider at 9555
160404 16:51:39 [Note] WSREP: Provider resumed.
160404 16:51:40 [Note] WSREP: 0.0 (www2): State transfer to 2.0 () complete.
160404 16:51:40 [Note] WSREP: Shifting DONOR/DESYNCED -> JOINED (TO: 63180)
160404 16:51:40 [Note] WSREP: Member 0.0 (www2) synced with group.
160404 16:51:40 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 63180)
160404 16:51:40 [Note] WSREP: Synchronized with group, ready for connections
160404 16:51:40 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.

O que fazer agora? Como continuo a operação de atualização do nó?

mariadb
  • 1 respostas
  • 5406 Views

Sidebar

Stats

  • Perguntas 205573
  • respostas 270741
  • best respostas 135370
  • utilizador 68524
  • Highest score
  • respostas
  • Marko Smith

    Você pode passar usuário/passar para autenticação básica HTTP em parâmetros de URL?

    • 5 respostas
  • Marko Smith

    Ping uma porta específica

    • 18 respostas
  • Marko Smith

    Verifique se a porta está aberta ou fechada em um servidor Linux?

    • 7 respostas
  • Marko Smith

    Como automatizar o login SSH com senha?

    • 10 respostas
  • Marko Smith

    Como posso dizer ao Git para Windows onde encontrar minha chave RSA privada?

    • 30 respostas
  • Marko Smith

    Qual é o nome de usuário/senha de superusuário padrão para postgres após uma nova instalação?

    • 5 respostas
  • Marko Smith

    Qual porta o SFTP usa?

    • 6 respostas
  • Marko Smith

    Linha de comando para listar usuários em um grupo do Windows Active Directory?

    • 9 respostas
  • Marko Smith

    O que é um arquivo Pem e como ele difere de outros formatos de arquivo de chave gerada pelo OpenSSL?

    • 3 respostas
  • Marko Smith

    Como determinar se uma variável bash está vazia?

    • 15 respostas
  • Martin Hope
    Davie Ping uma porta específica 2009-10-09 01:57:50 +0800 CST
  • Martin Hope
    kernel O scp pode copiar diretórios recursivamente? 2011-04-29 20:24:45 +0800 CST
  • Martin Hope
    Robert ssh retorna "Proprietário incorreto ou permissões em ~/.ssh/config" 2011-03-30 10:15:48 +0800 CST
  • Martin Hope
    Eonil Como automatizar o login SSH com senha? 2011-03-02 03:07:12 +0800 CST
  • Martin Hope
    gunwin Como lidar com um servidor comprometido? 2011-01-03 13:31:27 +0800 CST
  • Martin Hope
    Tom Feiner Como posso classificar a saída du -h por tamanho 2009-02-26 05:42:42 +0800 CST
  • Martin Hope
    Noah Goodrich O que é um arquivo Pem e como ele difere de outros formatos de arquivo de chave gerada pelo OpenSSL? 2009-05-19 18:24:42 +0800 CST
  • Martin Hope
    Brent Como determinar se uma variável bash está vazia? 2009-05-13 09:54:48 +0800 CST

Hot tag

linux nginx windows networking ubuntu domain-name-system amazon-web-services active-directory apache-2.4 ssh

Explore

  • Início
  • Perguntas
    • Recentes
    • Highest score
  • tag
  • help

Footer

AskOverflow.Dev

About Us

  • About Us
  • Contact Us

Legal Stuff

  • Privacy Policy

Language

  • Pt
  • Server
  • Unix

© 2023 AskOverflow.DEV All Rights Reserve