Buy Percona ServicesBuy Now!

Percona Server for MongoDB 3.4.6-1.6 is Now Available

Lastest Forum Posts - July 31, 2017 - 2:27am
Percona announces the release of Percona Server for MongoDB 3.4.6-1.6 on July 27, 2017. Download the latest version from the Percona web site or the Percona Software Repositories.

Percona Server for MongoDB is an enhanced, open source, fully compatible, highly-scalable, zero-maintenance downtime database supporting the MongoDB v3.4 protocol and drivers. It extends MongoDB with Percona Memory Engine and MongoRocks storage engine, as well as several enterprise-grade features:Percona Server for MongoDB requires no changes to MongoDB applications or code.

This release is based on MongoDB 3.4.6 and does not include any additional changes.

Percona Server for MySQL 5.7.18-16 Is Now Available

Lastest Forum Posts - July 31, 2017 - 2:26am
Percona is glad to announce the GA release of Percona Server for MySQL 5.7.18-16 on July 28, 2017 (Downloads are available here and from the Percona Software Repositories).

Based on MySQL 5.7.18, including all the bug fixes in it, Percona Server for MySQL 5.7.18-16 is the current GA release in the Percona Server for MySQL 5.7 series. All of Percona's software is open-source and free, and you can find all the release details in the 5.7.18-16 milestone at Launchpad

Please note that RHEL 5, CentOS 5 and Ubuntu versions 12.04 and older are not supported in future releases of Percona Server and no further packages are added for these distributions.

New Features:
  • Percona Server for MySQL is now available on Debian 9 (stretch). The support only covers the amd64 architecture.
  • Percona Server for MySQL can now be built with the support of OpenSSL 1.1.
  • MyRocks storage engine has been merged into Percona Server.
  • TokuDB enables to kill a query that is awaiting an FT locktree lock.
  • TokuDB enables using the MySQL DEBUG_SYNC facility within Percona FT.
Bugs Fixed:
  • Row counts in TokuDB could be lost intermittently after restarts. Bug fixed #2.
  • In TokuDB, two races in the fractal tree lock manager could significantly affect transactional throughput for some applications that used a small number of concurrent transactions. These races manifested as transactions unnecessarily waiting for an available lock. Bug fixed #3.
  • Percona FT could assert when opening a dictionary with no useful information to an error log. Bug fixed #23.
  • Percona FT could assert for various reasons deserializing nodes with no useful error output. Bug fixed #24.
  • It was not possible to build Percona Server on Debian 9 (stretch) due to issues with OpenSSL 1.1. Bug fixed #1702903 (upstream #83814).
  • Packaging was using the dpkg --verify command which is not available on wheezy/precise. Bug fixed #1694907.
  • Enabling and disabling the slow query log rotation spuriously added the version suffix to the next slow query log file name. Bug fixed #1704056.
  • With two client connections to a server (debug server build), the server could crash after one of the clients set the global option userstat and flushed the client statistics (FLUSH CLIENT_STATISTICS) and then both clients were closed. Bug fixed #1661488.
  • Percona FT did not pass cmake flags on to snappy cmake. Bug fixed #41. The progress status for partitioned TokuDB table ALTERs was misleading. Bug fixed #42.
  • When a client application is connecting to the Aurora cluster end point using SSL (--ssl-verify-server-cert or --ssl-mode=VERIFY_IDENTITY option), wildcard and SAN enabled SSL certificates were ignored. Note that the --ssl-verify-server-cert option is deprecated in Percona Server 5.7. Bug fixed #1673656 (upstream #68052).
  • Killing a stored procedure execution could result in an assert failure on a debug server build. Bug fixed #1689736 (upstream #86260).
  • The SET STATEMENT .. FOR statement changed the global instead of the session value of a variable if the statement occurred immediately after the SET GLOBAL or SHOW GLOBAL STATUS command. Bug fixed #1385352.
  • When running SHOW ENGINE INNODB STATUS, the Buffer pool size, bytes entry contained 0. BUg fixed #1586262.
  • The synchronization between the LRU manager and page cleaner threads was not done at shutdown. Bug fixed #1689552.
  • Spurious lock_wait_timeout_thread wakeup in lock_wait_suspend_thread() could occur. Bug fixed #1704267 (upstream #72123).
