Saul  Alaniz

Saul Alaniz

1651824660

Cómo Unir MySQL Y Postgres En Una Vista Materializada En Vivo

Cuando trabaja en un proyecto que consta de muchos microservicios, es probable que también incluya varias bases de datos.

Por ejemplo, puede tener una base de datos MySQL y una base de datos PostgreSQL , ambas ejecutándose en servidores separados.

Por lo general, para unir los datos de las dos bases de datos, tendría que introducir un nuevo microservicio que uniría los datos. Pero esto aumentaría la complejidad del sistema.

En este tutorial, usaremos Materialise para unir MySQL y Postgres en una vista materializada en vivo. Entonces podremos consultar eso directamente y obtener resultados de ambas bases de datos en tiempo real usando SQL estándar.

Materialise es una base de datos de transmisión disponible en la fuente escrita en Rust que mantiene los resultados de una consulta SQL (una vista materializada) en la memoria a medida que cambian los datos.

El tutorial incluye un proyecto de demostración que puede comenzar a usar docker-compose.

El proyecto de demostración que vamos a utilizar monitoreará los pedidos en nuestro sitio web simulado. Generará eventos que luego podrían usarse para enviar notificaciones cuando un carrito ha estado abandonado por mucho tiempo.

La arquitectura del proyecto de demostración es la siguiente:

mz-carrito-abandonado-demo

requisitos previos


Todos los servicios que usaremos en la demostración se ejecutarán dentro de los contenedores Docker, de esa manera no tendrá que instalar ningún servicio adicional en su computadora portátil o servidor en lugar de Docker y Docker Compose.

En caso de que no tenga Docker y Docker Compose ya instalados, puede seguir las instrucciones oficiales sobre cómo hacerlo aquí:

Visión de conjunto

Como se muestra en el diagrama anterior, tendremos los siguientes componentes:

  • Un servicio simulado para generar pedidos continuamente.
  • Los pedidos se almacenarán en una base de datos MySQL .
  • A medida que se producen las escrituras en la base de datos, Debezium transmite los cambios desde MySQL a un tema de Redpanda .
  • También tendremos una base de datos de Postgres donde podemos obtener nuestros usuarios.
  • Luego incorporaremos este tema de Redpanda en Materialise directamente junto con los usuarios de la base de datos de Postgres.
  • En Materialise uniremos nuestros pedidos y usuarios, filtraremos y crearemos una vista materializada que muestre la información del carrito abandonado.
  • Luego, crearemos un sumidero para enviar los datos del carrito abandonado a un nuevo tema de Redpanda.
  • Al final usaremos Metabase para visualizar los datos.
  • Más adelante, podría usar la información de ese nuevo tema para enviar notificaciones a sus usuarios y recordarles que tienen un carrito abandonado.

Como nota al margen aquí, estaría perfectamente bien usando Kafka en lugar de Redpanda. Simplemente me gusta la simplicidad que aporta Redpanda, ya que puede ejecutar una sola instancia de Redpanda en lugar de todos los componentes de Kafka.

Cómo ejecutar la demostración

Primero, comience clonando el repositorio:

git clone https://github.com/bobbyiliev/materialize-tutorials.git

Después de eso, puede acceder al directorio:

cd materialize-tutorials/mz-join-mysql-and-postgresql

Empecemos ejecutando primero el contenedor de Redpanda:

docker-compose up -d redpanda

Construye las imágenes:

docker-compose build

Finalmente, inicie todos los servicios:

docker-compose up -d

Para iniciar Materialise CLI, puede ejecutar el siguiente comando:

docker-compose run mzcli

Este es solo un acceso directo a un contenedor Docker con postgres-clientpreinstalado. Si ya lo has hecho, psqlpuedes ejecutarlo psql -U materialize -h localhost -p 6875 materializeen su lugar.

Cómo crear una fuente de Materialise Kafka

