This document discusses MySQL multi-source replication, which enables a replication slave to receive transactions from multiple masters simultaneously. It provides configuration steps for setting up a MariaDB/Percona Server database as a multi-source replication slave, including ensuring unique server IDs and GTID domains for each master, defining replication connections, and enabling parallel replication threads to optimize transaction processing from multiple sources.
Wars of MySQL Cluster ( InnoDB Cluster VS Galera ) Mydbops
MySQL Clustering over InnoDB engines has grown a lot over the last decade. Galera began working with InnoDB early and then Group Replication came to the environment later, where the features are now rich and robust. This presentation offers a technical comparison of both of them.
ProxySQL High Avalability and Configuration Management OverviewRené Cannaò
The document provides an overview of high availability and configuration management options for ProxySQL. It discusses deploying ProxySQL locally on application servers, in a dedicated layer, or using both approaches. When deploying in a dedicated layer, options for high availability include keepalived, load balancers, Consul, and Kubernetes. Configuration can be managed through tools like Ansible, Puppet, or by loading SQL files. ProxySQL Cluster enables syncing configuration across nodes.
The document discusses the Performance Schema in MySQL. It provides an overview of what the Performance Schema is and how it can be used to monitor events within a MySQL server. It also describes how to configure the Performance Schema by setting up actors, objects, instruments, consumers and threads to control what is monitored. Finally, it explains how to initialize the Performance Schema by truncating existing summary tables before collecting new performance data.
Get Your Insecure PostgreSQL Passwords to SCRAMJonathan Katz
Passwords: they just seem to work. You connect to your PostgreSQL database and you are prompted for your password. You type in the correct character combination, and presto! you're in, safe and sound.
But what if I told you that all was not as it seemed. What if I told you there was a better, safer way to use passwords with PostgreSQL? What if I told you it was imperative that you upgraded, too?
PostgreSQL 10 introduced SCRAM (Salted Challenge Response Authentication Mechanism), introduced in RFC 5802, as a way to securely authenticate passwords. The SCRAM algorithm lets a client and server validate a password without ever sending the password, whether plaintext or a hashed form of it, to each other, using a series of cryptographic methods.
In this talk, we will look at:
* A history of the evolution of password storage and authentication in PostgreSQL
* How SCRAM works with a step-by-step deep dive into the algorithm (and convince you why you need to upgrade!)
* SCRAM channel binding, which helps prevent MITM attacks during authentication
* How to safely set and modify your passwords, as well as how to upgrade to SCRAM-SHA-256 (which we will do live!)
all of which will be explained by some adorable elephants and hippos!
At the end of this talk, you will understand how SCRAM works, how to ensure your PostgreSQL drivers supports it, how to upgrade your passwords to using SCRAM-SHA-256, and why you want to tell other PostgreSQL password mechanisms to SCRAM!
MariaDB Server Performance Tuning & OptimizationMariaDB plc
This document discusses various techniques for optimizing MariaDB server performance, including:
- Tuning configuration settings like the buffer pool size, query cache size, and thread pool settings.
- Monitoring server metrics like CPU usage, memory usage, disk I/O, and MariaDB-specific metrics.
- Analyzing slow queries with the slow query log and EXPLAIN statements to identify optimization opportunities like adding indexes.
This presentation covers MySQL data encryption at disk. How to encrypt all tablespaces and MySQL related files for the compliances ? The new releases in MySQL 8.0 take care of the encryption of the system tablespace and supporting tables unlike MySQL 5.7.
MariaDB Performance Tuning and OptimizationMariaDB plc
This document discusses MariaDB performance tuning and optimization. It covers common principles like tuning from the start of application development. Specific topics discussed include server hardware, OS settings, MariaDB configuration settings like innodb_buffer_pool_size, database design best practices, and query monitoring and tuning tools. The overall goal is to efficiently use hardware resources, ensure best performance for users, and avoid outages.
Wars of MySQL Cluster ( InnoDB Cluster VS Galera ) Mydbops
MySQL Clustering over InnoDB engines has grown a lot over the last decade. Galera began working with InnoDB early and then Group Replication came to the environment later, where the features are now rich and robust. This presentation offers a technical comparison of both of them.
ProxySQL High Avalability and Configuration Management OverviewRené Cannaò
The document provides an overview of high availability and configuration management options for ProxySQL. It discusses deploying ProxySQL locally on application servers, in a dedicated layer, or using both approaches. When deploying in a dedicated layer, options for high availability include keepalived, load balancers, Consul, and Kubernetes. Configuration can be managed through tools like Ansible, Puppet, or by loading SQL files. ProxySQL Cluster enables syncing configuration across nodes.
The document discusses the Performance Schema in MySQL. It provides an overview of what the Performance Schema is and how it can be used to monitor events within a MySQL server. It also describes how to configure the Performance Schema by setting up actors, objects, instruments, consumers and threads to control what is monitored. Finally, it explains how to initialize the Performance Schema by truncating existing summary tables before collecting new performance data.
Get Your Insecure PostgreSQL Passwords to SCRAMJonathan Katz
Passwords: they just seem to work. You connect to your PostgreSQL database and you are prompted for your password. You type in the correct character combination, and presto! you're in, safe and sound.
But what if I told you that all was not as it seemed. What if I told you there was a better, safer way to use passwords with PostgreSQL? What if I told you it was imperative that you upgraded, too?
PostgreSQL 10 introduced SCRAM (Salted Challenge Response Authentication Mechanism), introduced in RFC 5802, as a way to securely authenticate passwords. The SCRAM algorithm lets a client and server validate a password without ever sending the password, whether plaintext or a hashed form of it, to each other, using a series of cryptographic methods.
In this talk, we will look at:
* A history of the evolution of password storage and authentication in PostgreSQL
* How SCRAM works with a step-by-step deep dive into the algorithm (and convince you why you need to upgrade!)
* SCRAM channel binding, which helps prevent MITM attacks during authentication
* How to safely set and modify your passwords, as well as how to upgrade to SCRAM-SHA-256 (which we will do live!)
all of which will be explained by some adorable elephants and hippos!
At the end of this talk, you will understand how SCRAM works, how to ensure your PostgreSQL drivers supports it, how to upgrade your passwords to using SCRAM-SHA-256, and why you want to tell other PostgreSQL password mechanisms to SCRAM!
MariaDB Server Performance Tuning & OptimizationMariaDB plc
This document discusses various techniques for optimizing MariaDB server performance, including:
- Tuning configuration settings like the buffer pool size, query cache size, and thread pool settings.
- Monitoring server metrics like CPU usage, memory usage, disk I/O, and MariaDB-specific metrics.
- Analyzing slow queries with the slow query log and EXPLAIN statements to identify optimization opportunities like adding indexes.
This presentation covers MySQL data encryption at disk. How to encrypt all tablespaces and MySQL related files for the compliances ? The new releases in MySQL 8.0 take care of the encryption of the system tablespace and supporting tables unlike MySQL 5.7.
MariaDB Performance Tuning and OptimizationMariaDB plc
This document discusses MariaDB performance tuning and optimization. It covers common principles like tuning from the start of application development. Specific topics discussed include server hardware, OS settings, MariaDB configuration settings like innodb_buffer_pool_size, database design best practices, and query monitoring and tuning tools. The overall goal is to efficiently use hardware resources, ensure best performance for users, and avoid outages.
This document provides an overview and instructions for installing and configuring ProxySQL. It discusses:
1. What ProxySQL is and its functions like load balancing and query caching
2. How to install ProxySQL on CentOS and configure the /etc/proxysql.cnf file
3. How to set up the ProxySQL schema to define servers, users, variables and other settings needed for operation
4. How to test ProxySQL functions like server status changes and benchmark performance
The document discusses MySQL Shell and how it can help database administrators (DBAs) with common tasks like deploying architectures, preparing upgrades, dumping and loading data, and managing users. MySQL Shell provides tools like the Admin API for configuring MySQL clusters and replicasets, an upgrade checker utility to validate upgrades to MySQL 8.0, and parallel dump and load functionality to backup, migrate, and reset data.
The presentation covers improvements made to the redo logs in MySQL 8.0 and their impact on the MySQL performance and Operations. This covers the MySQL version still MySQL 8.0.30.
MySQL 8.0 is the latest Generally Available version of MySQL. This session will help you upgrade from older versions, understand what utilities are available to make the process smoother and also understand what you need to bear in mind with the new version and considerations for possible behavior changes and solutions.
We talk a lot about Galera Cluster being great for High Availability, but what about Disaster Recovery (DR)? Database outages can occur when you lose a data centre due to data center power outages or natural disaster, so why not plan appropriately in advance?
In this webinar, we will discuss the business considerations including achieving the highest possible uptime, analysis business impact as well as risk, focus on disaster recovery itself, as well as discussing various scenarios, from having no offsite data to having synchronous replication to another data centre.
This webinar will cover MySQL with Galera Cluster, as well as branches MariaDB Galera Cluster as well as Percona XtraDB Cluster (PXC). We will focus on architecture solutions, DR scenarios and have you on your way to success at the end of it.
This is the presentation delivered by Karthik.P.R at MySQL User Camp Bangalore on 09th June 2017. ProxySQL is a high performance MySQL Load Balancer Designed to scale database servers.
Reduce Storage Costs by 5x Using The New HDFS Tiered Storage Feature DataWorks Summit
This document discusses how HDFS tiered storage can be used to reduce storage costs by 5x. It introduces the new HDFS storage model that supports multiple storage types like ARCHIVE, DISK, SSD, and RAM_DISK. Block storage policies like HOT, WARM, and COLD can be defined to control where blocks are stored. eBay uses HDFS tiered storage to archive older data to cheaper ARCHIVE nodes, analyzing access patterns to define archival policies. Data is moved between storage types using the HDFS mover tool while maintaining replication and rack requirements.
Optimizing MariaDB for maximum performanceMariaDB plc
When it comes to optimizing the performance of a database, DBAs have to look at everything from the OS to the network. In this session, MariaDB Enterprise Architect Manjot Singh shares best practices for getting the most out of MariaDB. He highlights recommended OS settings, important configuration and tuning parameters, options for improving replication and clustering performance and features such as query result caching.
2021년 11월 18일(목)
- 14:00 ~ 15:00 MySQL Operator for Kubernetes
: Kubernetes 환경에서 MySQL에 대한 더 쉬운 운영
- 15:00 ~ 15:15 MySQL HA and Auto-Failover
: MySQL replication과 오픈소스 MHA를 통한 고가용성 확보
MariaDB MaxScale is a database proxy that provides scalability, high availability, and data streaming capabilities for MariaDB and MySQL databases. It acts as a load balancer and router to distribute queries across database servers. MaxScale supports services like read/write splitting, query caching, and security features like selective data masking. It can monitor replication lag and route queries accordingly. MaxScale uses a plugin architecture and its core remains stateless to provide flexibility and high performance.
MariaDB 10.5 binary install (바이너리 설치)
- 네오클로바 DB지원사업부
1. About MariaDB
1.1 MariaDB 개요
1.2 MariaDB as a R-DBMS
1.3 Open Source Database System
2. 설치
2.1 설치 기본 정보
2.2 설치 준비
2.3 MariaDB 설치
2.4 MariaDB 시작 / 접속 / 종료
2.5 추가 설정
MaxScale is a database proxy that provides high availability and scalability for MariaDB servers. It can be used to configure load balancing of read/write connections, auto failover/switchover/rejoin using MariaDB GTID replication. Keepalived can be used with MaxScale to provide high availability by monitoring MaxScale and failing over if needed. The document provides details on setting up MariaDB replication with GTID, installing and configuring MaxScale and Keepalived. It also describes testing the auto failover functionality.
MySQL InnoDB Cluster - A complete High Availability solution for MySQLOlivier DASINI
MySQL InnoDB Cluster provides a complete high availability solution for MySQL. It uses MySQL Group Replication, which allows for multiple read-write replicas of a database to exist with synchronous replication. MySQL InnoDB Cluster also includes MySQL Shell for setup, management and orchestration of the cluster, and MySQL Router for intelligent connection routing. It allows databases to scale out writes across replicas in a fault-tolerant and self-healing manner.
MySQL Database Architectures - MySQL InnoDB ClusterSet 2021-11Kenny Gryp
Oracle's MySQL solutions make it easy to setup various database architectures and achieve high availability with the introduction MySQL InnoDB Cluster and MySQL InnoDB ReplicaSet meeting various high availability requirements. MySQL InnoDB ClusterSet provides a popular disaster recovery solution.
Completely built in-house and supported by Oracle, many enterprises large and small have adopted these solutions into business critical applications.
In this presentation the various database architecture solutions for high availability and disaster recovery will be covered and help you choose the right solutions based on your business requirements.
MySQL Replication: What’s New in MySQL 5.7 and BeyondAndrew Morgan
Continuing in the footsteps of its predecessor, MySQL 5.7 is set to be a groundbreaking release. In this webinar, the engineers behind the product provide insights into what’s new for MySQL replication in the latest 5.7 Development Milestone Release and review the early access features available via labs.mysql.com. The next generation of replication features cover several technical areas such as better semi-synchronous replication, an enhanced multithreaded slave (per-transaction parallelism), improved monitoring with performance schema tables, online configuration changes, options for fine-tuning replication performance, support for more-advanced topologies with multisource replication, and much more. This is also a great chance to learn about MySQL Group Replication – the next generation of active-active, update-anywhere replication for MySQL.
This document provides an overview and instructions for installing and configuring ProxySQL. It discusses:
1. What ProxySQL is and its functions like load balancing and query caching
2. How to install ProxySQL on CentOS and configure the /etc/proxysql.cnf file
3. How to set up the ProxySQL schema to define servers, users, variables and other settings needed for operation
4. How to test ProxySQL functions like server status changes and benchmark performance
The document discusses MySQL Shell and how it can help database administrators (DBAs) with common tasks like deploying architectures, preparing upgrades, dumping and loading data, and managing users. MySQL Shell provides tools like the Admin API for configuring MySQL clusters and replicasets, an upgrade checker utility to validate upgrades to MySQL 8.0, and parallel dump and load functionality to backup, migrate, and reset data.
The presentation covers improvements made to the redo logs in MySQL 8.0 and their impact on the MySQL performance and Operations. This covers the MySQL version still MySQL 8.0.30.
MySQL 8.0 is the latest Generally Available version of MySQL. This session will help you upgrade from older versions, understand what utilities are available to make the process smoother and also understand what you need to bear in mind with the new version and considerations for possible behavior changes and solutions.
We talk a lot about Galera Cluster being great for High Availability, but what about Disaster Recovery (DR)? Database outages can occur when you lose a data centre due to data center power outages or natural disaster, so why not plan appropriately in advance?
In this webinar, we will discuss the business considerations including achieving the highest possible uptime, analysis business impact as well as risk, focus on disaster recovery itself, as well as discussing various scenarios, from having no offsite data to having synchronous replication to another data centre.
This webinar will cover MySQL with Galera Cluster, as well as branches MariaDB Galera Cluster as well as Percona XtraDB Cluster (PXC). We will focus on architecture solutions, DR scenarios and have you on your way to success at the end of it.
This is the presentation delivered by Karthik.P.R at MySQL User Camp Bangalore on 09th June 2017. ProxySQL is a high performance MySQL Load Balancer Designed to scale database servers.
Reduce Storage Costs by 5x Using The New HDFS Tiered Storage Feature DataWorks Summit
This document discusses how HDFS tiered storage can be used to reduce storage costs by 5x. It introduces the new HDFS storage model that supports multiple storage types like ARCHIVE, DISK, SSD, and RAM_DISK. Block storage policies like HOT, WARM, and COLD can be defined to control where blocks are stored. eBay uses HDFS tiered storage to archive older data to cheaper ARCHIVE nodes, analyzing access patterns to define archival policies. Data is moved between storage types using the HDFS mover tool while maintaining replication and rack requirements.
Optimizing MariaDB for maximum performanceMariaDB plc
When it comes to optimizing the performance of a database, DBAs have to look at everything from the OS to the network. In this session, MariaDB Enterprise Architect Manjot Singh shares best practices for getting the most out of MariaDB. He highlights recommended OS settings, important configuration and tuning parameters, options for improving replication and clustering performance and features such as query result caching.
2021년 11월 18일(목)
- 14:00 ~ 15:00 MySQL Operator for Kubernetes
: Kubernetes 환경에서 MySQL에 대한 더 쉬운 운영
- 15:00 ~ 15:15 MySQL HA and Auto-Failover
: MySQL replication과 오픈소스 MHA를 통한 고가용성 확보
MariaDB MaxScale is a database proxy that provides scalability, high availability, and data streaming capabilities for MariaDB and MySQL databases. It acts as a load balancer and router to distribute queries across database servers. MaxScale supports services like read/write splitting, query caching, and security features like selective data masking. It can monitor replication lag and route queries accordingly. MaxScale uses a plugin architecture and its core remains stateless to provide flexibility and high performance.
MariaDB 10.5 binary install (바이너리 설치)
- 네오클로바 DB지원사업부
1. About MariaDB
1.1 MariaDB 개요
1.2 MariaDB as a R-DBMS
1.3 Open Source Database System
2. 설치
2.1 설치 기본 정보
2.2 설치 준비
2.3 MariaDB 설치
2.4 MariaDB 시작 / 접속 / 종료
2.5 추가 설정
MaxScale is a database proxy that provides high availability and scalability for MariaDB servers. It can be used to configure load balancing of read/write connections, auto failover/switchover/rejoin using MariaDB GTID replication. Keepalived can be used with MaxScale to provide high availability by monitoring MaxScale and failing over if needed. The document provides details on setting up MariaDB replication with GTID, installing and configuring MaxScale and Keepalived. It also describes testing the auto failover functionality.
MySQL InnoDB Cluster - A complete High Availability solution for MySQLOlivier DASINI
MySQL InnoDB Cluster provides a complete high availability solution for MySQL. It uses MySQL Group Replication, which allows for multiple read-write replicas of a database to exist with synchronous replication. MySQL InnoDB Cluster also includes MySQL Shell for setup, management and orchestration of the cluster, and MySQL Router for intelligent connection routing. It allows databases to scale out writes across replicas in a fault-tolerant and self-healing manner.
MySQL Database Architectures - MySQL InnoDB ClusterSet 2021-11Kenny Gryp
Oracle's MySQL solutions make it easy to setup various database architectures and achieve high availability with the introduction MySQL InnoDB Cluster and MySQL InnoDB ReplicaSet meeting various high availability requirements. MySQL InnoDB ClusterSet provides a popular disaster recovery solution.
Completely built in-house and supported by Oracle, many enterprises large and small have adopted these solutions into business critical applications.
In this presentation the various database architecture solutions for high availability and disaster recovery will be covered and help you choose the right solutions based on your business requirements.
MySQL Replication: What’s New in MySQL 5.7 and BeyondAndrew Morgan
Continuing in the footsteps of its predecessor, MySQL 5.7 is set to be a groundbreaking release. In this webinar, the engineers behind the product provide insights into what’s new for MySQL replication in the latest 5.7 Development Milestone Release and review the early access features available via labs.mysql.com. The next generation of replication features cover several technical areas such as better semi-synchronous replication, an enhanced multithreaded slave (per-transaction parallelism), improved monitoring with performance schema tables, online configuration changes, options for fine-tuning replication performance, support for more-advanced topologies with multisource replication, and much more. This is also a great chance to learn about MySQL Group Replication – the next generation of active-active, update-anywhere replication for MySQL.
Geographically Distributed Multi-Master MySQL ClustersContinuent
Global data access can greatly expand the reach of your business. Continuent's multi-site multi-master (MSMM) solutions enable applications to accept write traffic in multiple locations across on-premises and vCloud Air.
As an example, this includes the following real-world, business-critical use cases:
- Improve performance for globally distributed users registering hardware devices by permitting updates on the geographically closest site
- Ensure availability of credit card processing by spreading transaction processing across two or more sites. Users can still process credit card transactions if a single site is unavailable to them for any reason, including end-user Internet routing problems
- Enable business continuity by using multi-master updates on different hosting providers for service scalability, personalization and software upgrades of GPS devices.
Individual Continuent clusters already provide excellent single-site database availability and performance. In this webinar we review the benefits of combining multiple Continuent clusters into a global multi-site multi-master (MSMM) topology for:
- Optimizing your installation for MSMM
- Optimizing your application for MSMM
- Monitoring and administration
- Failover and recovery of individual servers or entire locations.
Multi-master, multi-region MySQL deployment in Amazon AWSContinuent
MySQL data rules the cloud, but recent experience shows us that there's no substitute for maintaining copies of data, across availability zones and regions, when it comes to Amazon Web Services (AWS) data resilience.
In this webinar, we discuss the multi-master capabilities of Continuent Tungsten to help you build and manage systems that spread data across multiple sites. We cover important topics such as setting up large scale topologies, handling failures, and how to handle data privacy issues like removing personally identifiable information or handling privacy law restrictions on data movement. We will conclude with a live demonstration of a distributed MySQL solution with Continuent Tungsten clusters working across multiple AWS availability zones and regions.
Geographically Distributed Multi-Master MySQL ClustersContinuent
In this webinar, we discuss the multi-master capabilities of Continuent Tungsten to help you build and manage systems that spread data across multiple sites. We cover important topics such as setting up large scale topologies, handling failures, and how to handle data privacy issues like removing personally identifiable information or handling privacy law restrictions on data movement. We will conclude with a live demonstration of a distributed MySQL solution with Continuent Tungsten clusters working across multiple Amazon Web Services (AWS) availability zones and regions.
Tungsten University: MySQL Multi-Master Operations Made Simple With Tungsten ...Continuent
Deployment of MySQL multi-master topologies with Tungsten Replicator has been constantly improving. Yet, earlier there were some heavy operations to sustain, and unfriendly commands to perform. The latest version of Tungsten Replicator delivers all the topologies of its predecessors, with an improved installation tool that cuts down the deployment time to half in simple topologies, and to 1/10th in complex ones. Now you can install master/slave, multi-master, fan-in, and star topologies in less than a minute.
But there is more. Thanks to a versatile Tungsten Replicator installation tool, you can define your own deployment on-the-fly, and get creative: you can have stars with satellites, all-masters with fan-in slaves, and other customized clusters.
We will also cover other enhancements in Tungsten Replicator 2.1.1, such as full integration with MySQL 5.6, enhanced output from administrative tools, a few more goodies.
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
This document summarizes and compares several solutions for multi-master replication in MySQL databases: Native MySQL replication, MySQL Cluster (NDB), Galera, and Tungsten. Native MySQL replication supports only limited topologies and has asynchronous replication. MySQL Cluster allows synchronous replication across two data centers but is limited to in-memory tables. Galera provides synchronous, row-based replication across multiple masters with automatic conflict resolution. Tungsten allows asynchronous multi-master replication to different database systems and automatic failover.
OSMC 2008 | Monitoring MySQL by Geert VanderkelenNETWAYS
Monitoring MySQL has a long history within Nagios. Several plugins are available already. In addition to that, there are probably lots of plugins that have been developed by the community. We take a look at some of these and discuss what kind of additional useful information could be pulled out of a MySQL Server for monitoring it even better. A simple example on how to write such plugins will be shown, also using NDB API for monitoring MySQL Cluster. Now that MySQL Enterprise Monitor (MEM) is available, we'll go through the possibilities for combining the two platforms. We will also discuss the NDOUtils for storing configuration and event data using MySQL.
This talk starts with a brief overview of MySQL itself: some history, where it's heading too, and why it is so successful.
This document provides an overview of GTID in MySQL 5.6. It begins by introducing GTID and its components - the server ID (SID) and transaction ID (GNO). It then discusses the problems GTID solves like replication restarts and automation. The document outlines how to implement GTID in new and existing replication topologies. It also covers repairing GTID and using it for high availability and failover.
This document discusses MySQL replication basics. Replication allows data from one master database to be synchronized to multiple slave databases. The master writes transactions to its binary log which are replicated to slaves. Each node has a unique ID. Slaves pull data from the master's binary logs and execute the transactions locally. Replication can be used for load balancing, high availability, or backups of the master database.
This document discusses MySQL replication basics. Replication allows data from one master database to be replicated to multiple slave databases. The master writes transactions to its binary log which are then read and replicated to slaves via each slave's replication threads. Replication can be used for load balancing, high availability, and backups. Configuration involves assigning server IDs, enabling binary logging on the master, and slaves reading the master's binary log.
Advanced Query Optimizer Tuning and AnalysisMYXPLAIN
The document discusses techniques for identifying and addressing problems with a database query optimizer. It describes how to use tools like the slow query log, SHOW PROCESSLIST, and PERFORMANCE SCHEMA to find slow queries and examine their execution plans. The document provides examples of analyzing queries, identifying inefficient plans, and determining appropriate actions like rewriting queries or adjusting optimizer settings.
This document summarizes information about scaling out MariaDB server and cluster with MaxScale. It discusses the ReadWriteSplit and ConnectionRoute routers for scaling out a MariaDB server replication topology. It also discusses using the Galera Monitor and ReadWriteSplit modules to scale out a MariaDB Cluster deployment with MaxScale. Configurations are provided for using these routers and monitors with MaxScale.
The document discusses new features in MySQL 5.6 replication including:
1) Crash-safe slaves that store replication information in database tables to prevent data loss if slaves crash.
2) Multi-threaded slaves that improve performance by distributing the replication workload across multiple threads.
3) Time-delayed replication that allows replication to be delayed by a configurable number of seconds.
4) Optimized row-based replication that reduces the size of binary logs by only replicating changed columns where possible.
Replication allows data to be shared between multiple MySQL databases. The master database records all changes in binary logs which are used to replicate data to slave databases. Slaves pull data from the master's binary logs and execute the same statements locally to match the master's data. This allows for high availability, load balancing, and off-site processing capabilities.
The MySQL sys schema was integrated fully into MySQL Server from version 5.7.7 and has been improved in MySQL 8.0. Whether you are a DBA trying to determine where the resources are being used on your database instance and by whom, or a developer trying to figure out why your MySQL statements are running too slowly, the MySQL sys schema can help. Join this session to learn how to better use the MySQL sys schema to answer your day-to-day questions—from the original developer of the MySQL sys schema.
The document discusses MySQL monitoring using various tools and techniques. It covers basic monitoring of system resources and database health using commands like top, mytop and check_mysql. It also discusses advanced monitoring solutions like Nagios plugins, MySQL Activity Report, CACTI and Munin for more in-depth performance and replication monitoring. Specifically, it provides details on using the Nagios check_mysql_health plugin to monitor various MySQL metrics and parameters.
The document discusses several new features and enhancements in Oracle Database 11g Release 1. Key points include:
1) Encrypted tablespaces allow full encryption of data while maintaining functionality like indexing and foreign keys.
2) New caching capabilities improve performance by caching more results and metadata to avoid repeat work.
3) Standby databases have been enhanced and can now be used for more active purposes like development, testing, reporting and backups while still providing zero data loss protection.
The document discusses new features in Oracle Database 11g Release 1. Key points include:
1. Encrypted tablespaces allow encryption of data at the tablespace level while still supporting indexing and queries.
2. New caching capabilities improve performance by caching more results in memory, such as function results and query results.
3. Standby databases have enhanced capabilities and can now be used for more active purposes like development, testing and reporting for increased usability and value.
MySQL/MariaDB Parallel Replication: inventory, use-case and limitationsJean-François Gagné
- The document discusses various parallel replication technologies in MySQL/MariaDB including schema-based parallel replication in MySQL 5.6, group commit-based approaches in MariaDB 10.0 and MySQL 5.7, and optimistic parallel replication in MariaDB 10.1.
- It provides an overview of how each approach tags and dispatches transactions to worker threads on slaves and their limitations regarding transaction ordering and gaps.
- Examples from Booking.com show how parallel replication can scale to thousands of servers but also hit issues like long transactions blocking progress.
- Drizzle is an open source database that is compatible with MySQL and aims to be faster and more scalable.
- The document discusses how to install Drizzle, differences from MySQL like unsupported features and data types, and how to migrate data from MySQL to Drizzle using the drizzledump tool which converts the schema and data.
- Issues that may occur during migration like character set problems are addressed, and future plans like replication from MySQL to Drizzle are mentioned.
1) MySQL live migration involves a 3 step process of taking a baseline dump/snapshot from the source database, setting up replication between the source and destination for continuous data movement, and finally performing a switchover to migrate to the destination.
2) The baseline dump uses mysqldump to export data, users, privileges and stored objects from the source and import to the destination. The --master-data option captures binary log coordinates for setting up replication.
3) Replication is setup using the binary log coordinates to synchronize data between the source and destination. Monitoring replication status ensures the destination lag is low before switchover.
MySQL and MariaDB implementations of multi-source replication allow a slave server to replicate from multiple master servers simultaneously. MySQL 5.7 introduced multi-source replication using new CHANNEL syntax for CHANGE MASTER, SHOW SLAVE STATUS, and START/STOP SLAVE commands. MariaDB 10 implemented it similarly with new CHANNEL syntax. Both require global transaction identifiers and crash-safe tables to be enabled. Monitoring information is now split into separate records for each master in SHOW SLAVE STATUS.
MySQLinsanity! This document provides an overview of Stanley Huang's MySQL performance tuning experience and expertise. It begins with introductions and background on Stanley Huang. It then discusses the typical phases of MySQL performance tuning projects, including SQL tuning and RDBMS tuning. Specific tips are provided around topics like slow query logging, index usage, partitioning, and server configuration. The document concludes with an invitation for questions.
Similar to MySQL Multi-Source Replication for PL2016 (20)
Migrations from PLSQL and Transact-SQL - m18Wagner Bianchi
Check out the status of the current features supported by MariaDB Server 10.3 and the best practices brought to the marketplace by MariaDB Practitioners for migrating Oracle and SQL Server to MariaDB Server. Also, some of the many features related to the PL/SQL is exhibited in this presentation. You can watch the presentation's video at https://www.linkedin.com/feed/update/urn:li:activity:6381185127497625601
Maxscale switchover, failover, and auto rejoinWagner Bianchi
How the MariaDB Maxscale Switchover, Failover, and Rejoin works under the hood by Esa Korhonen and Wagner Bianchi.
You can watch the video of the presentation at
https://www.linkedin.com/feed/update/urn:li:activity:6381185640607809536
Meetup São Paulo, Maxscale Implementação e Casos de UsoWagner Bianchi
Este documento apresenta:
1) Wagner Bianchi, palestrante sobre MaxScale 2.0;
2) A agenda inclui instalação e configuração do MaxScale para ReadWriteSplit, Schemarouter e Binlogrouter;
3) É fornecido um Vagrantfile para criar ambientes virtuais com MariaDB e configurar o MaxScale.
Webinar: MariaDB Provides the Solution to Ease Multi-Source ReplicationWagner Bianchi
MariaDB provides the solution to ease Multi-Source Replication aimed to show up the main characteristics of the
feature that was lunched together with MariaDB 10.0.1.
O documento descreve os processos de replicação de dados no MySQL, comparando as abordagens clássica e GTID. Ele explica como configurar a replicação em ambos os modelos, destacando que a replicação GTID é mais recente e oferece vantagens como fácil configuração e recuperação.
1) O documento discute transações em bancos de dados, definindo-as como unidades lógicas de trabalho envolvendo diversas operações. 2) Transações podem ser implícitas ou explícitas e precisam seguir as propriedades ACID (atomicidade, consistência, isolamento e durabilidade). 3) O documento também aborda deadlocks, principais comandos de transação e níveis de isolamento.
Views são tabelas virtuais derivadas de outras tabelas, que permitem visualizar e acessar dados de forma segura e flexível, facilitando o acesso, independência da estrutura física e controle de acesso aos dados. Views podem ser criadas através do comando CREATE VIEW e atualizadas via ALTER VIEW ou CREATE OR REPLACE VIEW.
Triggers são objetos no banco de dados que são acionados por eventos como INSERT, UPDATE e DELETE em uma tabela. Eles podem ser definidos para rodar antes ou depois do evento e são usados para validações ou para atualizar outras tabelas quando há alterações de dados. Triggers podem acessar os valores antigos e novos dos registros afetados e executar múltiplas instruções SQL.
UNIFAL - MySQL Linguagem SQL Básico - 5.0/5.6Wagner Bianchi
O documento fornece uma introdução abrangente sobre a linguagem SQL, incluindo suas principais subdivisões (DML, DDL, DCL, DTL), elementos e operadores. Também discute funções agregadas comuns.
Este documento fornece um resumo das principais novidades do MySQL 5.6, incluindo melhorias no otimizador de consultas, no storage engine InnoDB, no particionamento de tabelas e na replicação de dados, com recursos como index condition pushdown, multi-threaded slaves e replication checksums.
Este documento fornece um resumo do treinamento "Treinamento MySQL Administrators For IBMers":
1. O treinamento tem o objetivo de apresentar a arquitetura e principais recursos do MySQL versões 5.0 e 5.1 para formação de competências na administração e monitoramento do banco de dados.
2. O instrutor Wagner Bianchi tem experiência de 6 anos com MySQL e certificações do Oracle e Sun Microsystems.
3. O treinamento inclui tópicos como instalação do MySQL, arquitetura, logs, configuração,
InnoDB Plugin - II Fórum da Comunidade MySQLWagner Bianchi
O documento discute o InnoDB Plugin e Built-in do MySQL, comparando suas funcionalidades e desempenho. Aborda tuning de performance do buffer pool e variáveis importantes, além de novas funcionalidades no MySQL 5.6 como fulltext search e INFORMATION_SCHEMA tables.
The document provides an overview of MySQL Cluster, a database clustering product. It describes the key components of MySQL Cluster - management nodes, data nodes, and SQL nodes. It explains how MySQL Cluster provides high availability and automatic partitioning of data across nodes. Benchmarks show that MySQL Cluster can scale out to improve performance and handle increased load by adding more nodes.
3. www.percona.com
•
•
● enables a replication slave to receive transactions from multiple
sources/masters simultaneously;
● aggregate data from multiple servers - Data Mart/Data Warehouse;
● merge table shards - no auto_increment conflict control;
● can be carefully used connecting many location on one geo-positioned
cluster;
● centralize all data for backup propose.
6. www.percona.com
•
•
● No gtid_mode variable to turn on GTID
● Binary logs has positions and GTIDs
• CHANGE MASTER ‘’ TO
• CHANGE MASTER 'foo' TO
• CHANGE MASTER TO
● MASTER_USE_GTID=CURRENT_POS|SLAVE_POS
•
● Accessed using SHOW ALL SLAVES STATUS;
● SET @@default_master_connection works well;
set @@default_master_connection=''; -- default slave connection
show status like 'Slave_running';
set @@default_master_connection='connection_name01'; -- named connection name
show status like 'Slave_running';
7. www.percona.com
•
box01
Multi-Source Slave
box02
box03
box04
MariaDB [(none)]> pager egrep "Connection|Gtid"
PAGER set to 'egrep "Connection|Seconds"'
MariaDB [(none)]> show all slaves statusG
Connection_name: box02
Gtid_IO_Pos: 1-1-63,3-3-1
Gtid_Slave_Pos: 1-1-63,3-3-1
Connection_name: box03
Gtid_IO_Pos: 1-1-63,3-3-1
Gtid_Slave_Pos: 1-1-63,3-3-1
Connection_name: box04
Gtid_IO_Pos: 1-1-63,3-3-1
Gtid_Slave_Pos: 1-1-63,3-3-1
3 rows in set (0.00 sec)
On the multi-source slave side:
● Use SHOW ALL SLAVES STATUSG
● Use @@default_master_connection
● Use STOP/START ALL SLAVES
● Use STOP/START SLAVE 'box02'
10. www.percona.com
•
● Make sure the replication user is set on all the servers;
● Make sure all the servers has unique server_id and gtid_domain_id;
•
#: Connection name with box02
MariaDB [(none)]> change master 'box02' to master_host='192.168.0.102',
master_user='repl', master_password='Bi@nchI', master_use_gtid=current_pos;
#: Connection name with box03
MariaDB [(none)]> change master 'box03' to master_host='192.168.0.103',
master_user='repl', master_password='Bi@nchI', master_use_gtid=current_pos;
#: Connection name with box04
MariaDB [(none)]> change master 'box04' to master_host='192.168.0.104',
master_user='repl', master_password='Bi@nchI', master_use_gtid=current_pos;
11. www.percona.com
•
# start all slaves
MariaDB [(none)]> start all slaves;
Query OK, 0 rows affected, 3 warnings (0.02 sec)
MariaDB [(none)]> show warnings;
+-------+------+-----------------------+
| Level | Code | Message |
+-------+------+-----------------------+
| Note | 1937 | SLAVE 'box04' started |
| Note | 1937 | SLAVE 'box03' started |
| Note | 1937 | SLAVE 'box02' started |
+-------+------+-----------------------+
3 rows in set (0.00 sec)
MariaDB [(none)]> stop all slaves;
Query OK, 0 rows affected, 3 warnings (0.02 sec)
12. www.percona.com
•
#: setting the @@default_master_connection
MariaDB [(none)]> set @@default_master_connection='box02';
Query OK, 0 rows affected (0.00 sec)
#: showing some box02 Connection name's status replication variables
MariaDB [(none)]> pager egrep "Slave_IO_State|Using_Gtid|Gtid_IO_Pos"
PAGER set to 'egrep "Slave_IO_State|Using_Gtid|Gtid_IO_Pos"'
MariaDB [(none)]> show slave statusG
Slave_IO_State: Waiting for master to send event
Using_Gtid: Current_Pos
Gtid_IO_Pos: 1-1-64,2-2-1,3-3-1
1 row in set (0.00 sec)
#: starting and stopping just box02, as per @@default_master_connection set
MariaDB [(none)]> stop slave;
Query OK, 0 rows affected (0.01 sec)
MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.02 sec)
13. www.percona.com
•
#: relay logs - one group for each set connection name - host+relay-bin+connection_name
-rw-rw---- 1 mysql mysql 306 Mar 23 00:32 maria01-relay-bin-box02.000001
-rw-rw---- 1 mysql mysql 663 Mar 23 00:32 maria01-relay-bin-box02.000002
-rw-rw---- 1 mysql mysql 66 Mar 23 00:32 maria01-relay-bin-box02.index
-rw-rw---- 1 mysql mysql 306 Mar 23 00:32 maria01-relay-bin-box03.000001
-rw-rw---- 1 mysql mysql 663 Mar 23 00:32 maria01-relay-bin-box03.000002
-rw-rw---- 1 mysql mysql 66 Mar 23 00:32 maria01-relay-bin-box03.index
-rw-rw---- 1 mysql mysql 306 Mar 23 00:32 maria01-relay-bin-box04.000001
-rw-rw---- 1 mysql mysql 663 Mar 23 00:32 maria01-relay-bin-box04.000002
-rw-rw---- 1 mysql mysql 66 Mar 23 00:32 maria01-relay-bin-box04.index
#: master.info - one per set connection name - master-connection_name.info
-rw-rw---- 1 mysql mysql 153 Mar 23 00:32 master-box02.info
-rw-rw---- 1 mysql mysql 153 Mar 23 00:32 master-box03.info
-rw-rw---- 1 mysql mysql 153 Mar 23 00:32 master-box04.info
#: multi-master.info file, listing all set connections names
-rw-rw---- 1 mysql mysql 18 Feb 15 11:00 multi-master.info
[root@maria01 mysql]# cat multi-master.info #: don't edit this file :)
box02
box03
box04
14. www.percona.com
•
•
•
#: check gtid_current and gtid_slave pos variables
MariaDB [mysql]> select @@gtid_current_pos, @@gtid_slave_posG
*************************** 1. row ***************************
@@gtid_current_pos: 1-1-64,2-2-1,3-3-1
@@gtid_slave_pos: 1-1-64,2-2-1,3-3-1
1 row in set (0.00 sec)
#: check current clave current and slave pos from mysql.gtid_slave_pos table
MariaDB [mysql]> select * from mysql.gtid_slave_pos;
+-----------+--------+-----------+--------+
| domain_id | sub_id | server_id | seq_no |
+-----------+--------+-----------+--------+
| 1 | 16 | 1 | 63 |
| 1 | 20 | 1 | 64 |
| 3 | 1 | 3 | 1 |
+-----------+--------+-----------+--------+
3 rows in set (0.00 sec)
15. www.percona.com
• @@GTID_CURRENT_POS
•
● CHANGE MASTER 'foo' TO … MASTER_USE_GTID=CURRENT_POS;
● @@GTID_STRICT_MODE=1
#: checking global variable @@gtid_current_pos
MariaDB [(none)]> SELECT @@GTID_CURRENT_POS,@@GTID_STRICT_MODEG
*************************** 1. row ***************************
@@GTID_CURRENT_POS: 1-1-68,2-2-149378,3-3-88622,4-4-98365
@@GTID_STRICT_MODE: 1 -- help keeping binlogs identical across multiple servers
1 row in set (0.00 sec)
16. www.percona.com
• @@GTID_SLAVE_POS CHANGE MASTER
TO
• CHANGE MASTER 'foo' TO … MASTER_USE_GTID=SLAVE_POS;
•
#: checking global variable @@gtid_slave_pos
MariaDB [(none)]> SELECT @@GTID_SLAVE_POSG
*************************** 1. row ***************************
@@GTID_SLAVE_POS: 1-1-66,2-2-149378,3-3-88622,4-4-98365
1 row in set (0.00 sec)
#: checking global variable @@gtid_slave_pos (can't be set per Connection Name)
MariaDB [(none)]> SET GLOBAL GTID_SLAVE_POS='1-1-66,2-2-149378,3-3-88622,4-4-98365';
Query OK, 0 rows affected, 3 warnings (0.01 sec)
#: SHOULD BE DONE AFTER STOPPING REPLICATION CONNECTION NAMES...
17. www.percona.com
•
•
#: comparing both @@gtid_current_pos and @@gtid_slave_pos
MariaDB [(none)]> SELECT @@GLOBAL.GTID_CURRENT_POS,@@GLOBAL.GTID_SLAVE_POSG
*************************** 1. row ***************************
@@GLOBAL.GTID_CURRENT_POS: 1-1-71,2-2-149378,3-3-88622,4-4-98365 -- 5 ADDITIONAL TRXs
@@GLOBAL.GTID_SLAVE_POS: 1-1-66,2-2-149378,3-3-88622,4-4-98365
1 row in set (0.00 sec)
#: setting dynamically @@gtid_slave_pos - TRANSACTIONS CANNOT BE REPLAYED
MariaDB [(none)]> SET GLOBAL GTID_SLAVE_POS='1-1-66,2-2-149378,3-3-88622,4-4-98365';
ERROR 1947 (HY000): Specified GTID 1-1-66 conflicts with the binary log which contains
a more recent GTID 1-1-71. If MASTER_GTID_POS=CURRENT_POS is used, the binlog position
will override the new value of @@gtid_slave_pos.
#: command above was embraced by START/STOP ALL SLAVES.
19. www.percona.com
•
#: making a multi-source slave multi-threaded
MariaDB [(none)]> stop all slaves;
Query OK, 0 rows affected, 3 warnings (0.00 sec)
MariaDB [(none)]> set global slave_parallel_threads=12;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> set global slave_domain_parallel_threads=4;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> start all slaves;
Query OK, 0 rows affected, 3 warnings (0.03 sec)
MariaDB [(none)]> select @@slave_parallel_mode,@@slave_parallel_threads,@@slave_domain_parallel_threadsG
*************************** 1. row ***************************
@@slave_parallel_mode: optimistic # will retry transaction in case of parallelism conflicts
@@slave_parallel_threads: 12 # total of threads available for slave to execute relay logs
@@slave_domain_parallel_threads: 4 # minimum # of thread used for a domain_id all time
1 row in set (0.00 sec)
20. www.percona.com
•
#: making a multi-source slave multi-threaded
MariaDB [(none)]> SELECT ID,TIME,STATE,USER FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER='system user';
+----+------+------------------------------------------------------------------+-------------+
| ID | TIME | STATE | USER |
+----+------+------------------------------------------------------------------+-------------+
| 18 | 452 | Waiting for master to send event | system user |
| 17 | 364 | Slave has read all relay log; waiting for the slave I/O thread t | system user |
| 16 | 452 | Waiting for master to send event | system user |
| 15 | 364 | Slave has read all relay log; waiting for the slave I/O thread t | system user |
| 14 | 364 | Slave has read all relay log; waiting for the slave I/O thread t | system user |
| 13 | 452 | Waiting for master to send event | system user |
| 12 | 452 | Waiting for work from SQL thread | system user |
| 11 | 452 | Waiting for work from SQL thread | system user |
| 10 | 0 | Update_rows_log_event::ha_update_row(-1) | system user |
| 9 | 0 | Unlocking tables | system user |
| 8 | 452 | Waiting for work from SQL thread | system user |
| 7 | 452 | Waiting for work from SQL thread | system user |
| 6 | 0 | Update_rows_log_event::ha_update_row(-1) | system user |
| 5 | 0 | Update_rows_log_event::ha_update_row(-1) | system user |
| 4 | 0 | Update_rows_log_event::ha_update_row(-1) | system user |
| 3 | 0 | Update_rows_log_event::ha_update_row(-1) | system user |
+----+------+------------------------------------------------------------------+-------------+
16 rows in set (0.07 sec)
21. www.percona.com
•
●
● binlog_commit_wait_usec=100000
● binlog_commit_wait_count=20
●
#: binary logs for group commit
[root@maria02 mysql]# mysqlbinlog mysql-bin.000017 -vvvv | egrep "cid=353579"
#160325 21:37:27 server id 2 end_log_pos 27101572 GTID 2-2-149349 cid=353579 trans
#160325 21:37:27 server id 2 end_log_pos 27103107 GTID 2-2-149350 cid=353579 trans
#160325 21:37:27 server id 2 end_log_pos 27104646 GTID 2-2-149351 cid=353579 trans
#160325 21:37:27 server id 2 end_log_pos 27106181 GTID 2-2-149352 cid=353579 trans
#160325 21:37:27 server id 2 end_log_pos 27107716 GTID 2-2-149353 cid=353579 trans
#160325 21:37:27 server id 2 end_log_pos 27109251 GTID 2-2-149354 cid=353579 trans
MariaDB [(none)]> show global status where variable_name in
('Binlog_commits','Binlog_group_commits');
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Binlog_commits | 39681 |
| Binlog_group_commits | 5523 |
+----------------------+-------+
2 rows in set (0.02 sec)
the bigger the difference between the two variables
the bigger the apparent group commit efficiency
23. www.percona.com
•
● One can restart both threads or just SQL_THREAD;
#: adding new schema to box02
box02> set sql_log_bin=0; create database if not exists box02_new; set sql_log_bin=1;
Query OK, 0 rows affected (0.00 sec)
Query OK, 1 row affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
#: adding filters on multi-source slave
box01> stop slave 'box02'; set global box02.replicate_ignore_db='box02_new'; start slave 'box02';
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
#: remove filter
box01> stop slave; set global box02.replicate_ignore_db=''; start slave;
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.11 sec)
24. www.percona.com
• sql_slave_skip_counter
● If parallel replication is enabled:
•
● Stop all slaves, turn off the parallel replication and skip_counter;
● Set a new value for @@GLOBAL.GTID_SLAVE_POS;
MariaDB [box02]> set default_master_connection='box02'; set global sql_slave_skip_counter=1;
Query OK, 0 rows affected (0.00 sec)
ERROR 1966 (HY000): When using parallel replication and GTID with multiple replication domains,
@@sql_slave_skip_counter can not be used. Instead, setting @@gtid_slave_pos explicitly can be used to skip
to after a given GTID position.
MariaDB [box02]> stop all slaves; set @@global.gtid_slave_pos='1-1-71,2-2-149382,3-3-88623,4-4-98365';
Query OK, 0 rows affected, 3 warnings (0.00 sec)
Query OK, 0 rows affected (0.01 sec)
MariaDB [box02]> start all slaves;
Query OK, 0 rows affected, 3 warnings (0.01 sec)
26. www.percona.com
●
● gtid_mode=on
●
●
● PERFORMANCE_SCHEMA
● SHOW SLAVE STATUS
● SHOW SLAVE STATUS FOR CHANNEL
mysql> pager egrep "Slave_IO|Channel"
PAGER set to 'egrep "Slave_IO|Channel"'
mysql> show slave statusG
Slave_IO_State: Waiting for master to send event
Slave_IO_Running: Yes
Channel_Name: box02
Slave_IO_State: Waiting for master to send event
Slave_IO_Running: Yes
Channel_Name: box03
Slave_IO_State: Waiting for master to send event
Slave_IO_Running: Yes
Channel_Name: box04
3 rows in set (0.00 sec)
28. www.percona.com
•
•
#: Replication Channel for box02
box01> change master to master_host='192.168.0.12', master_user='repl',
master_password='Bi@nchI', master_auto_position=1 for channel 'box02';
#: Replication Channel for box03
box01> change master to master_host='192.168.0.13', master_user='repl',
master_password='Bi@nchI', master_auto_position=1 for channel 'box03';
#: Replication Channel for box04
box01> change master to master_host='192.168.0.14', master_user='repl',
master_password='Bi@nchI', master_auto_position=1 for channel 'box04';
29. www.percona.com
#: relay logs - one group for each set connection name
-rw-r----- 1 mysql mysql 847 Mar 27 00:51 percona01-relay-bin-box02.000018
-rw-r----- 1 mysql mysql 534 Mar 27 00:51 percona01-relay-bin-box02.000019
-rw-r----- 1 mysql mysql 70 Mar 27 00:51 percona01-relay-bin-box02.index
-rw-r----- 1 mysql mysql 597 Mar 27 00:51 percona01-relay-bin-box03.000017
-rw-r----- 1 mysql mysql 534 Mar 27 00:51 percona01-relay-bin-box03.000018
-rw-r----- 1 mysql mysql 70 Mar 27 00:51 percona01-relay-bin-box03.index
-rw-r----- 1 mysql mysql 550 Mar 27 00:51 percona01-relay-bin-box04.000017
-rw-r----- 1 mysql mysql 487 Mar 27 00:51 percona01-relay-bin-box04.000018
-rw-r----- 1 mysql mysql 70 Mar 27 00:51 percona01-relay-bin-box04.index
#:No master.info file as it needs to be configured with crash-safe, repos as TABLE
mysql> show variables where variable_name in
('master_info_repository','relay_log_info_repository');
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| master_info_repository | TABLE |
| relay_log_info_repository | TABLE |
+---------------------------+-------+
2 rows in set (0.00 sec)
•
30. www.percona.com
•
#: stopping all slaves
mysql> stop slave;
Query OK, 0 rows affected (0.06 sec)
mysql> show slave statusG
Slave_IO_Running: No
Slave_SQL_Running: No
[...snip...]
3 rows in set (0.00 sec)
#: stopping just one specific slave
mysql> stop slave for channel 'box02';
Query OK, 0 rows affected (0.01 sec)
mysql> show slave status for channel 'box02'G
Slave_IO_Running: No
Slave_SQL_Running: No
Slave_SQL_Running_State:
1 row in set (0.00 sec)
31. www.percona.com
•
#: starting all slaves
mysql> start slave;
Query OK, 0 rows affected (0.06 sec)
mysql> show slave statusG
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
[...snip...]
3 rows in set (0.00 sec)
#: starting just one specific slave
mysql> start slave for channel 'box02';
Query OK, 0 rows affected (0.01 sec)
mysql> show slave status for channel 'box02'G
Slave_IO_Running: No
Slave_SQL_Running: No
Slave_SQL_Running_State:
1 row in set (0.00 sec)
32. www.percona.com
•
#: show all slaves status
mysql> show slave statusG
Channel_Name: box02
Channel_Name: box03
Channel_Name: box04
3 rows in set (0.00 sec)
#: show slave status for a specific slave
mysql> show slave status for channel 'box02'G
Slave_IO_State: Waiting for master to send event
Retrieved_Gtid_Set: 61be13a1-d574-11e5-83c7-0800274fb806:1-61...
Executed_Gtid_Set: 4bd77dee-d572-11e5-b09f-0800274fb806:1-56...
Channel_Name: box02
1 row in set (0.00 sec)
33. www.percona.com
#: PERFORMANCE_SCHEMA replication tables
mysql> show tables from performance_schema like 'replication%';
+---------------------------------------------+
| Tables_in_performance_schema (replication%) |
+---------------------------------------------+
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| replication_connection_configuration |
| replication_connection_status |
| replication_group_member_stats |
| replication_group_members |
+---------------------------------------------+
8 rows in set (0.00 sec)
34. www.percona.com
#: PERFORMANCE_SCHEMA replication tables
mysql> select channel_name,service_state,last_heartbeat_timestamp
-> from performance_schema.replication_connection_statusG
*************************** 1. row ***************************
channel_name: box02
service_state: ON
last_heartbeat_timestamp: 2016-03-26 22:22:39
*************************** 2. row ***************************
channel_name: box03
service_state: ON
last_heartbeat_timestamp: 2016-03-26 22:22:30
*************************** 3. row ***************************
channel_name: box04
service_state: ON
last_heartbeat_timestamp: 2016-03-26 22:22:31
3 rows in set (0.00 sec)
35. www.percona.com
mysql> select @@slave_parallel_workers, @@slave_parallel_type;
+--------------------------+-----------------------+
| @@slave_parallel_workers | @@slave_parallel_type |
+--------------------------+-----------------------+
| 8 | LOGICAL_CLOCK |
+--------------------------+-----------------------+
1 row in set (0.00 sec)
#: PERFORMANCE_SCHEMA, checking coordinators state (multi-threaded slaves)
mysql> select channel_name, service_state
-> from performance_schema.replication_applier_status_by_coordinatorG
*************************** 1. row ***************************
channel_name: box02
service_state: ON
*************************** 2. row ***************************
channel_name: box03
service_state: ON
*************************** 3. row ***************************
channel_name: box04
service_state: ON
3 rows in set (0.00 sec)
36. www.percona.com
#: PERFORMANCE_SCHEMA, checking coordinators state (multi-threaded slaves)
mysql> select channel_name,thread_id,service_state,last_seen_transaction
-> from performance_schema.replication_applier_status_by_worker
-> where last_seen_transaction<>''G
*************************** 1. row ***************************
channel_name: box03
thread_id: 71
service_state: ON
last_seen_transaction: ab001313-d573-11e5-bc39-0800274fb806:2536
*************************** 2. row ***************************
channel_name: box03
thread_id: 72
service_state: ON
last_seen_transaction: ab001313-d573-11e5-bc39-0800274fb806:2537
*************************** 3. row ***************************
channel_name: box03
thread_id: 73
service_state: ON
last_seen_transaction: ab001313-d573-11e5-bc39-0800274fb806:2538
...
39. www.percona.com
#: rewriting updates on db A to db B
box01> stop slave; change replication filter replicate_rewrite_db=((box02,box03)); start slave;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.07 sec)
#: writing some data to A to be routed to B
box02> insert into box02.t1 set i=10;
Query OK, 1 row affected (1.01 sec)
#: checking data on A
box01> select * from box02.t1;
Empty set (0.00 sec)
#: checking data on B
box01> select * from box03.t1G
*************************** 1. row ***************************
i: 10
1 row in set (0.00 sec)
#: remove filter
box01> stop slave; change replication filter replicate_rewrite_db=(); start slave;
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.12 sec)
● REPLICATE_REWRITE_DB
40. www.percona.com
•
●
●
box01> SELECT @@HOSTNAME,ID,USER,STATE,TIME,INFO
-> FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER='system user';
+------------+----+-------------+--------------------------------------------------------+------+------+
| @@HOSTNAME | ID | USER | STATE | TIME | INFO |
+------------+----+-------------+--------------------------------------------------------+------+------+
| box01 | 32 | system user | Waiting for an event from Coordinator | 721 | NULL |
| box01 | 33 | system user | Waiting for an event from Coordinator | 721 | NULL |
| box01 | 34 | system user | Waiting for an event from Coordinator | 721 | NULL |
| box01 | 35 | system user | Waiting for an event from Coordinator | 721 | NULL |
| box01 | 36 | system user | Waiting for an event from Coordinator | 721 | NULL |
| box01 | 25 | system user | Waiting for an event from Coordinator | 721 | NULL |
| box01 | 26 | system user | Waiting for an event from Coordinator | 721 | NULL |
| box01 | 27 | system user | Waiting for master to send event | 721 | NULL |
[...snip...]
+------------+----+-------------+--------------------------------------------------------+------+------+
30 rows in set (0.00 sec)
41. www.percona.com
•
UUID()
mysql> select * from performance_schema.replication_applier_status_by_workerG
*************************** 1. row ***************************
CHANNEL_NAME: box02
WORKER_ID: 1
THREAD_ID: NULL
SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: fa11b361-d572-11e5-b63e-0800274fb806:66
LAST_ERROR_NUMBER: 1062
LAST_ERROR_MESSAGE: Worker 0 failed executing transaction 'fa11b361-d572-11e5-b63e-
0800274fb806:66' at master log mysql-bin.000008, end_log_pos 793; Could not execute Write_rows event on table
box02.t1; Duplicate entry '1' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the
event's master log mysql-bin.000008, end_log_pos 793
LAST_ERROR_TIMESTAMP: 2016-04-21 00:18:14
mysql> stop slave for channel 'box02'; set gtid_next='fa11b361-d572-11e5-b63e-0800274fb806:66'; begin;
commit; set gtid_next=automatic; start slave for channel 'box02';
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (1.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.02 sec)
42. www.percona.com
Feature MariaDB MySQL 5.7
Multi-Source Slave
Creation
CHANGE MASTER 'name' TO...; CHANGE MASTER TO … FOR CHANNEL 'name';
Parallel Threads slave_parallel_mode=optimistic
slave_parallel_threads=16 # ALL
slave_domain_parallel_threads=4
slave_parallel_max_queued=512M
slave_parallel_workers=4 # per RC
slave_parallel_type='LOGICAL_CLOCK'
slave_pending_jobs_size_max=256M
Replication Filters set global box02.
replicate_ignore_db='foo';
CHANGE REPLICATION FILTER ...
Skip Replication Errors SET GLOBAL GTID_SLAVE_POS='1-1-66';
SET GLOBAL
slave_exec_mode='IDEMPOTENT';
SET GLOBAL sql_slave_skip_counter=1;
SET GLOBAL slave_exec_mode='IDEMPOTENT';
SET GTID_NEXT='UUID:TRX_ID'
SET GLOBAL sql_slave_skip_counter=1; start
slave for channel 'xxxx'; (NO GTID)
Possible number of
sources/masters
You can for now only have 64 masters
256 replication channels for any combination
of hostname and port