I Use This!
Very High Activity


Analyzed 23 days ago. based on code collected 23 days ago.
Posted about 10 hours ago by MariaDB
Say Hello to MariaDB TX Shane Johnson Tue, 05/23/2017 - 15:49 We believe an enterprise database solution requires technology, tools and services, and that it should be easy to buy, easy to deploy and easy to manage – providing a great ... [More] customer and user experience from beginning to end.  In fact, we've made ease of use a central theme in our roadmap, and with the introduction of MariaDB TX today, we're taking another first step – packaging MariaDB technology, tools and services into a unified offering to help customers succeed with MariaDB infrastructure: MariaDB Server, MariaDB MaxScale and MariaDB Cluster. In addition to introducing MariaDB TX, we are releasing MariaDB Server 10.2 and MariaDB MaxScale 2.1. MariaDB Server, MariaDB MaxScale and MariaDB Cluster (Galera Cluster for MariaDB), along with MariaDB connectors and drivers, form the base technology in MariaDB TX. By bringing them together, we are building a modular, integrated platform rather than separate, independent products – making them easier to deploy, easier to use and easier to manage ... together. In addition, MariaDB TX includes tools for administration (SQLyog for MariaDB), monitoring (Monyog for MariaDB) and backup/restore (MariaDB Backup) as well as notification services (e.g., security alerts). In addition, we're creating and investing in more innovative tools for future release, including MariaDB Replication Manager (MRM).  And finally, to ensure customer success and satisfaction with MariaDB TX, we provide expert services for everything from database administration to enterprise architecture to migration management. In addition to technical support, customers can choose to extend their team with a remote DBA, a dedicated enterprise architect or migration project manager – resources with expert knowledge and experience.    A great way to learn more about MariaDB TX 2.0, including the new features in MariaDB Server 10.2 and MariaDB MaxScale 2.1, is to join our upcoming launch webinar.  If you want to dive right in, keep reading!   MariaDB TX 2.0 Product highlights A comprehensive set of JSON functions in a relational database An SSD optimized storage engine with unrivaled performance and efficiency An advanced database firewall, complete with data masking With MariaDB Server 10.2 and MaxScale 2.1, MariaDB TX 2.0 raises the completeness, compatibility, performance, scalability, security and disaster recovery of MariaDB – setting a new standard for open source database solutions in the enterprise.  Completeness and compatibility First, we wanted to increase SQL completeness and schema compatibility. If you choose MariaDB TX over Oracle Database or Microsoft SQL Server, you should be able to perform similar queries on similar schemas. And while many of these features have long been available in proprietary databases, we're excited to make them available in an open source database.  Completeness Compatibility Common table expressions Window functions JSON and GeoJSON functions EXECUTE IMMEDIATE statements Subqueries within views Multiple temp tables per query CHECK constraints with expressions DEFAULT values for BLOB/TEXT DECIMAL columns up to 38 places Multiple triggers per type per table Performance and scalability Next, we wanted to increase performance and scalability, focusing on storage, replication, querying and routing. At scale, improving storage efficiency and reducing disk IO not only improves performance, it reduces costs. Today, that means optimizing for SSDs, which is why we're introducing MyRocks, a storage engine developed by Facebook for web-scale use cases. Storage Querying MyRocks storage engine InnoDB enhancements InnoDB NUMA interleave Virtual Column indexes Fast connections Optimizer enhancements Query caching Streaming inserts Replication Routing Binary Log read throttling Binary Log compression Dynamic server configuration Read-write splitting + master pinning Multi-statement routing + master pinning Security and disaster recovery Finally, we wanted to increase security and disaster recovery. In particular, by expanding the capabilities of the database firewall by ensuring sensitive data was protected, prepared statements were examined and denial of service queries were prevented. For disaster recovery, we introduce point-in-time rollback a la Oracle Flashback. Security Disaster recovery Per user resource limits Enforced TLS connections Data masking Prepared Statement filtering Result Set limiting Dynamic firewall rule configuration Delayed replication Binary Log based rollback Resources Webinar: Introducing MariaDB TX 2.0! Blog: What's New in MariaDB Server 10.2 Blog: What's New in MariaDB MaxScale 2.1 Community MariaDB Releases MaxScale We believe an enterprise database solution requires technology, tools and services, and that it should be easy to buy, easy to deploy and easy to manage – providing a great customer and user experience from beginning to end. That's why we're introducing MariaDB TX. Login or Register to post comments [Less]
Posted about 10 hours ago by MariaDB
What's New in MariaDB Server 10.2 RalfGebhardt Tue, 05/23/2017 - 17:03 We are happy to announce the general availability (GA) of MariaDB Server 10.2! MariaDB Server 10.2 is the newest major version of MariaDB Server, the fastest ... [More] growing open source relational database. MariaDB Server 10.2 is the next evolution after MariaDB Server 10.1. In 10.1 the integration of Galera Cluster as a high availability solution, data-at-rest encryption and other security features like the password validation API have been the key enhancements of MariaDB Server. Now, with MariaDB Server 10.2.6 GA, new significant enhancements are available for our users and customers, including: SQL enhancements like window functions, common table expressions and JSON functions allow new use cases for MariaDB Server Standard MariaDB Server replication has further optimizations Many area limitations have been removed, which allows easier use and there is no need for limitation handling on the application level MyRocks, a new storage engine developed by Facebook, has been introduced, which will further enrich the use cases for MariaDB Server Window Functions Window functions are popular in Business Intelligence (BI) where more complex report generation is needed based on a subset of the data, like country or sales team metrics. Another common use case is where time-series based data should be aggregated based on a time window instead of just a current record, like all rows inside a certain time span. As analytics is becoming more and more important to end users, window functions deliver a new way of writing performance optimized analytical SQL queries, which are easy to read and maintain, and eliminates the need to write expensive subqueries and self-joins. Common Table Expressions Hierarchical and recursive queries are usually implemented using common table expressions (CTEs). They are similar to derived tables in a FROM clause, but by having an identification keyword WITH, the optimizer can produce more efficient query plans. Acting as an automatically created temporary and named result set, which is only valid for the time of the query, it can be used for recursive and hierarchical execution, and also allows for reuse of the temporary dataset. Having a dedicated method also helps to create more expressive and cleaner SQL code. JSON Functions JSON (JavaScript Object Notation), a text-based and platform independent data exchange format, is used not only to exchange data, but also as a format to store unstructured data. MariaDB Server 10.2 offers more than 24 JSON functions to allow querying, modification, validation and indexing of JSON formated data, which is stored in a text-based field of a database. As a result, the powerful relational model of MariaDB can be enriched by working with unstructured data, where required. Through the use of virtual columns, the JSON function, JSON_VALUE and the newest indexing feature of MariaDB Server 10.2 on virtual columns, JSON values will be automatically extracted from the JSON string, stored in a virtual column and indexed providing the fastest access to the JSON string. Using the JSON function JSON_VALID, the new CHECK CONSTRAINTS in MariaDB Server 10.2 guarantee that only JSON strings of the correct JSON format can be added into a field. Binary Log Based Rollback The enhanced mysqlbinlog utility delivered with MariaDB Server 10.2 includes a new point-in-time rollback function, which allows a database or table to revert to an earlier state, and delivers binary log based rollback of already committed data. The tool mysqlbinlog is not directly modifying any data, it is generating an “export file” including the reverted statements of the transactions, logged in a binary log file. The created file can be used with the command line client or other SQL tool to execute the included SQL statements. This way all committed transactions up to a given timestamp will be rolled back. In the case of addressing logical mistakes like adding, changing or deleting data, so far the only possible way has been to use mysqlbinlog to review transactions and fix the problems manually. However, this often leads to data inconsistency because corrections typically only address the wrong statement, thereby ignoring other data dependencies. Typically caused by DBA or user error, restoring a huge database can result in a significant outage of service. Rolling back the last transactions using point-in-time roll back takes only the time of the extract, a short review and the execution of the reverted transactions – saving valuable time, resources and service.   Start now and learn about the newest evolution of MariaDB Server 10.2:  Window functions Common table expressions JSON and GeoJSON functions Delayed replication and compressed binary log Enforced CHECK constraints DEFAULT now allows the use of expressions Multiple triggers per table Binary Log Based Roll Back InnoDB from MySQL 5.7, which is the default engine in MariaDB 10.2 Indexes for virtual columns Limitations on number of connections, queries and forcing of encryption per user. See CREATE USER and look for 10.2 features Community DBA Developer Galera GeoData High Availability InnoDB MariaDB Releases Replication Security Storage Engines We are happy to announce the general availability (GA) of MariaDB Server 10.2! MariaDB Server 10.2 is the newest major version of MariaDB Server, the fastest growing open source relational database. Login or Register to post comments [Less]
Posted about 10 hours ago by MariaDB
What's New in MariaDB MaxScale 2.1 Dipti Joshi Tue, 05/23/2017 - 19:44 We are happy to announce the 2.1 GA release of MariaDB MaxScale, the next-generation database proxy for MariaDB. MariaDB MaxScale 2.1 introduces the following key ... [More] new capabilities: Dynamic Configuration Server, monitor and listeners: MaxScale 2.1 supports dynamic configuration of servers, monitors and listeners, which can be added, modified or removed during runtime. A set of new commands were added to maxadmin. Database firewall filter: Rules can now be modified during runtime using the new module commands introduced in this release. Persistent configuration changes: The runtime configuration changes are immediately applied to the running MaxScale as well as persisted using the new hierarchical configuration architecture. Security Selective data masking: Meet your HIPAA and PCI compliance needs by obfuscating sensitive data using the new masking filter. Result set limiting: Prevent access to large sets of data with a single query by using maxrows filter - securing your database servers against malicious or accidental DoS attack. Secured single sign-on: MariaDB MaxScale now supports LDAP/GSSAPI authentication support. Prepared statement filtering by database firewall: The database firewall filter now applies the filtering rules to prepared statements as well. Function filtering by database firewall: Now the database firewall filter adds a rule to whitelist or blacklist a query based on presence of a function. Secure binlog server: The binlog cache files on MaxScale can now be encrypted. MaxScale binlog server also uses SSL in communication with master and slave. Query Performance Query cache filter: MariaDB MaxScale 2.1 now allows caching of query results in MaxScale for a configurable timeout. If a query is in cache, MaxScale will return results from cache before going to server to fetch query results. Our internal testing has shown 2.8x performance improvement from 2.0 to 2.1.3 using cache filter. Streaming insert plugin: A new plugin in MariaDB MaxScale 2.1 converts all INSERT statements done inside an explicit transaction into LOAD DATA LOCAL INFILE. Scalability Aurora Cluster support: MariaDB MaxScale can now be used as a proxy for Amazon Aurora Cluster. Newly added monitor detects read replicas and write node in Aurora Cluster, and supports launchable scripts on monitored events like other monitors. Multi-master for MySQL monitor: Now MariaDB MaxScale can detect complex multi-master replication topologies for MariaDB and MySQL environment. Failover mode for MySQL monitor: For a two-node master-slave cluster, MariaDB MaxScale now allows slave to act as a master in case the original master fails. Read-write splitting with master pinning: MariaDB MaxScale 2.1 introduces a new “Consistent Critical Read Filter.” This filter detects a statement that would modify the database and route all subsequent statements to the master server where data is guaranteed to be in an up-to-date state. Thanks to community members and especially OutboundEngine who beta tested MariaDB MaxScale 2.1.0 to MariaDB MaxScale 2.1.2 in order for us to reach GA with MariaDB MaxScale 2.1.3. Links: Release notes List of bugs fixed Binaries MaxScale 2.1.3 documentation in our Knowledge Base Source code in GitHub, tagged with maxscale-2.1.3 Please post your questions in our Knowledge Base or email me at dipti.joshi@mariadb.com. MaxScale We are happy to announce the 2.1 GA release of MariaDB MaxScale, the next-generation database proxy for MariaDB. Login or Register to post comments [Less]
Posted about 11 hours ago by Guilhem Bichot
CTEs and Recursive CTEs appeared in MySQL 8.0; first in a Labs release and now in the official release 8.0.1. Several blogs have been published: here, here and here ; my colleague Øystein also wrote how using a CTE made one DBT3 query run twice faster.…
Posted about 12 hours ago by The Pythian Group
This Log Buffer Edition covers Oracle, SQL Server, MySQL. Oracle: A Sneak Peek at Oracle’s Chatbot Cloud Service and 5 Key Factors Necessary for Bot ROI Oracle JET Hybrid – NavDrawer Template Menu/Header Structure Oracle Enterprise Linux 6.6 AMI ... [More] Available on AWS Datascape Podcast Episode 9 – What’s Up with Oracle These Days? Sequential Asynchronous calls in Node.JS – using callbacks, async and ES6 Promises SQL Server: Fixing an SSRS Password Error while Changing Credentials Azure DWH Part 8: Accessing Azure SQL Data Warehouse with C# Personal Data, Privacy, and the GDPR Performance Myths : Truncate Can’t Be Rolled Back Troubleshooting CPU Performance on VMware MySQL: MySQL Shell: eye candy for a future release ! MySQL 8.0: It’s doxygen time for MTR How to login in MariaDB with OS user without password MySQL Enterprise backup : How to setup a slave for a standalone server with zero downtime? Command Line Aficionados: Introducing s9s for ClusterControl [Less]
Posted about 13 hours ago by Daniel Bartholomew
The MariaDB project is pleased to announce the immediate availability of MariaDB 10.2.6 Stable (GA). This is the first stable (GA) release in the MariaDB 10.2 series. See the What is MariaDB 10.2? page for more details on the new features in MariaDB ... [More] 10.2. Download MariaDB 10.2.6 Release Notes Changelog What is MariaDB 10.2? MariaDB […] The post MariaDB 10.2.6 Stable now available appeared first on MariaDB.org. [Less]
Posted about 22 hours ago by Andrew Grimo
Recently MySQL launched the General Availability of their Group Replication enhancements via the MySQL Shell and MySQL Router. Although these URLs just noted go to their respective documentation pages, these collectively are part of the InnoDB ... [More] Cluster offering. The MySQL shell provides sophisticated provisioning, monitored insight and management of a Group Replication setup. When provisioned as such, you… Read More » [Less]
Posted 1 day ago by MySQL Performance Blog
In this blog, we’ll look at ICP counters in the information_schema.INNODB_METRICS. This is part two of the Index Condition Pushdown (ICP) counters blog post series.  As mentioned in the previous post, in this blog we will look at how to check on ICP ... [More] counters on MySQL and Percona Server for MySQL. This also applies to MariaDB, since the INNODB_METRICS table is also available for MariaDB (as opposed to the Handler_icp_% counters being MariaDB-specific). We will use the same table and data set as in the previous post. For simplicity we’ll show the examples on MySQL 5.7.18, but they also apply to the latest Percona Server for MySQL (5.7.18) and MariaDB Server (10.2.5): mysql [localhost] {msandbox} (test) > SELECT @@version, @@version_comment; +-----------+------------------------------+ | @@version | @@version_comment            | +-----------+------------------------------+ | 5.7.18    | MySQL Community Server (GPL) | +-----------+------------------------------+ 1 row in set (0.00 sec) mysql [localhost] {msandbox} (test) > SHOW CREATE TABLE t1G *************************** 1. row ***************************       Table: t1 Create Table: CREATE TABLE `t1` (  `f1` int(11) DEFAULT NULL,  `f2` int(11) DEFAULT NULL,  `f3` int(11) DEFAULT NULL,  KEY `idx_f1_f2` (`f1`,`f2`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 1 row in set (0.00 sec) mysql [localhost] {msandbox} (test) > SELECT COUNT(*) FROM t1; +----------+ | COUNT(*) | +----------+ |  3999996 | +----------+ 1 row in set (3.98 sec) mysql [localhost] {msandbox} (test) > SELECT * FROM t1 LIMIT 12; +------+------+------+ | f1   | f2   | f3   | +------+------+------+ |    1 |    1 |    1 | |    1 |    2 |    1 | |    1 |    3 |    1 | |    1 |    4 |    1 | |    2 |    1 |    1 | |    2 |    2 |    1 | |    2 |    3 |    1 | |    2 |    4 |    1 | |    3 |    1 |    1 | |    3 |    2 |    1 | |    3 |    3 |    1 | |    3 |    4 |    1 | +------+------+------+ 12 rows in set (0.00 sec) Before proceeding with the examples, let’s see what counters we have available and how to enable and query them. The documentation page is at the following link: https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-metrics-table.html. The first thing to notice is that we are advised to check the validity of the counters for each version where we want to use them. The counters represented in the INNODB_METRICS table are subject to change, so for the most up-to-date list it’s best to query the running MySQL server: mysql [localhost] {msandbox} (test) > SELECT NAME, SUBSYSTEM, STATUS FROM information_schema.INNODB_METRICS WHERE NAME LIKE '%icp%'; +------------------+-----------+----------+ | NAME             | SUBSYSTEM | STATUS   | +------------------+-----------+----------+ | icp_attempts     | icp       | disabled | | icp_no_match     | icp       | disabled | | icp_out_of_range | icp       | disabled | | icp_match        | icp       | disabled | +------------------+-----------+----------+ 4 rows in set (0.00 sec) Looking good! We have all the counters we expected, which are: icp_attempts: the number of rows where ICP was evaluated icp_no_match: the number of rows that did not completely match the pushed WHERE conditions icp_out_of_range: the number of rows that were checked that were not in a valid scanning range icp_match: the number of rows that completely matched the pushed WHERE conditions This link to the code can be used for reference: https://github.com/mysql/mysql-server/blob/5.7/include/my_icp.h. After checking which counters we have at our disposal, you need to enable them (they are not enabled by default). For this, we can use the “modules” provided by MySQL to group similar counters for ease of use. This is also explained in detail in the documentation link above, under the “Counter Modules” section. INNODB_METRICS counters are quite inexpensive to maintain, as you can see in this post by Peter Z. mysql [localhost] {msandbox} (test) > SET GLOBAL innodb_monitor_enable = module_icp; Query OK, 0 rows affected (0.00 sec) mysql [localhost] {msandbox} (test) > SELECT NAME, SUBSYSTEM, STATUS FROM information_schema.INNODB_METRICS WHERE NAME LIKE '%icp%'; +------------------+-----------+---------+ | NAME             | SUBSYSTEM | STATUS  | +------------------+-----------+---------+ | icp_attempts     | icp       | enabled | | icp_no_match     | icp       | enabled | | icp_out_of_range | icp       | enabled | | icp_match        | icp       | enabled | +------------------+-----------+---------+ 4 rows in set (0.00 sec) Perfect, we now know what counters we need, and how to enable them. We just need to know how to query them, and we can move on to the examples. However, before rushing into saying that a simple SELECT against the INNODB_METRICS table will do, let’s step back a bit and see what columns we have available that can be of use: mysql [localhost] {msandbox} (test) > DESCRIBE information_schema.INNODB_METRICS; +-----------------+--------------+------+-----+---------+-------+ | Field           | Type         | Null | Key | Default | Extra | +-----------------+--------------+------+-----+---------+-------+ | NAME            | varchar(193) | NO   |     |         |       | | SUBSYSTEM       | varchar(193) | NO   |     |         |       | | COUNT           | bigint(21)   | NO   |     | 0       |       | | MAX_COUNT       | bigint(21)   | YES  |     | NULL    |       | | MIN_COUNT       | bigint(21)   | YES  |     | NULL    |       | | AVG_COUNT       | double       | YES  |     | NULL    |       | | COUNT_RESET     | bigint(21)   | NO   |     | 0       |       | | MAX_COUNT_RESET | bigint(21)   | YES  |     | NULL    |       | | MIN_COUNT_RESET | bigint(21)   | YES  |     | NULL    |       | | AVG_COUNT_RESET | double       | YES  |     | NULL    |       | | TIME_ENABLED    | datetime     | YES  |     | NULL    |       | | TIME_DISABLED   | datetime     | YES  |     | NULL    |       | | TIME_ELAPSED    | bigint(21)   | YES  |     | NULL    |       | | TIME_RESET      | datetime     | YES  |     | NULL    |       | | STATUS          | varchar(193) | NO   |     |         |       | | TYPE            | varchar(193) | NO   |     |         |       | | COMMENT         | varchar(193) | NO   |     |         |       | +-----------------+--------------+------+-----+---------+-------+ 17 rows in set (0.00 sec) There are two types: %COUNT and %COUNT_RESET. The former counts since the corresponding counters were enabled, and the latter since they were last reset (we have the TIME_% columns to check when any of these were done). This is why in our examples we are going to check the %COUNT_RESET counters, so we can reset them before running each query (as we did with FLUSH STATUS in the previous post). Without further ado, let’s check how this all works together: mysql [localhost] {msandbox} (test) > SET GLOBAL innodb_monitor_reset = module_icp; Query OK, 0 rows affected (0.00 sec) mysql [localhost] {msandbox} (test) > SELECT * FROM t1 WHERE f1 < 3 AND (f2 % 4) = 1; +------+------+------+ | f1   | f2   | f3   | +------+------+------+ |    1 |    1 |    1 | |    2 |    1 |    1 | +------+------+------+ 2 rows in set (0.00 sec) mysql [localhost] {msandbox} (test) > SELECT NAME, COUNT_RESET FROM information_schema.INNODB_METRICS WHERE NAME LIKE 'icp%'; +------------------+-------------+ | NAME             | COUNT_RESET | +------------------+-------------+ | icp_attempts     |           9 | | icp_no_match     |           6 | | icp_out_of_range |           1 | icp_match        |           2 | +------------------+-------------+ 4 rows in set (0.00 sec) mysql [localhost] {msandbox} (test) > EXPLAIN SELECT * FROM t1 WHERE f1 < 3 AND (f2 % 4) = 1; +----+-------------+-------+------------+-------+---------------+-----------+---------+------+------+----------+-----------------------+ | id | select_type | table | partitions | type  | possible_keys | key       | key_len | ref  | rows | filtered | Extra                 | +----+-------------+-------+------------+-------+---------------+-----------+---------+------+------+----------+-----------------------+ |  1 | SIMPLE      | t1    | NULL       | range | idx_f1_f2     | idx_f1_f2 | 5       | NULL |    8 |   100.00 | Using index condition | +----+-------------+-------+------------+-------+---------------+-----------+---------+------+------+----------+-----------------------+ 1 row in set, 1 warning (0.00 sec) If you checked the GitHub link above, you might have noted that the header file only contains three of the counters. This is because icp_attempts is computed as the sum of the rest. As expected, icp_match equals the number of returned rows, which makes sense. icp_no_match should also make sense if we check the amount of rows present without the WHERE conditions on f2. mysql [localhost] {msandbox} (test) > SELECT * FROM t1 WHERE f1 < 3; +------+------+------+ | f1   | f2   | f3   | +------+------+------+ |    1 |    1 |    1 | |    1 |    2 |    1 | |    1 |    3 |    1 | |    1 |    4 |    1 | |    2 |    1 |    1 | |    2 |    2 |    1 | |    2 |    3 |    1 | |    2 |    4 |    1 | +------+------+------+ 8 rows in set (0.00 sec) So, 8 – 2 = 6, which is exactly icp_no_match‘s value. Finally, we are left with icp_out_of_range. For each end of range the ICP scan detects, this counter is incremented by one. We only scanned one range in the previous query, so let’s try something more interesting (scanning three ranges): mysql [localhost] {msandbox} (test) > SET GLOBAL innodb_monitor_reset = module_icp; Query OK, 0 rows affected (0.00 sec) mysql [localhost] {msandbox} (test) > SELECT * FROM t1 WHERE ((f1 < 2) OR (f1 > 4 AND f1 < 6) OR (f1 > 8 AND f1 < 12)) AND (f2 % 4) = 1; +------+------+------+ | f1   | f2   | f3   | +------+------+------+ |    1 |    1 |    1 | |    5 |    1 |    1 | |    9 |    1 |    1 | |   10 |    1 |    1 | |   11 |    1 |    1 | +------+------+------+ 5 rows in set (0.00 sec) mysql [localhost] {msandbox} (test) > SELECT NAME, COUNT_RESET FROM information_schema.INNODB_METRICS WHERE NAME LIKE 'icp%'; +------------------+-------------+ | NAME             | COUNT_RESET | +------------------+-------------+ | icp_attempts     |          23 | | icp_no_match     |          15 | | icp_out_of_range |           3 | | icp_match        |           5 | +------------------+-------------+ 4 rows in set (0.01 sec) We have now scanned three ranges on f1, namely: (f1 < 2), (4 < f1 < 6) and (8 < f1 < 12). This is correctly reflected in the corresponding counter. Remember that the MariaDB Handler_icp_attempts status counter we looked at in the previous post does not take into account the out-of-range counts. This means the two “attempts” counters will not be the same! mysql [localhost] {msandbox} (test) > SET GLOBAL innodb_monitor_reset = module_icp; SET GLOBAL innodb_monitor_reset = dml_reads; FLUSH STATUS; ... mysql [localhost] {msandbox} (test) > SELECT * FROM t1 WHERE ((f1 < 2) OR (f1 > 4 AND f1 < 6) OR (f1 > 8 AND f1 < 12)) AND (f2 % 4) = 1; ... 5 rows in set (0.00 sec) mysql [localhost] {msandbox} (test) > SELECT NAME, COUNT_RESET FROM information_schema.INNODB_METRICS WHERE NAME LIKE 'icp_attempts'; +--------------+-------------+ | NAME         | COUNT_RESET | +--------------+-------------+ | icp_attempts |          23 | +--------------+-------------+ 1 row in set (0.00 sec) mysql [localhost] {msandbox} (test) > SHOW STATUS LIKE 'Handler_icp_attempts'; +----------------------+-------+ | Variable_name        | Value | +----------------------+-------+ | Handler_icp_attempts | 20    | +----------------------+-------+ 1 row in set (0.00 sec) It can be a bit confusing to have two counters that supposedly measure the same counts yielding different values, so watch this if you use MariaDB. ICP Counters in PMM Today you can find an ICP counters graph for MariaDB (Handler_icp_attempts) in PMM 1.1.3. Additionally, in release 1.1.4 you’ll find graphs for ICP metrics from information_schema.INNODB_METRICS: just look for the INNODB_METRICS-based graph on the InnoDB Metrics dashboard! I hope you found this blog post series useful! Let me know if you have any questions or comments below. [Less]
Posted 1 day ago by HowToForge
In this tutorial, I will show you step by step to configure MySQL securely for remote connections with SSL. MySQL is an open source relational database system that works on many Operating Systems including Windows, Linux, MacOS and FreeBSD. It is probably the most popular OpenSource RDBMS and a central component of the LAMP and LEMP Stacks.
Posted 2 days ago by Jean-François Gagné
Kristian Nielsen is working on a new feature for MariaDB 10.3 and he published very interesting results.  This feature is MDEV-12179: Per-engine mysql.gtid_slave_pos tables.  He writes about replicating twice as fast in the worst case when using two ... [More] storage engines (InnoDB and MariaRocks in his tests, but could also be InnoDB and TokuDB or TokuDB and MyRocks).  I will let you read all the details [Less]