Ahora que está en Materialise CLI, definamos las orderstablas en la mysql.shopbase de datos como fuentes de Redpanda:

CREATE SOURCE orders
FROM KAFKA BROKER 'redpanda:9092' TOPIC 'mysql.shop.orders'
FORMAT AVRO USING CONFLUENT SCHEMA REGISTRY 'http://redpanda:8081'
ENVELOPE DEBEZIUM;

Si tuviera que verificar las columnas disponibles de la ordersfuente ejecutando la siguiente declaración:

SHOW COLUMNS FROM orders;

Podrá ver que, dado que Materialise extrae los datos del esquema del mensaje del registro de Redpanda, conoce los tipos de columna que se deben usar para cada atributo:

    name      | nullable |   type
--------------+----------+-----------
 id           | f        | bigint
 user_id      | t        | bigint
 order_status | t        | integer
 price        | t        | numeric
 created_at   | f        | text
 updated_at   | t        | timestamp

Cómo crear vistas materializadas

A continuación, crearemos nuestra primera vista materializada para obtener todos los datos de la ordersfuente de Redpanda:

CREATE MATERIALIZED VIEW orders_view AS
SELECT * FROM orders;
CREATE MATERIALIZED VIEW abandoned_orders AS
    SELECT
        user_id,
        order_status,
        SUM(price) as revenue,
        COUNT(id) AS total
    FROM orders_view
    WHERE order_status=0
    GROUP BY 1,2;

Ahora puede usar SELECT * FROM abandoned_orders;para ver los resultados:

SELECT * FROM abandoned_orders;

Para obtener más información sobre la creación de vistas materializadas, consulte la sección Vistas materializadas de la documentación de Materialise.

Cómo crear una fuente de Postgres

Hay dos formas de crear una fuente de Postgres en Materialise:

  • Usando Debezium tal como lo hicimos con la fuente MySQL.
  • Usando Postgres Materialise Source, que le permite conectar Materialise directamente a Postgres para que no tenga que usar Debezium.

Para esta demostración, usaremos Postgres Materialise Source solo como una demostración de cómo usarlo, pero siéntase libre de usar Debezium en su lugar.

Para crear una fuente Materialise de Postgres, ejecute la siguiente instrucción:

CREATE MATERIALIZED SOURCE "mz_source" FROM POSTGRES
CONNECTION 'user=postgres port=5432 host=postgres dbname=postgres password=postgres'
PUBLICATION 'mz_source';

Un resumen rápido de la declaración anterior:

  • MATERIALIZED: Materializa los datos de la fuente de PostgreSQL. Todos los datos se retienen en la memoria y hace que las fuentes se puedan seleccionar directamente.
  • mz_source: El nombre de la fuente de PostgreSQL.
  • CONNECTION: Los parámetros de conexión de PostgreSQL.
  • PUBLICATION: La publicación de PostgreSQL, que contiene las tablas que se transmitirán a Materialise.

Una vez que hayamos creado la fuente de PostgreSQL, para poder consultar las tablas de PostgreSQL, necesitaríamos crear vistas que representen las tablas originales de la publicación ascendente.

En nuestro caso, solo tenemos una tabla llamada, userspor lo que la declaración que necesitaríamos ejecutar es:

CREATE VIEWS FROM SOURCE mz_source (users);

Para ver las vistas disponibles ejecute la siguiente instrucción:

SHOW FULL VIEWS;

Una vez hecho esto, puede consultar las nuevas vistas directamente:

SELECT * FROM users;

A continuación, avancemos y creemos algunas vistas más.

Cómo crear un lavabo Kafka

Los sumideros le permiten enviar datos desde Materialise a una fuente externa.

Para esta demostración, usaremos Redpanda .

Redpanda es compatible con la API de Kafka y Materialise puede procesar datos de la misma manera que procesaría datos de una fuente de Kafka.

