M|18 Choosing the Right High Availability Strategy for You

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 document discusses how Tradingscreen automates tasks related to managing their MariaDB databases across multiple environments. Some key points: - Tradingscreen has over 100 database servers across different regions to support their financial services clients. - They developed tools like DBABot, RosBot, and various scripts to automate backups, replication monitoring, user access removal, and schema deployments across their environments in order to reduce errors and make processes more efficient. - The tools leverage technologies like Percona Toolkit, XtraBackup, Git, and APIs to perform tasks like backups, replication monitoring, schema changes, and more. This allows a smaller team of DBAs to manage a large, globally distributed database infrastructure

Ansell Guardian® faced challenges with their previous database replication solution as their data and usage grew globally. They evaluated MariaDB/Galera and implemented it to replace their legacy solution. The implementation was smooth using automation scripts. MariaDB/Galera provided increased performance, faster deployment times, and more reliable data synchronization across their 3 data centers compared to their previous solution. It helped resolve a critical data divergence issue and improved the user experience. They plan to further enhance their database infrastructure using MaxScale in the future.

This document discusses how to get the most out of MariaDB MaxScale. It provides an overview of MariaDB MaxScale and the MariaDB platform. It then demonstrates how MariaDB MaxScale can be used to handle multiple paths and listeners, routing queries using hints, masking data, and rerouting queries. Live demos are shown of these MaxScale features. The document concludes by discussing MaxScale's flexible plugin-based architecture and capabilities for load balancing, failover, and transforming queries.

Maheedhar Gunturu presented on connecting Kafka message systems with Scylla. He discussed the benefits of message queues like Kafka including centralized infrastructure, buffering capabilities, and streaming data transformations. He then explained Kafka Connect which provides a standardized framework for building connectors with distributed and scalable connectors. Scylla and Cassandra connectors are available today with a Scylla shard aware connector being developed.

Qinglin Zhang, Database Kernel Engineer at Tencent, introduces CynosDB, Tencent's self-developed database for the cloud. CynosDB is based on MariaDB Server, but separates computing and storage. Zhang goes on to provide a detailed explanation of the architecture with a focus on how Tencent implemented the computing and storage layers, and created Tencent’s MariaDB-based “Aurora”.

Outbrain is the world's largest content discovery program. Learn about their use case with Scylla where they lowered latency while doing 20X IOPS of Cassandra.

THINQ provides a cloud-based Communications-Platform-as-a-Service (CPaaS) that routes tens of millions of phone calls per day for customers in enterprise and telecommunications industries. In this session Sasha Vaniachine, Senior Database Administrator at THINQ, explains how he combined MariaDB Server and MariaDB ColumnStore to support both high-performance transaction processing and scalable analytics. In addition, he shares some of THINQ's best practices and lessons learned from supporting an ever-increasing database workload that currently exceeds 10,000 transactions per second.

- Galera is a MySQL clustering solution that provides true multi-master replication with synchronous replication and no single point of failure. - It allows high availability, data integrity, and elastic scaling of databases across multiple nodes. - Companies like Percona and MariaDB have integrated Galera to provide highly available database clusters.

An introduction to Kafka cruise control which performs dynamic workload balancing for Kafka clusters.

The document discusses high availability techniques for MariaDB including master-slave replication, multi-master clustering, and topologies. It covers fundamental concepts like failover, switchover, and rejoin. Master-slave replication can be asynchronous or semi-synchronous and is used for different types of workloads. Multi-master clustering uses synchronous replication and global transaction IDs. Topologies include spanning multiple data centers and read scaling. Internals involve the binary log, global transaction IDs, and replication processes. Optimizations configure parallel replication and throttling.

This document discusses configuring workload-based storage and topologies in MariaDB. It introduces several MariaDB storage engines including InnoDB, MyRocks, Aria, Spider, and ColumnStore. For each engine, it provides an overview of use cases, key configuration parameters, and recommendations on when to use each engine. It also provides an example of using different engines like MyRocks, InnoDB and Spider across multiple microservices databases based on the workload. The document aims to help users choose the right storage engine for their specific workload needs.

