Anne  de Morel

Anne de Morel

1656059891

La Différence Entre Le RedoLog et BinLog de MySQL

RedoLog

Nous savons que lorsque MySQL écrit des données, il peut ajouter des données ou localiser une donnée déjà existante à modifier.

Pour les lectures et écritures aléatoires à partir du disque, cela est lent et ne peut pas répondre au scénario d'opérations d'E/S élevées.

Pour améliorer l'efficacité d'écriture, nous pouvons d'abord écrire en mémoire, puis écrire sur le disque lorsqu'il est libre.

Mais cela crée un problème : les données en mémoire ne sont pas persistantes, donc s'il y a une coupure de courant, les données seront perdues ?

Pour résoudre le problème de perte de données, MySQL a introduit des journaux redo pour résoudre ce problème.

C'est ce qu'on appelle WAL (Write-Ahead Logging), une pratique courante pour améliorer l'efficacité des E/S par rapport aux bases de données non en mémoire.

Cela permet de s'appuyer sur la journalisation pour récupérer les données en cas de plantage, garantissant ainsi la persistance des données.

Journalisation par écriture anticipée

Un algorithme de journalisation efficace dans les bases de données. Pour les bases de données sans mémoire, les opérations d'E/S de disque constituent un goulot d'étranglement majeur dans l'efficacité de la base de données.

Avec la même quantité de données, un système de base de données utilisant la journalisation WAL n'a qu'environ la moitié des opérations d'écriture sur disque de la journalisation de restauration traditionnelle au moment de la validation des transactions, ce qui améliore considérablement l'efficacité des opérations d'E/S du disque de base de données, améliorant ainsi les performances de la base de données.

Avantages de WAL

  • Les lectures et les écritures peuvent être exécutées complètement simultanément sans se bloquer (mais les écritures ne sont toujours pas simultanées).
  • WAL a de meilleures performances dans la plupart des cas (car il n'est pas nécessaire d'écrire deux fichiers pour chaque écriture).
  • Le comportement des E/S de disque est plus prévisible.
  • Moins fsync()d'opérations sont utilisées, ce qui réduit les problèmes de fragilité du système.

Implémentation de RedoLog

Voyons comment MySQL le fait vraiment.

Lorsqu'un enregistrement doit être mis à jour, le moteur InnoDB écrit d' redo logabord l'enregistrement et met à jour la mémoire. Au moment approprié, par exemple lorsque le disque est libre, les données du redo logsont vidées sur le disque.

Dans le moteur InnoDB, redo logla taille est fixe, par exemple, il peut être configuré comme un ensemble de quatre fichiers, chacun d'une taille de 1 Go, de sorte qu'un total de 4 Go d'opérations peut être enregistré.

write posest l'emplacement actuel de l'enregistrement, se déplaçant au fur et à mesure de son écriture, checkpointmarque l'emplacement actuel à effacer et l'enregistrement est mis à jour dans le fichier de données avant d'être effacé.

Le checkpointmarque la position actuelle à effacer et l'enregistrement est mis à jour dans le fichier de données avant d'être effacé, se déplaçant à nouveau dans une direction pendant l'effacement.

Si write pos finit d'écrire le dernier fichier, il se déplacera vers ib-log-file-0et recommencera à écrire.

Si le write posrattrape le check point, le redo logest plein, vous ne pouvez donc pas effectuer de nouvelle mise à jour, vous devez vous arrêter et effacer certaines données et synchroniser les données sur le disque avant d' check pointavancer.

Comment afficher les paramètres de redo log ?

Chaque moteur de stockage InnoDB a au moins un groupe de fichiers de journalisation et chaque groupe de fichiers a au moins deux fichiers de journalisation, la valeur par défaut étant ib-log-file-0et ib-log-file-1.

show variables like '%innodb_log%';

journal de la corbeille

Le redo logest spécifique au moteur InnoDB et protège les données, mais comment les autres moteurs enregistrent-ils les données ?

Au niveau du serveur, MySQL a son propre journal, c'est-à-dire bin-log(un journal archivé). Vous devez regarder MySQL isolément. MySQL = Serveur + différents moteurs de stockage de données, pas dans son ensemble.

Binlog enregistre un journal binaire de toutes les modifications apportées à la structure de la table de la base de données MySQL et aux données de la table, mais pas les requêtes select et show. bin-logles journaux sont consignés en tant qu'événements et incluent le temps consommé par les instructions.

