Balanceamento de carga de banco de dados com ProxySQL e AWS Aurora

ProxySQL é uma solução comprovada que ajuda os administradores de banco de dados a lidar com os requisitos de alta disponibilidade de seus bancos de dados. Por ser compatível com SQL, ele também pode ser usado para moldar o tráfego em direção aos bancos de dados - você pode rotear consultas para os nós específicos, pode reescrever consultas se necessário, também pode limitar o tráfego, implementar firewall SQL, criar um espelho do seu tráfego e enviá-lo para um hostgroup separado.

O ProxySQL 2.0.5 suporta nativamente Galera Cluster, MySQL Replication e MySQL Group Replication. Infelizmente, por padrão, ele não oferece suporte ao AWS Aurora; mas ainda há uma solução alternativa que você pode usar.

Você pode estar se perguntando, por que devo me preocupar com o ProxySQL quando a AWS me fornece um endpoint que fará a divisão de leitura e gravação para mim? Esse é realmente o caso, mas é apenas a divisão r/w. O ProxySQL, por outro lado, oferece a oportunidade não apenas de separar leituras de gravações, mas também de controlar o tráfego do banco de dados. O ProxySQL geralmente pode evitar que seus bancos de dados sejam sobrecarregados apenas reescrevendo uma única consulta.

ProxySQL 2.0.5 e AWS Aurora

Se você decidir experimentar o ProxySQL, há algumas etapas a serem seguidas. Primeiro, você precisará de uma instância do EC2 para instalar o ProxySQL. Depois de ter a instância em funcionamento, você pode instalar o ProxySQL mais recente. Recomendamos usar o repositório para isso. Você pode configurá-lo seguindo as etapas na página de documentação:https://github.com/sysown/proxysql/wiki. Para o Ubuntu 16.04 LTS, que usamos, você deve executar:

apt-get install -y lsb-release

wget -O - 'https://repo.proxysql.com/ProxySQL/repo_pub_key' | apt-key add -

echo deb https://repo.proxysql.com/ProxySQL/proxysql-2.0.x/$(lsb_release -sc)/ ./ \

| tee /etc/apt/sources.list.d/proxysql.list

Então é hora de instalar o ProxySQL:

apt-get update

apt-get install proxysql

Em seguida, precisamos verificar se temos a conectividade de nossa instância ProxySQL para nós do AWS Aurora. Usaremos endpoints diretos para a conectividade.

Podemos testar facilmente a conectividade usando telnet para o endpoint correto na porta 3306 :

[email protected]:~# telnet dbtest-instance-1.cqb1vho43rod.eu-central-1.rds.amazonaws.com 3306

Trying 10.0.0.53...

Connected to dbtest-instance-1.cqb1vho43rod.eu-central-1.rds.amazonaws.com.

Escape character is '^]'.

J

