We are running 5 node percona cluster on Ubuntu 16.04, and its configured with master-slave replication. Suddenly we got an alert for replica broken from slave server, which was earlier configured with normal replication
We have tried to sync the data and configure the replication, unable to fix that immediately due to huge transactions and GTID enabled servers. So we have decided to follow with innobackupex tool, and problem fixed in 2 hours
Followed all the steps from percona doc and shared the experience in my environment
Steps involving to repair the broken Replication :
1.Backup master server 2.Prepare the backup 3.Restore and Configure the Replication 4Check Replication Status
10 Older Entries »
Author: Robert Agar
The role of a corporate database administrator has evolved tremendously since the introduction of relational databases in the late 1970s. A DBA from the early 1980s would be totally unprepared for the complexities that face database professionals in 2019. It’s a completely different world and the skillset required has radically changed.
The heightened focus on the value of a company’s accumulated data has made DBAs more important to the business goals of an organization than ever before. Keeping this valuable resource safe and accessible is one of the modern DBA’s primary responsibilities. Many diverse methods are required to fulfill these duties, and a DBA must be comfortable using them all to address problems encountered in day-to-day activities.
Common Issues Faced by DBAs
The laundry list of issues that DBAs must deal with regularly is a long one. …[Read more]
This blog post focuses on MySQL 5.7's newly improved features of security validation and password expiration.
The post Security Validation and Password Expiration in MySQL 5.7 appeared first on Datavail.
We remember when we first started auditing MySQL servers, there were very few tools available. In one of our early big gigs, we were battling serious performance issues for a client. At the time, tuning-primer.sh was about the only tool available that could be used to diagnose performance bottlenecks. Fortunately, with a lot of manual interpolation of the raw data it presented, we were able to find the issue with the server and suggest how to resolve them. For that we are very thankful. It was a first step in analyzing MySQL status variables, minimizing the number of formulas to learn and calculate by hand. Obviously doing it by hand takes forever!
Now fast-forward to today. Unfortunately, not much has changed. Many DBAs and developers are still using open source tools such as tuning-primer, mysqltuner.pl, mysqlreport, and so on. Don’t get the wrong; those tools have …[Read more]
With Galera (Percona Cluster or MariaDB Cluster), it is sometimes advisable to not route traffic to a node during a backup due to the node already being under a heavier load. In these situations, it may be wise to not route traffic there until the backup is complete.
Since the default /usr/bin/clustercheck script did not have the option of doing this, we created a modified version. The below script looks for the presence of the xtrabackup tool running in the process list. If it is found, the clustercheck script returns the appropriate exit code (502) which signals the load balancer to not route traffic its way. The script could easily be modified to look for the presence of programs/tools in the process list.
We hope others will find it useful.
#!/bin/bash # clustercheck.sh # # Script to make a proxy (ie HAProxy) capable of monitoring Percona XtraDB Cluster nodes properly # # Modified by Itchy …[Read more]
Ever get called out for a MySQL issue only to realize that there was no issue? It was a false alarm from the monitor. We sure have and it’s frustrating, especially at 3:00 or 4:00 in the morning!
Many DBAs work in an environment where there is some sort of first level support that gets assigned tickets first. Unfortunately, many of the times these groups are, shall we say, less than skilled in MySQL. As a result, they quickly escalate the ticket onto the primary on-call DBA, even when there is really nothing wrong.
Much of the time, there are multiple types of MySQL topology in these environments: standalone, galera cluster, replication, etc. Writing large runbooks with detailed test cases can be a daunting process and one that will cause many first-level support engineers to give up and simply escalate the issue anyway.
In an effort to avoid undue call outs, we developed a simple bash …[Read more]
This document outlines best practices for loading data into MySQL very quickly. While this is not a comprehensive list of loading methods and configuration, it is a good starting point.
Assuming you are loading into InnoDB tables (and you should probably be doing so), you will want to ensure that MySQL is properly performance tuned for loading large amounts of data. Out of the box MySQL configuration is rarely sufficient for performance with MySQL. It is essential that the InnoDB settings, in particular, be set properly.
First of all, consider the InnoDB Buffer Pool. If you are doing a one-time load, it may be a good idea to configure this as large as possible. In fact, we sometimes set this to approximately 90% of the available RAM on the system for the load. This can then be dropped to between 70 and 80% for …[Read more]
10 Older Entries »