Other bugs fixed: #1686603, #6, #44, #65, #1160986, #1686934, #1688319, #1689989, #1690012, #1691682, #1697700, #1699788, #1121072, and #1684601 (upstream #86016).

The release notes for Percona Server for MySQL 5.7.18-16 are available in the online documentation. Please report any bugs on the launchpad bug tracker.

Note

Due to new package dependency, Ubuntu/Debian users should use apt-get dist-upgrade or apt-get install percona-server-server-5.7 to upgrade.

Joining cluster fails because of SST timeout

Lastest Forum Posts - July 30, 2017 - 11:20pm
I'm running into the same problem as this topic:
https://www.percona.com/forums/quest...o-join-cluster

After 9000 seconds SST is stopped, so nodes can no longer join my cluster, as it's too big now to complete in time.
Is there a fix for this yet?

Percona Server for MySQL 5.7.18-16 Is Now Available

Latest MySQL Performance Blog posts - July 28, 2017 - 11:49am

Percona is glad to announce the GA release of Percona Server for MySQL 5.7.18-16 on July 28, 2017 (Downloads are available here and from the Percona Software Repositories).

Based on MySQL 5.7.18, including all the bug fixes in it, Percona Server for MySQL 5.7.18-16 is the current GA release in the Percona Server for MySQL 5.7 series. All of Percona‘s software is open-source and free, and you can find all the release details in the 5.7.18-16 milestone at Launchpad

Please note that RHEL 5, CentOS 5 and Ubuntu versions 12.04 and older are not supported in future releases of Percona Server and no further packages are added for these distributions.

New Features:

  • Percona Server for MySQL is now available on Debian 9 (stretch). The support only covers the amd64 architecture.
  • Percona Server for MySQL can now be built with the support of OpenSSL 1.1.
  • MyRocks storage engine has been merged into Percona Server.
  • TokuDB enables to kill a query that is awaiting an FT locktree lock.
  • TokuDB enables using the MySQL DEBUG_SYNC facility within Percona FT.

Bugs Fixed:

  • Row counts in TokuDB could be lost intermittently after restarts. Bug fixed #2.
  • In TokuDB, two races in the fractal tree lock manager could significantly affect transactional throughput for some applications that used a small number of concurrent transactions. These races manifested as transactions unnecessarily waiting for an available lock. Bug fixed #3.
  • Percona FT could assert when opening a dictionary with no useful information to an error log. Bug fixed #23.
  • Percona FT could assert for various reasons deserializing nodes with no useful error output. Bug fixed #24.
  • It was not possible to build Percona Server on Debian 9 (stretch) due to issues with OpenSSL 1.1. Bug fixed #1702903 (upstream #83814).
  • Packaging was using the dpkg --verify command which is not available on wheezy/precise. Bug fixed #1694907.
  • Enabling and disabling the slow query log rotation spuriously added the version suffix to the next slow query log file name. Bug fixed #1704056.
  • With two client connections to a server (debug server build), the server could crash after one of the clients set the global option userstat and flushed the client statistics (FLUSH CLIENT_STATISTICS) and then both clients were closed. Bug fixed #1661488.
  • Percona FT did not pass cmake flags on to snappy cmake. Bug fixed #41. The progress status for partitioned TokuDB table ALTERs was misleading. Bug fixed #42.
  • When a client application is connecting to the Aurora cluster end point using SSL (--ssl-verify-server-cert or --ssl-mode=VERIFY_IDENTITY option), wildcard and SAN enabled SSL certificates were ignored. Note that the --ssl-verify-server-cert option is deprecated in Percona Server 5.7. Bug fixed #1673656 (upstream #68052).
  • Killing a stored procedure execution could result in an assert failure on a debug server build. Bug fixed #1689736 (upstream #86260).
  • The SET STATEMENT .. FOR statement changed the global instead of the session value of a variable if the statement occurred immediately after the SET GLOBAL or SHOW GLOBAL STATUS command. Bug fixed #1385352.
  • When running SHOW ENGINE INNODB STATUS, the Buffer pool size, bytes entry contained 0. BUg fixed #1586262.
  • The synchronization between the LRU manager and page cleaner threads was not done at shutdown. Bug fixed #1689552.
  • Spurious lock_wait_timeout_thread wakeup in lock_wait_suspend_thread() could occur. Bug fixed #1704267 (upstream #72123).

