Galera Cluster - Node Recovery - Webinar slides

Since 5.7.2, MySQL implements parallel replication in the same schema, also known as LOGICAL_CLOCK (DATABASE based parallel replication is also implemented in 5.6 but this is not covered in this talk). In early 5.7 versions, parallel replication was based on group commit (like MariaDB) and 5.7.6 changed that to intervals. Intervals are more complicated but they are also more powerful. In this talk, I will explain in detail how they work and why intervals are better than group commit. I will also cover how to optimize parallel replication in MySQL 5.7 and what improvements are coming in MySQL 8.0. I will also explain why Group Replication is replicating faster than standard asynchronous replication. Come to this talk to get all the details about MySQL 5.7 Parallel Replication.

24시간 365일 서비스를 위한 MySQL DB 이중화. MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다. 목차 1. DB 이중화 필요성 2. 이중화 방안 - HW 이중화 - MySQL Replication 이중화 3. 이중화 운영 장애 4. DNS와 VIP 5. MySQL 이중화 솔루션 비교 대상 - MySQL을 서비스하고 있는 인프라 담당자 - MySQL 이중화에 관심 있는 개발자

Of course there is no such thing as perfect service discovery, and we will see why in the talk. However, the way ProxySQL is deployed in this case minimizes the risk for split-brains, and this is why I qualify it as almost perfect. But let’s step back a little... MySQL alone is not a high availability solution. To provide resilience to primary failure, other components need to be integrated with MySQL. At MessageBird, these additional components are ProxySQL and Orchestrator. In this talk, we describe how ProxySQL is architectured to provide close to perfect Service Discovery and how this, combined with Orchestrator, allows for automatic failover. The talk presents the details of the integration of MySQL, ProxySQL and Orchestrator in Google Cloud (and it would be easy to re-implement a similar architecture at other cloud vendors or on-premises). We will also cover lessons learned for the 2 years this architecture has been in production. Come to this talk to learn more about MySQL high availability, ProxySQL and Orchestrator.

Understanding ProxySQL internals and then interacting with some common features of ProxySQL such as query rewriting, mirroring, failovers, and ProxySQL Cluster

There are many ways to run high availability with PostgreSQL. Here, we present a template for you to create your own customized, high-availability solution using Python and for maximum accessibility, a distributed configuration store like ZooKeeper or etcd.

This presentation was made by Mr. Santhinesh Kumar Nagendran at Mydbops Database Meetup -2 held at Bangalore on 26-01-2019.

At the end of 2016, Oracle released a new Plugin called MySQL Group Replication, which is a new MySQL replication method that aims to provide better High Availability, and built-in failover with consistency guarantees. I evaluated the initial GA versions back in early 2017. I presented my initial findings with several best practices and concerns with the current implementation which made me state that Group Replication was not quite ready yet. (https://www.slideshare.net/Grypyrg/my-sql-group-replication) (Un)lucky as I was, a large part of the attendees were Oracle developers and the months after this, many of these bugs and missing features were implemented in both MySQL 8.0 as well as backported to MySQL 5.7. (Thank you!) This is a followup presentation on my previous analysis, where I will look into the changes since and re-evaluate the readiness of Group Replication for production usage and provide my insights and opinion on the state of GR.

This document summarizes Frédéric Descamps' journey to add a user to the router_rest_accounts table to authenticate with the MySQL Router REST API. After several failed attempts using generated or external passwords, he learns directly from the MySQL Router development team that the REST API supports using the default MySQL 8.0 authentication string or the modular_crypt_format for password hashes, allowing simple password insertion.

This document summarizes Olivier Dasini's presentation on migrating a MySQL database from the latin1 character set to UTF-8. Some key points: - The migration involved converting database tables, columns, and data to the UTF-8 character set and UTF-8 collations to support non-Latin characters from around the world. - Challenges included minimizing downtime to avoid loss of income, dealing with legacy data issues, and handling errors due to differences between character sets. - The solution involved a rolling upgrade approach, with slaves being migrated first to test the process before a master-slave switchover. - Significant effort was required to clean legacy data issues and handle errors manually

MariaDB에서 구성에 따른 이중화 방식들

오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.

In MySQL 8.0.19, we introduced DNS-SRV support in the Connectors, which improves the integration with various service discovery services.

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/)

This document summarizes Matteo Merli's talk on moving Apache Pulsar to a ZooKeeper-less metadata model. It discusses how Pulsar currently uses ZooKeeper for metadata storage but faces scalability issues. The talk outlines PIP-45, a plan to introduce a pluggable metadata backend into Pulsar to replace the direct ZooKeeper usage. This would allow alternative storage options like Etcd and improve scalability. It also discusses successes already achieved in Pulsar 2.10 by abstracting the metadata access and future goals around scaling to support millions of topics.

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.