Vamos a crear una vista materializada, que contendrá todos los pedidos pendientes de pago de gran volumen:

 CREATE MATERIALIZED VIEW high_value_orders AS
      SELECT
        users.id,
        users.email,
        abandoned_orders.revenue,
        abandoned_orders.total
      FROM users
      JOIN abandoned_orders ON abandoned_orders.user_id = users.id
      GROUP BY 1,2,3,4
      HAVING revenue > 2000;

Como puede ver, aquí estamos uniendo la usersvista que ingiere los datos directamente desde nuestra fuente de Postgres y la abandond_ordersvista que ingiere los datos del tema de Redpanda, juntos.

Vamos a crear un Sumidero donde enviaremos los datos de la vista materializada anterior:

CREATE SINK high_value_orders_sink
    FROM high_value_orders
    INTO KAFKA BROKER 'redpanda:9092' TOPIC 'high-value-orders-sink'
    FORMAT AVRO USING
    CONFLUENT SCHEMA REGISTRY 'http://redpanda:8081';

Ahora, si se conectara al contenedor de Redpanda y usara el rpk topic consumecomando, podrá leer los registros del tema.

Sin embargo, por el momento, no podremos obtener una vista previa de los resultados rpkporque tiene formato AVRO. Lo más probable es que Redpanda implemente esto en el futuro, pero por el momento, podemos transmitir el tema nuevamente a Materialise para confirmar el formato.

Primero, obtenga el nombre del tema que se ha generado automáticamente:

SELECT topic FROM mz_kafka_sinks;

Producción:

                              topic
-----------------------------------------------------------------
 high-volume-orders-sink-u12-1637586945-13670686352905873426

Para obtener más información sobre cómo se generan los nombres de los temas, consulte la documentación aquí .

Luego crea una nueva fuente materializada a partir de este tema de Redpanda:

CREATE MATERIALIZED SOURCE high_volume_orders_test
FROM KAFKA BROKER 'redpanda:9092' TOPIC ' high-volume-orders-sink-u12-1637586945-13670686352905873426'
FORMAT AVRO USING CONFLUENT SCHEMA REGISTRY 'http://redpanda:8081';

¡Asegúrate de cambiar el nombre del tema en consecuencia!

Finalmente, consulta esta nueva vista materializada:

SELECT * FROM high_volume_orders_test LIMIT 2;

Ahora que tiene los datos en el tema, puede hacer que otros servicios se conecten a ellos y los consuman y luego activen correos electrónicos o alertas, por ejemplo.

Cómo conectar la metabase

Para acceder a la instancia de Metabasehttp://localhost:3030 , visite si está ejecutando la demostración localmente o http://your_server_ip:3030si está ejecutando la demostración en un servidor. Luego siga los pasos para completar la configuración de Metabase.

Asegúrese de seleccionar Materialise como la fuente de los datos.

Una vez que esté listo, podrá visualizar sus datos tal como lo haría con una base de datos PostgreSQL estándar.

Cómo detener la demostración

Para detener todos los servicios, ejecute el siguiente comando:

docker-compose down

Conclusión

Como puede ver, este es un ejemplo muy simple de cómo usar Materialise. Puede usar Materialise para ingerir datos de una variedad de fuentes y luego transmitirlos a una variedad de destinos.

Fuente: https://www.freecodecamp.org/news/how-to-join-mysql-and-postgres-in-a-live-materialized-view/

#mysql #postgre

What is GEEK

Buddha Community

Cómo Unir MySQL Y Postgres En Una Vista Materializada En Vivo
Saul  Alaniz

Saul Alaniz

1651824660

Cómo Unir MySQL Y Postgres En Una Vista Materializada En Vivo

Cuando trabaja en un proyecto que consta de muchos microservicios, es probable que también incluya varias bases de datos.

Por ejemplo, puede tener una base de datos MySQL y una base de datos PostgreSQL , ambas ejecutándose en servidores separados.

Por lo general, para unir los datos de las dos bases de datos, tendría que introducir un nuevo microservicio que uniría los datos. Pero esto aumentaría la complejidad del sistema.