Les deux scénarios les plus importants pour activer la journalisation Binlog sont les suivants :

  • Réplication parent-enfant : activez la fonction Binlog dans la bibliothèque principale, afin que la bibliothèque principale puisse transmettre Binlog à la bibliothèque secondaire, et que la bibliothèque secondaire puisse obtenir Binlog et réaliser la récupération des données pour obtenir la cohérence des données primaire-secondaire.
  • Récupération de données : récupérez des données via des outils tels que mysqlbinlog.

Les fichiers bin-log sont consignés selon trois modes : statement, rowet mixed, le rowmode étant généralement utilisé.

Pourquoi y a-t-il deux journaux ?

MySQL n'avait pas de moteur InnoDB au début, le moteur fourni avec MySQL était MyISAM, mais MyISAM n'avait pas la capacité de gérer les données de récupération en cas de crash et les bin-logjournaux ne pouvaient être utilisés que pour l'archivage.

InnoDB a été ajouté en tant que plugin plus tard, il a donc implémenté son propre système de journalisation pour sécuriser les données et faire face à la récupération après un crash.

La différence entre le journal bin et le journal redo.

Ici, j'ai résumé cinq points principaux:

  • Le contenu est différent : redo logest un journal physique et le contenu est basé sur la Page sur disque, le bin-logcontenu est binaire et selon le paramètre binlog_format, peut être basé sur des instructions SQL, sur les données elles-mêmes, ou un mélange des deux.
  • Différents niveaux : redo logfonctionne avec InnoDB et le moteur, bin-logest situé au niveau du serveur MySQL et est disponible pour tous les moteurs.
  • Différentes formes de stockage sur disque : le journal redo écrit cycliquement, bin-logs'accumule, il peut donc être utilisé pour la récupération de données ou la synchronisation primaire-secondaire
  • Le moment de l'écriture est différent : bin-logsont écrits lorsqu'une transaction est généralement validée ou lorsque N transactions sont validées une fois, redo logsont écrits à différents moments, soit à chaque fois qu'une transaction est validée, par une autre transaction threadée, soit toutes les secondes lorsque le disque est vidé. ( Remarque : les transactions non validées dans redo logpeuvent également être vidées sur le disque)
  • Différents rôles : le journal redo est utilisé pour la récupération après un crash afin de s'assurer que le temps d'arrêt de MySQL n'affecte pas la persistance ; bin-logest utilisé pour la récupération à un moment donné afin de garantir que le serveur peut récupérer les données en fonction du moment dans le temps. bin-logIl est également utilisé pour la réplication primaire-secondaire.

Engagement en deux phases

Étant donné qu'il redo-logse trouve dans le niveau InnoDB et bin-logdans le niveau serveur, cela introduit un nouveau problème.

Si le fichier de journalisation est écrit avec succès et que le bin-logse bloque avant d'être écrit sur le disque, la transaction n'a pas encore été validée, de sorte que les nouvelles données écrites sur le redo-logne sont pas valides.

Le redémarrage de la base de données pour la récupération des données restaure les données sur le redo-logdisque, ce qui crée des données non valides.

Dans ce cas, comme vous le savez fort bien, un commit en deux phases est introduit.

Dans la première étape, le redo-logest écrit et à l'état préparé. Une fois que la couche serveur a enregistré les bin-logdonnées et les a déposées sur le disque, la transaction valide le redo-logen même temps, de sorte que le redo-logdevient validé, ce qui garantit la cohérence des redo-logdonnées et des bin-logdonnées.

L'exécution d'une déclaration de mise à jour

Avec les connaissances précédentes, vous pouvez maintenant explorer comment l' updateinstruction est exécutée dans MySQL.

Supposons que nous exécutons maintenant le SQL :update table_test set a = a+1 where id = 2;

  • Tout d'abord, le client se connecte via le connecteur et détermine les autorisations.
  • Après vérification, le SQL passe par l'analyseur pour l'analyse lexicale et syntaxique (AST) et s'il s'agit d'une instruction Update, MySQL effacera tout le cache de requête pour la table de requête table_test. (Comme vous pouvez le voir, il n'est pas recommandé d'activer le cache des requêtes)
  • L'optimiseur optimise le SQL validé, prévoit de faire correspondre l' idindex et génère un plan d'exécution.
  • L'exécuteur obtient le SQL final et appelle l'interface du moteur de stockage correspondant pour commencer à exécuter le updateSQL.
  • Le moteur InnoDB ouvre une transaction, le moteur d'exécution demande d'abord à partir de la mémoire s'il existe des données avec id=2, si elles correspondent alors aux données correspondantes avec field+1, puis les enregistre en mémoire. S'il n'interroge pas les données avec id=2, il ira sur le disque, la requête lira les données en mémoire dans les pages, puis les mettra à jour et les enregistrera en mémoire.
  • Le moteur InnoDB enregistrera ensuite les lignes de données dans redo-log, qui est pré-validé, notifiant à l'exécuteur du serveur qu'il est prêt à valider la transaction.
  • L'exécuteur générera le correspondant bin-loget l'écrira sur le disque.
  • La transaction est validée et le redo-logest ensuite validé.
  • C'est là que l'exécution d'une transaction est terminée.

 

