The document discusses two scenarios for performing point-in-time recovery on a Galera cluster after a node truncates a production table. Scenario 1 involves stopping the application, restoring from backup, replaying binary logs up until the truncate event, and restarting nodes. Scenario 2 maintains application uptime by removing the problematic node, restoring its data, and reintegrating it while masking the truncate from other nodes. The document also provides tips for optimizing XtraBackup state snapshot transfers and migrating an asynchronous slave to a new master node.
Advanced percona xtra db cluster in a nutshell... la suite plsc2016Frederic Descamps
This is a tutorial I gave with my colleague Kenny Gryp at Percona Live 2016 in Santa Clara
Percona XtraDB Cluster is a high availability and high scalability solution for MySQL clustering. Percona XtraDB Cluster integrates Percona Server with the Galera synchronous replication library in a single product package, which enables you to create a cost-effective MySQL cluster.
For three years at Percona Live, we've introduced people to this technology... but what's next? This tutorial continues your education, and targets users that already have experience with Percona XtraDB Cluster and want to go further.
This tutorial will cover the following topics:
- Bootstrapping in details
- certification errors, understanding and preventing them
- Replication failures, how to deal with them
- Secrets of Galera Cache
- Mastering flow control
- Understanding and verifying replication throughput
- How to use WAN replication
- Implications of consistent reads
- Backups
- Load balancers and proxy protocol
Percona XtraDB Cluster is a high availability and high scalability solution for MySQL clustering. Percona XtraDB Cluster integrates Percona Server with the Galera synchronous replication library in a single product package which enables you to create a cost-effective MySQL cluster.
This tutorial will cover the following topics:
- Migration from standard MySQL Master-Slave Architecture to PXC
- Configuration differences between standard MySQLl and Xtradb Cluster
- How to add a node and what does SST, IST mean ? How to use them ?
- How to backup the cluster
- How to monitor the cluster
- 2 nodes servers- Why this isn't ideal but reasons and steps to setting it up anyway.
- Galera Arbitrator: Defining what it is.
- How to maintain the cluster
- Setting up load balancing for Xtradb cluster
- How to handle the cluster in the cloud
- Tips and tricks
- ... and if available cover PXC 5.6 with Galera 3 !!
Advanced Percona XtraDB Cluster in a nutshell... la suiteKenny Gryp
Percona XtraDB Cluster is a high availability and high scalability solution for MySQL clustering. Percona XtraDB Cluster integrates Percona Server with the Galera synchronous replication library in a single product package which enables you to create a cost-effective MySQL cluster.
Since three years during Percona Live we initiate people to this technology... but what's next ? This tutorial is the continuation. It targets users that already have experience with PXC and want to go further.
This tutorial will cover the following topics:
- monitoring and trending
- problem solving
- limitations, when not to choose for PXC
- how to test ? (benchmark)
- schema changes
- backups
- multi datacenter
- advanced load balancing with HA Pproxy and Maxscale
- fine tune some important variables like galera cache, flow control limit, ...
We always say Galera replication is synchronous, but is it really? Always? For every step? What are the caveats of such replication? What does virtual-synchronous mean?
In this talk, I'll discuss what certification and group communication are, and how they're performed. I'll also cover the difference between MySQL 5.6 GTID and Galera GTID. The goal of this presentation is to explain how a transaction is replicated using Galera.
After this presentation, the audience should be comfortable with terms like "brute force abort," "flow control," "local certification failure," etc.
The plan is to demystify Galera technology with easy illustrations and analogies.
Advanced percona xtra db cluster in a nutshell... la suite plsc2016Frederic Descamps
This is a tutorial I gave with my colleague Kenny Gryp at Percona Live 2016 in Santa Clara
Percona XtraDB Cluster is a high availability and high scalability solution for MySQL clustering. Percona XtraDB Cluster integrates Percona Server with the Galera synchronous replication library in a single product package, which enables you to create a cost-effective MySQL cluster.
For three years at Percona Live, we've introduced people to this technology... but what's next? This tutorial continues your education, and targets users that already have experience with Percona XtraDB Cluster and want to go further.
This tutorial will cover the following topics:
- Bootstrapping in details
- certification errors, understanding and preventing them
- Replication failures, how to deal with them
- Secrets of Galera Cache
- Mastering flow control
- Understanding and verifying replication throughput
- How to use WAN replication
- Implications of consistent reads
- Backups
- Load balancers and proxy protocol
Percona XtraDB Cluster is a high availability and high scalability solution for MySQL clustering. Percona XtraDB Cluster integrates Percona Server with the Galera synchronous replication library in a single product package which enables you to create a cost-effective MySQL cluster.
This tutorial will cover the following topics:
- Migration from standard MySQL Master-Slave Architecture to PXC
- Configuration differences between standard MySQLl and Xtradb Cluster
- How to add a node and what does SST, IST mean ? How to use them ?
- How to backup the cluster
- How to monitor the cluster
- 2 nodes servers- Why this isn't ideal but reasons and steps to setting it up anyway.
- Galera Arbitrator: Defining what it is.
- How to maintain the cluster
- Setting up load balancing for Xtradb cluster
- How to handle the cluster in the cloud
- Tips and tricks
- ... and if available cover PXC 5.6 with Galera 3 !!
Advanced Percona XtraDB Cluster in a nutshell... la suiteKenny Gryp
Percona XtraDB Cluster is a high availability and high scalability solution for MySQL clustering. Percona XtraDB Cluster integrates Percona Server with the Galera synchronous replication library in a single product package which enables you to create a cost-effective MySQL cluster.
Since three years during Percona Live we initiate people to this technology... but what's next ? This tutorial is the continuation. It targets users that already have experience with PXC and want to go further.
This tutorial will cover the following topics:
- monitoring and trending
- problem solving
- limitations, when not to choose for PXC
- how to test ? (benchmark)
- schema changes
- backups
- multi datacenter
- advanced load balancing with HA Pproxy and Maxscale
- fine tune some important variables like galera cache, flow control limit, ...
We always say Galera replication is synchronous, but is it really? Always? For every step? What are the caveats of such replication? What does virtual-synchronous mean?
In this talk, I'll discuss what certification and group communication are, and how they're performed. I'll also cover the difference between MySQL 5.6 GTID and Galera GTID. The goal of this presentation is to explain how a transaction is replicated using Galera.
After this presentation, the audience should be comfortable with terms like "brute force abort," "flow control," "local certification failure," etc.
The plan is to demystify Galera technology with easy illustrations and analogies.
Slides for the webinar held on January 21st 2014
Repair & Recovery for your MySQL, MariaDB & MongoDB / TokuMX Clusters
Galera Cluster, NDB Cluster, VIP with HAProxy and Keepalived, MongoDB Sharded Cluster, etc. all have their own availability models. We are aware of these availability models and will demonstrate in this webinar how to take corrective action in case of failures via our cluster management tool, ClusterControl.
In this webinar, Severalnines CTO Johan Andersson will show you how to leverage ClusterControl to detect failures in your database cluster and automatically repair them to maximize the availability of your database services. And Codership CEO Seppo Jaakola will be joining Johan to provide a deep-dive into Galera recovery internals.
Agenda:
Redundancy models for Galera, NDB and MongoDB/TokuMX
Failover & Recovery (Automatic vs Manual)
Zooming into Galera recovery procedures
Split brains in multi-datacenter setups
Webinar slides: Introducing Galera 3.0 - Now supporting MySQL 5.6Severalnines
You'll learn how Galera integrates with MySQL 5.6 and Global Transaction IDs to enable cross-datacenter and cloud replication over high latency networks. The benefits are clear; a globally distributed MySQL setup across regions to deliver Severalnines availability and real-time responsiveness.
Galera Cluster for MySQL is a true multi-master MySQL replication plugin, and has been proven in mission-critical infrastructures of companies like Ping Identity, AVG Technologies, KPN and HP Cloud DNS. In this webcast you¹ll learn about the following Galera Cluster capabilities, including the latest innovations in the new 3.0 release:
Galera Cluster features and benefits
Support for MySQL 5.6
Integration with MySQL Global Transaction Identifiers
Mixing Galera synchronous replication and asynchronous MySQL replication
Deploying in WAN and Cloud environments
Handling high-latency networks
Management of Galera
Built-in MySQL Replication is known for its capability to enable to scale reads easily. However, there are some limitations and known issues with this solution because of the asynchronous nature of this replication. This talk will describe another way of doing MySQL replication, by using synchronous replication, available in Percona XtraDB Cluster. The open source solution will be explained and compared to traditional asynchronous MySQL replication, as well as some known use cases will be described. Percona XtraDB Cluster is an, open source, high availability and high scalability solution for MySQL clustering. Features include: Synchronous replication, Multi-master replication support, Parallel replication, Automatic node provisioning.
Repair & Recovery for your MySQL, MariaDB & MongoDB / TokuMX Clusters - Webin...Severalnines
Slides for the webinar held on January 21st 2014
Repair & Recovery for your MySQL, MariaDB & MongoDB / TokuMX Clusters
Galera Cluster, NDB Cluster, VIP with HAProxy and Keepalived, MongoDB Sharded Cluster, etc. all have their own availability models. We are aware of these availability models and will demonstrate in this webinar how to take corrective action in case of failures via our cluster management tool, ClusterControl.
In this webinar, Severalnines CTO Johan Andersson will show you how to leverage ClusterControl to detect failures in your database cluster and automatically repair them to maximize the availability of your database services. And Codership CEO Seppo Jaakola will be joining Johan to provide a deep-dive into Galera recovery internals.
Agenda:
Redundancy models for Galera, NDB and MongoDB/TokuMX
Failover & Recovery (Automatic vs Manual)
Zooming into Galera recovery procedures
Split brains in multi-datacenter setups
Topics covered in this presentation:
1. The difference between traditional (e.g. MySQL) replication and Galera Cluster
2. General Galera Cluster principles
Galera cluster for MySQL - Introduction SlidesSeveralnines
This set of slides gives you an overview of Galera, configuration basics and deployment best practices.
The following topics are covered:
- Concepts
- Node provisioning
- Network partitioning
- Configuration example
- Benchmarks
- Deployment best practices
- Galera monitoring and management
In the first part of Galera Cluster best practices series, we will discuss the following topics:
* ongoing monitoring of the cluster and detection of bottlenecks;
* fine-tuning the configuration based on the actual database workload;
* selecting the optimal State Snapshot Transfer (SST) method;
* backup strategies
(video:http://galeracluster.com/videos/2159/)
Topics covered in this presentation, which was used for user group meetings, conferences & webinars:
1. Galera Cluster for MySQL - overview
2. Release 3 New Features:
* WAN Replication
* 5.6 Global Transaction ID (GTID) Support
* MySQL Replication Support
* and more features
3. The Galera Cluster Project
Upgrading MySQL databases do not come without risk. There is no guarantee that no problems will happen if you move to a new major MySQL version.
Should we just upgrade and rollback immediately if problems occur? But what if these problems only happen a few days after migrating to this new version?
You might have a database environment that is risk-adverse, where you really have to be sure that this new MySQL version will handle the workload properly.
Examples:
- Both MySQL 5.6 and 5.7 have a lot of changes in the MySQL Optimizer. It is expected that this improves performance of my queries, but is it really the case? What if there is a performance regression? How will this affect my database performance?
- Also, there are a lot of incompatible changes which are documented in the release notes, how do I know if I'm affected by this in my workload? It's a lot to read..
- Can I go immediately from MySQL 5.5 to 5.7 and skip MySQL 5.6 even though the MySQL documentation states that this is not supported?
- Many companies have staging environments, but is there a QA team and do they really test all functionality, under a similar workload?
This presentation will show you a process, using open source tools, of these types of migrations with a focus on assessing risk and fixing any problems you might run into prior to the migration.
This process can then be used for various changes:
- MySQL upgrades for major version upgrades
- Switching storage engines
- Changing hardware architecture
Additionally, we will describe ways to do the actual migration and rollback with the least amount of downtime.
Galera is slowly but surely establishing itself as a credible replacement for traditional MySQL master-slave architectures.
The benefits are clear - a true multi-master InnoDB setup with built-in fail-over, potentially across data centers.
But how do you migrate? Does the schema or application change? What are the limitations? Can migration be done online, without service interruption? What are the potential risks, and how to address those?
AGENDA
Application use cases for Galera
Schema design
Events and Triggers
Query design
Migrating the schema
Loading initial data into the cluster
Limitations
Performing Online Migration to Galera
Operational management checklist
Belts and suspenders: Plan B
Demo
2014 OSDC Talk: Introduction to Percona XtraDB Cluster and HAProxyBo-Yi Wu
Introduction to Percona XtraDB Cluster and HAProxy in 2014 OSDC talk.
Blog: http://blog.wu-boy.com/2014/04/osdc-2014-talk-introduction-to-percona-xtradb-cluster-and-haproxy/
OSDC: http://osdc.tw/program/2014-day2-10.html#content
From these slides you'll learn how Galera integrates with MySQL 5.6 and Global Transaction IDs to enable cross-datacenter and cloud replication over high latency networks.
ABOUT GALERA CLUSTER
Galera Cluster for MySQL is a true multi-master MySQL replication plugin, and has been proven in mission-critical infrastructures of companies like Ping Identity, AVG Technologies, KPN and HP Cloud DNS. In this webcast you¹ll learn about the following Galera Cluster capabilities, including the latest innovations in the new 3.0 release:
Galera Cluster features and benefits
Support for MySQL 5.6
Integration with MySQL Global Transaction Identifiers
Mixing Galera synchronous replication and asynchronous MySQL replication
Deploying in WAN and Cloud environments
Handling high-latency networks
Management of Galera
Percona XtraDB Cluster vs Galera Cluster vs MySQL Group ReplicationKenny Gryp
What are the implementation differences between Percona XtraDB Cluster 5.7, Galera Cluster 5.7 and MySQL Group Replication?
- How do each of these work?
- How do they behave differently?
- Are there any major issues with any of these?
This talk will describe these differences and also shed some light on how QA is done for each of these different technologies.
Slides used for the webinar: Introducing Galera 3.0 - Now supporting MySQL 5.6, Global Transaction IDs & WAN.
These slides covered the section: Galera Monitoring & Management
Setting up and maintaining a database cluster can be tricky. ClusterControl gives you the power to deploy, manage, monitor and scale entire clusters efficiently and reliably. ClusterControl supports a variety of SQL and NoSQL cluster topologies, as well as SQL load balancing via HAProxy.
Galera Cluster for MySQL is a true multi-master MySQL replication plugin, and has been proven in mission-critical infrastructures of companies like Ping Identity, AVG Technologies, KPN and HP Cloud DNS. In this webcast you¹ll learn about the following Galera Cluster capabilities, including the latest innovations in the new 3.0 release:
Galera Cluster features and benefits
Support for MySQL 5.6
Integration with MySQL Global Transaction Identifiers
Mixing Galera synchronous replication and asynchronous MySQL replication
Deploying in WAN and Cloud environments
Handling high-latency networks
Management of Galera
Not Less, Not More: Exactly Once, Large-Scale Stream Processing in ActionParis Carbone
Large-scale data stream processing has come a long way to where it is today. It combines all the essential requirements of modern data analytics: subsecond latency, high throughput and impressively, strong consistency. Apache Flink is a system that serves as a proof-of-concept of these characteristics and it is mainly well-known for its lightweight fault tolerance. Data engineers and analysts can now let the system handle Terabytes of computational state without worrying about failures that can potentially occur.
This presentation describes all the fundamental challenges behind exactly-once processing guarantees in large-scale streaming in a simple and intuitive way. Furthermore, it demonstrate the basic and extended versions of Flink's state-of-the-art snapshotting algorithm tailored to the needs of a dataflow graph.
Slides for the webinar held on January 21st 2014
Repair & Recovery for your MySQL, MariaDB & MongoDB / TokuMX Clusters
Galera Cluster, NDB Cluster, VIP with HAProxy and Keepalived, MongoDB Sharded Cluster, etc. all have their own availability models. We are aware of these availability models and will demonstrate in this webinar how to take corrective action in case of failures via our cluster management tool, ClusterControl.
In this webinar, Severalnines CTO Johan Andersson will show you how to leverage ClusterControl to detect failures in your database cluster and automatically repair them to maximize the availability of your database services. And Codership CEO Seppo Jaakola will be joining Johan to provide a deep-dive into Galera recovery internals.
Agenda:
Redundancy models for Galera, NDB and MongoDB/TokuMX
Failover & Recovery (Automatic vs Manual)
Zooming into Galera recovery procedures
Split brains in multi-datacenter setups
Webinar slides: Introducing Galera 3.0 - Now supporting MySQL 5.6Severalnines
You'll learn how Galera integrates with MySQL 5.6 and Global Transaction IDs to enable cross-datacenter and cloud replication over high latency networks. The benefits are clear; a globally distributed MySQL setup across regions to deliver Severalnines availability and real-time responsiveness.
Galera Cluster for MySQL is a true multi-master MySQL replication plugin, and has been proven in mission-critical infrastructures of companies like Ping Identity, AVG Technologies, KPN and HP Cloud DNS. In this webcast you¹ll learn about the following Galera Cluster capabilities, including the latest innovations in the new 3.0 release:
Galera Cluster features and benefits
Support for MySQL 5.6
Integration with MySQL Global Transaction Identifiers
Mixing Galera synchronous replication and asynchronous MySQL replication
Deploying in WAN and Cloud environments
Handling high-latency networks
Management of Galera
Built-in MySQL Replication is known for its capability to enable to scale reads easily. However, there are some limitations and known issues with this solution because of the asynchronous nature of this replication. This talk will describe another way of doing MySQL replication, by using synchronous replication, available in Percona XtraDB Cluster. The open source solution will be explained and compared to traditional asynchronous MySQL replication, as well as some known use cases will be described. Percona XtraDB Cluster is an, open source, high availability and high scalability solution for MySQL clustering. Features include: Synchronous replication, Multi-master replication support, Parallel replication, Automatic node provisioning.
Repair & Recovery for your MySQL, MariaDB & MongoDB / TokuMX Clusters - Webin...Severalnines
Slides for the webinar held on January 21st 2014
Repair & Recovery for your MySQL, MariaDB & MongoDB / TokuMX Clusters
Galera Cluster, NDB Cluster, VIP with HAProxy and Keepalived, MongoDB Sharded Cluster, etc. all have their own availability models. We are aware of these availability models and will demonstrate in this webinar how to take corrective action in case of failures via our cluster management tool, ClusterControl.
In this webinar, Severalnines CTO Johan Andersson will show you how to leverage ClusterControl to detect failures in your database cluster and automatically repair them to maximize the availability of your database services. And Codership CEO Seppo Jaakola will be joining Johan to provide a deep-dive into Galera recovery internals.
Agenda:
Redundancy models for Galera, NDB and MongoDB/TokuMX
Failover & Recovery (Automatic vs Manual)
Zooming into Galera recovery procedures
Split brains in multi-datacenter setups
Topics covered in this presentation:
1. The difference between traditional (e.g. MySQL) replication and Galera Cluster
2. General Galera Cluster principles
Galera cluster for MySQL - Introduction SlidesSeveralnines
This set of slides gives you an overview of Galera, configuration basics and deployment best practices.
The following topics are covered:
- Concepts
- Node provisioning
- Network partitioning
- Configuration example
- Benchmarks
- Deployment best practices
- Galera monitoring and management
In the first part of Galera Cluster best practices series, we will discuss the following topics:
* ongoing monitoring of the cluster and detection of bottlenecks;
* fine-tuning the configuration based on the actual database workload;
* selecting the optimal State Snapshot Transfer (SST) method;
* backup strategies
(video:http://galeracluster.com/videos/2159/)
Topics covered in this presentation, which was used for user group meetings, conferences & webinars:
1. Galera Cluster for MySQL - overview
2. Release 3 New Features:
* WAN Replication
* 5.6 Global Transaction ID (GTID) Support
* MySQL Replication Support
* and more features
3. The Galera Cluster Project
Upgrading MySQL databases do not come without risk. There is no guarantee that no problems will happen if you move to a new major MySQL version.
Should we just upgrade and rollback immediately if problems occur? But what if these problems only happen a few days after migrating to this new version?
You might have a database environment that is risk-adverse, where you really have to be sure that this new MySQL version will handle the workload properly.
Examples:
- Both MySQL 5.6 and 5.7 have a lot of changes in the MySQL Optimizer. It is expected that this improves performance of my queries, but is it really the case? What if there is a performance regression? How will this affect my database performance?
- Also, there are a lot of incompatible changes which are documented in the release notes, how do I know if I'm affected by this in my workload? It's a lot to read..
- Can I go immediately from MySQL 5.5 to 5.7 and skip MySQL 5.6 even though the MySQL documentation states that this is not supported?
- Many companies have staging environments, but is there a QA team and do they really test all functionality, under a similar workload?
This presentation will show you a process, using open source tools, of these types of migrations with a focus on assessing risk and fixing any problems you might run into prior to the migration.
This process can then be used for various changes:
- MySQL upgrades for major version upgrades
- Switching storage engines
- Changing hardware architecture
Additionally, we will describe ways to do the actual migration and rollback with the least amount of downtime.
Galera is slowly but surely establishing itself as a credible replacement for traditional MySQL master-slave architectures.
The benefits are clear - a true multi-master InnoDB setup with built-in fail-over, potentially across data centers.
But how do you migrate? Does the schema or application change? What are the limitations? Can migration be done online, without service interruption? What are the potential risks, and how to address those?
AGENDA
Application use cases for Galera
Schema design
Events and Triggers
Query design
Migrating the schema
Loading initial data into the cluster
Limitations
Performing Online Migration to Galera
Operational management checklist
Belts and suspenders: Plan B
Demo
2014 OSDC Talk: Introduction to Percona XtraDB Cluster and HAProxyBo-Yi Wu
Introduction to Percona XtraDB Cluster and HAProxy in 2014 OSDC talk.
Blog: http://blog.wu-boy.com/2014/04/osdc-2014-talk-introduction-to-percona-xtradb-cluster-and-haproxy/
OSDC: http://osdc.tw/program/2014-day2-10.html#content
From these slides you'll learn how Galera integrates with MySQL 5.6 and Global Transaction IDs to enable cross-datacenter and cloud replication over high latency networks.
ABOUT GALERA CLUSTER
Galera Cluster for MySQL is a true multi-master MySQL replication plugin, and has been proven in mission-critical infrastructures of companies like Ping Identity, AVG Technologies, KPN and HP Cloud DNS. In this webcast you¹ll learn about the following Galera Cluster capabilities, including the latest innovations in the new 3.0 release:
Galera Cluster features and benefits
Support for MySQL 5.6
Integration with MySQL Global Transaction Identifiers
Mixing Galera synchronous replication and asynchronous MySQL replication
Deploying in WAN and Cloud environments
Handling high-latency networks
Management of Galera
Percona XtraDB Cluster vs Galera Cluster vs MySQL Group ReplicationKenny Gryp
What are the implementation differences between Percona XtraDB Cluster 5.7, Galera Cluster 5.7 and MySQL Group Replication?
- How do each of these work?
- How do they behave differently?
- Are there any major issues with any of these?
This talk will describe these differences and also shed some light on how QA is done for each of these different technologies.
Slides used for the webinar: Introducing Galera 3.0 - Now supporting MySQL 5.6, Global Transaction IDs & WAN.
These slides covered the section: Galera Monitoring & Management
Setting up and maintaining a database cluster can be tricky. ClusterControl gives you the power to deploy, manage, monitor and scale entire clusters efficiently and reliably. ClusterControl supports a variety of SQL and NoSQL cluster topologies, as well as SQL load balancing via HAProxy.
Galera Cluster for MySQL is a true multi-master MySQL replication plugin, and has been proven in mission-critical infrastructures of companies like Ping Identity, AVG Technologies, KPN and HP Cloud DNS. In this webcast you¹ll learn about the following Galera Cluster capabilities, including the latest innovations in the new 3.0 release:
Galera Cluster features and benefits
Support for MySQL 5.6
Integration with MySQL Global Transaction Identifiers
Mixing Galera synchronous replication and asynchronous MySQL replication
Deploying in WAN and Cloud environments
Handling high-latency networks
Management of Galera
Not Less, Not More: Exactly Once, Large-Scale Stream Processing in ActionParis Carbone
Large-scale data stream processing has come a long way to where it is today. It combines all the essential requirements of modern data analytics: subsecond latency, high throughput and impressively, strong consistency. Apache Flink is a system that serves as a proof-of-concept of these characteristics and it is mainly well-known for its lightweight fault tolerance. Data engineers and analysts can now let the system handle Terabytes of computational state without worrying about failures that can potentially occur.
This presentation describes all the fundamental challenges behind exactly-once processing guarantees in large-scale streaming in a simple and intuitive way. Furthermore, it demonstrate the basic and extended versions of Flink's state-of-the-art snapshotting algorithm tailored to the needs of a dataflow graph.
Percona Live 2022 - The Evolution of a MySQL Database SystemFrederic Descamps
From a single MySQL instance to multi-site high availability, this is what you will find out in this presentation. You will learn how to make this transition and which solutions best suit changing business requirements (RPO, RTO). Recently, MySQL has extended the possibilities for easy deployment of architecture with integrated tools. Come and discover these open source solutions that are part of MySQL.
PuppetConf 2016: Deconfiguration Management: Making Puppet Clean Up Its Own M...Puppet
Here are the slides from Josh Snyder's presentation called Deconfiguration Management: Making Puppet Clean Up Its Own Mess. Watch the videos at https://www.youtube.com/playlist?list=PLV86BgbREluVjwwt-9UL8u2Uy8xnzpIqa
Kernel Recipes 2015 - Kernel dump analysisAnne Nicolas
Kernel dump analysis
Cloud this, cloud that…It’s making everything easier, especially for web hosted services. But what about the servers that are not supposed to crash ? For applications making the assumption the OS won’t do any fault or go down, what can you write in your post-mortem once the server froze and has been restarted ? How to track down the bug that lead to service unavailability ?
In this talk, we’ll see how to setup kdump and how to panic a server to generate a coredump. Once you have the vmcore file, how to track the issue with “crash” tool to find why your OS went down. Last but not least : with “crash” you can also modify your live kernel, the same way you would do with gdb.
Adrien Mahieux – System administrator obsessed with performance and uptime, tracking down microseconds from hardware to software since 2011. The application must be seen as a whole to provide efficiently the requested service. This includes searching for bottlenecks and tradeoffs, design issues or hardware optimization.
Similar to Fosdem 2014 - MySQL & Friends Devroom: 15 tips galera cluster (20)
MySQL Innovation & Cloud Day - Document Store avec MySQL HeatWave Database Se...Frederic Descamps
Découvrez un nouveau monde où l'on peut gérer ses données sans la moindre ligne de SQL.
MySQL Document Store utilise le nouveau protocol MySQL X, qui est également présent avec MySQL Database Service sur OCI, et permet aux développeurs d'écrire du code simple et efficace.
Mais attention, si nécessaire, MySQL Document Store peut également traiter les document JSON comme s'ils étaient des tables relationnelles et permettre des requêtes très poussées...
In this tutorial, we cover the different deployment possibilities of the MySQL architecture depending on the business requirements for the data. We also deploy some architecture and see how to evolve to the next one.
The tutorial covers the new MySQL Solutions like InnoDB ReplicaSet, InnoDB Cluster, and InnoDB ClusterSet.
LinuxFest Northwest 2022 - The Evolution of a MySQL Database SystemFrederic Descamps
At the beginning of a project, the database is just a single MySQL instance (maybe not even running on its own hardware)... but with the evolution of the business requirements, the database must change to also meet the new targets of data loss and uptime. During this session we will follow the journey of a single MySQL server from the simple instance to a High Available Architecture with multi-site Disaster Recovery. We will discover easy manageable native solutions like MySQL InnoDB ReplicaSet, MySQL InnoDB Cluster and MySQL InnoDB ClusterSet. The session is also illustrated with commands and examples.
Open Source 101 2022 - MySQL Indexes and HistogramsFrederic Descamps
Nobody complains that the database is too fast. But when things slow down, the complaints come quickly. The two most popular approaches to speeding up queries are indexes and histograms. But there are so many options and types on indexes that it can get confusing. Histograms are fairly new to MySQL but they do not work for all types of data. This talk covers how indexes and histograms work and show you how to test just how effective they are so you can measure the performance of your queries.
Pi Day 2022 - from IoT to MySQL HeatWave Database ServiceFrederic Descamps
HeatWave is a massively parallel, high performance, in-memory query accelerator for Oracle MySQL Database Service that accelerates MySQL performance by orders of magnitude for analytics and mixed workloads. But how do you collect data from an Internet of Things Environment so you can use HeatWave to process it? In one hour you will see how data collected by a Raspberry PI or other Internet of Things device can be uploaded to the MySQL Database Service and then processed by HeatWave.
D'une simple instance MysQL à une haute-disponibilité multi-sites, voici ce que vous décrouvrirez dans cette présentation. Comment effectuer cette transition et quelles solutions conviennent les mieux aux évolutions des exigences commerciales (RPO, RTO). Récemment, MySQL a étendu les possibilités de déploiement aisé d'architecture avec des outils intégrés. Venez découvrir ces solution Open Source qui font partie de MySQL.
FOSDEM 2022 MySQL Devroom: MySQL 8.0 - Logical Backups, Snapshots and Point-...Frederic Descamps
Logical dumps are becoming popular again. MySQL Shell parallel dump & load utility changed to way to deal with logical dumps, certainly when using instances in the cloud. MySQL 8.0 released also an awesome physical snapshot feature with CLONE.
In this session, I will show how to use these two ways of saving your data and how to use the generated backup to perform point-in-time recovery like a rockstar with MySQL 8.0 in 2022 !
Présentation de MySQL 8.0 est des nouveautés récentes dans les toutes dernières versions ainsi que des informations sur la prochaine beta du MySQL Operator for Kubernetes
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Search and Society: Reimagining Information Access for Radical FuturesBhaskar Mitra
The field of Information retrieval (IR) is currently undergoing a transformative shift, at least partly due to the emerging applications of generative AI to information access. In this talk, we will deliberate on the sociotechnical implications of generative AI for information access. We will argue that there is both a critical necessity and an exciting opportunity for the IR community to re-center our research agendas on societal needs while dismantling the artificial separation between the work on fairness, accountability, transparency, and ethics in IR and the rest of IR research. Instead of adopting a reactionary strategy of trying to mitigate potential social harms from emerging technologies, the community should aim to proactively set the research agenda for the kinds of systems we should build inspired by diverse explicitly stated sociotechnical imaginaries. The sociotechnical imaginaries that underpin the design and development of information access technologies needs to be explicitly articulated, and we need to develop theories of change in context of these diverse perspectives. Our guiding future imaginaries must be informed by other academic fields, such as democratic theory and critical theory, and should be co-developed with social science scholars, legal scholars, civil rights and social justice activists, and artists, among others.
1. #Fosdem 2014 #MySQL & Friends
#devroom
15 Tips to improve your
Galera Cluster Experience
2. Who am I ?
Frédéric Descamps “lefred”
@lefred
http://about.me/lefred
Percona Consultant since 2011
Managing MySQL since 3.23
devops believer
I installed my first galera cluster in feb 2010
2/5/14
3. Who am I ?
Frédéric Descamps “lefred”
@lefred
http://about.me/lefred
Percona Consultant since 2011
Managing MySQL since 3.23
devops believer
I installed my first galera cluster in feb 2010
2/5/14
9. Suddenly !
Oups ! Dim0 truncated a production table...
:-S
We can have 2 scenarios :
–
–
2/5/14
The application can keep running even without that table
The application musts be stopped !
10. Suddenly !
Oups ! Dim0 truncated a production table...
:-S
We can have 2 scenarios :
–
–
2/5/14
The application can keep running even without that table
The application musts be stopped !
11. Suddenly !
Oups ! Dim0 truncated a production table...
:-S
We can have 2 scenarios :
–
–
2/5/14
The application can keep running even without that table
The application musts be stopped !
12. Suddenly !
Oups ! Dim0 truncated a production table...
:-S
We can have 2 scenarios :
–
–
2/5/14
The application can keep running even without that table
The application musts be stopped !
14. Scenario 1: application must be stopped !
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Stop the each node of the cluster
2/5/14
15. Scenario 1: application must be stopped !
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Stop the each node of the cluster
2/5/14
16. Scenario 1: application must be stopped !
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Stop the each node of the cluster
2/5/14
17. Scenario 1: application must be stopped !
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Stop the each node of the cluster
2/5/14
18. Scenario 1: application must be stopped !
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Stop the each node of the cluster
/etc/init.d/mysql stop
or
service mysql stop
2/5/14
19. Scenario 1: application must be stopped !
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Stop the each node of the cluster
– Find the binlog file and position before “the
event” happened
2/5/14
20. Scenario 1: application must be stopped !
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Stop the each node of the cluster
– Find the binlog file and position before “the
event” happened
# mysqlbinlog binlog.000001 | grep truncate B 2
#140123 23:37:03 server id 1 end_log_pos 1224
Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1390516623/*!*/;
truncate table speakers
2/5/14
21. Scenario 1: application must be stopped !
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Stop the each node of the cluster
– Find the binlog file and position before “the
event” happened
– Restore the backup on one node
2/5/14
22. Scenario 1: application must be stopped !
We have Xtrabackup (and it creates daily backups!)
# cp binlog.00001 ~
# innobackupex applylog .
We
etc..have binary logs
These are the steps :
– Stop the each node of the cluster
– Find the binlog file and position before “the
event” happened
– Restore the backup on one node
2/5/14
23. Scenario 1: application must be stopped !
We have Xtrabackup (and it creates daily backups!)
# /etc/init.d/mysql bootstrappxc
We have binary logs
These are the steps :
– Stop the each node of the cluster
– Find the binlog file and position before “the
event” happened
– Restore the backup on one node
– Restart that node (being sure the application doesn't
connect to it)
2/5/14
25. Scenario 1: application must be stopped ! (2)
–
2/5/14
Replay all the binary logs since the backup BUT
the position of the event
26. Scenario 1: application must be stopped ! (2)
–
Replay all the binary logs since the backup BUT
the position of the event
# cat xtrabackup_binlog_info
Binlog.000001 565
# mysqlbinlog binlog.000001 | grep end_log_pos |
grep 1224 B 1
#140123 23:36:53 server id 1 end_log_pos 1136
#140123 23:37:03 server id 1 end_log_pos 1224
# mysqlbinlog binlog.000001 j 565
stopposition 1136 | mysql
2/5/14
28. Scenario 1: application must be stopped ! (2)
–
–
–
2/5/14
Replay all the binary logs since the backup BUT
the position of the event
Start other nodes 1 by 1 and let them perform
SST
Enable connections from the application
29. Scenario 1: application must be stopped ! (2)
–
–
–
2/5/14
Replay all the binary logs since the backup BUT
the position of the event
Start other nodes 1 by 1 and let them perform
SST
Enable connections from the application
30. Scenario 1: application must be stopped ! (2)
–
–
–
2/5/14
Replay all the binary logs since the backup BUT
the position of the event
Start other nodes 1 by 1 and let them perform
SST
Enable connections from the application
32. Scenario 2: application can keep running
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Take care of quorum (add garbd, change pc.weight,
pc.ignore_quorum)
–
–
2/5/14
Find the binlog file and position before “the
event” happened (thank you dim0!)
Remove one node from the cluster (and be sure the
app doesn't connect to it, load-balancer...)
33. Scenario 2: application can keep running
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Take care of quorum (add garbd, change pc.weight,
pc.ignore_quorum)
–
–
2/5/14
Find the binlog file and position before “the
event” happened (thank you dim0!)
Remove one node from the cluster (and be sure the
app doesn't connect to it, load-balancer...)
34. Scenario 2: application can keep running
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Take care of quorum (add garbd, change pc.weight,
pc.ignore_quorum)
–
–
2/5/14
Find the binlog file and position before “the
event” happened (thank you dim0!)
Remove one node from the cluster (and be sure the
app doesn't connect to it, load-balancer...)
35. Scenario 2: application can keep running
We have Xtrabackup (and it creates daily backups!)
We have binary logs
These are the steps :
– Take care of quorum (add garbd, change pc.weight,
pc.ignore_quorum)
–
–
2/5/14
Find the binlog file and position before “the
event” happened (thank you dim0!)
Remove one node from the cluster (and be sure the
app doesn't connect to it, load-balancer...)
37. Scenario 2: application can keep running (2)
–
–
–
–
–
–
2/5/14
Restore the backup on the node we stopped
Start mysql without joining the cluster (--wsrepcluster-address=dummy://)
Replay the binary log until the position of “the
event”
Export the table we need (mysqldump)
Import it on the cluster
Restart mysql on the off-line node and let it
perform SST
38. Scenario 2: application can keep running (2)
–
–
–
–
–
–
2/5/14
Restore the backup on the node we stopped
Start mysql without joining the cluster (--wsrepcluster-address=dummy://)
Replay the binary log until the position of “the
event”
Export the table we need (mysqldump)
Import it on the cluster
Restart mysql on the off-line node and let it
perform SST
39. Scenario 2: application can keep running (2)
–
–
–
–
–
–
2/5/14
Restore the backup on the node we stopped
Start mysql without joining the cluster (--wsrepcluster-address=dummy://)
Replay the binary log until the position of “the
event”
Export the table we need (mysqldump)
Import it on the cluster
Restart mysql on the off-line node and let it
perform SST
40. Scenario 2: application can keep running (2)
–
–
–
–
–
–
2/5/14
Restore the backup on the node we stopped
Start mysql without joining the cluster (--wsrepcluster-address=dummy://)
Replay the binary log until the position of “the
event”
Export the table we need (mysqldump)
Import it on the cluster
Restart mysql on the off-line node and let it
perform SST
41. Scenario 2: application can keep running (2)
–
–
–
–
–
–
2/5/14
Restore the backup on the node we stopped
Start mysql without joining the cluster (--wsrepcluster-address=dummy://)
Replay the binary log until the position of “the
event”
Export the table we need (mysqldump)
Import it on the cluster
Restart mysql on the off-line node and let it
perform SST
42. Scenario 2: application can keep running (2)
–
–
–
–
–
–
2/5/14
Restore the backup on the node we stopped
Start mysql without joining the cluster (--wsrepcluster-address=dummy://)
Replay the binary log until the position of “the
event”
Export the table we need (mysqldump)
Import it on the cluster
Restart mysql on the off-line node and let it
perform SST
44. Reduce “donation” time during XtraBackup SST
When performing SST with Xtrabackup the
donor can still be active
by default this is disabled in clustercheck
(AVAILABLE_WHEN_DONOR=0)
Running Xtrabackup can increase the load
(CPU / IO) on the server
2/5/14
45. Reduce “donation” time during XtraBackup SST (2)
Using Xtrabackup 2.1 features helps to reduce
the time of backup on the donor
[mysqld]
wsrep_sst_method=xtrabackupv2
wsrep_sst_auth=root:dim0DidItAgain
[sst]
streamfmt=xbstream
[xtrabackup]
compress
compact
parallel=8
compressthreads=8
2/5/14
rebuildthreads=8
compress & compact can reduce the size
of payload transferred among nodes
but in general it slows down the process
47. Move asynchronous slave to a new master in 5.5
binlog.000039
102
writes
B
A
binlog.000002
102
as
yn
c
writes
master_host=A
master_log_file=binlog.000002
master_pos=102
2/5/14
C
writes
binlog.000001
402
48. Move asynchronous slave to a new master in 5.5
(2)
binlog.000039
102
writes
B
writes
as
yn
c
C
master_host=B
master_log_file=binlog.000002
master_pos=102
2/5/14
writes
binlog.000001
402
49. Move asynchronous slave to a new master in 5.5
(2)
binlog.000039
102
writes
B
writes
as
yn
c
C
master_host=B
master_log_file=binlog.000002
master_pos=102
2/5/14
writes
binlog.000001
402
51. Move asynchronous slave to a new master in
5.5 (3)
How can we know which file and position
need to be used by the async slave ?
Find the last received Xid in the relay log on
the async slave (using mysqlbinlog)
2/5/14
52. Move asynchronous slave to a new master in
5.5 (3)
How can we know which file and position
need to be used by the async slave ?
Find the last received Xid in the relay log on
the async slave (using mysqlbinlog)
2/5/14
53. Move asynchronous slave to a new master in
5.5 (3)
How can we know which file and position
need to be used by the async slave ?
Find the last received Xid in the relay log on
the async slave (using mysqlbinlog)
# mysqlbinlog percona4relaybin.000002 | tail
MjM5NDMxMDMxOTEtNTI4NzYxMTUxMDctMTM3NTAyNTI2NjUtNTc1ODY3MTc0MTg=
'/*!*/;
# at 14611057
#140131 12:48:12 server id 1 end_log_pos 29105924 Xid = 30097
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
2/5/14
55. Move asynchronous slave to a new master in
5.5 (3)
How can we know which file and position need
to be used by the async slave ?
Find the last received Xid in the relay log on the
async slave (using mysqlbinlog)
Find in the new master which binary position
matches that same Xid
Use the binary log file and the position for your
CHANGE MASTER statement
2/5/14
56. Move asynchronous slave to a new master in
5.5 (3)
How can we know which file and position need
to be used by the async slave ?
Find the last received Xid in the relay log on the
async slave (using mysqlbinlog)
Find in the new master which binary position
matches that same Xid
Use the binary log file and the position for your
CHANGE MASTER statement
2/5/14
57. Move asynchronous slave to a new master in
5.5 (3)
How can we know which file and position need
to be used by the async slave ?
# mysqlbinlog percona3bin.000004 | grep 'Xid = 30097'
#140131 12:48:12 server id 1 end_log_pos 28911093
Xid = 30097
Find the last received Xid in the relay log on the
async slave (using mysqlbinlog)
Find in the new master which binary position
matches that same Xid
Use the binary log file and the position for your
CHANGE MASTER statement
2/5/14
58. Move asynchronous slave to a new master in
5.5 (3)
How can we know which file and position need
to be used by the async slave ?
Find the last received Xid in the relay log on the
async slave (using mysqlbinlog)
Find in the new master which binary position
matches that same Xid
Use the binary log file and the position for your
CHANGE MASTER statement
2/5/14
59. Move asynchronous slave to a new master in
5.5 (3)
How can we know which file and position need
to be used by the async slave ?
Async mysql> slave stop;
Async mysql> change master to master_host='percona3',
> master_log_file='percona3bin.000004',
> master_log_pos=28911093;
Find the last received Xid in the relay log on the
async slave (using mysqlbinlog)
Async mysql> start slave;
Find in the new master which binary position
matches that same Xid
Use the binary log file and the position for your
CHANGE MASTER statement
2/5/14
62. Move asynchronous slave to a new master in 5.6
With 5.6 and GTID it's easier !
... but ...
It requires rsync SST (binlogs are needed)
Or since Jan 30th
wsrep_sst_xtrabackupv2 supports
Xtrabackup 2.1.7 that makes is possible !!!
Just change master ;-)
2/5/14
63. Move asynchronous slave to a new master in 5.6
With 5.6 and GTID it's easier !
... but ...
It requires rsync SST (binlogs are needed)
Or since Jan 30th
wsrep_sst_xtrabackupv2 supports
Xtrabackup 2.1.7 that makes is possible !!!
Just change master ;-)
2/5/14
64. Move asynchronous slave to a new master in 5.6
With 5.6 and GTID it's easier !
... but ...
It requires rsync SST (binlogs are needed)
Or since Jan 30th
wsrep_sst_xtrabackupv2 supports
Xtrabackup 2.1.7 that makes is possible !!!
Just change master ;-)
2/5/14
65. Move asynchronous slave to a new master in 5.6
With 5.6 and GTID it's easier !
... but ...
It requires rsync SST (binlogs are needed)
Or since Jan 30th
wsrep_sst_xtrabackupv2 supports
Xtrabackup 2.1.7 that makes is possible !!!
Just change master ;-)
2/5/14
66. Move asynchronous slave to a new master in 5.6
With 5.6 and GTID it's easier !
... but ...
It requires rsync SST (binlogs are needed)
Or since Jan 30th
wsrep_sst_xtrabackupv2 supports
Xtrabackup 2.1.7 that makes is possible !!!
Just change master ;-)
2/5/14
69. Allow longer downtime for a node
When a node goes off-line, when it joins again
the cluster, it sends its last replicated event to
the donor
If the donor can send all next events, IST will
be performed (very fast)
If not... SST is mandatory
2/5/14
70. Allow longer downtime for a node
When a node goes off-line, when it joins again
the cluster, it sends its last replicated event to
the donor
If the donor can send all next events, IST will
be performed (very fast)
If not... SST is mandatory
2/5/14
71. Allow longer downtime for a node
When a node goes off-line, when it joins again
the cluster, it sends its last replicated event to
the donor
If the donor can send all next events, IST will
be performed (very fast)
If not... SST is mandatory
2/5/14
73. Allow longer downtime for a node (2)
Those events are stored on a cache on disk:
galera.cache
The size of the cache is 128Mb by default
It can be increased using gcache.size provider
option:
2/5/14
74. Allow longer downtime for a node (2)
Those events are stored on a cache on disk:
galera.cache
The size of the cache is 128Mb by default
It can be increased using gcache.size provider
option:
2/5/14
75. Allow longer downtime for a node (2)
Those events are stored on a cache on disk:
galera.cache
The size of the cache is 128Mb by default
It can be increased using gcache.size provider
option:
2/5/14
76. Allow longer downtime for a node (2)
Those events are stored on a cache on disk:
galera.cache
The size of the cache is 128Mb by default
It can be increased using gcache.size provider
option:
In /etc/my.cnf:
wsrep_provider_options = “gcache.size=1G”
2/5/14
78. Then choose the right donor !
Let's imagine this:
Event 1
B
C
A
writes
2/5/14
Event 1
Event 1
79. Then choose the right donor ! (2)
Let's imagine this:
Event 1
Event 2
B
C
A
writes
2/5/14
Event 1
Event 1
Event 2
80. Then choose the right donor ! (3)
Let's imagine this:
Event 1
Event 2
Join:
last event = 1
B
C
A
writes
2/5/14
Event 1
Event 2
Event 1
81. Then choose the right donor ! (4)
Let's imagine this:
Event 1
Event 2
IST
B
C
A
writes
2/5/14
Event 1
Event 2
Event 1
82. Then choose the right donor ! (5)
Let's imagine this:
Event 1
Event 2
B
C
A
writes
2/5/14
Event 1
Event 2
Event 1
Event 2
83. Then choose the right donor ! (6)
Let's imagine this:
Event 1
Event 2
Let's format
the disk
B
C
A
writes
2/5/14
Event 1
Event 2
84. Then choose the right donor ! (7)
Let's imagine this:
Event 1
Event 2
Join:
no cluster info
B
C
A
writes
2/5/14
Event 1
Event 2
85. Then choose the right donor ! (8)
Full SST needed
Event 1
Event 2
SST
B
C
A
writes
2/5/14
Event 1
Event 2
86. Then choose the right donor ! (9)
This is what we have now:
Event 1
Event 2
Event 3
B
C
A
writes
2/5/14
Event 1
Event 2
Event 3
Event 3
87. Then choose the right donor ! (10)
Let's remove node B for maintenance
Event 1
Event 2
Event 3
B
C
A
writes
2/5/14
Event 1
Event 2
Event 3
Event 4
Event 3
Event 4
88. Then choose the right donor ! (11)
Now let's remove node C to replace a disk :-(
Event 1
Event 2
Event 3
B
C
A
writes
2/5/14
Event 1
Event 2
Event 3
Event 4
Event 5
89. Then choose the right donor ! (12)
Node C joins again and performs SST
Event 1
Event 2
Event 3
B
C
A
writes
2/5/14
Event 1
Event 2
Event 3
Event 4
Event 5
90. Then choose the right donor ! (12)
Node C joins again and performs SST
Event 1
Event 2
Event 3
B
C
A
writes
2/5/14
Event 1
Event 2
Event 3
Event 4
Event 5
Event 6
Event 6
91. Then choose the right donor ! (13)
Node B joins again but donor selection is not
clever yet...
Event 1
Event 2
Event 3
Join:
last event = 3
B
C
A
writes
2/5/14
Event 1
Event 2
Event 3
Event 4
Event 5
Event 6
Event 6
92. Then choose the right donor ! (13)
Node B joins again but donor selection is not
clever yet...
Event 1
Event 2
Event 3
Join:
last event = 3
B
SST will be needed !
C
A
writes
2/5/14
Event 1
Event 2
Event 3
Event 4
Event 5
Event 6
Event 6
93. Then choose the right donor ! (14)
So how to tell node B that it needs to use
node A?
Event 1
Event 2
Event 3
Join:
last event = 3
B
# /etc/init.d/mysql start wsrepsst_donor=nodeA
C
A
writes
2/5/14
Event 1
Event 2
Event 3
Event 4
Event 5
Event 6
Event 6
95. Then choose the right donor ! (15)
With 5.6 you have now the possibility to know the
lowest sequence number in gcache using
wsrep_local_cached_downto
To know the latest event's sequence number on
the node that joins the cluster, you have two
possibilities:
2/5/14
96. Then choose the right donor ! (15)
With 5.6 you have now the possibility to know the
lowest sequence number in gcache using
wsrep_local_cached_downto
To know the latest event's sequence number on
the node that joins the cluster, you have two
possibilities:
2/5/14
97. Then choose the right donor ! (15)
With 5.6 you have now the possibility to know the
lowest sequence number in gcache using
wsrep_local_cached_downto
To know the latest event's sequence number on
the node that joins the cluster, you have two
possibilities:
# cat grasdate.dat
# GALERA saved state
version: 2.1
uuid: 419201747ec611e3a05a6a2ab4033f05
seqno: 11
cert_index:
2/5/14
98. Then choose the right donor ! (15)
With 5.6 you have now the possibility to know the
lowest sequence number in gcache using
wsrep_local_cached_downto
To know the latest event's sequence number on
the node that joins the cluster, you have two
possibilities:
# cat grasdate.dat
# GALERA saved state
version: 2.1
uuid: 419201747ec611e3a05a6a2ab4033f05
seqno: 11
cert_index:
2/5/14
99. Then choose the right donor ! (15)
With 5.6 you have now the possibility to know the
lowest sequence number in gcache using
wsrep_local_cached_downto
To know the latest event's sequence number on
the node that joins the cluster, you have two
possibilities:
# mysqld_safe wsreprecover
140124 10:46:32 mysqld_safe Logging to '/var/lib/mysql/percona1_error.log'.
140124 10:46:32 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140124 10:46:32 mysqld_safe Skipping wsreprecover
for 419201747ec611e3a05a6a2ab4033f05:11 pair
140124 10:46:32 mysqld_safe Assigning 419201747ec611e3a05a6a2ab4033f05:11
to wsrep_start_position
140124 10:46:34 mysqld_safe mysqld from pid file /var/lib/mysql/percona1.pid ended
2/5/14
100. Then choose the right donor ! (15)
With 5.6 you have now the possibility to know the
lowest sequence number in gcache using
wsrep_local_cached_downto
To know the latest event's sequence number on
the node that joins the cluster, you have two
possibilities:
# mysqld_safe wsreprecover
140124 10:46:32 mysqld_safe Logging to '/var/lib/mysql/percona1_error.log'.
140124 10:46:32 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140124 10:46:32 mysqld_safe Skipping wsreprecover
for 419201747ec611e3a05a6a2ab4033f05:11 pair
140124 10:46:32 mysqld_safe Assigning 419201747ec611e3a05a6a2ab4033f05:11
to wsrep_start_position
140124 10:46:34 mysqld_safe mysqld from pid file /var/lib/mysql/percona1.pid ended
2/5/14
103. Measuring Max Replication Throughput
Since (5.5.33) wsrep_desync can be used to
find out how fast a node can replicate
The process is to collect the amount of
transactions (events) during peak time for a define
time range (let's take 1 min)
2/5/14
104. Measuring Max Replication Throughput
Since (5.5.33) wsrep_desync can be used to
find out how fast a node can replicate
The process is to collect the amount of
transactions (events) during peak time for a define
time range (let's take 1 min)
2/5/14
105. Measuring Max Replication Throughput
Since (5.5.33) wsrep_desync can be used to
find out how fast a node can replicate
The process is to collect the amount of
transactions (events) during peak time for a define
time range (let's take 1 min)
mysql> pager grep wsrep
mysql> show global status like 'wsrep_last_committed';
> select sleep(60);
> show global status like 'wsrep_last_committed';
| wsrep_last_committed | 61472 |
| wsrep_last_committed | 69774 |
2/5/14
106. Measuring Max Replication Throughput
Since (5.5.33) wsrep_desync can be used to
find out how fast a node can replicate
The process is to collect the amount of
transactions (events) during peak69774 – 61472 = 8302
time for a define
8302 / 60 = 138.36 tps
time range (let's take 1 min)
mysql> pager grep wsrep
mysql> show global status like 'wsrep_last_committed';
> select sleep(60);
> show global status like 'wsrep_last_committed';
| wsrep_last_committed | 61472 |
| wsrep_last_committed | 69774 |
2/5/14
108. Measuring Max Replication Throughput
Since (5.5.33) wsrep_desync can be used to find
out how fast a node can replicate
The process is to collect the amount of transactions
(events) during peak time for a define time range (let's
take 1 min)
Then collect the amount of transactions and the
duration to process them after the node was in
desync mode and not allowing writes
In desync mode, the node doesn't sent flow control
messages to the cluster
2/5/14
109. Measuring Max Replication Throughput
Since (5.5.33) wsrep_desync can be used to find
out how fast a node can replicate
The process is to collect the amount of transactions
(events) during peak time for a define time range (let's
take 1 min)
Then collect the amount of transactions and the
duration to process them after the node was in
desync mode and not allowing writes
In desync mode, the node doesn't sent flow control
messages to the cluster
2/5/14
110. Measuring Max Replication Throughput
Since (5.5.33) wsrep_desync can be used to find
out how fast a node can replicate
The process is to collect the amount of transactions
(events) during peak time for a define time range (let's
take 1 min)
Then collect the amount of transactions and the
duration to process them after the node was in
desync mode and not allowing writes
In desync mode, the node doesn't sent flow control
messages to the cluster
2/5/14
111. Measuring Max Replication Throughput
set global wsrep_desync=ON; flush tables with read lock;
show global status like 'wsrep_last_committed';
select sleep( 60 ); unlock tables;
Since (5.5.33) wsrep_desync can be used to find
out how fast a node can replicate
+++
| Variable_name | Value |
+++
| wsrep_last_committed | 145987 |
+++
The process is to collect the amount of transactions
(events) during peak time for a define time range (let's
take 1 min)
Then collect the amount of transactions and the
duration to process them after the node was in
desync mode and not allowing writes
In desync mode, the node doesn't sent flow control
messages to the cluster
2/5/14
112. Measuring Max Replication Throughput
In another terminal you run myq_gadget and
when wsrep_local_recv_queue (Queue
Dn) is back to 0 check again the value of
wsrep_last_committed.
2/5/14
113. Measuring Max Replication Throughput
In another terminal you run myq_gadget and
when wsrep_local_recv_queue (Queue
Dn) is back to 0 check again the value of
wsrep_last_committed.
LefredPXC / percona3 / Galera 2.8(r165)
Wsrep Cluster Node Queue Ops Bytes Flow Conflct PApply Commit
time P cnf # cmt sta Up Dn Up Dn Up Dn pau snt lcf bfa dst oooe oool wind
13:25:24 P 7 3 Dono T/T 0 8k 0 0 0 0 0.0 0 0 0 125 0 0 0
13:25:25 P 7 3 Dono T/T 0 8k 0 197 0 300K 0.0 0 0 0 145 90 0 2
...
13:26:46 P 7 3 Dono T/T 0 7 0 209 0 318K 0.0 0 0 0 139 62 0 1
13:26:47 P 7 3 Dono T/T 0 0 0 148 0 222K 0.0 0 0 0 140 40 0 1
2/5/14
114. Measuring Max Replication Throughput
In another terminal you run myq_gadget and
when wsrep_local_recv_queue (Queue
Dn) is back to 0 check again the value of
wsrep_last_committed. This is when FTWRL
is released
LefredPXC / percona3 / Galera 2.8(r165)
Wsrep Cluster Node Queue Ops Bytes Flow Conflct PApply Commit
time P cnf # cmt sta Up Dn Up Dn Up Dn pau snt lcf bfa dst oooe oool wind
13:25:24 P 7 3 Dono T/T 0 8k 0 0 0 0 0.0 0 0 0 125 0 0 0
13:25:25 P 7 3 Dono T/T 0 8k 0 197 0 300K 0.0 0 0 0 145 90 0 2
...
13:26:46 P 7 3 Dono T/T 0 7 0 209 0 318K 0.0 0 0 0 139 62 0 1
13:26:47 P 7 3 Dono T/T 0 0 0 148 0 222K 0.0 0 0 0 140 40 0 1
2/5/14
115. Measuring Max Replication Throughput
In another terminal you run myq_gadget and
when wsrep_local_recv_queue (Queue
This is when galera
Dn) is back to 0 check again the value of
catch up.
wsrep_last_committed = 165871
wsrep_last_committed. This is when FTWRL
is released
LefredPXC / percona3 / Galera 2.8(r165)
Wsrep Cluster Node Queue Ops Bytes Flow Conflct PApply Commit
time P cnf # cmt sta Up Dn Up Dn Up Dn pau snt lcf bfa dst oooe oool wind
13:25:24 P 7 3 Dono T/T 0 8k 0 0 0 0 0.0 0 0 0 125 0 0 0
13:25:25 P 7 3 Dono T/T 0 8k 0 197 0 300K 0.0 0 0 0 145 90 0 2
...
13:26:46 P 7 3 Dono T/T 0 7 0 209 0 318K 0.0 0 0 0 139 62 0 1
13:26:47 P 7 3 Dono T/T 0 0 0 148 0 222K 0.0 0 0 0 140 40 0 1
2/5/14
116. Measuring Max Replication Throughput
In another terminal you run myq_gadget and
165871 145987 = 19884
when wsrep_local_recv_queue (Queue
19884 / 82 = 242.48 tps
Dn) is back toWe're currently at 57% value of
0 check again the
of our capacity
wsrep_last_committed.
LefredPXC / percona3 / Galera 2.8(r165)
Wsrep Cluster Node Queue Ops Bytes Flow Conflct PApply Commit
time P cnf # cmt sta Up Dn Up Dn Up Dn pau snt lcf bfa dst oooe oool wind
13:25:24 P 7 3 Dono T/T 0 8k 0 0 0 0 0.0 0 0 0 125 0 0 0
13:25:25 P 7 3 Dono T/T 0 8k 0 197 0 300K 0.0 0 0 0 145 90 0 2
...
13:26:46 P 7 3 Dono T/T 0 7 0 209 0 318K 0.0 0 0 0 139 62 0 1
13:26:47 P 7 3 Dono T/T 0 0 0 148 0 222K 0.0 0 0 0 140 40 0 1
2/5/14
118. Multicast replication
By default, galera uses
unicast TCP
1 copy of the replication
message sent to all other
nodes in the cluster
2/5/14
119. Multicast replication (2)
By default, galera uses
unicast TCP
1 copy of the replication
message sent to all other
nodes in the cluster
More nodes, more
bandwidth
2/5/14
121. Multicast replication (3)
If your network supports it you
can use Multicast UDP for
replication
wsrep_provider_options =
“gmacast.mcast_addr =
239.192.0.11”
wsrep_cluster_cluster_addr
ess = gcomm://239.192.0.11
2/5/14
122. Multicast replication (3)
If your network supports it you
can use Multicast UDP for
replication
wsrep_provider_options =
“gmacast.mcast_addr =
239.192.0.11”
wsrep_cluster_cluster_addr
ess = gcomm://239.192.0.11
2/5/14
123. Multicast replication (3)
If your network supports it you
can use Multicast UDP for
replication
wsrep_provider_options =
“gmacast.mcast_addr =
239.192.0.11”
wsrep_cluster_cluster_addr
ess = gcomm://239.192.0.11
2/5/14
126. SSL everywhere !
It's possible to have the Galera replication
encrypted via SSL
But now it's also possible to have SST over
SSL, with xtrabackup_v2 and with rsync
https://github.com/tobz/galera-secure-rsync
2/5/14
127. SSL everywhere !
It's possible to have the Galera replication
encrypted via SSL
But now it's also possible to have SST over
SSL, with xtrabackup_v2 and with rsync
https://github.com/tobz/galera-secure-rsync
2/5/14
128. SSL everywhere !
It's possible to have the Galera replication
encrypted via SSL
But now it's also possible to have SST over
SSL, with xtrabackup_v2 and with rsync
https://github.com/tobz/galera-secure-rsync
2/5/14
130. SSL everywhere : certs creation
openssl req new x500 days
365000 nodes keyout key.pem
out cert.pem
Same cert and key must be copied on all
nodes
Copy them in /etc/mysql for example and
let only mysql read them
2/5/14
131. SSL everywhere : certs creation
openssl req new x500 days
365000 nodes keyout key.pem
out cert.pem
Same cert and key must be copied on all
nodes
Copy them in /etc/mysql for example and
let only mysql read them
2/5/14
132. SSL everywhere : certs creation
openssl req new x500 days
365000 nodes keyout key.pem
out cert.pem
Same cert and key must be copied on all
nodes
Copy them in /etc/mysql for example and
let only mysql read them
2/5/14
134. SSL everywhere : galera configuration
wsrep_provider_options =
“socket.ssl.cert=/etc/mysql/cert.pem;
socket.ssl_key=/etc/mysql/key.pem”
It's possible to set a remote Certificate
Authority for validation (use
socket.ssl_ca)
All nodes must have SSL enabled
2/5/14
135. SSL everywhere : galera configuration
wsrep_provider_options =
“socket.ssl.cert=/etc/mysql/cert.pem;
socket.ssl_key=/etc/mysql/key.pem”
It's possible to set a remote Certificate
Authority for validation (use
socket.ssl_ca)
All nodes must have SSL enabled
2/5/14
136. SSL everywhere : galera configuration
wsrep_provider_options =
“socket.ssl.cert=/etc/mysql/cert.pem;
socket.ssl_key=/etc/mysql/key.pem”
It's possible to set a remote Certificate
Authority for validation (use
socket.ssl_ca)
All nodes must have SSL enabled
2/5/14
138. SSL everywhere : SST configuration
As Xtrabackup 2.1 supports encryption, it's now also
possible to use SSL for SST
Use wsrep_sst_method=xtrabackupv2
[sst]
tkey=/etc/mysql/key.pem
tcert=/etc/mysql/cert.pem
encrypt=3
2/5/14
139. SSL everywhere : SST configuration
As Xtrabackup 2.1 supports encryption, it's now also
possible to use SSL for SST
Use wsrep_sst_method=xtrabackupv2
[sst]
tkey=/etc/mysql/key.pem
tcert=/etc/mysql/cert.pem
encrypt=3
2/5/14
140. SSL everywhere : SST configuration
As Xtrabackup 2.1 supports encryption, it's now also
possible to use SSL for SST
Use wsrep_sst_method=xtrabackupv2
[sst]
tkey=/etc/mysql/key.pem
tcert=/etc/mysql/cert.pem
encrypt=3
2/5/14
141. SSL everywhere : SST configuration
As Xtrabackup 2.1 supports encryption, it's now also
possible to use SSL for SST
Use wsrep_sst_method=xtrabackupv2
[sst]
tkey=/etc/mysql/key.pem
tcert=/etc/mysql/cert.pem
encrypt=3
2/5/14
142. SSL everywhere : SST configuration
As Xtrabackup 2.1 supports encryption, it's now also
possible to use SSL for SST
Use wsrep_sst_method=xtrabackupv2
[sst]
tkey=/etc/mysql/key.pem
tcert=/etc/mysql/cert.pem
encrypt=3
2/5/14
143. SSL everywhere : SST configuration
As Xtrabackup 2.1 supports encryption, it's now also
possible to use SSL for SST
Use wsrep_sst_method=xtrabackupv2
[sst]
tkey=/etc/mysql/key.pem
tcert=/etc/mysql/cert.pem
encrypt=3
2/5/14
145. SSL everywhere : SST configuration
And for those using rsync ?
galerasecurersync acts like
wsrep_sst_rsync but secures the communication
with SSL using socat.
Uses also the same cert and key file
wsrep_sst_method=secure_rsync
https://github.com/tobz/galera-secure-rsync
2/5/14
146. SSL everywhere : SST configuration
And for those using rsync ?
galerasecurersync acts like
wsrep_sst_rsync but secures the communication
with SSL using socat.
Uses also the same cert and key file
wsrep_sst_method=secure_rsync
https://github.com/tobz/galera-secure-rsync
2/5/14
147. SSL everywhere : SST configuration
And for those using rsync ?
galerasecurersync acts like
wsrep_sst_rsync but secures the communication
with SSL using socat.
Uses also the same cert and key file
wsrep_sst_method=secure_rsync
https://github.com/tobz/galera-secure-rsync
2/5/14
148. SSL everywhere : SST configuration
And for those using rsync ?
galerasecurersync acts like
wsrep_sst_rsync but secures the communication
with SSL using socat.
Uses also the same cert and key file
wsrep_sst_method=secure_rsync
https://github.com/tobz/galera-secure-rsync
2/5/14
149. SSL everywhere : SST configuration
And for those using rsync ?
galerasecurersync acts like
wsrep_sst_rsync but secures the communication
with SSL using socat.
Uses also the same cert and key file
wsrep_sst_method=secure_rsync
https://github.com/tobz/galera-secure-rsync
2/5/14
150. SSL everywhere : SST configuration
And for those using rsync ?
galerasecurersync acts like
wsrep_sst_rsync but secures the communication
with SSL using socat.
Uses also the same cert and key file
wsrep_sst_method=secure_rsync
https://github.com/tobz/galera-secure-rsync
2/5/14
153. Decode GRA* files
When a replication failure occurs, a
GRA_*.log file is created into the datadir
For each of those files, a corresponding
message is present in the mysql error log file
Can be a false positive (bad DDL statement)...
or not !
This is how you can decode the content of that
file
2/5/14
154. Decode GRA* files
When a replication failure occurs, a
GRA_*.log file is created into the datadir
For each of those files, a corresponding
message is present in the mysql error log file
Can be a false positive (bad DDL statement)...
or not !
This is how you can decode the content of that
file
2/5/14
155. Decode GRA* files
When a replication failure occurs, a
GRA_*.log file is created into the datadir
For each of those files, a corresponding
message is present in the mysql error log file
Can be a false positive (bad DDL statement)...
or not !
This is how you can decode the content of that
file
2/5/14
156. Decode GRA* files
When a replication failure occurs, a
GRA_*.log file is created into the datadir
For each of those files, a corresponding
message is present in the mysql error log file
Can be a false positive (bad DDL statement)...
or not !
This is how you can decode the content of that
file
2/5/14
158. Decode GRA* files (2)
Download a binlog header file (http://goo.gl/kYTkY2)
Join the header and one GRA_*.log file:
–
cat GRAheader > GRA_3_3bin.log
–
cat GRA_3_3.log >> GRA_3_3bin.log
Now you can just use mysqlbinlog vvv and find
out what the problem was !
2/5/14
159. Decode GRA* files (2)
Download a binlog header file (http://goo.gl/kYTkY2)
Join the header and one GRA_*.log file:
–
cat GRAheader > GRA_3_3bin.log
–
cat GRA_3_3.log >> GRA_3_3bin.log
Now you can just use mysqlbinlog vvv and find
out what the problem was !
2/5/14
160. Decode GRA* files (2)
Download a binlog header file (http://goo.gl/kYTkY2)
Join the header and one GRA_*.log file:
–
cat GRAheader > GRA_3_3bin.log
–
cat GRA_3_3.log >> GRA_3_3bin.log
Now you can just use mysqlbinlog vvv and find
out what the problem was !
2/5/14
161. Decode GRA* files (2)
Download a binlog header file (http://goo.gl/kYTkY2)
Join the header and one GRA_*.log file:
–
cat GRAheader > GRA_3_3bin.log
–
cat GRA_3_3.log >> GRA_3_3bin.log
Now you can just use mysqlbinlog vvv and find
out what the problem was !
2/5/14
162. Decode GRA* files (2)
Download a binlog header file (http://goo.gl/kYTkY2)
Join the header and one GRA_*.log file:
–
cat GRAheader > GRA_3_3bin.log
–
cat GRA_3_3.log >> GRA_3_3bin.log
Now you can just use mysqlbinlog vvv and find
out what the problem was !
2/5/14
163. Decode GRA* files (2)
Download a binlog header file (http://goo.gl/kYTkY2)
Join the header and one GRA_*.log file:
–
cat GRAheader > GRA_3_3bin.log
–
cat GRA_3_3.log >> GRA_3_3bin.log
Now you can just use mysqlbinlog vvv and find
out what the problem was !
wsrep_log_conflicts = 1
wsrep_debug = 1
wsrep_provider_options = “cert.log_conflicts=1”
2/5/14
166. Avoiding SST when adding a new node
It's possible to use a backup to prepare a new
node.
Those are the 3 prerequisites:
–
–
–
2/5/14
use XtraBackup >= 2.0.1
the backup needs to be performed with
galerainfo
the gcache must be large enough
167. Avoiding SST when adding a new node
It's possible to use a backup to prepare a new
node.
Those are the 3 prerequisites:
–
–
–
2/5/14
use XtraBackup >= 2.0.1
the backup needs to be performed with
galerainfo
the gcache must be large enough
168. Avoiding SST when adding a new node
It's possible to use a backup to prepare a new
node.
Those are the 3 prerequisites:
–
–
–
2/5/14
use XtraBackup >= 2.0.1
the backup needs to be performed with
galerainfo
the gcache must be large enough
169. Avoiding SST when adding a new node
It's possible to use a backup to prepare a new
node.
Those are the 3 prerequisites:
–
–
–
2/5/14
use XtraBackup >= 2.0.1
the backup needs to be performed with
galerainfo
the gcache must be large enough
170. Avoiding SST when adding a new node
It's possible to use a backup to prepare a new
node.
Those are the 3 prerequisites:
–
–
–
2/5/14
use XtraBackup >= 2.0.1
the backup needs to be performed with
galerainfo
the gcache must be large enough
172. Avoiding SST when adding a new node (2)
Restore the backup on the new node
Display the content of xtrabackup_galera_info:
5f22b204dc6b11e108007a9c9624dd66:23
Create the file called grastate.dat like this:
#GALERA saved state
version: 2.1
uuid:5f22b204dc6b11e108007a9c9624dd66
seqno: 23
cert_index:
2/5/14
173. Avoiding SST when adding a new node (2)
Restore the backup on the new node
Display the content of xtrabackup_galera_info:
5f22b204dc6b11e108007a9c9624dd66:23
Create the file called grastate.dat like this:
#GALERA saved state
version: 2.1
uuid:5f22b204dc6b11e108007a9c9624dd66
seqno: 23
cert_index:
2/5/14
174. Avoiding SST when adding a new node (2)
Restore the backup on the new node
Display the content of xtrabackup_galera_info:
5f22b204dc6b11e108007a9c9624dd66:23
Create the file called grastate.dat like this:
#GALERA saved state
version: 2.1
uuid:5f22b204dc6b11e108007a9c9624dd66
seqno: 23
cert_index:
2/5/14
175. Avoiding SST when adding a new node (2)
Restore the backup on the new node
Display the content of xtrabackup_galera_info:
5f22b204dc6b11e108007a9c9624dd66:23
Create the file called grastate.dat like this:
#GALERA saved state
version: 2.1
uuid:5f22b204dc6b11e108007a9c9624dd66
seqno: 23
cert_index:
2/5/14
176. Avoiding SST when adding a new node (2)
Restore the backup on the new node
Display the content of xtrabackup_galera_info:
5f22b204dc6b11e108007a9c9624dd66:23
Create the file called grastate.dat like this:
#GALERA saved state
version: 2.1
uuid:5f22b204dc6b11e108007a9c9624dd66
seqno: 23
cert_index:
2/5/14
177. Avoiding SST when adding a new node (2)
Restore the backup on the new node
Display the content of xtrabackup_galera_info:
5f22b204dc6b11e108007a9c9624dd66:23
mysql> show global status like 'wsrep_provider_version';
+++
| Variable_name | Value |
+++
| wsrep_provider_version | 2.1(r113) |
+++
Create the file called grastate.dat like this:
#GALERA saved state
version: 2.1
uuid:5f22b204dc6b11e108007a9c9624dd66
seqno: 23
cert_index:
2/5/14
180. Play with quorum and weight
Galera manages Quorum
If a node does not see more than 50% of the total
amount of nodes, reads/writes are not accepted
Split brain is prevented
This requires at least 3 nodes to work properly
Can be disabled (but be warned!)
You can cheat ;-)
2/5/14
181. Play with quorum and weight
Galera manages Quorum
If a node does not see more than 50% of the total
amount of nodes, reads/writes are not accepted
Split brain is prevented
This requires at least 3 nodes to work properly
Can be disabled (but be warned!)
You can cheat ;-)
2/5/14
182. Play with quorum and weight
Galera manages Quorum
If a node does not see more than 50% of the total
amount of nodes, reads/writes are not accepted
Split brain is prevented
This requires at least 3 nodes to work properly
Can be disabled (but be warned!)
You can cheat ;-)
2/5/14
183. Play with quorum and weight
Galera manages Quorum
If a node does not see more than 50% of the total
amount of nodes, reads/writes are not accepted
Split brain is prevented
This requires at least 3 nodes to work properly
Can be disabled (but be warned!)
You can cheat ;-)
2/5/14
184. Play with quorum and weight
Galera manages Quorum
If a node does not see more than 50% of the total
amount of nodes, reads/writes are not accepted
Split brain is prevented
This requires at least 3 nodes to work properly
Can be disabled (but be warned!)
You can cheat ;-)
2/5/14
185. Play with quorum and weight
Galera manages Quorum
If a node does not see more than 50% of the total
amount of nodes, reads/writes are not accepted
Split brain is prevented
This requires at least 3 nodes to work properly
Can be disabled (but be warned!)
You can cheat ;-)
2/5/14
194. Quorum: arbitrator
It's possible to use an arbitrator (garbd) to play
an extra node. All traffic will pass through it
but it won't have any MySQL running.
Useful in case of storage available only for 2
nodes or if you have an even amount of
nodes.
Odd number of nodes is always advised
2/5/14
195. Quorum: arbitrator
It's possible to use an arbitrator (garbd) to play
an extra node. All traffic will pass through it
but it won't have any MySQL running.
Useful in case of storage available only for 2
nodes or if you have an even amount of
nodes.
Odd number of nodes is always advised
2/5/14
196. Quorum: arbitrator
It's possible to use an arbitrator (garbd) to play
an extra node. All traffic will pass through it
but it won't have any MySQL running.
Useful in case of storage available only for 2
nodes or if you have an even amount of
nodes.
Odd number of nodes is always advised
2/5/14
198. Quorum: cheat !
You can disable quorum but watch out ! (you have
been warned):
wsrep_provider_options = “pc.ignore_quorum=true”
You can define the weigth of a node to affect the
quorum calculation (default is 1):
wsrep_provider_options = “pc.weight=1”
2/5/14
199. Quorum: cheat !
You can disable quorum but watch out ! (you have
been warned):
wsrep_provider_options = “pc.ignore_quorum=true”
You can define the weigth of a node to affect the
quorum calculation (default is 1):
wsrep_provider_options = “pc.weight=1”
2/5/14
200. Quorum: cheat !
You can disable quorum but watch out ! (you have
been warned):
wsrep_provider_options = “pc.ignore_quorum=true”
You can define the weigth of a node to affect the
quorum calculation (default is 1):
wsrep_provider_options = “pc.weight=1”
2/5/14
201. Quorum: cheat !
You can disable quorum but watch out ! (you have
been warned):
wsrep_provider_options = “pc.ignore_quorum=true”
You can define the weigth of a node to affect the
quorum calculation (default is 1):
wsrep_provider_options = “pc.weight=1”
2/5/14
202. Quorum: cheat !
You can disable quorum but watch out ! (you have
been warned):
wsrep_provider_options = “pc.ignore_quorum=true”
You can define the weigth of a node to affect the
quorum calculation (default is 1):
wsrep_provider_options = “pc.weight=1”
2/5/14
204. How to optimize WAN replication?
Galera 2 requires all point-to-point connections for
replication
datacenter A
2/5/14
datacenter B
205. How to optimize WAN replication?
Galera 2 requires all point-to-point connections for
replication
datacenter A
2/5/14
datacenter B
206. How to optimize WAN replication?
Galera 2 requires all point-to-point connections for
replication
datacenter A
2/5/14
datacenter B
207. How to optimize WAN replication?
Galera 2 requires all point-to-point connections for
replication
datacenter A
2/5/14
datacenter B
208. How to optimize WAN replication?
Galera 2 requires all point-to-point connections for
replication
datacenter A
2/5/14
datacenter B
209. How to optimize WAN replication?
Galera 2 requires all point-to-point connections for
replication
datacenter A
2/5/14
datacenter B
210. How to optimize WAN replication?
Galera 2 requires all point-to-point connections for
replication
datacenter A
2/5/14
datacenter B
211. How to optimize WAN replication?
Galera 2 requires all point-to-point connections for
replication
datacenter A
2/5/14
datacenter B
212. How to optimize WAN replication? (2)
Galera 3 brings the notion of “cluster segments”
datacenter A
2/5/14
datacenter B
213. How to optimize WAN replication? (3)
Segments gateways can change per transaction
datacenter A
2/5/14
datacenter B
214. How to optimize WAN replication? (3)
Replication traffic between segments is mimized.
Writesets are relayed to the other segment
through one node
commit
WS
datacenter A
2/5/14
datacenter B
215. How to optimize WAN replication? (3)
Replication traffic between segments is mimized.
Writesets are relayed to the other segment
through one node
commit
WS
datacenter A
2/5/14
WS
WS
datacenter B
216. How to optimize WAN replication? (4)
From those local relays replication is propagated to
every nodes in the segment
commit
WS
datacenter A
2/5/14
datacenter B
WS
217. How to optimize WAN replication? (4)
From those local relays replication is propagated to
every nodes in the segment
commit
gmcasts.segment = 1...255
WS
datacenter A
2/5/14
datacenter B
WS
220. Load balancers
Galera is generally used in combination with a
load balancer
The most used is HA Proxy
Codership provides one with Galera: glbd
2/5/14
221. Load balancers
Galera is generally used in combination with a
load balancer
The most used is HA Proxy
Codership provides one with Galera: glbd
2/5/14
222. Load balancers
Galera is generally used in combination with a
load balancer
The most used is HA Proxy
Codership provides one with Galera: glbd
2/5/14
223. Load balancers
Galera is generally used in combination with a
load balancer
The most used is HA Proxy
Codership provides one with Galera: glbd
app 1
app 2
app 3
HA PROXY
2/5/14
node 1
node 2
node 3
225. Load balancers: myths, legends and reality
TIME_WAIT
–
On heavy load, you may have an issue with a large amount of
TCP connections in TIME_WAIT state
–
This can leas to a TCP port exhaustion !
How to fix ?
–
–
2/5/14
Use nolinger option in HA Proxy (for glbd check
http://www.lefred.be/node/168), but this lead to an increase
of Aborted_clients is the client is connecting and
disconnecting to MySQL too fast
Modify the value of tcp_max_tw_buckets
226. Load balancers: myths, legends and reality
TIME_WAIT
–
On heavy load, you may have an issue with a large amount of
TCP connections in TIME_WAIT state
–
This can leas to a TCP port exhaustion !
How to fix ?
–
–
2/5/14
Use nolinger option in HA Proxy (for glbd check
http://www.lefred.be/node/168), but this lead to an increase
of Aborted_clients is the client is connecting and
disconnecting to MySQL too fast
Modify the value of tcp_max_tw_buckets
227. Load balancers: myths, legends and reality
TIME_WAIT
–
On heavy load, you may have an issue with a large amount of
TCP connections in TIME_WAIT state
–
This can leas to a TCP port exhaustion !
How to fix ?
–
–
2/5/14
Use nolinger option in HA Proxy (for glbd check
http://www.lefred.be/node/168), but this lead to an increase
of Aborted_clients is the client is connecting and
disconnecting to MySQL too fast
Modify the value of tcp_max_tw_buckets
228. Load balancers: myths, legends and reality
TIME_WAIT
–
On heavy load, you may have an issue with a large amount of
TCP connections in TIME_WAIT state
–
This can leas to a TCP port exhaustion !
How to fix ?
–
–
2/5/14
Use nolinger option in HA Proxy (for glbd check
http://www.lefred.be/node/168), but this lead to an increase
of Aborted_clients is the client is connecting and
disconnecting to MySQL too fast
Modify the value of tcp_max_tw_buckets
229. Load balancers: myths, legends and reality
TIME_WAIT
–
On heavy load, you may have an issue with a large amount of
TCP connections in TIME_WAIT state
–
This can leas to a TCP port exhaustion !
How to fix ?
–
–
2/5/14
Use nolinger option in HA Proxy (for glbd check
http://www.lefred.be/node/168), but this lead to an increase
of Aborted_clients is the client is connecting and
disconnecting to MySQL too fast
Modify the value of tcp_max_tw_buckets
230. Load balancers: myths, legends and reality
TIME_WAIT
–
On heavy load, you may have an issue with a large amount of
TCP connections in TIME_WAIT state
–
This can leas to a TCP port exhaustion !
How to fix ?
–
–
2/5/14
Use nolinger option in HA Proxy (for glbd check
http://www.lefred.be/node/168), but this lead to an increase
of Aborted_clients is the client is connecting and
disconnecting to MySQL too fast
Modify the value of tcp_max_tw_buckets
231. Load balancers: common issues
Persitent Connections
–
Many people expects the following scenario:
app 1
app 2
HA PROXY
node 1
2/5/14
node 2
node 3
app 3
232. Load balancers: common issues
Persitent Connections
–
When the node that was specified to receive the persistent
write fails for example
app 1
app 2
HA PROXY
node 1
2/5/14
node 2
node 3
app 3
233. Load balancers: common issues
Persitent Connections
–
When the node is back on-line...
app 1
app 2
HA PROXY
node 1
2/5/14
node 2
node 3
app 3
234. Load balancers: common issues
Persitent Connections
–
Only the new connections will use again the preferred node
app 1
app 2
HA PROXY
node 1
2/5/14
node 2
node 3
app 3
235. Load balancers: common issues
Persitent Connections
–
Only the new connections will use again the preferred node
app 1
app 2
HA PROXY
node 1
2/5/14
node 2
node 3
app 3
236. Load balancers: common issues
Persitent Connections
–
Only the new connections will use again the preferred node
app 1
app 2
HA PROXY
node 1
2/5/14
node 2
node 3
app 3
238. Load balancers: common issues
Persitent Connections
–
–
HA Proxy decides where the connection will go at TCP
handshake
Once the TCP session is established, the sessions will stay
where they are !
Solution ?
–
With HA Proxy 1.5 you can now specify the following option :
onmarkeddown shutdownsessions
2/5/14
239. Load balancers: common issues
Persitent Connections
–
–
HA Proxy decides where the connection will go at TCP
handshake
Once the TCP session is established, the sessions will stay
where they are !
Solution ?
–
With HA Proxy 1.5 you can now specify the following option :
onmarkeddown shutdownsessions
2/5/14
240. Load balancers: common issues
Persitent Connections
–
–
HA Proxy decides where the connection will go at TCP
handshake
Once the TCP session is established, the sessions will stay
where they are !
Solution ?
–
With HA Proxy 1.5 you can now specify the following option :
onmarkeddown shutdownsessions
2/5/14
241. Load balancers: common issues
Persitent Connections
–
–
HA Proxy decides where the connection will go at TCP
handshake
Once the TCP session is established, the sessions will stay
where they are !
Solution ?
–
With HA Proxy 1.5 you can now specify the following option :
onmarkeddown shutdownsessions
2/5/14
242. Load balancers: common issues
Persitent Connections
–
–
HA Proxy decides where the connection will go at TCP
handshake
Once the TCP session is established, the sessions will stay
where they are !
Solution ?
–
With HA Proxy 1.5 you can now specify the following option :
onmarkeddown shutdownsessions
2/5/14
243. Load balancers: common issues
Persitent Connections
–
–
HA Proxy decides where the connection will go at TCP
handshake
Once the TCP session is established, the sessions will stay
where they are !
Solution ?
–
With HA Proxy 1.5 you can now specify the following option :
onmarkeddown shutdownsessions
2/5/14
246. Taking backups without stalls
When you want to perform a consistent
backup, you need to take a FLUSH TABLES
WITH READ LOCK (FTWRL)
By default even with Xtrabackup
This causes a Flow Control in galera
So how can we deal with that ?
2/5/14
247. Taking backups without stalls
When you want to perform a consistent
backup, you need to take a FLUSH TABLES
WITH READ LOCK (FTWRL)
By default even with Xtrabackup
This causes a Flow Control in galera
So how can we deal with that ?
2/5/14
248. Taking backups without stalls
When you want to perform a consistent
backup, you need to take a FLUSH TABLES
WITH READ LOCK (FTWRL)
By default even with Xtrabackup
This causes a Flow Control in galera
So how can we deal with that ?
2/5/14
249. Taking backups without stalls
When you want to perform a consistent
backup, you need to take a FLUSH TABLES
WITH READ LOCK (FTWRL)
By default even with Xtrabackup
This causes a Flow Control in galera
So how can we deal with that ?
2/5/14
251. Taking backups without stalls
Choose the node from which you want to take the backup
Change the state to 'Donor/Desynced' (see tip 9)
set global wsrep_desync=ON
Take the backup
Wait that wsrep_local_recv_queue is back
down to 0
Change back the state to 'Joined'
set global wsrep_desync=OFF
2/5/14
252. Taking backups without stalls
Choose the node from which you want to take the backup
Change the state to 'Donor/Desynced' (see tip 9)
set global wsrep_desync=ON
Take the backup
Wait that wsrep_local_recv_queue is back
down to 0
Change back the state to 'Joined'
set global wsrep_desync=OFF
2/5/14
253. Taking backups without stalls
Choose the node from which you want to take the backup
Change the state to 'Donor/Desynced' (see tip 9)
set global wsrep_desync=ON
Take the backup
Wait that wsrep_local_recv_queue is back
down to 0
Change back the state to 'Joined'
set global wsrep_desync=OFF
2/5/14
254. Taking backups without stalls
Choose the node from which you want to take the backup
Change the state to 'Donor/Desynced' (see tip 9)
set global wsrep_desync=ON
Take the backup
Wait that wsrep_local_recv_queue is back
down to 0
Change back the state to 'Joined'
set global wsrep_desync=OFF
2/5/14
255. Taking backups without stalls
Choose the node from which you want to take the backup
Change the state to 'Donor/Desynced' (see tip 9)
set global wsrep_desync=ON
Take the backup
Wait that wsrep_local_recv_queue is back
down to 0
Change back the state to 'Joined'
set global wsrep_desync=OFF
2/5/14
256. Taking backups without stalls
Choose the node from which you want to take the backup
Change the state to 'Donor/Desynced' (see tip 9)
set global wsrep_desync=ON
Take the backup
Wait that wsrep_local_recv_queue is back
down to 0
Change back the state to 'Joined'
set global wsrep_desync=OFF
2/5/14
257. Taking backups without stalls
Choose the node from which you want to take the backup
Change the state to 'Donor/Desynced' (see tip 9)
set global wsrep_desync=ON
Take the backup
Wait that wsrep_local_recv_queue is back
down to 0
Change back the state to 'Joined'
set global wsrep_desync=OFF
2/5/14