Perguntas[galera](dba)

Então o cenário é esse. Já configurei um cluster MariaDB Galera de 4 nós (10.5). Também estou adicionando em cima um 5º Árbitro Galera e tudo sincroniza e conecta muito bem. No entanto, quando habilito o SSL no cluster (depois de inicializá-lo do zero), consigo sincronizar os 4 nós, mas o Árbitro por algum motivo não sincroniza.

Interessante é que quando os nós estão sincronizando eles estão produzindo "connecting...ssl://172.31.0.4:4567". No entanto, quando o árbitro está tentando sincronizar, está exibindo "conectando...tcp://172.31.0.4:4567". Parece que está tentando sobre tcp por algum motivo.

Sua configuração é essa quando eu inicializo

    name:    garb
    address: gcomm://mariadb-galera-0:4567,mariadb-galera-1:4567,mariadb-galera-2:4567,mariadb-galera-3:4567,mariadb-galera-arb:4567
    group:   scluster
    sst:     trivial
    donor:
    options: socket.ssl_key=/etc/ssl/galera/server-key.pem;socket.ssl_cert=/etc/ssl/galera/server-cert.pem;socket.ssl_ca=/etc/ssl/galera/ca-cert.pem;socket.ssl_cipher=AES128-SHA; gcs.fc_limit=9999999; gcs.fc_factor=1.0; gcs.fc_master_slave=yes
    cfg:
    log:

Não me dá um erro ssl ou cert apenas expirando

INFO: (8bef8261-9d27, 'tcp://0.0.0.0:4567') connection to peer 00000000-0000 with addr tcp://172.31.0.4:4567 timed out, no messages seen in PT3S, socket stats: rtt: 39 rttvar: 19 rto: 200000 lost: 0 last_data_recv: 3500 cwnd: 10 last_queued_since: 3499991400 last_delivered_since: 3499991400 send_queue_length: 0 send_queue_bytes: 0

Os pemarquivos são exatamente os mesmos que estou usando em todos os nós + o árbitro.

Li na documentação que preciso especificar ciphercaso contrário estarei recebendo um erro. Eu tentei AES128-SHAe AES128-SHA256não declarando nada, mas ainda expirando.

Abaixo estão as opções do provedor wsrep do phpmyadmin de um dos nós. O cipherparece vazio, mas, novamente, por que o árbitro está tentando se conectar a "tcp://" e não a "ssl://" como os outros?

Obrigado por ajudar

Eu tenho um cluster Galera Replication com três nós MariaDB onde um cluster Maxscale Active-Passive na frente fornece uma imagem de nó único para clientes tis.

Eu tenho um cliente de mau comportamento, que abre conexões e não as fecha. O número de conexões continua aumentando até que os limites do banco de dados sejam atingidos. Para limitar o número de conexões que configurei abaixo de dois parâmetros

max_connections=
max_user_connections=

Minha situação é essa, quando tenho apenas max_connections configurados, sempre que os limites são atingidos o nó Galera deixa de aceitar mais conexão com erro de "Too many connections". Quando o Maxscale vê essas rejeições de conexão n vezes, ele coloca o servidor em modo de manutenção . Eu posso entender esse comportamento, é esperado. Quando configuro max_user_connections, e porque o aplicativo está se comportando mal e tentando fazer novas conexões continuamente, quando o limite específico do usuário atinge mais tentativas de conexões falham nos nós mariadb no backend. O Maxscale observa essas falhas e novamente coloca o servidor no modo Manutenção . Acredito que durante esse tempo ele veja apenas tentativas de conexão do cliente ruim, nenhum outro aplicativo tentou se conectar.

E desta forma, MaxScale coloca todos os três nós no modo de Manutenção ao longo do tempo, o que torna o serviço DB completo indisponível.

Para mim como administrador, a situação se torna a mesma, colocar um limite específico de usuário não alcança nada. Eu gostaria de perguntar dois pontos aqui

Q1. Como posso evitar que apenas uma falha de conexão de usuário coloque o nó mariadb de back-end em manutenção?

Q2. Alguma documentação, ou tutoriais, referência de artigo sobre como e quando MaxScale decide colocar um servidor em modo de manutenção?

Abaixo estão os detalhes sobre o ambiente

Galera - 25.3.23, MariaDB - 10.3.12, MaxScale - 2.4.11, OS - RHEL 7.4 (Maipo)

Aqui está minha configuração