Merci d'avoir lu cet article.

Restez à l'écoute pour plus.

Source : https://betterprogramming.pub/mysqls-redolog-and-binlog-1a35bc052489

#mysql 

What is GEEK

Buddha Community

La Différence Entre Le RedoLog et BinLog de MySQL
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

Anne  de Morel

Anne de Morel

1656059891

La Différence Entre Le RedoLog et BinLog de MySQL

RedoLog

Nous savons que lorsque MySQL écrit des données, il peut ajouter des données ou localiser une donnée déjà existante à modifier.

Pour les lectures et écritures aléatoires à partir du disque, cela est lent et ne peut pas répondre au scénario d'opérations d'E/S élevées.

Pour améliorer l'efficacité d'écriture, nous pouvons d'abord écrire en mémoire, puis écrire sur le disque lorsqu'il est libre.

Mais cela crée un problème : les données en mémoire ne sont pas persistantes, donc s'il y a une coupure de courant, les données seront perdues ?

Pour résoudre le problème de perte de données, MySQL a introduit des journaux redo pour résoudre ce problème.

C'est ce qu'on appelle WAL (Write-Ahead Logging), une pratique courante pour améliorer l'efficacité des E/S par rapport aux bases de données non en mémoire.

Cela permet de s'appuyer sur la journalisation pour récupérer les données en cas de plantage, garantissant ainsi la persistance des données.

Journalisation par écriture anticipée

Un algorithme de journalisation efficace dans les bases de données. Pour les bases de données sans mémoire, les opérations d'E/S de disque constituent un goulot d'étranglement majeur dans l'efficacité de la base de données.

Avec la même quantité de données, un système de base de données utilisant la journalisation WAL n'a qu'environ la moitié des opérations d'écriture sur disque de la journalisation de restauration traditionnelle au moment de la validation des transactions, ce qui améliore considérablement l'efficacité des opérations d'E/S du disque de base de données, améliorant ainsi les performances de la base de données.

Avantages de WAL

  • Les lectures et les écritures peuvent être exécutées complètement simultanément sans se bloquer (mais les écritures ne sont toujours pas simultanées).
  • WAL a de meilleures performances dans la plupart des cas (car il n'est pas nécessaire d'écrire deux fichiers pour chaque écriture).
  • Le comportement des E/S de disque est plus prévisible.
  • Moins fsync()d'opérations sont utilisées, ce qui réduit les problèmes de fragilité du système.

Implémentation de RedoLog

Voyons comment MySQL le fait vraiment.

Lorsqu'un enregistrement doit être mis à jour, le moteur InnoDB écrit d' redo logabord l'enregistrement et met à jour la mémoire. Au moment approprié, par exemple lorsque le disque est libre, les données du redo logsont vidées sur le disque.

Dans le moteur InnoDB, redo logla taille est fixe, par exemple, il peut être configuré comme un ensemble de quatre fichiers, chacun d'une taille de 1 Go, de sorte qu'un total de 4 Go d'opérations peut être enregistré.

write posest l'emplacement actuel de l'enregistrement, se déplaçant au fur et à mesure de son écriture, checkpointmarque l'emplacement actuel à effacer et l'enregistrement est mis à jour dans le fichier de données avant d'être effacé.

Le checkpointmarque la position actuelle à effacer et l'enregistrement est mis à jour dans le fichier de données avant d'être effacé, se déplaçant à nouveau dans une direction pendant l'effacement.

Si write pos finit d'écrire le dernier fichier, il se déplacera vers ib-log-file-0et recommencera à écrire.

Si le write posrattrape le check point, le redo logest plein, vous ne pouvez donc pas effectuer de nouvelle mise à jour, vous devez vous arrêter et effacer certaines données et synchroniser les données sur le disque avant d' check pointavancer.

Comment afficher les paramètres de redo log ?

Chaque moteur de stockage InnoDB a au moins un groupe de fichiers de journalisation et chaque groupe de fichiers a au moins deux fichiers de journalisation, la valeur par défaut étant ib-log-file-0et ib-log-file-1.

show variables like '%innodb_log%';

journal de la corbeille

