domingo, 14 de abril de 2019

Configuração simples do KeepaliveD

Então keepalived tem sido em torno de um bom tempo agora .... no entanto, ainda é um mistério para muitos.
Portanto, este é um exemplo muito simples de como o keepalived pode funcionar com o MySQL. Espero que isso possa ajudar as pessoas com dúvidas.

Nós teremos um mestre simples para configurar escravos. Significado .. nós escrevemos para um a menos que tenhamos failover para o segundo para algum evento.

1º - instalar keepalived


# yum search keepalived
keepalived .x86_64: Balanceador de carga e serviço de alta disponibilidade

  Apenas para nomes e resumos, use "pesquisar todos" para tudo.
# yum -y install keepalived

Agora você deve ter um arquivo de configuração

# ls -ltr /etc/keepalived/keepalived.conf  

Mantenha o original como você sempre faz backup .. certo ....
# cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.orig

Então você precisa descobrir um ipaddress que você pode usar para o seu ip virtual. Eu escolhi 192.168.0.123 para este exemplo.

Em seguida, vamos configurar um script para ser usado em nosso novo arquivo de configuração.

Algumas coisas que fiz aqui ..
Eu deixei um arquivo .cnf para keepalived e um log all no / etc / keepalived.
Isso simplifica o exemplo para que você possa fazer isso ou usar seus próprios arquivos cnf.

Um roteiro:

cat /etc/keepalived/keepalived_check.sh  
#! / bin / bash

# monitorar o status do mysql

# se este nó mysql estiver morto

# e seu escravo está vivo, então pare seu keepalived. O outro nó ligará o IP.



exportar MYSQL_HOME = / etc / keepalived /

Exportar PATH = $ MYSQL_HOME / bin: $ PATH



mysql = "/ usr / bin / mysql"

mysqladmin = "/ usr / bin / mysqladmin"

delay_file = "$ MYSQL_HOME / slave_delay_second.log"

slave_host = $ 1





ALIVE = $ ($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.localhost.cnf   ping | grep alive | wc -l);

REMOTEALIVE = $ ($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.remotehost.cnf   ping | grep alive | wc -l);



if [[$ ALIVE -ne 1]]

então

#echo "MySQL está inoperante"

        if [[$ REMOTEALIVE-eq 1]]

        então

#         eco "Shutdown keep alive"

            systemctl stop keepalived  

#       echo "stop keepalived"

        fi

#outro

#echo "MySQL está ativo"

#encontro

fi



sair 0 #todo feito

Novo arquivo de configuração

cat /etc/keepalived/keepalived.conf
global_defs {



      notification_email {

        anothermysqldba@gmail.com  

      }



      notification_email_from anothermysqldba@gmail.com  

      smtp_server localhost

      smtp_connect_timeout 30



      }







vrrp_script check_mysql {

   script "/etc/keepalived/keepalived_check.sh"

   intervalo 2

   peso 2

}







vrrp_instance VI_1 {



      estado MESTRE

      interface enp0s8   # <--- O NOME DA INTERFACE REALIZA SEU IP REAL / sbin / ifconfig

        # encontrado com show ip link

      virtual_router_id 51

      prioridade 101

      advert_int 1

      nopreempt   # somente necessário no nó de prioridade mais alta

      autenticação {

        auth_type PASS

        auth_pass 1111

      }





      track_script {

        check_mysql

      }



      virtual_ipaddress {

        192.168.0.123  

      }




}



Isso tudo é ótimo, mas funciona ...

Então nós temos 2 hosts

[root @ centosa keepalived] # hostname

centosa

[root @ centosb keepalived] # hostname
centosb

Comece a manter o serviço

[root @ centosa keepalived] # systemctl status keepalived
● keepalived.service - Monitor de alta disponibilidade de LVS e VRRP
   Carregado: carregado (/usr/lib/systemd/system/keepalived.service; desativado; predefinido do fornecedor: desativado)
   Ativo: inativo (morto)
[root @ centosa keepalived] # systemctl restart keepalived
[root @ centosa keepalived] # systemctl status keepalived
keepalived.service - Monitor de alta disponibilidade de LVS e VRRP
   Carregado: carregado (/usr/lib/systemd/system/keepalived.service; desativado; predefinido do fornecedor: desativado)
    Ativo: ativo (em execução)

