Home News Feeds Planet MySQL
Newsfeeds
Planet MySQL
Planet MySQL - https://planet.mysql.com

  • Percona XtraDB Cluster 5.7.19-29.22 is now available
    Percona announces the release of Percona XtraDB Cluster 5.7.19-29.22 on September 22, 2017. Binaries are available from the downloads section or our software repositories. NOTE: You can also run Docker containers from the images in the Docker Hub repository. Percona XtraDB Cluster 5.7.19-29.22 is now the current release, based on the following: Percona Server 5.7.19-17 Galera Replication library 3.22 wsrep API version 29 All Percona software is open-source and free. Upgrade Instructions After you upgrade each node to Percona XtraDB Cluster 5.7.19-29.22, run the following command on one of the nodes: $ mysql -uroot -p < /usr/share/mysql/pxc_cluster_view.sql Then restart all nodes, one at a time: $ sudo service mysql restart New Features Introduced the pxc_cluster_view table to get a unified view of the cluster. This table is exposed through the performance schema. mysql> select * from pxc_cluster_view; ----------------------------------------------------------------------------- HOST_NAME UUID STATUS LOCAL_INDEX SEGMENT ----------------------------------------------------------------------------- n1 b25bfd59-93ad-11e7-99c7-7b26c63037a2 DONOR 0 0 n2 be7eae92-93ad-11e7-88d8-92f8234d6ce2 JOINER 1 0 ----------------------------------------------------------------------------- 2 rows in set (0.01 sec) PXC-803: Added support for new features in Percona XtraBackup 2.4.7: wsrep_debug enables debug logging encrypt_threads specifies the number of threads that XtraBackup should use for encrypting data (when encrypt=1). This value is passed using the --encrypt-threads option in XtraBackup. backup_threads specifies the number of threads that XtraBackup should use to create backups. See the --parallel option in XtraBackup. Improvements PXC-835: Limited wsrep_node_name to 64 bytes. PXC-846: Improved logging to report reason of IST failure. PXC-851: Added version compatibility check during SST with XtraBackup: If a donor is 5.6 and a joiner is 5.7: A warning is printed to perform mysql_upgrade. If a donor is 5.7 and a joiner is 5.6: An error is printed and SST is rejected. Fixed Bugs PXC-825: Fixed script for SST with XtraBackup (wsrep_sst_xtrabackup-v2) to include the --defaults-group-suffix when logging to syslog. For more information, see #1559498. PXC-826: Fixed multi-source replication to PXC node slave. For more information, see #1676464. PXC-827: Fixed handling of different binlog names between donor and joiner nodes when GTID is enabled. For more information, see #1690398. PXC-830: Rejected the RESET MASTER operation when wsrep provider is enabled and gtid_mode is set to ON. For more information, see #1249284. PXC-833: Fixed connection failure handling during SST by making the donor retry connection to joiner every second for a maximum of 30 retries. For more information, see #1696273. PXC-839: Fixed GTID inconsistency when setting gtid_next. PXC-840: Fixed typo in alias for systemd configuration. PXC-841: Added check to avoid replication of DDL if sql_log_bin is disabled. For more information, see #1706820. PXC-842: Fixed deadlocks during Load Data Infile (LDI) with log-bin disabled by ensuring that a new transaction (of 10 000 rows) starts only after the previous one is committed by both wsrep and InnoDB. For more information, see #1706514. PXC-843: Fixed situation where the joiner hangs after SST has failed by dropping all transactions in the receive queue. For more information, see #1707633. PXC-853: Fixed cluster recovery by enabling wsrep_ready whenever nodes become PRIMARY. PXC-862: Fixed script for SST with XtraBackup (wsrep_sst_xtrabackup-v2) to use the ssl-dhparams value from the configuration file. Help us improve our software quality by reporting any bugs you encounter using our bug tracking system. As always, thanks for your continued support of Percona!

  • MySQL Enterprise Monitor 3.4.3 GA has been released
    We are pleased to announce that MySQL Enterprise Monitor 3.4.3 is now available for download on the My Oracle Support (MOS) web site. It will also be available for download via the Oracle Software Delivery Cloud in a few days. MySQL Enterprise Monitor is the best-in-class tool for monitoring and management of your MySQL assets and is included with your MySQL Enterprise Edition and MySQL Cluster Carrier Grade Edition subscriptions. You can find more information on the contents of this release in the change log. Highlights of MySQL Enterprise Monitor 3.4 include: The Replication Dashboard is extended to provide monitoring support for Group Replication, which was introduced in MySQL Server 5.7.17. The Topology view provides a visual representation of your group replication topologies, and the Status drill downs are updated with Group Replication-specific information. The status of the entire group is reported on, also showing node failure tolerances and whether Group Replication has quorum. New Group Replication Configuration and Group Replication Status Advisors provide continuous analysis of the condition of your group replication topologies. The Configuration Advisor checks for misconfigurations which could lead to unstable or insecure installations; the Status Advisor continuously monitors for servers which go offline or fall out of sync with the other members of the cluster. The new Table Statistics report utilizes sys schema and its schema_table_statistics view to show detailed table statistics in both table and treemap forms. Available on MySQL 5.6 and above, report details include total latencies, total number of rows deleted, total I/O write requests. In general, the user interface page-loading times and page responsiveness are improved in 3.4. In addition, time series graphs are much faster in this release, particularly when you specify a long time period. This graph performance improvement is gained by continuous aggregation of time series data. If you are updating from an earlier version, a one-time aggregation of your historic time series data is performed when you first start the Service Manager (as shown by a progress indicator next to the System Status Summary). You will find binaries for the new release on My Oracle Support. Choose the "Patches & Updates" tab, and then choose the "Product or Family (Advanced Search)" side tab in the "Patch Search" portlet. You will also find the binaries on the Oracle Software Delivery Cloud soon.  Search "All Categories" for "MySQL" and choose from the results accordingly.  You will find the Enterprise Monitor along with other MySQL products. Please open a bug or a ticket on My Oracle Support to report problems, request features, or give us general feedback about how this release meets your needs. If you are not a MySQL Enterprise customer and want to try the Monitor and Query Analyzer using our 30-day free customer trial, go to http://www.mysql.com/trials, or contact Sales at http://www.mysql.com/about/contact. Thanks and Happy Monitoring! - The MySQL Enterprise Tools Development Team Useful URLs What's New in 3.4 Change log Installation documentation Complete documentation Product information Frequently Asked Questions

  • MySQL Enterprise Monitor 3.3.5 has been released
    We are pleased to announce that MySQL Enterprise Monitor 3.3.5 is now available for download on the My Oracle Support (MOS) web site. This is a maintenance release that includes a few new features and fixes a number of bugs. You can find more information on the contents of this release in the change log. You will find binaries for the new release on My Oracle Support. Choose the "Patches & Updates" tab, and then choose the "Product or Family (Advanced Search)" side tab in the "Patch Search" portlet. Important: MySQL Enterprise Monitor (MEM) 3.4 offers many significant improvements over MEM 3.3 and we highly recommend that you consider upgrading. More information on MEM 3.4 is available here: What's new in MySQL Enterprise Monitor 3.4? MySQL Enterprise Monitor MySQL Enterprise Monitor Frequently Asked Questions MySQL Enterprise Monitor Change History Please open a bug or a ticket on My Oracle Support to report problems, request features, or give us general feedback about how this release meets your needs. If you are not a MySQL Enterprise customer and want to try the Monitor and Query Analyzer using our 30-day free customer trial, go to http://www.mysql.com/trials, or contact Sales at http://www.mysql.com/about/contact. Thanks and Happy Monitoring! - The MySQL Enterprise Tools Development Team Useful URLs What's New in 3.3 Change log Installation documentation Complete documentation Product information Frequently Asked Questions

  • MySQL Enterprise Monitor 3.2.9 has been released
    We are pleased to announce that MySQL Enterprise Monitor 3.2.9 is now available for download on the My Oracle Support (MOS) web site. This is a maintenance release that includes a few new features and fixes a number of bugs. You can find more information on the contents of this release in the change log. You will find binaries for the new release on My Oracle Support. Choose the "Patches & Updates" tab, and then choose the "Product or Family (Advanced Search)" side tab in the "Patch Search" portlet. Important: MySQL Enterprise Monitor (MEM) 3.4 offers many significant improvements over MEM 3.2 and MEM 3.3 and we highly recommend that you consider upgrading. More information on MEM 3.4 is available here: What's new in MySQL Enterprise Monitor 3.4? MySQL Enterprise Monitor MySQL Enterprise Monitor Frequently Asked Questions MySQL Enterprise Monitor Change History Please open a bug or a ticket on My Oracle Support to report problems, request features, or give us general feedback about how this release meets your needs. If you are not a MySQL Enterprise customer and want to try the Monitor and Query Analyzer using our 30-day free customer trial, go to http://www.mysql.com/trials, or contact Sales at http://www.mysql.com/about/contact. Thanks and Happy Monitoring! - The MySQL Enterprise Tools Development Team Useful URLs My Oracle Support What's New in 3.1 Change log Installation documentation Complete documentation Product information Frequently Asked Questions Download from My Oracle Support

  • How to Deal with XA Transactions Recovery
    For most people (including me until recently) database XA transactions are a fuzzy concept. In over eight years with Percona, I have never had to deal with XA transactions. Then a few weeks ago I got two customers having issues with XA transactions. That deserves a post. XA 101 What are XA transactions? XA transactions are useful when you need to coordinate a transaction between different systems. The simplest example could be simply two storage engines within MySQL. Basically, it follows this sequence: XA START Some SQL statements XA END XA PREPARE XA COMMIT or ROLLBACK Once prepared, the XA transaction survives a MySQL crash. Upon restart, you’ll see something like this in the MySQL error log: 2017-08-23T14:53:54.189068Z 0 [Note] Starting crash recovery... 2017-08-23T14:53:54.189204Z 0 [Note] InnoDB: Starting recovery for XA transactions... 2017-08-23T14:53:54.189225Z 0 [Note] InnoDB: Transaction 45093 in prepared state after recovery 2017-08-23T14:53:54.189244Z 0 [Note] InnoDB: Transaction contains changes to 2 rows 2017-08-23T14:53:54.189257Z 0 [Note] InnoDB: 1 transactions in prepared state after recovery 2017-08-23T14:53:54.189267Z 0 [Note] Found 1 prepared transaction(s) in InnoDB 2017-08-23T14:53:54.189312Z 0 [Warning] Found 1 prepared XA transactions 2017-08-23T14:53:54.189329Z 0 [Note] Crash recovery finished. 2017-08-23T14:53:54.189472Z 0 [Note] InnoDB: Starting recovery for XA transactions... 2017-08-23T14:53:54.189489Z 0 [Note] InnoDB: Transaction 45093 in prepared state after recovery 2017-08-23T14:53:54.189501Z 0 [Note] InnoDB: Transaction contains changes to 2 rows 2017-08-23T14:53:54.189520Z 0 [Note] InnoDB: 1 transactions in prepared state after recovery 2017-08-23T14:53:54.189529Z 0 [Note] Found 1 prepared transaction(s) in InnoDB 2017-08-23T14:53:54.189539Z 0 [Warning] Found 1 prepared XA transactions The command xa recover shows you an output like:mysql> xa recover; +----------+--------------+--------------+-----------+ | formatID | gtrid_length | bqual_length | data | +----------+--------------+--------------+-----------+ | 1234 | 4 | 5 | bqual | +----------+--------------+--------------+-----------+ 1 row in set (0.00 sec) There are some binary data that can’t be shown in HTML. The XA Xid is made of three fields: gtrid (global trx id), bqual (branch qualifier) and formatId. Java applications use all three fields. For my example above, I used “X’01020304′,’bqual’,1234”. You can trust Java application servers to be creative with Xid values. With MySQL 5.7, you can output the data part in hex with convert xid :mysql> xa recover convert xid; +----------+--------------+--------------+----------------------+ | formatID | gtrid_length | bqual_length | data | +----------+--------------+--------------+----------------------+ | 1234 | 4 | 5 | 0x01020304627175616C | +----------+--------------+--------------+----------------------+ 1 row in set (0.01 sec) The Problem If you do nothing, the prepared transaction stays there forever and holds locks and a read view open. As a consequence, the history list grows without bound along with your ibdata1 file, where the undo entries are kept. If you have slaves, they all have the prepared transaction too (at least with 5.7). No fun. As a consequence, if you are using XA transactions, you MUST check if there are prepared transactions pending after the server or mysqld restarted. If you find such transactions, you need to commit or roll them back, depending on what is involved. But how do you commit these XA transactions? The problem here is the output of xa recover. As it is, the output is unusable if there is a bqual field or non-default formatID field:mysql> xa commit 0x01020304627175616C; ERROR 1397 (XAE04): XAER_NOTA: Unknown XID The Fix Looking back at the xa recover convert xid output above, the gtrid_length and bqual_length are provided. With the use of these values, you can extract the parts of the data field which gives us: gtrid = 0x01020304 bqual = 0x627175616C And, of course, the formatID is 1234. Altogether, we have: mysql> xa commit 0x01020304,0x627175616C,1234; Query OK, 0 rows affected (0.15 sec) Which finally works! On 5.6 the convert xid option is not available. You have to be a bit more creative:root@master57:/var/lib/mysql# mysql -r -e 'xa recoverG' | hexdump -C 00000000 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a |****************| 00000010 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 20 31 2e 20 72 |*********** 1. r| 00000020 6f 77 20 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a |ow *************| 00000030 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 0a 20 |**************. | 00000040 20 20 20 66 6f 72 6d 61 74 49 44 3a 20 31 32 33 | formatID: 123| 00000050 34 0a 67 74 72 69 64 5f 6c 65 6e 67 74 68 3a 20 |4.gtrid_length: | 00000060 34 0a 62 71 75 61 6c 5f 6c 65 6e 67 74 68 3a 20 |4.bqual_length: | 00000070 35 0a 20 20 20 20 20 20 20 20 64 61 74 61 3a 20 |5. data: | 00000080 01 02 03 04 62 71 75 61 6c 0a |....bqual.| 0000008a But there is a limitation in 5.6: you can only XA commit/rollback transactions that belong to your session. That means after a crash you are out of luck. To get rid of these you need to promote a slave or perform a logical dump and restore. The best plan is to avoid the use of XA transactions with 5.6. I submitted this bug to Percona Server for MySQL in order to get a usable output out of xa recover convert xid. If you think this is important, vote for it!

Banner
Copyright © 2017 andhrabay.com. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.