Configuração da Galeria MariaDB

[server]

# this is only for the mysqld standalone daemon
[mysqld]
#user statistics
userstat=1
performance_schema
#wait_timeout=600
max_allowed_packet=1024M
#
lower_case_table_names=1
#
max_connections=1500
max_user_connections=200
#
# * Galera-related settings
#
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_provider_options="gcache.size=300M; gcache.page_size=300M; pc.ignore_sb=false; pc.ignore_quorum=false"
#wsrep_cluster_address defines members of the cluster
wsrep_cluster_address=gcomm://x.x.x.1,x.x.x.2,x.x.x.3
wsrep_cluster_name="mariadb-cluster"
wsrep_node_address=x.x.x.1
wsrep_node_incoming_address=x.x.x.1
wsrep_debug=OFF
#
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_doublewrite=1
query_cache_size=0
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=5G
#
bind-address=x.x.x.1
#
[mariadb]
#performance
wait_timeout=31536000
#
#query logging
log_output=FILE
#slow queries
slow_query_log
slow_query_log_file=/var/log/mariadb/mariadb-slow.log
long_query_time=10.0
log_queries_not_using_indexes=ON
min_examined_row_limit=1000
log_slow_rate_limit=1
log_slow_verbosity=query_plan,explain
#
#error logs
log_error=/var/log/mariadb/mariadb-error.log
log_warnings=2

Da mesma forma, todos os três nós Galera são configurados.

Configuração MaxScale

[maxscale]
threads=auto

# Server definitions
[mariadb1]
type=server
address=x.x.x.1
port=3306
protocol=MariaDBBackend
#priority=0

[mariadb2]
type=server
address=x.x.x.2
port=3306
protocol=MariaDBBackend
#priority=1

[mariadb3]
type=server
address=x.x.x.3
port=3306
protocol=MariaDBBackend
#priority=1

# Monitor for the servers
#

[Galera-Monitor]
type=monitor
module=galeramon
servers=mariadb1, mariadb2, mariadb3
user=xxx
password=xxx
#disable_master_role_setting=true
monitor_interval=1000
#use_priority=true
#
disable_master_failback=true
available_when_donor=true

# Service definitions

[Galera-Service]
type=service
router=readwritesplit
master_accept_reads=true
connection_keepalive=300s
master_reconnection=true
master_failure_mode=error_on_write
connection_timeout=3600s
servers=mariadb1, mariadb2, mariadb3
user=xxx
password=xxx
#filters=Query-Log-Filter

#Listener

[Galera-Listener]
type=listener
service=Galera-Service
protocol=MariaDBClient
port=4306

Temos algumas tabelas com row_format=Compact. A maior tabela tem cerca de 30 GB, então com que segurança posso alterar as tabelas e definir o formato da linha como compactado para a tabela grande e dinâmico para outras três tabelas com menos de 10 GB cada? É um cluster com três nós com mariadb v10.4.12 e Galera 4. Executar DDL / alterar tabelas e alterar o formato da linha pode levar ao bloqueio do cluster e talvez tenha demorado muito!

Alguém pode me ajudar e me orientar como posso fazer? Você acha que usar o modo RSU ajuda aqui e é seguro, já que falamos em alterar o formato da linha?

Trabalhando com Galera 25.3.23 no RHEL 7.3

Galera funciona bem antes. Após alterar a porta do servidor MySQL de 3306 para 13306, um dos nós reporta erro, após a reinicialização:

Slave I/O: error connecting to master 'repuser@<IP>:3306' - retry-time: 60  maximum-retries: 86400  message: Can't connect to MySQL server on '<IP>' (111 "Connection refused"), Internal MariaDB error code: 2003

Os outros 2 nós funcionam bem após a reinicialização.

Pesquisei na web, mas não encontrei a maneira de especificar o número da porta.

Além disso, se possível, compartilhe o uso do ID "repuser".

instalei MaxScale 2.4.4com Galera Cluster. Consigo acessar a galera com o usuário maxscale mas não consigo logar com outros usuários no maxscale. Criei um usuário na galera e outro usuário com mesmo nome de usuário com maxctrl mas ele retorna erro de acesso negado. Como posso criar usuários para aplicativos no maxscale 2.4.4.

maxscale.cnf

[maxscale]
threads=1

[Galera-Monitor]
type=monitor
module=galeramon
servers=server1,server2,server3
user=maxscale
password=qwe123
disable_master_failback=1