En este tutorial, usaremos Materialise para unir MySQL y Postgres en una vista materializada en vivo. Entonces podremos consultar eso directamente y obtener resultados de ambas bases de datos en tiempo real usando SQL estándar.

Materialise es una base de datos de transmisión disponible en la fuente escrita en Rust que mantiene los resultados de una consulta SQL (una vista materializada) en la memoria a medida que cambian los datos.

El tutorial incluye un proyecto de demostración que puede comenzar a usar docker-compose.

El proyecto de demostración que vamos a utilizar monitoreará los pedidos en nuestro sitio web simulado. Generará eventos que luego podrían usarse para enviar notificaciones cuando un carrito ha estado abandonado por mucho tiempo.

La arquitectura del proyecto de demostración es la siguiente:

mz-carrito-abandonado-demo

requisitos previos


Todos los servicios que usaremos en la demostración se ejecutarán dentro de los contenedores Docker, de esa manera no tendrá que instalar ningún servicio adicional en su computadora portátil o servidor en lugar de Docker y Docker Compose.

En caso de que no tenga Docker y Docker Compose ya instalados, puede seguir las instrucciones oficiales sobre cómo hacerlo aquí:

Visión de conjunto

Como se muestra en el diagrama anterior, tendremos los siguientes componentes:

  • Un servicio simulado para generar pedidos continuamente.
  • Los pedidos se almacenarán en una base de datos MySQL .
  • A medida que se producen las escrituras en la base de datos, Debezium transmite los cambios desde MySQL a un tema de Redpanda .
  • También tendremos una base de datos de Postgres donde podemos obtener nuestros usuarios.
  • Luego incorporaremos este tema de Redpanda en Materialise directamente junto con los usuarios de la base de datos de Postgres.
  • En Materialise uniremos nuestros pedidos y usuarios, filtraremos y crearemos una vista materializada que muestre la información del carrito abandonado.
  • Luego, crearemos un sumidero para enviar los datos del carrito abandonado a un nuevo tema de Redpanda.
  • Al final usaremos Metabase para visualizar los datos.
  • Más adelante, podría usar la información de ese nuevo tema para enviar notificaciones a sus usuarios y recordarles que tienen un carrito abandonado.

Como nota al margen aquí, estaría perfectamente bien usando Kafka en lugar de Redpanda. Simplemente me gusta la simplicidad que aporta Redpanda, ya que puede ejecutar una sola instancia de Redpanda en lugar de todos los componentes de Kafka.

Cómo ejecutar la demostración

Primero, comience clonando el repositorio:

git clone https://github.com/bobbyiliev/materialize-tutorials.git

Después de eso, puede acceder al directorio:

cd materialize-tutorials/mz-join-mysql-and-postgresql

Empecemos ejecutando primero el contenedor de Redpanda:

docker-compose up -d redpanda

Construye las imágenes:

docker-compose build

Finalmente, inicie todos los servicios:

docker-compose up -d

Para iniciar Materialise CLI, puede ejecutar el siguiente comando:

docker-compose run mzcli

Este es solo un acceso directo a un contenedor Docker con postgres-clientpreinstalado. Si ya lo has hecho, psqlpuedes ejecutarlo psql -U materialize -h localhost -p 6875 materializeen su lugar.

Cómo crear una fuente de Materialise Kafka

Ahora que está en Materialise CLI, definamos las orderstablas en la mysql.shopbase de datos como fuentes de Redpanda:

CREATE SOURCE orders
FROM KAFKA BROKER 'redpanda:9092' TOPIC 'mysql.shop.orders'
FORMAT AVRO USING CONFLUENT SCHEMA REGISTRY 'http://redpanda:8081'
ENVELOPE DEBEZIUM;

Si tuviera que verificar las columnas disponibles de la ordersfuente ejecutando la siguiente declaración:

SHOW COLUMNS FROM orders;