5.7.12_2>ZWP-&[Ov8NzJ:H#Mmysql_native_password^CConnection closed by foreign host.

O primeiro parece bom. Continuaremos com o segundo nó do Aurora:

[email protected]:~# telnet dbtest-instance-1-eu-central-1a.cqb1vho43rod.eu-central-1.rds.amazonaws.com 3306

Trying 10.0.1.90...

Connected to dbtest-instance-1-eu-central-1a.cqb1vho43rod.eu-central-1.rds.amazonaws.com.

Escape character is '^]'.

J

tr3'3rynMmysql_native_password^CConnection closed by foreign host.

Funciona muito bem também. Se você não conseguir se conectar aos nós do Aurora, precisará garantir que todos os bits de segurança estejam alinhados corretamente:verifique a configuração da VPC, veja se o nó ProxySQL pode acessar a VPC do Aurora, verifique se os grupos de segurança permitem a passagem do tráfego. A camada de segurança de rede da AWS pode ser complicada de configurar se você não tiver experiência, mas finalmente poderá fazê-la funcionar.

Com a conectividade resolvida, precisaremos criar um usuário no Aurora. Usaremos esse usuário para monitorar os nós do Aurora no ProxySQL. Primeiro, podemos ter que instalar o cliente MySQL no nó ProxySQL:

[email protected]:~# apt install mysql-client-core-5.7

Em seguida, usaremos o endpoint do cluster para conectar ao gravador e criar um usuário nele:

[email protected]:~# mysql -h dbtest.cluster-cqb1vho43rod.eu-central-1.rds.amazonaws.com -u root -ppassword

mysql> CREATE USER 'monuser'@'10.0.0.191' IDENTIFIED BY 'mon1t0r';

Query OK, 0 rows affected (0.02 sec)

mysql> GRANT REPLICATION CLIENT ON *.* TO 'monuser'@'10.0.0.191';

Query OK, 0 rows affected (0.00 sec)

Com isso feito, podemos fazer login na interface de administração do ProxySQL (por padrão na porta 6032) para definir o usuário do monitor e sua senha.

[email protected]:~# mysql -P6032 -u admin -padmin -h127.0.0.1

mysql> SET mysql-monitor_username='monuser';

Query OK, 1 row affected (0.00 sec)



mysql> SET mysql-monitor_password='mon1t0r';

Query OK, 1 row affected (0.00 sec)

mysql> LOAD MYSQL VARIABLES TO RUNTIME;

Query OK, 0 rows affected (0.00 sec)

mysql> SAVE MYSQL VARIABLES TO DISK;

Query OK, 116 rows affected (0.00 sec)

Agora é hora de definir os nós do Aurora no ProxySQL:

mysql> INSERT INTO mysql_servers (hostgroup_id, hostname) VALUES (10, 'dbtest-instance-1.cqb1vho43rod.eu-central-1.rds.amazonaws.com'), (20, 'dbtest-instance-1-eu-central-1a.cqb1vho43rod.eu-central-1.rds.amazonaws.com');

Query OK, 2 rows affected (0.01 sec)

Como você pode ver, usamos seus endpoints diretos como o nome do host. Feito isso, usaremos a tabela mysql_replication_hostgroup para definir grupos de hosts de leitores e gravadores. Também teremos que passar o tipo de verificação correto - por padrão, o ProxySQL procura a variável 'read_only' enquanto o Aurora usa 'innodb_read_only' para diferenciar entre o gravador e os leitores.

mysql> SHOW CREATE TABLE mysql_replication_hostgroups\G

*************************** 1. row ***************************

       table: mysql_replication_hostgroups

Create Table: CREATE TABLE mysql_replication_hostgroups (

    writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,

    reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND reader_hostgroup>=0),

    check_type VARCHAR CHECK (LOWER(check_type) IN ('read_only','innodb_read_only','super_read_only')) NOT NULL DEFAULT 'read_only',

    comment VARCHAR NOT NULL DEFAULT '', UNIQUE (reader_hostgroup))

1 row in set (0.00 sec)



mysql> INSERT INTO mysql_replication_hostgroups VALUES (10, 20, 'innodb_read_only', 'Aurora');

Query OK, 1 row affected (0.00 sec)

mysql> LOAD MYSQL SERVERS TO RUNTIME;

Query OK, 0 rows affected (0.00 sec)

É isso, agora podemos ver como o ProxySQL configurou os nós na configuração de tempo de execução:

mysql> SELECT hostgroup_id, hostname, port  FROM runtime_mysql_servers;

+--------------+-----------------------------------------------------------------------------+------+

| hostgroup_id | hostname                                                                    | port |

+--------------+-----------------------------------------------------------------------------+------+

| 10           | | 3306 |

| 20           | dbtest-instance-1-eu-central-1a.cqb1vho43rod.eu-central-1.rds.amazonaws.com | 3306 |

| 20           | dbtest-instance-1.cqb1vho43rod.eu-central-1.rds.amazonaws.com               | 3306 |

+--------------+-----------------------------------------------------------------------------+------+

3 rows in set (0.00 sec)

Como você pode ver, dbtest-instance-1.cqb1vho43rod.eu-central-1.rds.amazonaws.com é o escritor. Vamos tentar o failover agora:

mysql> SELECT hostgroup_id, hostname, port  FROM runtime_mysql_servers;

+--------------+-----------------------------------------------------------------------------+------+

| hostgroup_id | hostname                                                                    | port |

+--------------+-----------------------------------------------------------------------------+------+

| 10           | dbtest-instance-1-eu-central-1a.cqb1vho43rod.eu-central-1.rds.amazonaws.com | 3306 |

| 20           | dbtest-instance-1-eu-central-1a.cqb1vho43rod.eu-central-1.rds.amazonaws.com | 3306 |

| 20           | dbtest-instance-1.cqb1vho43rod.eu-central-1.rds.amazonaws.com               | 3306 |

+--------------+-----------------------------------------------------------------------------+------+

3 rows in set (0.00 sec)

Como você pode ver, o escritor (hostgroup 10) mudou para o segundo nó.

Conclusão