[Galera-Service]
type=service
router=readwritesplit
servers=server1,server2,server3
user=maxscale
password=qwe123

[Galera-Listener]
type=listener
#router=readwritesplit
service=Galera-Service
protocol=MySQLClient
port=3306

[Write-Service]
type=service
router=readconnroute
router_options=master
servers=server1, server2, server3
user=maxscale
password=qwe123

[Read-Service]
type=service
router=readconnroute
router_options=slave
servers=server1, server2, server3
user=maxscale
password=qwe123

#[Splitter-Service]
#type=service
#router=readwritesplit
#servers=server1,server2,server3
#user=maxscale
#password=qwe123

#[Splitter-Listener]
#type=listener
#service=Splitter-Service
#protocol=MariaDBClient
#port=3306

[CLI]
type=service
router=cli

[CLI-Listener]
type=listener
service=CLI
protocol=maxscaled
address=0.0.0.0
port=6603

[server1]
type=server
address=192.168.122.93
port=3306
protocol=MySQLBackend

[server2]
type=server
address=192.168.122.17
port=3306
protocol=MySQLBackend

[server3]
type=server
address=192.168.122.13
port=3306
protocol=MySQLBackend

Achei enable_root_user=1para login no maxscale com usuário root mas não sei onde devo adicioná-lo;

maxctrl list servers
┌─────────┬────────────────┬──────┬─────────────┬─────────────────────────┬──────┐
│ Server  │ Address        │ Port │ Connections │ State                   │ GTID │
├─────────┼────────────────┼──────┼─────────────┼─────────────────────────┼──────┤
│ server1 │ 192.168.122.93 │ 3306 │ 0           │ Master, Synced, Running │      │
├─────────┼────────────────┼──────┼─────────────┼─────────────────────────┼──────┤
│ server2 │ 192.168.122.17 │ 3306 │ 0           │ Slave, Synced, Running  │      │
├─────────┼────────────────┼──────┼─────────────┼─────────────────────────┼──────┤
│ server3 │ 192.168.122.13 │ 3306 │ 0           │ Slave, Synced, Running  │      │
└─────────┴────────────────┴──────┴─────────────┴─────────────────────────┴──────┘

maxscale é executado 192.168.122.222e eu quero que todos os aplicativos se conectem a este endereço com seu próprio usuário;

A seguinte configuração se aplica:

• Cluster galera de 3 nós no docker
• contêiner de backup que deve executar o mariabackup para obter os dados do cluster galera
• rede está bem. container de backup pode pingar galera
• mariadb/mariabackup versão 10.3
• o container de backup só tem o mariabackup instalado.

O comando que eu usei

mariabackup --backup --host=<service_name> --port=3306 --user=root --password=<pass> --target-dir=/backup

Ao tentar fazer backup do galera-cluster de dentro do contêiner de backup, recebo o seguinte erro

00] 2019-09-15 23:38:34 Connecting to MySQL server host: mdb_mariadb, user: root, password: set, port: 3306, socket: /var/run/mysqld/mysqld.sock
[00] 2019-09-15 23:38:34 Using server version 10.3.18-MariaDB-1:10.3.18+maria~bionic-log
[00] 2019-09-15 23:38:34 Warning: option 'datadir' points to nonexistent directory '/var/lib/mysql/'
[00] 2019-09-15 23:38:34 Warning: MySQL variable 'datadir' points to nonexistent directory '/var/lib/mysql/'
[00] 2019-09-15 23:38:34 Warning: option 'datadir' has different values:
  '/var/lib/mysql/' in defaults file
  '/var/lib/mysql/' in SHOW VARIABLES
mariabackup based on MariaDB server 10.3.18-MariaDB debian-linux-gnu (x86_64)
[00] 2019-09-15 23:38:34 uses posix_fadvise().
mariabackup: Can't change dir to '/var/lib/mysql/' (Errcode: 2 "No such file or directory")
[00] 2019-09-15 23:38:34 my_setwd() failed , /var/lib/mysql/

O que eu tentei.

• pesquisando várias essências para pistas
• pesquisando os scripts mariadb fornecidos pela instalação do servidor
• tentando combinações de opções diferentes, mas sempre o mesmo erro.

Pergunta:

• Alguém já fez backups remotos e pode me dizer como você conseguiu?
• A abordagem está errada e existe uma maneira melhor de fazer backups dinâmicos uma vez por dia e incrementais durante o dia?