Podrá ver que, dado que Materialise extrae los datos del esquema del mensaje del registro de Redpanda, conoce los tipos de columna que se deben usar para cada atributo:

    name      | nullable |   type
--------------+----------+-----------
 id           | f        | bigint
 user_id      | t        | bigint
 order_status | t        | integer
 price        | t        | numeric
 created_at   | f        | text
 updated_at   | t        | timestamp

Cómo crear vistas materializadas

A continuación, crearemos nuestra primera vista materializada para obtener todos los datos de la ordersfuente de Redpanda:

CREATE MATERIALIZED VIEW orders_view AS
SELECT * FROM orders;
CREATE MATERIALIZED VIEW abandoned_orders AS
    SELECT
        user_id,
        order_status,
        SUM(price) as revenue,
        COUNT(id) AS total
    FROM orders_view
    WHERE order_status=0
    GROUP BY 1,2;

Ahora puede usar SELECT * FROM abandoned_orders;para ver los resultados:

SELECT * FROM abandoned_orders;

Para obtener más información sobre la creación de vistas materializadas, consulte la sección Vistas materializadas de la documentación de Materialise.

Cómo crear una fuente de Postgres

Hay dos formas de crear una fuente de Postgres en Materialise:

  • Usando Debezium tal como lo hicimos con la fuente MySQL.
  • Usando Postgres Materialise Source, que le permite conectar Materialise directamente a Postgres para que no tenga que usar Debezium.

Para esta demostración, usaremos Postgres Materialise Source solo como una demostración de cómo usarlo, pero siéntase libre de usar Debezium en su lugar.

Para crear una fuente Materialise de Postgres, ejecute la siguiente instrucción:

CREATE MATERIALIZED SOURCE "mz_source" FROM POSTGRES
CONNECTION 'user=postgres port=5432 host=postgres dbname=postgres password=postgres'
PUBLICATION 'mz_source';

Un resumen rápido de la declaración anterior:

  • MATERIALIZED: Materializa los datos de la fuente de PostgreSQL. Todos los datos se retienen en la memoria y hace que las fuentes se puedan seleccionar directamente.
  • mz_source: El nombre de la fuente de PostgreSQL.
  • CONNECTION: Los parámetros de conexión de PostgreSQL.
  • PUBLICATION: La publicación de PostgreSQL, que contiene las tablas que se transmitirán a Materialise.

Una vez que hayamos creado la fuente de PostgreSQL, para poder consultar las tablas de PostgreSQL, necesitaríamos crear vistas que representen las tablas originales de la publicación ascendente.

En nuestro caso, solo tenemos una tabla llamada, userspor lo que la declaración que necesitaríamos ejecutar es:

CREATE VIEWS FROM SOURCE mz_source (users);

Para ver las vistas disponibles ejecute la siguiente instrucción:

SHOW FULL VIEWS;

Una vez hecho esto, puede consultar las nuevas vistas directamente:

SELECT * FROM users;

A continuación, avancemos y creemos algunas vistas más.

Cómo crear un lavabo Kafka

Los sumideros le permiten enviar datos desde Materialise a una fuente externa.

Para esta demostración, usaremos Redpanda .

Redpanda es compatible con la API de Kafka y Materialise puede procesar datos de la misma manera que procesaría datos de una fuente de Kafka.

Vamos a crear una vista materializada, que contendrá todos los pedidos pendientes de pago de gran volumen:

 CREATE MATERIALIZED VIEW high_value_orders AS
      SELECT
        users.id,
        users.email,
        abandoned_orders.revenue,
        abandoned_orders.total
      FROM users
      JOIN abandoned_orders ON abandoned_orders.user_id = users.id
      GROUP BY 1,2,3,4
      HAVING revenue > 2000;

Como puede ver, aquí estamos uniendo la usersvista que ingiere los datos directamente desde nuestra fuente de Postgres y la abandond_ordersvista que ingiere los datos del tema de Redpanda, juntos.