Le redo logest spécifique au moteur InnoDB et protège les données, mais comment les autres moteurs enregistrent-ils les données ?

Au niveau du serveur, MySQL a son propre journal, c'est-à-dire bin-log(un journal archivé). Vous devez regarder MySQL isolément. MySQL = Serveur + différents moteurs de stockage de données, pas dans son ensemble.

Binlog enregistre un journal binaire de toutes les modifications apportées à la structure de la table de la base de données MySQL et aux données de la table, mais pas les requêtes select et show. bin-logles journaux sont consignés en tant qu'événements et incluent le temps consommé par les instructions.

Les deux scénarios les plus importants pour activer la journalisation Binlog sont les suivants :

  • Réplication parent-enfant : activez la fonction Binlog dans la bibliothèque principale, afin que la bibliothèque principale puisse transmettre Binlog à la bibliothèque secondaire, et que la bibliothèque secondaire puisse obtenir Binlog et réaliser la récupération des données pour obtenir la cohérence des données primaire-secondaire.
  • Récupération de données : récupérez des données via des outils tels que mysqlbinlog.

Les fichiers bin-log sont consignés selon trois modes : statement, rowet mixed, le rowmode étant généralement utilisé.

Pourquoi y a-t-il deux journaux ?

MySQL n'avait pas de moteur InnoDB au début, le moteur fourni avec MySQL était MyISAM, mais MyISAM n'avait pas la capacité de gérer les données de récupération en cas de crash et les bin-logjournaux ne pouvaient être utilisés que pour l'archivage.

InnoDB a été ajouté en tant que plugin plus tard, il a donc implémenté son propre système de journalisation pour sécuriser les données et faire face à la récupération après un crash.

La différence entre le journal bin et le journal redo.

Ici, j'ai résumé cinq points principaux:

  • Le contenu est différent : redo logest un journal physique et le contenu est basé sur la Page sur disque, le bin-logcontenu est binaire et selon le paramètre binlog_format, peut être basé sur des instructions SQL, sur les données elles-mêmes, ou un mélange des deux.
  • Différents niveaux : redo logfonctionne avec InnoDB et le moteur, bin-logest situé au niveau du serveur MySQL et est disponible pour tous les moteurs.
  • Différentes formes de stockage sur disque : le journal redo écrit cycliquement, bin-logs'accumule, il peut donc être utilisé pour la récupération de données ou la synchronisation primaire-secondaire
  • Le moment de l'écriture est différent : bin-logsont écrits lorsqu'une transaction est généralement validée ou lorsque N transactions sont validées une fois, redo logsont écrits à différents moments, soit à chaque fois qu'une transaction est validée, par une autre transaction threadée, soit toutes les secondes lorsque le disque est vidé. ( Remarque : les transactions non validées dans redo logpeuvent également être vidées sur le disque)
  • Différents rôles : le journal redo est utilisé pour la récupération après un crash afin de s'assurer que le temps d'arrêt de MySQL n'affecte pas la persistance ; bin-logest utilisé pour la récupération à un moment donné afin de garantir que le serveur peut récupérer les données en fonction du moment dans le temps. bin-logIl est également utilisé pour la réplication primaire-secondaire.

Engagement en deux phases

Étant donné qu'il redo-logse trouve dans le niveau InnoDB et bin-logdans le niveau serveur, cela introduit un nouveau problème.

Si le fichier de journalisation est écrit avec succès et que le bin-logse bloque avant d'être écrit sur le disque, la transaction n'a pas encore été validée, de sorte que les nouvelles données écrites sur le redo-logne sont pas valides.

Le redémarrage de la base de données pour la récupération des données restaure les données sur le redo-logdisque, ce qui crée des données non valides.

Dans ce cas, comme vous le savez fort bien, un commit en deux phases est introduit.

Dans la première étape, le redo-logest écrit et à l'état préparé. Une fois que la couche serveur a enregistré les bin-logdonnées et les a déposées sur le disque, la transaction valide le redo-logen même temps, de sorte que le redo-logdevient validé, ce qui garantit la cohérence des redo-logdonnées et des bin-logdonnées.

L'exécution d'une déclaration de mise à jour

Avec les connaissances précédentes, vous pouvez maintenant explorer comment l' updateinstruction est exécutée dans MySQL.