Eu tenho vários servidores MariaDB, cada um com várias instâncias em execução. Estou tentando descobrir como inicializar um cluster Galera, mas especificar qual instância quero iniciar, ou seja:

node1, 2 e 3 cada um tem instâncias 1-4 rodando via mysqld_multi, cada uma rodando em sua própria porta.

Eu quero usar a instância 4 em cada servidor para o cluster, então encerro cada uma.

No meu cluster de teste (que tem uma única instância do MariaDB em execução) o bootstrap é simples: inicie-o no primeiro nó com galera_new_cluster e depois abra os outros dois servidores.

Como eu faria a mesma coisa, mas especificaria GNR "4" para inicializar o cluster?

estamos usando MariaDB 10.2 com plugin Galera. O cluster consiste em 4 nós - 3 são consultas complexas de serviço ocupado e 1 é mais para um backup.

Recentemente nos deparamos com o ProxySQL e isso nos parece muito interessante em termos de dividir consultas de inserção em um servidor e selecionar dados de outros. Esperamos evitar deadlocks e problemas de autoincremento durante alta atividade.

Mas um de nossos desenvolvedores descobriu um atraso - ao usar o ProxySQL ele tenta inserir um registro simples e fazer uma seleção instantânea desse registro. Em geral, a cada segundo ou terceiro tal solicitação de seleção falha devido à latência. Se ele adicionar um pequeno atraso de 0,01s - ele nunca falhará, pois todos os nós da galera são capazes de sincronizar dentro desse tempo.

Agora a questão é - é possível armazenar em cache os dados inseridos com o ProxySQL, para que a "seleção" instantânea seja retornada do cache, pelo menos nos primeiros 0,01 segundos.

Ou existem outras formas ou sugestões neste cenário?

Obrigada. :)

Eu preciso executar uma instrução alter, mas gostaria de evitar travar/parar o cluster. Os documentos Galera aconselharam usar:

SET wsrep_OSU_method='RSU';

Em seguida, execute a instrução ALTER, uma vez finich:

SET wsrep_OSU_method='TOI';

O problema é que isso precisa ser executado em todos os nós e eu só tenho acesso a um nó atrás de um balanceador de carga, alguma alternativa ou solução alternativa?

No momento, nossa configuração é CloudFlare > 1x HAProxy (Dallas,TX), 3x servidores de aplicativos (Dallas,TX), 3x nós MariaDB em um cluster multimestre Galera (Dallas,TX). Os servidores de aplicativos são dimensionados automaticamente horizontalmente para lidar com qualquer tráfego que seja lançado neles. Os servidores HAProxy e DB são dimensionados quando necessário. Os servidores de aplicativos também mantêm caches de leitura SQL individuais para facilitar a carga no banco de dados.

Nosso principal ponto de venda é manter nosso produto online não importa o que aconteça, pois nossa solução atende a serviços de emergência do governo e, como somos uma start-up, nosso orçamento é muito apertado.

Foi inesperado que nosso provedor de nuvem atual (que não podemos alterar nos meses seguintes) esteja enfrentando DDOS por cerca de 30 minutos por mês. Para a nossa situação, nem mesmo um minuto de inatividade é aceitável.

Então, estou pensando em usar algo como CloudFlare > 3x HAProxy (Dallas,TX; Freemont,CA; Newark,NJ) > 6x servidores de aplicativos (Dallas,TX; Freemont,CA; Newark,NJ) > 3 Galera Multi-master + 2 Árbitro Galera (Dallas,TX; Freemont,CA; Newark,NJ; Atlanta,GA; San Francisco,SF).

Isso vai aumentar um pouco nossos custos, e é por isso que eu quero dois Árbitros Galera se eu puder economizar custos e ao mesmo tempo aumentar a estabilidade.

Minha principal pergunta é: quais são os requisitos de recursos para o Galera Arbitrator e valeria a pena ter três nós MariaDB e dois nós do Galera Arbitrator, em vez de apenas três nós MariaDB no cluster? Outra maneira de colocar isso é: vale a pena usar garbd em configurações com mais de três nós de tamanho?

Desde que, em termos de rota, nossos servidores HAProxy escolherão os servidores de aplicativos na mesma região, que posteriormente escolherão o servidor de banco de dados na mesma região. As escolhas são baseadas em uma combinação de tempo de conexão e carga do servidor.