Vamos a crear un Sumidero donde enviaremos los datos de la vista materializada anterior:

CREATE SINK high_value_orders_sink
    FROM high_value_orders
    INTO KAFKA BROKER 'redpanda:9092' TOPIC 'high-value-orders-sink'
    FORMAT AVRO USING
    CONFLUENT SCHEMA REGISTRY 'http://redpanda:8081';

Ahora, si se conectara al contenedor de Redpanda y usara el rpk topic consumecomando, podrá leer los registros del tema.

Sin embargo, por el momento, no podremos obtener una vista previa de los resultados rpkporque tiene formato AVRO. Lo más probable es que Redpanda implemente esto en el futuro, pero por el momento, podemos transmitir el tema nuevamente a Materialise para confirmar el formato.

Primero, obtenga el nombre del tema que se ha generado automáticamente:

SELECT topic FROM mz_kafka_sinks;

Producción:

                              topic
-----------------------------------------------------------------
 high-volume-orders-sink-u12-1637586945-13670686352905873426

Para obtener más información sobre cómo se generan los nombres de los temas, consulte la documentación aquí .

Luego crea una nueva fuente materializada a partir de este tema de Redpanda:

CREATE MATERIALIZED SOURCE high_volume_orders_test
FROM KAFKA BROKER 'redpanda:9092' TOPIC ' high-volume-orders-sink-u12-1637586945-13670686352905873426'
FORMAT AVRO USING CONFLUENT SCHEMA REGISTRY 'http://redpanda:8081';

¡Asegúrate de cambiar el nombre del tema en consecuencia!

Finalmente, consulta esta nueva vista materializada:

SELECT * FROM high_volume_orders_test LIMIT 2;

Ahora que tiene los datos en el tema, puede hacer que otros servicios se conecten a ellos y los consuman y luego activen correos electrónicos o alertas, por ejemplo.

Cómo conectar la metabase

Para acceder a la instancia de Metabasehttp://localhost:3030 , visite si está ejecutando la demostración localmente o http://your_server_ip:3030si está ejecutando la demostración en un servidor. Luego siga los pasos para completar la configuración de Metabase.

Asegúrese de seleccionar Materialise como la fuente de los datos.

Una vez que esté listo, podrá visualizar sus datos tal como lo haría con una base de datos PostgreSQL estándar.

Cómo detener la demostración

Para detener todos los servicios, ejecute el siguiente comando:

docker-compose down

Conclusión

Como puede ver, este es un ejemplo muy simple de cómo usar Materialise. Puede usar Materialise para ingerir datos de una variedad de fuentes y luego transmitirlos a una variedad de destinos.

Fuente: https://www.freecodecamp.org/news/how-to-join-mysql-and-postgres-in-a-live-materialized-view/

#mysql #postgre

Joe  Hoppe

Joe Hoppe

1595905879

Best MySQL DigitalOcean Performance – ScaleGrid vs. DigitalOcean Managed Databases

HTML to Markdown

MySQL is the all-time number one open source database in the world, and a staple in RDBMS space. DigitalOcean is quickly building its reputation as the developers cloud by providing an affordable, flexible and easy to use cloud platform for developers to work with. MySQL on DigitalOcean is a natural fit, but what’s the best way to deploy your cloud database? In this post, we are going to compare the top two providers, DigitalOcean Managed Databases for MySQL vs. ScaleGrid MySQL hosting on DigitalOcean.

At a glance – TLDR
ScaleGrid Blog - At a glance overview - 1st pointCompare Throughput
ScaleGrid averages almost 40% higher throughput over DigitalOcean for MySQL, with up to 46% higher throughput in write-intensive workloads. Read now

ScaleGrid Blog - At a glance overview - 2nd pointCompare Latency
On average, ScaleGrid achieves almost 30% lower latency over DigitalOcean for the same deployment configurations. Read now

