TokuDB Hotbackup is a solution that allows you to do backups on the fly. It works as a library that intercepts certain system calls that duplicate data written to already copied parts of files, so that at the end of the backup process the copied files contain the same content as the original files. There are several blog posts describing how TokuDB Hot Backup works in details:[Read more]
10 Older Entries »
TwinDB Backup supports encrypted backup copies since version 2.11.0. As usual the tool supports natively backup and restore operations, if backup copies are encrypted the tool takes care of decryption.
Installing TwinDB Packages repository
I will work with CentOS 7 system to show the example, but there are also packages for Ubuntu trusty and Debian jessie.
We host our packages in PackageCloud which provides a great installation guide if you need to install the repo via puppet, chef etc. The manual way is pretty straightforward as well. A PackageCloud script installs and configures the repository.
curl -s https://packagecloud.io/install/repositories/twindb/main/script.rpm.sh | sudo bash
Once the repository is ready it’s time to install the tool.
yum install …[Read more]
Logging is a very important diagnostic tool for understanding the behavior of the application as well as troubleshooting any issue with the application. Since MySQL Enterprise Backup (MEB) is a command line application, there is little interaction with the myriad of operations going on behind the scenes. Thus, logging messages are very important for knowing the progress of current operation as well as learning more about errors should they occur. The messages logged by MEB are written to the console and the log file as depicted in the following diagram, which looks similar to the Tee command in UNIX.
By default, MEB creates the log file in the default ‘<backup_dir>/meta’ directory with a name like MEB_<Date.time>_<operation_name>.log. For example – MEB created a log file with the name, …[Read more]
MySQL Enterprise Backup Team is pleased to announce major improvements in incremental backup performance starting with release 4.1.
The current incremental backup algorithm scans all the tables to gather changed pages even if very few tables are modified since the previous backup and thus results in a 'full-scan' incremental backup. This may result in increment backups requiring the same amount of time as full backup because it scans all the tables. The new algorithm aims to eliminate this extra time.
The new algorithm scans only those tables that have been modified since the previous backup. This algorithm relies on modification time, which is similar to an earlier improvement made for full backup. That full backup algorithm is known as optimistic full backup, hence new improvement is named …[Read more]
MySQL Enterprise Backup Team is pleased to announce redo log performance improvements during the backup operation starting with release 4.1.
As explained in Redo Logging in InnoDB, redo logs are written to the redo log files in a circular fashion. Unless the MySQL server is idle, it continues to generate redo logs. MySQL Enterprise Backup (MEB) copies the redo logs from the redo log files to the ibbackup_logfile during a backup operation. MEB copies the redo logs in order to ensure that it does not miss any transaction while the physical backup is being done. MEB continues to copy the redo logs until it reads all the files from the data directory. If the redo log records are written faster than they can be processed by MEB, the backup operation fails with the following error.
Recently I worked on a ticket where a customer performed a point-in-time recovery PITR using a large set of binary logs. Normally we handle this by applying the last backup, then re-applying all binary logs created since the last backup. In the middle of the procedure, their new server crashed. We identified the binary log position and tried to restart the PITR from there. However, using the option
, the restore failed with the error “The BINLOG statement of type
Table_map was not preceded by a format description
BINLOG statement.” This is a known bug and is reported as MySQL
In this blog, we’ll discuss how to use concurrency to help with WAN latency when using synchronous clusters.
WAN Latency Problem
Our customers often ask us for help or advice with WAN clustering problems. Historically, the usual solution for MySQL WAN deployments is having the primary site in one data center, and stand-by backup site in another data center (replicating from the primary asynchronously). These days, however, there is a huge desire to employ available synchronous replication solutions for MySQL. These solutions include things like Galera (i.e., Percona XtraDB Cluster) or the recently released MySQL Group Replication. This trend is attributable to the fact that these solutions are less problematic and provide more automatic fail over and fail back procedures. But it’s also because businesses want to write in both data centers simultaneously.
Unfortunately, WAN link reliability and latency makes …[Read more]
Join Percona’s Chief Evangelist Colin Charles on Wednesday, January 18, 2017, at 7:00 am (PST) / 10:00 am (EST) (UTC-8) as he presents “Lessons from Database Failures.”
MySQL failures at scale can teach a great deal. MySQL failures can lead to a discussion about such topics as high availability (HA), geographical redundancy and automatic failover. In this webinar, Colin will present case study material (how automatic failover caused Github to go offline, why Facebook uses assisted failover rather than fully automated failover, and other scenarios) to look at how the MySQL world is making things better. One way, for example, is using …[Read more]
In this blog post, we’ll look at how to replace MySQL with Percona Server for MySQL on a CPanel, WHM VPS or dedicated server.
In general, CPanel and WHM have been leaning towards support of MariaDB over other flavors. This is partly due to the upstream repos replacing the MySQL package with MariaDB (for example, on CentOS).
MySQL 5.6 is still supported though, which means they are keeping support for core MySQL products. But if you want to get some extra performance enhancements or enterprise features for free, without getting too many bells and whistles, you might want to install Percona Server.
I’ve done this work on a new dedicated server with the latest WHM and CPanel on CentOS 7, with MySQL 5.6 installed. …[Read more]
Many people store infrequently used data. This data is taking up storage space and might make your database slower than it could be. Archiving data can be a huge benefit, both regarding the performance impact and storage savings.
One of the reasons for archiving data is freeing up space on your database volumes. You can store archived data on slower, less expensive storage devices, and current data on the faster database drives. Archiving old data makes backups and restores run faster since they need to process less data. Last, but by no means least, archiving data has the benefit of making your queries perform more efficiently since they do not need to process through old …[Read more]
10 Older Entries »