[root @ centosa keepalived] # ssh 192.168.0.123 'hostname'
Senha: root@192.168.0.123:  

centosa

Prove as conexões já funcionam

[root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.101   -e "selecione @@ hostname"
+ ------------ +
| @@ hostname |
+ ------------ +
| centosb     |
+ ------------ +
[root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.102   -e "selecione @@ hostname"
+ ------------ +
| @@ hostname |
+ ------------ +
| centosa     |
+ ------------ +

Verifique se está funcionando ...

[root @ centosa keepalived] # status do systemctl keepalived | grep active
    Ativo: ativo  

[root @ centosb keepalived] # status do systemctl keepalived | grep active
    Ativo: ativo  

Teste o VIP atual .. pare o mysql e veja os mesmos hosts de mudança do VIP ...

[root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.123   -e "selecione @@ hostname"
+ ------------ +
| @@ hostname |
+ ------------ +
| centosa     |
+ ------------ +
[root @ centosa keepalived] # systemctl pára o mysqld  
[root @ centosa keepalived] # mysql --defaults-file = .my.remotehost.cnf --host = 192.168.0.123   -e "selecione @@ hostname"
+ ------------ +
| @@ hostname |
+ ------------ +
| centosb     |
+ ------------ +

terça-feira, 9 de abril de 2019

Às vezes, o banco de dados lento .. não é o banco de dados ...

Então eu fui recentemente perguntado por que o MySQL 5 atualizado, .6 era mais lento que o mais antigo 5.5

Então eu comecei a olhar por cima das variáveis ​​padrão e caches e etc.

O caso de teste era uma rotina simples que levava cerca de duas vezes mais tempo para ser executada em 5.6 do que em 5.5.

Para adicionar ao mix .. a versão 5.6 tinha o dobro do Innodb_buffer_pool_size e, claro, mais ram geral.

Então eu comecei alguns testes com o MySQLslap ...

Testes do Mysqlslap mostram mais lento em 5.6

5,6:
mysqlslap --defaults-file =. /. my.cnf --concurrency = 150 --iterações = 130 - consulta = / teste.sql --create-schema = applicationdata --verbose
Referência
Número médio de segundos para executar todas as consultas: 0,028 segundos
Número mínimo de segundos para executar todas as consultas: 0,019 segundos
Número máximo de segundos para executar todas as consultas: 0,071 segundos
Número de clientes executando consultas: 150
Número médio de consultas por cliente: 1

5,5:
mysqlslap --defaults-file =. /. my.cnf --concurrency = 150 --iterações = 130 --query = / test.sql --create-schema = applicationdata --verbose
Referência
Número médio de segundos para executar todas as consultas: 0,015 segundos
Número mínimo de segundos para executar todas as consultas: 0,011 segundos
Número máximo de segundos para executar todas as consultas: 0,024 segundos
Número de clientes executando consultas: 150
Número médio de consultas por cliente: 1


Tudo isso vai contra os benchmarks públicos
http://dimitrik.free.fr/blog/archives/2013/02/mysql-performance-mysql-56-ga-vs-mysql-55-32cores.html

Então eu verifiquei o nível do disco -

5,6:
# dd if = / dev / zero de = teste bs = 1048576 contagem = 2048
2048 + 0 registros em
2048 + 0 registra
2147483648 bytes (2,1 GB) copiados, 25,7401 s, 83,4 MB / s

# dd if = teste de = / dev / null bs = 1048576
2048 + 0 registros em
2048 + 0 registra
2147483648 bytes (2,1 GB) copiados, 29,1527 s, 73,7 MB / s

5,5:
# dd if = / dev / zero de = teste bs = 1048576 contagem = 2048
2048 + 0 registros em
2048 + 0 registra
2147483648 bytes (2,1 GB) copiados, 19,9214 segundos, 108 MB / s

# dd if = teste de = / dev / null bs = 1048576
2048 + 0 registros em
2048 + 0 registra
2147483648 bytes (2,1 GB) copiados, 20,0243 segundos, 107 MB / s



Aqui os discos com 5.5 são mais lentos independentemente do MySQL. Então, neste caso .... Olhe para corrigir a velocidade do disco .. MySQL estava funcionando bem e vontade.