ScaleGrid Blog - At a glance overview - 3rd pointCompare Pricing
ScaleGrid provides 30% more storage on average vs. DigitalOcean for MySQL at the same affordable price. Read now

MySQL DigitalOcean Performance Benchmark
In this benchmark, we compare equivalent plan sizes between ScaleGrid MySQL on DigitalOcean and DigitalOcean Managed Databases for MySQL. We are going to use a common, popular plan size using the below configurations for this performance benchmark:

Comparison Overview
ScaleGridDigitalOceanInstance TypeMedium: 4 vCPUsMedium: 4 vCPUsMySQL Version8.0.208.0.20RAM8GB8GBSSD140GB115GBDeployment TypeStandaloneStandaloneRegionSF03SF03SupportIncludedBusiness-level support included with account sizes over $500/monthMonthly Price$120$120

As you can see above, ScaleGrid and DigitalOcean offer the same plan configurations across this plan size, apart from SSD where ScaleGrid provides over 20% more storage for the same price.

To ensure the most accurate results in our performance tests, we run the benchmark four times for each comparison to find the average performance across throughput and latency over read-intensive workloads, balanced workloads, and write-intensive workloads.

Throughput
In this benchmark, we measure MySQL throughput in terms of queries per second (QPS) to measure our query efficiency. To quickly summarize the results, we display read-intensive, write-intensive and balanced workload averages below for 150 threads for ScaleGrid vs. DigitalOcean MySQL:

ScaleGrid MySQL vs DigitalOcean Managed Databases - Throughput Performance Graph

For the common 150 thread comparison, ScaleGrid averages almost 40% higher throughput over DigitalOcean for MySQL, with up to 46% higher throughput in write-intensive workloads.

#cloud #database #developer #digital ocean #mysql #performance #scalegrid #95th percentile latency #balanced workloads #developers cloud #digitalocean droplet #digitalocean managed databases #digitalocean performance #digitalocean pricing #higher throughput #latency benchmark #lower latency #mysql benchmark setup #mysql client threads #mysql configuration #mysql digitalocean #mysql latency #mysql on digitalocean #mysql throughput #performance benchmark #queries per second #read-intensive #scalegrid mysql #scalegrid vs. digitalocean #throughput benchmark #write-intensive

Loma  Baumbach

Loma Baumbach

1595781840

Exploring MySQL Binlog Server - Ripple

MySQL does not limit the number of slaves that you can connect to the master server in a replication topology. However, as the number of slaves increases, they will have a toll on the master resources because the binary logs will need to be served to different slaves working at different speeds. If the data churn on the master is high, the serving of binary logs alone could saturate the network interface of the master.

A classic solution for this problem is to deploy a binlog server – an intermediate proxy server that sits between the master and its slaves. The binlog server is set up as a slave to the master, and in turn, acts as a master to the original set of slaves. It receives binary log events from the master, does not apply these events, but serves them to all the other slaves. This way, the load on the master is tremendously reduced, and at the same time, the binlog server serves the binlogs more efficiently to slaves since it does not have to do any other database server processing.

MySQL Binlog Server Deployment Diagram - ScaleGrid Blog

Ripple is an open source binlog server developed by Pavel Ivanov. A blog post from Percona, titled MySQL Ripple: The First Impression of a MySQL Binlog Server, gives a very good introduction to deploying and using Ripple. I had an opportunity to explore Ripple in some more detail and wanted to share my observations through this post.

1. Support for GTID based replication

Ripple supports only GTID mode, and not file and position-based replication. If your master is running in non-GTID mode, you will get this error from Ripple:

Failed to read packet: Got error reading packet from server: The replication sender thread cannot start in AUTO_POSITION mode: this server has GTID_MODE = OFF instead of ON.

You can specify Server_id and UUID for the ripple server using the cmd line options: -ripple_server_id and -ripple_server_uuid

Both are optional parameters, and if not specified, Ripple will use the default server_id=112211 and uuid will be auto generated.