Supposons que nous exécutons maintenant le SQL :update table_test set a = a+1 where id = 2;

  • Tout d'abord, le client se connecte via le connecteur et détermine les autorisations.
  • Après vérification, le SQL passe par l'analyseur pour l'analyse lexicale et syntaxique (AST) et s'il s'agit d'une instruction Update, MySQL effacera tout le cache de requête pour la table de requête table_test. (Comme vous pouvez le voir, il n'est pas recommandé d'activer le cache des requêtes)
  • L'optimiseur optimise le SQL validé, prévoit de faire correspondre l' idindex et génère un plan d'exécution.
  • L'exécuteur obtient le SQL final et appelle l'interface du moteur de stockage correspondant pour commencer à exécuter le updateSQL.
  • Le moteur InnoDB ouvre une transaction, le moteur d'exécution demande d'abord à partir de la mémoire s'il existe des données avec id=2, si elles correspondent alors aux données correspondantes avec field+1, puis les enregistre en mémoire. S'il n'interroge pas les données avec id=2, il ira sur le disque, la requête lira les données en mémoire dans les pages, puis les mettra à jour et les enregistrera en mémoire.
  • Le moteur InnoDB enregistrera ensuite les lignes de données dans redo-log, qui est pré-validé, notifiant à l'exécuteur du serveur qu'il est prêt à valider la transaction.
  • L'exécuteur générera le correspondant bin-loget l'écrira sur le disque.
  • La transaction est validée et le redo-logest ensuite validé.
  • C'est là que l'exécution d'une transaction est terminée.

 

Merci d'avoir lu cet article.

Restez à l'écoute pour plus.

Source : https://betterprogramming.pub/mysqls-redolog-and-binlog-1a35bc052489

#mysql 

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

joe biden

1617255938

¿Cómo migrar los buzones de correo de Exchange a la nube de Office 365?

Si tiene problemas para migrar los buzones de correo de Exchange a Office 365, debe leer este artículo para saber cómo migrar los buzones de correo de Exchange EDB a Office 365. Al migrar a Office 365, los usuarios pueden acceder a sus buzones de correo desde cualquier lugar y desde cualquier dispositivo.

En esta publicación, explicaremos las razones detrás de esta migración y una solución profesional para migrar de Exchange a Office 365.

Razones para migrar Exchange Server a la nube de Office 365

Office 365 apareció por primera vez en 2011 y, dado que se considera la mejor plataforma para aquellas organizaciones que desean administrar todo su sistema de correo electrónico en la nube. Estas son las características clave de Office 365:

  1. Permite trabajar desde cualquier lugar y desde cualquier lugar.
  2. No se preocupe por el spam y el malware.
  3. La seguridad proporcionada por Office 365 es altamente confiable.
  4. Controla el costo total y brinda flexibilidad financiera.
  5. Todas las actualizaciones y mejoras son administradas por Microsoft.

¿Cómo migrar los buzones de correo de Exchange a Office 365?

Hay varias formas manuales de migrar los buzones de correo de Exchange EDB a Office 365, pero para evitar estos complicados y prolongados procedimientos, presentamos una solución de terceros, es decir, la herramienta de migración de Exchange, que es automatizada y directa para la migración de Exchange a Office 365. La herramienta funciona rápidamente y migra todos los elementos del buzón de Exchange Server a Office 365.

La herramienta de migración de Datavare Exchange es demasiado fácil de usar y ofrece pasos sencillos para migrar EDB a Office 365:

  1. Descargue e instale el software en su sistema.
  2. Agregue el archivo EDB de Exchange con el botón Examinar.
  3. Seleccione exportar a buzones de correo de Office 365.
  4. Proporcione los detalles de inicio de sesión de la cuenta de Office 365.
  5. Seleccione la carpeta y presione el botón Finalizar.

Por lo tanto, todos sus buzones de correo de Exchange EDB ahora se migran a Office 365.
Nota: puede usar filtros para migrar los elementos de datos deseados de la cuenta de Exchange a la de Office 365

Líneas finales

Este blog le indica una solución profesional para la migración de buzones de correo de Exchange a la cuenta de Office 365. Dado que las soluciones manuales son complicadas, sugerimos la herramienta de migración de Exchange, que es demasiado simple de usar. Los usuarios no se enfrentan a problemas al operar el programa. La mejor parte de este software es que no necesita habilidades técnicas para realizar la migración. Se puede comprender el funcionamiento del software descargando la versión de demostración que permite la migración de los primeros 50 elementos por carpeta.

Más información:- https://www.datavare.com/software/edb-migration.html

#herramienta de migración de intercambio #migración de intercambio #migrar buzones de correo de exchange

Devyn  Reilly

Devyn Reilly

1618900707

Setting MySQL Configuration Variables – MySQL 5.7 vs 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.

Setting MySQL Configuration Variables

#mysql #mysql 5.7 #mysql 8.0 #mysql server