Other bugs fixed: #1686603#6#44#65#1160986#1686934#1688319#1689989#1690012#1691682#1697700#1699788#1121072, and #1684601 (upstream #86016).

The release notes for Percona Server for MySQL 5.7.18-16 are available in the online documentation. Please report any bugs on the launchpad bug tracker.

Note

Due to new package dependency, Ubuntu/Debian users should use apt-get dist-upgrade or apt-get install percona-server-server-5.7 to upgrade.

Percona Server for MongoDB 3.4.6-1.6 is Now Available

Latest MySQL Performance Blog posts - July 28, 2017 - 10:37am

Percona announces the release of Percona Server for MongoDB 3.4.6-1.6 on July 27, 2017. Download the latest version from the Percona web site or the Percona Software Repositories.

Percona Server for MongoDB is an enhanced, open source, fully compatible, highly-scalable, zero-maintenance downtime database supporting the MongoDB v3.4 protocol and drivers. It extends MongoDB with Percona Memory Engine and MongoRocks storage engine, as well as several enterprise-grade features:

Percona Server for MongoDB requires no changes to MongoDB applications or code.

This release is based on MongoDB 3.4.6 and does not include any additional changes.

Is it possible to backup and restore InnoDB tables on Oracle's MySQL 5.7.19 Server?

Lastest Forum Posts - July 28, 2017 - 10:16am
Hello world!

I have the next configuration:
OS: Ubuntu 16.04.2 x86_64
MySQL Server: Ver 5.7.19-0ubuntu0.16.04.1 for Linux on x86_64 ((Ubuntu)) installed from Ubuntu's repos
Percona Tools: innobackupex version 2.4.8 Linux (x86_64) (revision id: 97330f7) installed from the Percona's repos.

The problem is the next: When I do the backup with innobackupex and then restore - my InnoDB tables got corrupted.
Code: 2017-07-28T15:49:50.078080Z 4 [Warning] InnoDB: Cannot open table forum/domain from the internal data dictionary of InnoDB though the .frm file for the table exists. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue. The backup/restore happens on the same server. MySQL server has the defaults settings, innodb_file_per_table option is not set directly, but Oracle's MySQL has that enabled by the default.
Code: mysql> show variables like '%innodb_file%'; +--------------------------+-----------+ | Variable_name | Value | +--------------------------+-----------+ | innodb_file_format | Barracuda | | innodb_file_format_check | ON | | innodb_file_format_max | Barracuda | | innodb_file_per_table | ON | +--------------------------+-----------+ 4 rows in set (0.00 sec) In order to do the backup, I do:
Code: innobackupex --defaults-extra-file=/root/.my.cnf --include=forum.* --parallel=9 --extra-lsndir=/home/forum --stream=xbstream --no-timestamp /home/forum 2>/home/backup.log | lzop -c > /home/forum.xbs.lzo the xtrabackup_info file from the result:
Code: uuid = 850f3d9e-73ab-11e7-8b45-448a5b2c32e7 name = tool_name = innobackupex tool_command = --defaults-extra-file=/root/.my.cnf --include=forum.* --parallel=9 --extra-lsndir=/home/forum --stream=xbstream --no-timestamp /home/forum tool_version = 2.4.8 ibbackup_version = 2.4.8 server_version = 5.7.19-0ubuntu0.16.04.1 start_time = 2017-07-28 17:43:27 end_time = 2017-07-28 17:43:36 lock_time = 0 binlog_pos = innodb_from_lsn = 0 innodb_to_lsn = 14341896999 partial = Y incremental = N format = xbstream compact = N compressed = N encrypted = N As the restore, I do the next:
unarchive the file:
Code: lzop -dcfU /home/forum.xbs.lzo | xbstream -x --directory=/home/forum.restore Apply Log:
Code: innobackupex --apply-log --redo-only /home/forum.restore --use-memory=1G 2>/home/restore.log Prepare the backup for usage:
Code: innobackupex --apply-log /home/forum.restore --use-memory=1G 2>>/home/restore.log After that my directory has:
Code: root@restore-test /home/forum.restore # tree . ├── backup-my.cnf ├── forum │ ├── db.opt │ ├── domain.frm │ └── domain.ibd ├── ib_buffer_pool ├── ibdata1 ├── ib_logfile0 ├── ib_logfile1 ├── ibtmp1 ├── xtrabackup_checkpoints ├── xtrabackup_info └── xtrabackup_logfile The final is:
  1. stop MySQL server
  2. chown -R mysql:mysql /home/forum.restore/forum
  3. mv /home/forum.restore/forum /var/lib/mysql/forum
  4. start MySQL