2. Connecting to the master using replication user and password

While connecting to the master, you can specify the replication user and password using the command line options:

-ripple_master_user and -ripple_master_password

3. Connection endpoint for the Ripple server

You can use the command line options -ripple_server_ports and -ripple_server_address to specify the connection end points for the Ripple server. Ensure to specify the network accessible hostname or IP address of your Ripple server as the -rippple_server_address. Otherwise, by default, Ripple will bind to localhost and hence you will not be able to connect to it remotely.

4. Setting up slaves to the Ripple server

You can use the CHANGE MASTER TO command to connect your slaves to replicate from the Ripple server.

To ensure that Ripple can authenticate the password that you use to connect to it, you need to start Ripple by specifying the option -ripple_server_password_hash

For example, if you start the ripple server with the command:

rippled -ripple_datadir=./binlog_server -ripple_master_address= <master ip> -ripple_master_port=3306 -ripple_master_user=repl -ripple_master_password='password' -ripple_server_ports=15000 -ripple_server_address='172.31.23.201' -ripple_server_password_hash='EF8C75CB6E99A0732D2DE207DAEF65D555BDFB8E'

you can use the following CHANGE MASTER TO command to connect from the slave:

CHANGE MASTER TO master_host='172.31.23.201', master_port=15000, master_password=’XpKWeZRNH5#satCI’, master_user=’rep’

Note that the password hash specified for the Ripple server corresponds to the text password used in the CHANGE MASTER TO command. Currently, Ripple does not authenticate based on the usernames and accepts any non-empty username as long as the password matches.

Exploring MySQL Binlog Server - Ripple

CLICK TO TWEET

5. Ripple server management

It’s possible to monitor and manage the Ripple server using the MySQL protocol from any standard MySQL client. There are a limited set of commands that are supported which you can see directly in the source code on the mysql-ripple GitHub page.

Some of the useful commands are:

  • SELECT @@global.gtid_executed; – To see the GTID SET of the Ripple server based on its downloaded binary logs.
  • STOP SLAVE; – To disconnect the Ripple server from the master.
  • START SLAVE; – To connect the Ripple server to the master.

#cloud #database #developer #high availability #mysql #performance #binary logs #gtid replication #mysql binlog #mysql protocol #mysql ripple #mysql server #parallel threads #proxy server #replication topology #ripple server

Whitney  Durgan

Whitney Durgan

1620633311

Performance Differences Between Postgres and MySQL

In this article, we discuss what workload analysis and running queries can teach us about the performance differences in JSON, indexing, and concurrency.

Introduction

In the Arctype Community, we answer a lot of questions about database performance, especially between Postgres and MySQL. Performance is a vital yet complex task when managing a database. It can be affected by the configuration, the hardware, or even the design of the system. Interestingly, both PostgreSQL and MySQL are configured with compatibility and stability but depend on our database design’s hardware infrastructure.

Not all relational database management systems (RDBMS) are created equal. Although PostgreSQL (or Postgres) and MySQL share some similarities, they also have unique qualities that make one a better choice over the other in specific situations. We discussed a lot of these differences in a previous post. Still, in terms of performance, they have a lot of differences.

#mysql #postgres #postgres vs mysql

Whitney  Durgan

Whitney Durgan

1618911221

Setting MySQL Configuration Variables - MySQL 5.7 vs MySQL 8.0

In this article, we will explain the differences in managing the configuration variables between MySQL 5.7 and MySQL 8.0.

MySQL configuration variables are a set of server system variables used to configure the operation and behavior of the server. In this blog post, we will explain the differences in managing the configuration variables between MySQL 5.7 and MySQL 8.0.

We will explain three different ways for setting the configuration variables based on your use-case. Configuration variables that can be set at run-time are called Dynamic variables and those that need a MySQL server restart to take effect are called Non-Dynamic variables.

#mysql #mysql 5.7 #mysql server #mysql 8.0