- 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.
Learn strategies to maintain your database's high availability even during peak use periods. MariaDB's Field CTO Max Mether offers best practices for high availability, disaster recovery and more.
Best Practice for Achieving High Availability in MariaDBMariaDB plc
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.
Database Security Threats - MariaDB Security Best PracticesMariaDB plc
This document discusses MariaDB security, including common threats, best practices, and MariaDB security features. It outlines network threats like viruses and hacker attacks, application issues like denial of service attacks and SQL injection, and excessive user privileges. Best practices covered include encrypting data at rest and in transit, using a database firewall, limiting user privileges, and implementing auditing. MariaDB security technologies described are data encryption, the MariaDB Audit Plugin, MaxScale for firewall/proxy functionality, and features for vulnerability protection. Configuration examples are provided for the database firewall, DDoS prevention, and data masking.
Running MariaDB in multiple data centersMariaDB plc
The document discusses running MariaDB across multiple data centers. It begins by outlining the need for multi-datacenter database architectures to provide high availability, disaster recovery, and continuous operation. It then describes topology choices for different use cases, including traditional disaster recovery, geo-synchronous distributed architectures, and how technologies like MariaDB Master/Slave and Galera Cluster work. The rest of the document discusses answering key questions when designing a multi-datacenter topology, trade-offs to consider, architecture technologies, and pros and cons of different approaches.
This document discusses different approaches to achieving high availability with MariaDB databases, including replication, Galera clusters, and MaxScale load balancing. It describes asynchronous and semi-synchronous replication topologies that provide redundancy and enable failover. Synchronous replication with Galera clusters is discussed as another option that ensures all nodes remain in sync with no data loss. MaxScale is presented as a tool that can monitor MariaDB topologies and perform load balancing and failover across nodes.
Getting started with MariaDB? Whether it is on your laptop or server, containers are great ephemeral vessels for your applications. But what about the data that drives your business? It must survive containers coming and going, maintain its availability and reliability, and grow when you need it.
How to make data available for analytics ASAPMariaDB plc
This document discusses how to make data available for analytics in MariaDB ColumnStore. It covers loading data using command line tools, SQL, and bulk write APIs. It also discusses integrating with applications via data adapters like Pentaho and MaxScale CDC. Future improvements may include integrated MaxScale CDC and performance enhancements to loading tools.
Hochverfügbarkeit mit MariaDB Enterprise
Presented by Ralf Gebhardt at the MariaDB Roadshow Germany: 4.7.2014 in Hamburg, 8.7.2014 in Berlin and 11.7.2014 in Frankfurt.
Best practices: running high-performance databases on KubernetesMariaDB plc
Databases benefit greatly from containerization in terms of performance, ease-of-deployment, and scalability. However, building a database-as-a-service (DBaaS) on Kubernetes without the right infrastructure can be a complex, time-consuming project where some database services have to be run outside of the cluster for the sake of leveraging persistent storage. This session offers up a global financial institution’s real-world account of how bare metal Kubernetes infrastructure can further enhance the performance of MariaDB’s innovative, load-balanced database services – and how the requisite persistent storage can be best provisioned, managed and backed up without service interruption or creating an additional burden for application owners and developers.
M|18 Choosing the Right High Availability Strategy for YouMariaDB plc
This document discusses MariaDB high availability strategies including replication, failover, and clustering. It defines key HA terminology and describes different replication topologies like asynchronous, semi-synchronous, and synchronous replication using Galera cluster. Use cases provided show how geographically distributed and production control systems benefit from MariaDB HA features.
Webinar Slides: Geo-Distributed MySQL Clustering Done Right!Continuent
With Multiple Active Primary MySQL Databases
Watch this on-demand webinar to learn the right way to deploy geo-distributed databases. We look at the pitfalls of deploying a single site and passive sites, and from there we show how to provide the best user experience by leveraging geo-distributed MySQL.
When considering geo-distributed MySQL database environments it is important to understand the nuances of having multiple active clusters deployed across sites and clouds. This webinar walks through the proper planning of geo-distributed MySQL for success.
Finally, you’ll learn about our best practices for multiple primary clusters, as well as failover and disaster recovery for MySQL.
AGENDA
- Why Geo-Distributed Databases
- Geo-Distributed MySQL Starts With High Performance Local Clusters
- Extend The Cluster To Multiple Datacenters/Clouds
- Best Practices For Multiple Primary Clusters
- Failover & Disaster Recovery
- Key Benefits
PRESENTER
Matthew Lang, Customer Success Director – Americas, Continuent, has over 25 years of experience in database administration, database programming, and system architecture, including the creation of a database replication product that is still in use today. He has designed highly available, scaleable systems that have allowed startups to quickly become enterprise organizations, utilizing a variety of technologies including open source projects, virtualization and cloud.
CCV: migrating our payment processing system to MariaDBMariaDB plc
CCV is a Dutch payment processor and loyalty provider. CCV's current payment processing platform is built on top of Microsoft SQL Server, but they are currently in the process of migrating it to MariaDB. This migration project is in progress and first production transactions are expected to run in 2020. In this session, Ernst Wernicke and Harry Dijkstra of CCV share how they are using MariaDB to meet critical high availability requirements, including geographic replication, zero data-loss, zero downtime (both planned and unplanned) and no single point of failure anywhere.
This document discusses various cloud design patterns for common problems such as retries, circuit breakers, throttling, leader election, and static content hosting. It provides examples of the retry pattern using services such as Azure Storage, SQL Database, Service Bus, Cache, and DocumentDB. Solutions for other patterns like queue-based load leveling, index tables, and valet keys are also briefly outlined.
Webinar Slides: MySQL HA/DR/Geo-Scale - High Noon #2: Galera ClusterContinuent
Galera Cluster vs. Continuent Tungsten Clusters
Building a Geo-Scale, Multi-Region and Highly Available MySQL Cloud Back-End
This second installment of our High Noon series of on-demand webinars is focused on Galera Cluster (including MariaDB Cluster & Percona XtraDB Cluster). It looks at some of the key characteristics of Galera Cluster and how it fares as a MySQL HA / DR / Geo-Scale solution, especially when compared to Continuent Tungsten Clustering.
Watch this webinar to learn how to do better MySQL HA / DR / Geo-Scale.
AGENDA
- Goals for the High Noon Webinar Series
- High Noon Series: Tungsten Clustering vs Others
- Galera Cluster (aka MariaDB Cluster & Percona XtraDB Cluster)
- Key Characteristics
- Certification-based Replication
- Galera Multi-Site Requirements
- Limitations Using Galera Cluster
- How to do better MySQL HA / DR / Geo-Scale?
- Galera Cluster vs Tungsten Clustering
- About Continuent & Its Solutions
PRESENTER
Matthew Lang - Customer Success Director – Americas, Continuent - has over 25 years of experience in database administration, database programming, and system architecture, including the creation of a database replication product that is still in use today. He has designed highly available, scaleable systems that have allowed startups to quickly become enterprise organizations, utilizing a variety of technologies including open source projects, virtualization and cloud.
The document outlines design principles for building applications on Azure. It discusses moving from traditional on-premises models to modern cloud-native approaches. Some key principles covered include using managed services, minimizing coordination between services, partitioning applications around limits, designing for scalability and self-healing, making all components redundant, using the appropriate data store, designing for evolution, and building applications around business needs.
Apache Kafka Bay Area Sep Meetup - 24/7 Customer, Inc.Suneet Grover
The document summarizes 24/7 Customer's experience migrating from Apache Kafka 0.7 and 0.8 to the newer 0.10.0.1 version. It describes the challenges faced with sticky partitions and range-based mirror makers in 0.8. It details 24/7 Customer's upgrade path from 0.8 to 0.8.2.2 to 0.9 to the current 0.10.0.1 version. It also discusses the configurations, monitoring, and design considerations for running Kafka reliably across multiple data centers.
Transform your DBMS to drive engagement innovation with Big DataAshnikbiz
This document discusses how organizations can save money on database management systems (DBMS) by moving from expensive commercial DBMS to more affordable open-source options like PostgreSQL. It notes that PostgreSQL has matured and can now handle mission critical workloads. The document recommends partnering with EnterpriseDB to take advantage of their commercial support and features for PostgreSQL. It highlights how customers have seen cost savings of 35-80% by switching to PostgreSQL and been able to reallocate funds to new business initiatives.
Exchange Server 2013 : les mécanismes de haute disponibilité et la redondance...Microsoft Technet France
La nouvelle version d'Exchange Server 2013 intègre une foule de nouveautés lui permettant d'être aujourd'hui le serveur de messagerie le plus sécurisé et le plus fiable sur le marché. L'expérience acquise par la gestion des solutions de messagerie Cloud par les équipes Microsoft a été directement intégrée dans cette nouvelle version du produit ce qui va vous permettre la mise en place d'un système de messagerie ultra résilient. Scott Schnoll, Principal Technical Writer dans l'équipe Exchange à Microsoft Corp va vous expliquer de manière didactique l'ensemble des mécanismes de haute disponibilité et les solutions de resilience inter sites dans les plus petits détails. Venez apprendre directement par l'expert qui a travaillé sur ces sujets chez Microsoft ! Attention, session très technique, en anglais.
Chef conf-2015-chef-patterns-at-bloomberg-scaleBiju Nair
This document discusses various patterns used at Bloomberg for managing infrastructure at scale using Chef. It describes how dedicated bootstrap servers are used to regularly build clusters in an isolated manner. The use of lightweight VMs for bootstrapping is explained. Techniques for building the bootstrap server, cleaning up configurations and converting it to an admin client are outlined. The document also covers topics like dynamic resource creation, injecting logic into community cookbooks, handling service restarts and implementing pluggable alerts.
Maximizing performance via tuning and optimizationMariaDB plc
Maximizing Performance via Tuning and Optimization outlines best practices for optimizing MariaDB server performance. It discusses:
- Defining service level agreements and metrics to monitor against them
- When to tune based on schema, query, or system changes
- Ensuring server, storage, network and OS settings support database needs
- Configuring connection pooling and threads to manage load
- Common MariaDB configuration settings that impact performance
- Query tuning techniques like indexing, monitoring tools, and database design
Choosing the right high availability strategyMariaDB plc
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 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.
IBM MQ High Availabillity and Disaster Recovery (2017 version)MarkTaylorIBM
This document discusses high availability and disaster recovery strategies for IBM MQ. It describes technologies like queue manager clusters, multi-instance queue managers, and HA clusters that can be used to provide high availability when failures occur across datacenters and clouds. Multi-instance queue managers provide basic failover of a queue manager between two systems without an HA cluster. HA clusters coordinate failover of resources like the queue manager, shared storage, and IP address across multiple machines for increased reliability. The IBM MQ Appliance also supports high availability between two appliances.
IBM MQ - High Availability and Disaster RecoveryMarkTaylorIBM
IBM MQ provides capabilities to keep data safe and businesses running in the event of failures. This includes solutions for high availability (HA) and disaster recovery (DR) whether running on-premises or in hybrid cloud environments. HA aims to keep systems running through failures while DR focuses on recovering after an HA failure. Key HA technologies in IBM MQ include queue manager clusters, queue sharing groups, multi-instance queue managers, and HA clusters. These solutions provide redundancy to prevent single points of failure and enable fast failover. DR requires replicating data to separate sites which IBM MQ supports through various backup and replication features.
Megastore combines the scalability of NoSQL with the ACID properties of relational databases. It uses Paxos replication across data centers to provide high availability with low latency. The data is partitioned into entity groups which are replicated independently to allow for scale. Transactions within a group use multi-version concurrency control and across groups use two-phase commit. Coordinators track write ordering to prevent conflicts during reads and writes. Metrics from Google showed Megastore provided low latency access even with widespread data distribution.
This document summarizes migrating from MySQL replication to Galera Cluster. It describes Galera Cluster as providing synchronous multi-master replication with automatic failover. The migration procedure involves converting an existing asynchronous slave to Galera, building up the Galera Cluster to the desired size, switching readers and writers over to the cluster, and then deactivating the original asynchronous replication. Key benefits of Galera Cluster include strong consistency, high availability, and ability to join new nodes automatically.
we will discuss important topics related to multi-master setups:
* Practical considerations when using Galera in a multi-master setup
* Evaluating the characteristics of your database workload
* Preparing your application for multi-master
* Detecting and dealing with transaction conflicts
This document provides best practices for implementing high availability and disaster recovery solutions for Informix databases using HDR, RSS, SDS, and connection manager technologies. It discusses configuration parameters and strategies for minimizing data loss and downtime in the event of failures. Key recommendations include using unbuffered logging, tuning bufferpool and I/O settings, and coordinating transactions across nodes for applications.
Detailed presentation on how queries and updates behave on updateable secondary. A few nuggets of best practices to make sure your HDR configuration works well.
Training Slides: Basics 102: Introduction to Tungsten ClusteringContinuent
This document provides an introduction to Continuent Tungsten clustering. It discusses key benefits like high availability, multi-site deployment, and ease of use. It examines the clustering architecture including topologies, automatic and manual failover, and rolling maintenance procedures. Commands for monitoring and managing the cluster are also reviewed, including cctrl and tpm diag. A demo shows using cctrl to perform a manual failover by promoting a slave to master.
High availability and disaster recovery in IBM PureApplication SystemScott Moonen
This document discusses high availability and disaster recovery strategies for IBM PureApplication System. It begins with definitions of key terms like HA, DR, RTO, and RPO. It then outlines the various tools in PureApplication System that can be used to achieve HA and DR, such as compute node availability, block storage, storage replication, and external storage. The document provides examples of how to compose these tools to meet different HA and DR scenarios, like handling compute node failures, database updates, and site failures. It concludes with some caveats around networking considerations and middleware-specific factors.
We will show the advantages of having a geo-distributed database cluster and how to create one using Galera Cluster for MySQL. We will also discuss the configuration and status variables that are involved and how to deal with typical situations on the WAN such as slow, untrusted or unreliable links, latency and packet loss. We will demonstrate a multi-region cluster on Amazon EC2 and perform some throughput and latency measurements in real-time (video http://galeracluster.com/videos/using-galera-replication-to-create-geo-distributed-clusters-on-the-wan-webinar-video-3/)
MySQL 5.7 clustering: The developer perspectiveUlf Wendel
(Compiled from revised slides of previous presentations - skip if you know the old presentations)
A summary on clustering MySQL 5.7 with focus on the PHP clients view and the PHP driver. Which kinds on MySQL clusters are there, what are their goal, how does wich one scale, what extra work does which clustering technique put at the client and finally, how the PHP driver (PECL/mysqlnd_ms) helps you.
Cinder enhancements are proposed to better support replication and other long-running volume operations using stateless snapshots. The enhancements include allowing volume drivers to report capabilities like stateless snapshots, tracking task status separately from volume status, and replicating snapshots between backends. This would enable optimizations like transferring snapshot data directly between storage controllers instead of through Cinder.
High-level architecture of a complete MariaDB deploymentFederico Razzoli
In this webinar Federico will illustrate how to design a complete MariaDB setup. This doesn't only include MariaDB, but all the components that are necessary to form a reliable, scalable architecture.
Federico will cover these points:
- MariaDB storage engines
- Asynchronous replication vs Galera
- Load balancing and failover: ProxySQL, MaxScale, HAProxy
- Eliminating SPoFs in the proxy level
- Backup strategies
- Monitoring solutions
Using galera replication to create geo distributed clusters on the wanSakari Keskitalo
We will show the advantages of having a geo-distributed database cluster and how to create one using Galera Cluster for MySQL. We will also discuss the configuration and status variables that are involved and how to deal with typical situations on the WAN such as slow, untrusted or unreliable links, latency and packet loss. We will demonstrate a multi-region cluster on Amazon EC2 and perform some throughput and latency measurements in real-time.
Using galera replication to create geo distributed clusters on the wanSakari Keskitalo
We will show the advantages of having a geo-distributed database cluster and how to create one using Galera Cluster for MySQL. We will also discuss the configuration and status variables that are involved and how to deal with typical situations on the WAN such as slow, untrusted or unreliable links, latency and packet loss. We will demonstrate a multi-region cluster on Amazon EC2 and perform some throughput and latency measurements in real-time.
Maria DB Galera Cluster for High AvailabilityOSSCube
Want to understand how to set high availability solutions for MySQL using MariaDB Galera Cluster? Join this webinar, and learn from experts. During this webinar, you will also get guidance on how to implement MariaDB Galera Cluster.
This document discusses configuring and implementing a MariaDB Galera cluster for high availability on 3 Ubuntu servers. It provides steps to install MariaDB with Galera patches, configure the basic Galera settings, and start the cluster across the nodes. Key aspects covered include state transfers methods, Galera architecture, and important status variables for monitoring the cluster.
Similar to Choosing the right high availability strategy (20)
MariaDB Paris Workshop 2023 - NewpharmaMariaDB plc
This document summarizes Newpharma's transition from a standalone database server to an enterprise MariaDB Galera cluster configuration between 2018-2023. It discusses the business needs that drove the change, including increased traffic and access to multiple data sources. Key benefits of the Galera cluster are highlighted like synchronous replication, read/write access from any node, and automatic node joining. Challenges of migrating like converting table types and splitting large transactions are also outlined. The transition has supported Newpharma's growth to over 100 million euro in turnover.
MariaDB Paris Workshop 2023 - Performance OptimizationMariaDB plc
MariaDB is an open-source database that is highly tunable and modular. It allows for various storage engines, plugins, and configurations to optimize performance depending on usage. Key aspects that impact performance include memory allocation, disk access, query optimization, and architecture choices like replication, sharding, or using ColumnStore for analytics. Solutions like MyRocks, Spider, MaxScale can improve performance for transactional or large scale workloads by optimizing resources, adding high availability, and distributing load.
MariaDB Paris Workshop 2023 - MaxScale MariaDB plc
The document outlines requirements and criteria for a database solution involving two buildings 30km apart with a WAN link. The chosen solution was MariaDB with Galera cluster for high availability and synchronous replication across sites, along with Maxscale for read/write splitting and failover. Maxscale instances on each site allow for zero downtime database patching and upgrades per site, while the Galera cluster provides structure-independent synchronous replication between sites.
MariaDB Tech und Business Update Hamburg 2023 - MariaDB Enterprise Server MariaDB plc
MariaDB Enterprise Server 10.6 includes the following key features:
- New JSON functions and data types like UUID and INET4.
- Improved Oracle compatibility with function parameters.
- Enhanced partitioning capabilities like converting partitions.
- Optimistic ALTER TABLE for replicas to reduce downtime.
- Online schema changes without locking tables for improved performance.
- Security enhancements including password policies and privilege changes.
MariaDB SkySQL is a cloud database service that provides autonomous scaling, observability, and cloud backup capabilities. It offers multi-cloud and hybrid operations across AWS, Google Cloud, and on-premises databases. The service includes features like the Remote Observability Service (ROS) for monitoring across environments, and a Cloud Backup Service. It aims to provide a simple yet advanced service for scaling databases from small to extreme sizes with tools for automation, self-service, and unified operations.
The document discusses high availability solutions for MariaDB databases. It begins by defining high availability and concepts like Recovery Time Objective (RTO) and Recovery Point Objective (RPO). It then presents different MariaDB and MaxScale architectures that provide high availability, including single node, primary-replica, Galera cluster, and SkySQL solutions. Key aspects covered are automatic failover, load balancing, data filtering, and service level agreements.
Die Neuheiten in MariaDB Enterprise ServerMariaDB plc
This document summarizes new features in MariaDB Enterprise Server. Key points include:
- MariaDB Enterprise Server is geared toward enterprise customers and focuses on stability, robustness, and predictability.
- It has a longer release cycle than Community Server, with new versions every 2 years and long maintenance cycles. New features from Community Server are backported.
- Recent additions include analytics functions, JSON support, bi-temporal modeling, schema changes, database compatibility features, and security enhancements.
- The upcoming 23.x release will include new JSON functions, data types like UUID and INET4, Oracle compatibility features, partitioning improvements, and Galera enhancements.
Global Data Replication with Galera for Ansell Guardian®MariaDB plc
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.
SkySQL is the first and only database-as-a-service (DBaaS) to perform workload analysis with advanced deep learning models, identifying and classifying discrete workload patterns so DBAs can better understand database workloads, identify anomalies and predict changes.
In this session, we’ll explain the concepts behind workload analysis and show how it can be used in the real world (and with sample real-world data) to improve database performance and efficiency by identifying key metrics and changes to cyclical patterns.
SkySQL uses best-of-breed software, and when it comes to metrics and monitoring that means Prometheus and Grafana. SkySQL Monitor is built on both, and provides customers with interactive dashboards for both real-time and historic metrics monitoring. In addition, it meets the same high availability and security requirements as other SkySQL components, ensuring metrics are always available and always secure.
In this session, we’ll explain how SkySQL Monitor works, walk through its dashboards and show how to monitor key metrics for performance and replication.
Introducing the R2DBC async Java connectorMariaDB plc
Not too long ago, a reactive variant of the JDBC driver was released, known as Reactive Relational Database Connectivity (R2DBC for short). While R2DBC started as an experiment to enable integration of SQL databases into systems that use reactive programming models, it now specifies a full-fledged service-provider interface that can be used to retrieve data from a target data source.
In this session, we’ll take a look at the new MariaDB R2DBC connector and examine the advantages of fully reactive, non-blocking development with MariaDB. And, of course, we’ll dive in and get a first-hand look at what it’s like to use the new connector with some live coding!
The capabilities and features of MariaDB Platform continue to expand, resulting in larger and more sophisticated production deployments – and the need for better tools. To provide DBAs with comprehensive, consolidating tooling, we created MariaDB Enterprise Tools: an easy-to-use, modular command-line interface for interacting with any part of MariaDB Platform.
In this session, we will provide a preview of the MariaDB Enterprise Client, walk through current and planned modules and discuss future plans for MariaDB Enterprise Tools – including SkySQL modules and the ability to create custom modules.
Faster, better, stronger: The new InnoDBMariaDB plc
For MariaDB Enterprise Server 10.5, the default transactional storage engine, InnoDB, has been significantly rewritten to improve the performance of writes and backups. Next, we removed a number of parameters to reduce unnecessary complexity, not only in terms of configuration but of the code itself. And finally, we improved crash recovery thanks to better consistency checks and we reduced memory consumption and file I/O thanks to an all new log record format.
In this session, we’ll walk through all of the improvements to InnoDB, and dive deep into the implementation to explain how these improvements help everything from configuration and performance to reliability and recovery.
SkySQL implements a groundbreaking, state-of-the-art architecture based on Kubernetes and ServiceNow, and with a strong emphasis on cloud security – using compartmentalization and indirect access to secure and protect customer databases.
In this session, we’ll walk through the architecture of SkySQL and discuss how MariaDB leverages an advanced Kubernetes operator and powerful ServiceNow configuration/workflow management to deploy and manage databases on cloud infrastructure.
Attendance Tracking From Paper To DigitalTask Tracker
If you are having trouble deciding which time tracker tool is best for you, try "Task Tracker" app. It has numerous features, including the ability to check daily attendance sheet, and other that make team management easier.
Sami provided a beginner-friendly introduction to Amazon Web Services (AWS), covering essential terms, products, and services for cloud deployment. Participants explored AWS' latest Gen AI offerings, making it accessible for those starting their cloud journey or integrating AI into coding practices.
Break data silos with real-time connectivity using Confluent Cloud Connectorsconfluent
Connectors integrate Apache Kafka® with external data systems, enabling you to move away from a brittle spaghetti architecture to one that is more streamlined, secure, and future-proof. However, if your team still spends multiple dev cycles building and managing connectors using just open source Kafka Connect, it’s time to consider a faster and cost-effective alternative.
What is OCR Technology and How to Extract Text from Any Image for FreeTwisterTools
Discover the fascinating world of Optical Character Recognition (OCR) technology with our comprehensive presentation. Learn how OCR converts various types of documents, such as scanned paper documents, PDFs, or images captured by a digital camera, into editable and searchable data. Dive into the history, modern applications, and future trends of OCR technology. Get step-by-step instructions on how to extract text from any image online for free using a simple tool, along with best practices for OCR image preparation. Ideal for professionals, students, and tech enthusiasts looking to harness the power of OCR.
Discover the Power of ONEMONITAR: The Ultimate Mobile Spy App for Android Dev...onemonitarsoftware
Unlock the full potential of mobile monitoring with ONEMONITAR. Our advanced and discreet app offers a comprehensive suite of features, including hidden call recording, real-time GPS tracking, message monitoring, and much more.
Perfect for parents, employers, and anyone needing a reliable solution, ONEMONITAR ensures you stay informed and in control. Explore the key features of ONEMONITAR and see why it’s the trusted choice for Android device monitoring.
Share this infographic to spread the word about the ultimate mobile spy app!
A captivating AI chatbot PowerPoint presentation is made with a striking backdrop in order to attract a wider audience. Select this template featuring several AI chatbot visuals to boost audience engagement and spontaneity. With the aid of this multi-colored template, you may make a compelling presentation and get extra bonuses. To easily elucidate your ideas, choose a typeface with vibrant colors. You can include your data regarding utilizing the chatbot methodology to the remaining half of the template.
React and Next.js are complementary tools in web development. React, a JavaScript library, specializes in building user interfaces with its component-based architecture and efficient state management. Next.js extends React by providing server-side rendering, routing, and other utilities, making it ideal for building SEO-friendly, high-performance web applications.
An MVP (Minimum Viable Product) mobile application is a streamlined version of a mobile app that includes only the core features necessary to address the primary needs of its users. The purpose of an MVP is to validate the app concept with minimal resources, gather user feedback, and identify any areas for improvement before investing in a full-scale development. This approach allows businesses to quickly launch their app, test its market viability, and make data-driven decisions for future enhancements, ensuring a higher likelihood of success and user satisfaction.
3. Approach to HA
3.7 days / year
Backup /
Restore
1
< 99.9%
52.6 min / year
Replication /
Automatic failover
3
~ 99.99%
8.8hs / year
Simple
replication /
manual
failover
2
~ 99.9%
5.3 min / year
Galera
Cluster
~ 99.999%
4 5
Other
Strategies for High Availability
4. An average of 80 percent of mission-critical application service
downtime is directly caused by people or process failures. The
other 20 percent is caused by technology failure, environmental
failure or a disaster
Gartner Research
5. High Availability Background
• High Availability isn’t always equal to long Uptime
– A system is “up” but it might not be accessible
– A system that is “down” just once, but for a long time, is NOT highly available
• High Availability rather means
– Long Mean Time Between Failures (MTBF)
– Short Mean Time To Recover (MTTR)
• High availability is:
– a system design protocol and associated implementation that ensures a certain degree of
operational continuity during a given reference period.
6. High Availability Components
High availability is a system design protocol and associated implementation that
ensures a certain degree of operational continuity during a reference period.
For stateful services, we
need to make sure that
data is made redundant.
It is not a replacement
for backups!
Data Redundancy
Some mechanism to
redirect traffic from the
failed server or
Datacenter to a working
one
Failover or Switchover
Solution
Availability of the
services needs to be
monitored, to take
action when there is a
failure or even to
prevent them
Monitoring and
Management
8. General Terms
• Single Point of Failure (SPOF)
– An element is a SPOF when its failure results in a full stop of the service as no other element
can take over (storage, WAN connection, replication channel)
– It is important to evaluate the costs for eliminating the SPOF, the likelihood that it may fail,
and the time required to bring it into service again
• Downtime
– the period of time a service is down. Planned and unplanned. Planned downtime is part of the
overall availability
• Shared vs. Local Storage
– Shared storage systems like SANs can provide built-in high availability, though this comes with
equally high costs
– Not really suitable for Disaster Recovery scenario on multiple Data Center
– Local storage comes with low cost but we need to implement ways for replicating /mirroring
data
9. General Terms
• Switchover
– When a manual process is used to switch from one system to a redundant or standby system in
case of a failure
• Failover
– Automatic switchover, without human intervention
• Failback
– A (often-underestimated) task to handle the recovery of a failed system and how to fail-back to
the original system after recovery
11. Replication Scheme
All nodes are masters
and applications can read
and write from/to any
node
Synchronous Replication
The Master does not
confirm transactions to
the client application until
at least one slave has
copied the change to its
relay log, and flushed it to
disk
Semi-Syncronous
Replication
The Master does not
wait for Slave, the
master writes events to
its binary log and
slaves request them
when they are ready
Asynchronous
Replication
12. HA Begins with Data Replication
• Replication enables data from one MariaDB server (the master) to be
replicated to one or more MariaDB servers (the slaves)
• MariaDB Replication:
– Very easy to setup:
• On master: Define a replication user
• On slave: CHANGE MASTER TO … <options>
– Used to scale out read workloads
– Provide a first level of high availability and geographic redundancy
– Allows to offload backups and analytic jobs.
13. Asynchronous Replication
• MariaDB Replication is asynchronous by default.
• Slave determines how much to read and from which point in the binary log
• Slave can be behind master in reading and applying changes.
– Single threaded vs parallel replication
• If the master crashes, transactions might not have been transmitted to any
slave
• Asynchronous replication is great for read scaling as adding more replicas
does not impact replication latency
14. Asynchronous Replication-Switch Over
1. The master server is down
2. The slave(s) server(s) is(are) updated to the last position in the relay log
3. Determine which slave server is the most suitable to promote to master
4. Point reminding slaves to the promoted server
5. Point applications to new master server
6. All steps are manual
Master and Slaves
ReadOnly Slaves
Master and Slaves
ReadOnly Slaves
16. MaxScale Use Case
Asynchronous
Replication Failover
New in MaxScale v2.2
Each application server
uses only 1 connection
MaxScale identifies the “master” and
“slaves” nodes
If the “master” node fails,
a new one can be selected and promoted
MariaDB Replication + R/W split routing
Max
Scale
Master and Slaves
ReadOnly Slaves
17. MariaDB GTID Implementation
• Always ON since MariaDB v10.0
– Compatible w/ non-GTID replication: binary log file and position.
• Allows for better control of the replication chain.
– Slave position is recorded crash safe in the same transaction as the last successful DML statement
– Doesn’t require knowing the last binary log file name and position.
– Replication will start from the last recorded GTID
• Allows multi-master replication
– A single slave can have multiple incoming Replication Streams
• MaxScale will select active master automatically
• GTID Components:
– Domain ID: Allows to identify the logical origin of the transactions.
– Server ID: Identifies the server where the transaction originated.
– Transaction Sequence: Monotonically increasing number identifying the transaction.
18. Semi-synchronous Replication
• MariaDB supports semi-synchronous replication:
– The master does not confirm transactions to the client application until at least one slave has
copied the change to its relay log, and flushed it to disk.
– Eliminates data loss by securing a copy of all transactions in at least one slave.
– When a commit returns successfully, it is known that the data exists in at least two places (on the
master and at least one slave).
– Semi- synchronous has a performance impact due to the additional round trip.
• Adds the network latency to the transaction processing time
19. MariaDB Enhanced Semi-synchronous Replication
• One or more slaves can be defined as working semi-synchronously.
• For these slaves, the master waits until the I/O thread on one or more of the semi-synch slaves
has flushed the transaction to disk.
• This ensures that all committed transactions are at least stored in the relay log of the slave.
• If no semi-synch slave can acknowledge the transaction, the master will
downgrade to asynchronous replication after waiting for a timeout period.
Once a semi-synch slave comes back online, the master will reset back to semi-
synch replication.
• Status variable: Rpl_semi_sync_master_status
20. Semi-synchronous Replication – Switch Over
• The steps for a failover are the same as when using the standard replication
• A slave should be chosen among those (if many) that are be semi- synched with the master
Master and Slaves
Semi-Sync
Slave
Async Slaves
Master and Slaves
Async Slaves
21. Semi-Sync Replication Topologies
• Semi- synchronous replication is used between master
and backup master
• Semi- sync replication has a performance impact, but the
risk for data loss is minimized.
• This topology works well when performing master
failover
– The backup master acts as a warm-standby server
– it has the highest probability of having up-to-date data if
compared to other slaves.
Semi_sync
Asynchronous
ReadOnly/
Backup Master
ReadOnly
22. MariaDB Multi-Source Replication
• It enables a slave to receive transactions from
multiple sources simultaneously.
• It can be used to backup multiple servers to a
single server, to merge table shards, and
consolidate data from multiple servers to a single
server.
• GTID helps to track transactions coming from
different servers / applications.
• Note: There is not conflict resolution. Last DML
to reach the slave ‘wins’
Master 2Master 1 Master 3
Slave
23. Combining MariaDB Replication Features
• Replication features can be combined to form more
resilient configurations
• Example:
– Implement semi-sync circular replication to increase data
resilience
– Use GTID to avoid duplicate transactions
– Use read-only slaves for read scale out
– Use MaxScale:
• Transactions will go to active master
• Reads will be offloaded to slaves
• Fast failover
– Writes go to a single master at any given time
Semi_sync
Asynchronous
Backup Master
ReadOnly
24. Synchronous Replication (Galera)
• Galera Replication is a synchronous multi-master
replication plug-in that enables a true master-
master setup for InnoDB.
• Every component of the cluster (node) is a share
nothing server
• All nodes are masters and applications can read and
write from any node
– NOTE: No conflict resolution
• A minimal Galera cluster consists of 3 nodes:
– A proper cluster needs to reach a quorum (i.e. the
majority of the nodes of the cluster)
• Transactions are synchronously committed on all
nodes.
MariaDB
MariaDB
MariaDB
25. Synchronous Replication (Galera)
• PROS
– A high availability solution with synchronous
replication, failover and resynchronization
– No loss of data
– All servers have up-to-date data (no slave lag)
– Read scalability, every node has latest data available
MariaDB
MariaDB
MariaDB
26. Synchronous Replication (Galera)
• CONS
– It only supports InnoDB
– The transaction rollback rate and hence the
transaction latency, can increase with the number of
the cluster nodes
– The cluster performs as its least performing node
• an overloaded master affects the performance of
the Galera cluster
– Network latency affects transaction throughput
MariaDB
MariaDB
MariaDB
27. MDBE
Cluster Failover
Clustered nodes cooperate
to remain in sync
With multiple master nodes,
reads and updates* both scale*
Synchronous replication with
optimistic locking delivers high
availability with little overhead
Fast failover because all
nodes remains synchronizedMariaDB
MariaDB
MariaDB
Load Balancing
and Failover
Application /
App Server
28. MaxScale Use Case
MDBE Cluster
Synchronous Replication
Each application server
uses only 1 connection
MaxScale selects one node
as “master” and the other
nodes as “slaves”
If the “master” node fails,
a new one can be elected
immediately
Galera Cluster + R/W split routing
Max
Scale
29. MariaDB HA: MaxScale
• Re-route traffic between
master and slave(s)
• Failover / slave promotion
- NEW in v2.2
• Switchover on command - NEW
in v2.2
• Implemented for Booking.com
• Part of MaxScale release
• All slaves are in sync,
easy to promote any slave
Read / Write Splitter
Detects Active Master
Binary Log
Server