Database schema changes are usually not popular among DBAs or sysadmins, not when you are operating a cluster and cannot afford to switch off the service during a maintenance window. There are different ways to perform schema changes, some procedures being more complicated than others. Galera Cluster is great at making your MySQL database highly available, but are you concerned about schema changes? Is an ALTER TABLE statement something that requires a lot of advance scheduling? What is the impact on your database uptime? This is a common question, since ALTER operations in MySQL usually cause the table to be locked and rebuilt – which can potentially be disruptive to your live applications. Fortunately, Galera Cluster has mechanisms to replicate DDL across its nodes. In these slides, you will learn about the following: How to perform Zero Downtime Schema Changes 2 main methods: TOI and RSU Total Order Isolation: predictability and consistency Rolling Schema Upgrades pt-online-schema-change Schema synchronization with re-joining nodes Recommended procedures Common pitfalls/user errors The slides are courtesy of Seppo Jaakola, CEO, Codership - creators of Galera Cluster

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

We have been served well by Zookeeper over the years, but it is time for Kafka to stand on its own. This is a talk on the ongoing effort to replace the use of Zookeeper in Kafka: why we want to do it and how it will work. We will discuss the limitations we have found and how Kafka benefits both in terms of stability and scalability by bringing consensus in house. This effort will not be completed over night, but we will discuss our progress, what work is remaining, and how contributors can help. (Note that I am proposing this as a joint talk with Colin McCabe, who is also a committer on the Apache Kafka project.)

The document discusses vCloud Air and how it can host business-critical MySQL databases. It provides an overview of vCloud Air and how to set up MySQL instances within it. While vCloud Air provides basic availability and scalability, VMware Continuent adds high availability, disaster recovery, and replication capabilities to MySQL databases running in vCloud Air. It also discusses using Continuent to implement cross-region clusters spanning vCloud Air and on-premises data centers.

HBase is used to serve online facing traffic in Pinterest. It means no downtime is allowed. However, we were on HBase 94. To upgrade to latest version, we need to figure out a way to live upgrade while keeping Pinterest site live. Recently, we successfully upgrade 94 HBase cluster to 1.2 with no downtime. We made change to both Asynchbase and HBase server side. We will talk about what we did and how we did it. We will also talk about the finding in config and performance tuning we did to achieve low latency.

- MariaDB provides several high availability options including asynchronous replication, semi-synchronous replication, Galera synchronous replication, and MaxScale for load balancing and failover. - Asynchronous replication allows for read scaling but carries a risk of data loss during failover. Semi-synchronous replication reduces this risk by ensuring data is written to at least one slave before confirming to the client. - Galera synchronous multi-master replication ensures all nodes remain in sync with no data loss but can impact performance. MaxScale helps manage replication topology and perform automated failovers.

This document discusses different high availability strategies for MariaDB databases. It covers asynchronous and semi-synchronous replication, which provide redundancy and failover capabilities but can have data loss risks. Synchronous replication with Galera Cluster is also described, which guarantees no data loss but has higher latency. Other topics include terminology, data redundancy approaches, and how features can be combined for resilient configurations.

This document discusses high availability and MariaDB replication. It defines high availability and outlines key components like data redundancy, failover solutions, and monitoring. It then describes MariaDB replication in detail, covering asynchronous and semi-synchronous replication as well as Galera cluster synchronous replication. MaxScale is introduced as a tool for load balancing, monitoring, and facilitating failovers in MariaDB replication topologies.

This document discusses high availability strategies for MariaDB databases. It defines high availability as a system that is continuously operational for a desirably long period of time. It then examines different levels of availability based on uptime percentages and corresponding downtime. Various high availability components are described, including data redundancy, failover/switchover solutions, and monitoring. Asynchronous and synchronous replication techniques are summarized, along with how MaxScale can implement read/write splitting and failover automation. The benefits and limitations of Galera cluster synchronous replication are also provided.