The database is there, but when i try to do any operation with the table (SHOW/DESCRIBE/etc) - I'm having the error listed above.

Percona PXC 5.6 cluster , IST fails with SSL

Lastest Forum Posts - July 28, 2017 - 9:11am
Hi ,
i have 2 node cluster with SSL turned on , SST works fine but when i shutdown node 2 and perform 2-3 transactions on node1 , restarts node2 then it fails during IST sync. I see this error on node1 ( donor ).

Jul 28 11:40:40 vishalmysql1 mysqld: 2017-07-28 11:40:40 23619 [Note] WSREP: Running: 'wsrep_sst_xtrabackup-v2 --role 'donor' --address 'vishalmysql2:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix '' --binlog 'vishalmysql1' --gtid '1ef1062a-6e4f-11e7-9633-661746480a72:60' --bypass'
Jul 28 11:40:40 vishalmysql1 mysqld: 2017-07-28 11:40:40 23619 [Note] WSREP: sst_donor_thread signaled with 0
Jul 28 11:40:40 vishalmysql1 mysqld: 2017-07-28 11:40:40 23619 [Note] WSREP: IST sender using ssl
Jul 28 11:40:40 vishalmysql1 mysqld: 2017-07-28 11:40:40 23619 [ERROR] WSREP: IST failed: IST sender, failed to connect 'ssl://vishalmysql2:4568': connect: Connection refused: 111 (Connection refused)
Jul 28 11:40:40 vishalmysql1 mysqld: at galera/src/ist.cpp:Sender():668
Jul 28 11:40:40 vishalmysql1 mysqld: 2017-07-28 11:40:40 23619 [Warning] WSREP: 1.0 (vishalmysql1): State transfer to 0.0 (vishalmysql2) failed: -111 (Connection refused)
Jul 28 11:40:40 vishalmysql1 mysqld: 2017-07-28 11:40:40 23619 [Note] WSREP: Shifting DONOR/DESYNCED -> JOINED (TO: 61)
Jul 28 11:40:41 vishalmysql1 mysqld: WSREP_SST: [INFO] Logging all stderr of SST/Innobackupex to syslog (2017-07-28 11:40:41)
Jul 28 11:40:41 vishalmysql1 -wsrep-sst-donor: Streaming with xbstream
Jul 28 11:40:41 vishalmysql1 -wsrep-sst-donor: Using socat as streamer
Jul 28 11:40:41 vishalmysql1 -wsrep-sst-donor: Using openssl based encryption with socat: with key, crt, and ca
Jul 28 11:40:41 vishalmysql1 -wsrep-sst-donor: Encrypting with CERT: /var/lib/mysql/CERTS/server-cert.pem, KEY: /var/lib/mysql/CERTS/server-key.pem, CA: /var/lib/mysql/CERTS/ca.pem
Jul 28 11:40:41 vishalmysql1 -wsrep-sst-donor: Bypassing the SST for IST
Jul 28 11:40:41 vishalmysql1 -wsrep-sst-donor: Evaluating xbstream -c ${INFO_FILE} ${IST_FILE} | socat -u stdio openssl-connect:vishalmysql2:4444,cert=/var/lib/mysql/CERTS/server-cert.pem,key=/var/lib/mysql/CERTS/server-key.pem,cafile=/var/lib/mysql/CERTS/ca.pem,verify=1; RC=( ${PIPESTATUS[@]} )
Jul 28 11:40:41 vishalmysql1 mysqld: 2017-07-28 11:40:41 23619 [ERROR] WSREP: sst sent called when not SST donor, state JOINED
Jul 28 11:40:41 vishalmysql1 -wsrep-sst-donor: Total time on donor: 0 seconds
Jul 28 11:40:41 vishalmysql1 -wsrep-sst-donor: Cleaning up temporary directories
Jul 28 11:40:41 vishalmysql1 mysqld: 2017-07-28 11:40:41 23619 [Note] WSREP: forgetting 1ac12fce (ssl://172.28.96.198:4567)
Jul 28 11:40:41 vishalmysql1 mysqld: 2017-07-28 11:40:41 23619 [Note] WSREP: Node ea1a47da state prim

Any idea ?

Migration back from PXC to standalone Percona server

Lastest Forum Posts - July 28, 2017 - 7:55am
Hi!

Could anyone, please, advise my any viable strategy on how to migrate back from PXC to standalone percona server without downtime? Is it possible to chain PXC with standalone slave percona server, switch their roles after sync and point application to a former standalone slave?

Thanks.

MySQL Binary log is not enabling even after changes in my.cnf

Lastest Forum Posts - July 28, 2017 - 3:04am
Hi There,

I have an issue with Enabling the binary logs on the MySQL Server. I've enabled the binary log configuration, even after that the logs are not getting generated.

Please find the below error for the same.

mysql> show binary logs;
--------------
show binary logs
--------------

ERROR 1381 (HY000): You are not using binary logging


Attached the my.cnf file.

qan does not remove or stop individual servers

Lastest Forum Posts - July 27, 2017 - 11:00am
Monitoring queries is such a great feature and I really like it. That said it can be clunky to admin. I am on RDS, which means that it can be easy to add instances but deleting QAN for instances about to be decommissioned is challenging. I took notes. Tried many things and eventually found the UUID associated with the QAN and removed it. Here's the details:

pmm-admin Info
pmm-admin 1.2.0 (both server & client)

I did the following
1. pmm-admin stop mysql:queries myrds2
2. pmm-admin list shows ALL mysql:queries had stopped, including my main RDS.
3. pmm-admin start mysql:queries myrds1
4. pmm-admin list shows ALL mysql:queries had started, including myrds2.
5. I again stopped mysql:queries : pmm-admin stop mysql:queries
6. ran pmm-admin remove mysql:queries myrds2
7. pmm-admin start mysql:queries myrds1 and mysql:queries myrds2 was STILL listed.
8.. systemctl stop pmm-mysql-queries-0
9. systemctl start pmm-mysql-queries-0
10. pmm-admin list show ALL mysql:queries had started, including myrds2.
11. went into PMM queries & the drop down showed me the UUID of myrds2.
12. pmm-admin stop mysql:queries
13. systemctl stop pmm-mysql-queries-0
14 sudo rm /usr/local/percona/qan-agent/instance/<myrds2>json
15 ran systemctl start pmm-mysql-queries-0
16. pmm-admin start mysql:queries
17. pmm-admin list showed that the myrds2 was no longer in the list.

I had to remove the <UUID>.json from the qan-agent/instances to get that RDS instance to stop collecting queries. I found that my running a find for the qan UUID on the instance I wanted to go away. Seems like remove should remove that UUID or at least change the name so it won't be used by qan.

I'm putting this here incase someone else is having similar problems.

What is MySQL Partitioning?

Latest MySQL Performance Blog posts - July 27, 2017 - 8:39am

In this blog, we’ll quickly look at MySQL partitioning.

Partitioning is a way in which a database (MySQL in this case) splits its actual data down into separate tables, but still get treated as a single table by the SQL layer.

When partitioning, it’s a good idea to find a natural partition key. You want to ensure that table lookups go to the correct partition or group of partitions. This means that all SELECT, UPDATE, DELETE should include that column in the WHERE clause. Otherwise, the storage engine does a scatter-gather, and queries ALL partitions in a UNION that is not concurrent.

Generally, you must add the partition key into the primary key along with the auto increment, i.e., PRIMARY KEY (part_id,id). If you don’t have well-designed and small columns for this composite primary key, it could enlarge all of your secondary indexes.

You can partition by range or hash. Range is great because you have groups of known IDs in each table, and it helps when querying across partition IDs. This still can create hotspots in the newest partition, as all new inserts go there. Partitioning by hash “load balances” the table, and allows you to write to partitions more concurrently. This makes range queries on the partition key a bad idea.

In MySQL 5.7, partitioning became native to the store engine and deprecated the old method where MySQL itself had to handle the partitions. This means InnoDB partitions (and a larger amount of partitions) are a better choice than in the past.

As with all features and recommendations, this only makes sense if it helps your data and workload!

Percona Server for MongoDB 3.2.15-3.5 is Now Available

Latest MySQL Performance Blog posts - July 26, 2017 - 9:42am

Percona announces the release of Percona Server for MongoDB 3.2.15-3.5 on July 26, 2017. Download the latest version from the Percona web site or the Percona Software Repositories.

Percona Server for MongoDB is an enhanced, open-source, fully compatible, highly scalable, zero-maintenance downtime database that supports the MongoDB v3.2 protocol and drivers. It extends MongoDB with MongoRocks, Percona Memory Engine, and PerconaFT storage engine, as well as enterprise-grade features like External Authentication, Audit Logging, Profiling Rate Limiting, and Hot Backup at no extra cost. The software requires no changes to MongoDB applications or code.

NOTE: We deprecated the PerconaFT storage engine. It will not be available in future releases.

This release is based on MongoDB 3.2.15 and does not include any additional changes.

Percona Server for MongoDB 3.2.15-3.5 release notes are available in the official documentation.

Percona audit log logging root events nonstop in XtraDB cluster 5.6.36-82.0-56-log

Lastest Forum Posts - July 26, 2017 - 8:51am
Hi , i am having this issue with installing percona audit plugin in XtraDB Cluster 5.6.36-82.0-56-log and right after installing it , audit.log starts logging root events every seconds quickly. File size is going to be very large. If i set the variables to "exclude" root@localhost then it stops but i do not want to do that and keep monitoring root also. Is there a reason why it does that ? ( any inter cluster communication happening ). Please help.

New cluster install, first cluster node doesn't show as

Lastest Forum Posts - July 26, 2017 - 8:15am
I've been trying to install Percona onto a 3 node cluster. I cant' even get the first node to show up a cluster size of 1:



Code: mysql> show status like 'wsrep%'; +--------------------------+----------------------+ | Variable_name | Value | +--------------------------+----------------------+ | wsrep_cluster_conf_id | 18446744073709551615 | | wsrep_cluster_size | 0 | | wsrep_cluster_state_uuid | | | wsrep_cluster_status | Disconnected | | wsrep_connected | OFF | | wsrep_local_bf_aborts | 0 | | wsrep_local_index | 18446744073709551615 | | wsrep_provider_name | | | wsrep_provider_vendor | | | wsrep_provider_version | | | wsrep_ready | ON | +--------------------------+----------------------+ 11 rows in set (0.00 sec)
running:
sudo /etc/init.d/mysql bootstrap-pxc

produces this:
[ ok ] Bootstrapping Percona XtraDB Cluster database server: mysqld already running.

So I have no idea why the cluster size is not 1.



What is innodb_autoinc_lock_mode and why should I care?

Latest MySQL Performance Blog posts - July 26, 2017 - 8:15am

In this blog post, we’ll look at what innodb_autoinc_lock_mode is and how it works.

I was recently discussing innodb_autoinc_lock_mode with some colleagues to address issues at a company I was working with.This variable defines the lock mode to use for generating auto-increment values. The permissible values are 0, 1 or 2 (for “traditional”, “consecutive” or “interleaved” lock mode, respectively). In most cases, this variable is set to the default of 1.

We recommend setting it to 2 when the BINLOG_FORMAT=ROW. With interleaved, INSERT statements don’t use the table-level AUTO-INC lock and multiple statements can execute at the same time. Setting it to 0 or 1 can cause a huge hit in concurrency for certain workloads.

Interleaved (or 2) is the fastest and most scalable lock mode, but it is not safe if using STATEMENT-based replication or recovery scenarios when SQL statements are replayed from the binary log. Another consideration – which you shouldn’t rely on anyway – is that IDs might not be consecutive with a lock mode of 2. That means you could do three inserts and expect IDs 100,101 and 103, but end up with 100, 102 and 104. For most people, this isn’t a huge deal.

If you are only doing simple inserts, this might not help you. I did a sysbench test on MySQL 5.7 in Amazon RDS with 100 threads and found no difference in performance or throughput between lock modes 1 and 2. It helps the most when you when the number of rows can’t be determined, such as with INSERT INTO…SELECT statements.

You can find a longer form article in the manual, but I highly recommend setting this value to 2 if you are not using STATEMENT-based replication.

Webinar Thursday July 27, 2017: Database Backup and Recovery Best Practices (with a Focus on MySQL)

Latest MySQL Performance Blog posts - July 25, 2017 - 12:46pm

Join Percona’s, Architect, Manjot Singh as he presents Database Backup and Recovery Best Practices (with a Focus on MySQL) on Thursday, July 27, 2017 at 11:00 am PDT / 2:00 pm EDT (UTC-7).

Register Now

In the case of a failure, do you know how long it will take to restore your database? Do you know how old the backup will be? In this presentation, we will cover the basics of best practices for backup, restoration and business continuity. Don’t put your company on the line due to bad data retention and backup policies.

Register for the webinar here.

Manjot Singh, Architect Manjot Singh is an Architect with Percona in California. He loves to learn about new technologies and apply them to real-world problems. Manjot is a veteran of startup and Fortune 500 enterprise companies alike, with a few years spent in government, education and hospital IT. Now he consults for Percona with companies around the world on many interesting problems.

QAN not picking up change to long_query_time

Lastest Forum Posts - July 25, 2017 - 6:21am
I have decreased long_query_time from the default of 10 to 1 second. I have confirmed that queries > 1 second are in the slow log. QAN does not show queries between 1 and 10 seconds, but it will still display queries > 10 seconds. What do I need to do for QAN to pick up these queries?

I am using PMM 1.2.0. The database is MariaDB 10.1.21.

Thanks - Chris

Percona XtraBackup 2.4.8 is Now Available

Lastest Forum Posts - July 25, 2017 - 12:48am
Percona announces the GA release of Percona XtraBackup 2.4.8 on July 24, 2017. You can download it from our download site and apt and yumrepositories.

Percona XtraBackup enables MySQL backups without blocking user queries, making it ideal for companies with large data sets and mission-critical applications that cannot tolerate long periods of downtime. Offered free as an open source solution, Percona XtraBackup drives down backup costs while providing unique features for MySQL backups. New features:

Bugs Fixed:

  • xtrabackup would hang with Waiting for master thread to be suspended message when backup was being prepared. Bug fixed #1671437.
  • xtrabackup would fail to prepare the backup with 6th page is not initialized message in case server didn’t properly initialize the page. Bug fixed #1671722.
  • xbstream could run out of file descriptors while extracting the backup which contains many tables. Bug fixed #1690823.
  • When a table was created with the DATA DIRECTORY option xtrabackup would back up the .frm and .islfiles, but not the .ibd file. Due to the missing .ibd files backup then could not be restored. Bug fixed #1701736.
  • Percona XtraBackup incorrectly determined use of master_auto_postion on a slave, and thus generated invalid xtrabackup_slave_info file. Bug fixed #1705193.
  • Percona XtraBackup will now print a warning if it encounters unsupported storage engine. Bug fixed #1394493.
  • Percona XtraBackup would crash while backing up MariaDB 10.2.x with --ftwrl-* options. Bug fixed #1704636.
  • xtrabackup --slave-info didn’t write the correct information into xtrabackup_slave_info file when multi-source replication was used. Bug fixed #1551634.
  • Along with xtrabackup_checkpints file, xtrabackup now copies xtrabackup_info file into directory specified by --extra-lsndir option. Bug fixed #1600656.
  • GTID position was not recorded when --binlog-info option was set to AUTO. Bug fixed #1651505.
Release notes with all the bugfixes for Percona XtraBackup 2.4.8 are available in our online documentation. Please report any bugs to the launchpad bug tracker.

Percona XtraBackup 2.3.9 is Now Available

Lastest Forum Posts - July 25, 2017 - 12:47am
Percona announces the release of Percona XtraBackup 2.3.9 on July 24, 2017. Downloads are available from our download site or Percona Software Repositories.

Percona XtraBackup enables MySQL backups without blocking user queries, making it ideal for companies with large data sets and mission-critical applications that cannot tolerate long periods of downtime. Offered free as an open source solution, Percona XtraBackup drives down backup costs while providing unique features for MySQL backups.

This release is the current GA (Generally Available) stable release in the 2.3 series. New Features

Bugs Fixed:

  • Percona XtraBackup would crash when being prepared if the index compaction was enabled. Bug fixed #1192834.
  • Fixed build failure on Debian Stretch by adding support for building with OpenSSL 1.1. Bug fixed #1678947.
  • xbstream could run out of file descriptors while extracting the backup which contains many tables. Bug fixed #1690823.
  • Percona XtraBackup incorrectly determined use of master_auto_postion on a slave, and thus generated invalid xtrabackup_slave_info file. Bug fixed #1705193.
  • Percona XtraBackup would crash while backing up MariaDB 10.2.x with --ftwrl-* options. Bug fixed #1704636.
  • Along with xtrabackup_checkpints file, xtrabackup now copies xtrabackup_info file into directory specified by --extra-lsndir option. Bug fixed #1600656.
  • GTID position was not recorded when --binlog-info option was set to AUTO. Bug fixed #1651505.
Release notes with all the bugfixes for Percona XtraBackup 2.3.9 are available in our online documentation. Bugs can be reported on the launchpad bug tracker.

Percona XtraBackup 2.4.8 is Now Available

Latest MySQL Performance Blog posts - July 24, 2017 - 10:59am

Percona announces the GA release of Percona XtraBackup 2.4.8 on July 24, 2017. You can download it from our download site and apt and yum repositories.

Percona XtraBackup enables MySQL backups without blocking user queries, making it ideal for companies with large data sets and mission-critical applications that cannot tolerate long periods of downtime. Offered free as an open source solution, Percona XtraBackup drives down backup costs while providing unique features for MySQL backups.

New features: Bugs Fixed:
  • xtrabackup would hang with Waiting for master thread to be suspended message when backup was being prepared. Bug fixed #1671437.
  • xtrabackup would fail to prepare the backup with 6th page is not initialized message in case server didn’t properly initialize the page. Bug fixed #1671722.
  • xbstream could run out of file descriptors while extracting the backup which contains many tables. Bug fixed #1690823.
  • When a table was created with the DATA DIRECTORY option xtrabackup would back up the .frm and .isl files, but not the .ibd file. Due to the missing .ibd files backup then could not be restored. Bug fixed #1701736.
  • Percona XtraBackup incorrectly determined use of master_auto_postion on a slave, and thus generated invalid xtrabackup_slave_info file. Bug fixed #1705193.
  • Percona XtraBackup will now print a warning if it encounters unsupported storage engine. Bug fixed #1394493.
  • Percona XtraBackup would crash while backing up MariaDB 10.2.x with --ftwrl-* options. Bug fixed #1704636.
  • xtrabackup --slave-info didn’t write the correct information into xtrabackup_slave_info file when multi-source replication was used. Bug fixed #1551634.
  • Along with xtrabackup_checkpints file, xtrabackup now copies xtrabackup_info file into directory specified by --extra-lsndir option. Bug fixed #1600656.
  • GTID position was not recorded when --binlog-info option was set to AUTO. Bug fixed #1651505.

Release notes with all the bugfixes for Percona XtraBackup 2.4.8 are available in our online documentation. Please report any bugs to the launchpad bug tracker.

Visit Percona Store


General Inquiries

For general inquiries, please send us your question and someone will contact you.