Quantcast
Channel: Planet MySQL
Viewing all 18783 articles
Browse latest View live

Optimizing VividCortex’s Samples View: Part 2

$
0
0

A few weeks ago, I wrote a blog post explaining how sketch sampling methods can be employed to achieve fast 30-day data visibility for monitoring users. The problem we faced was that with that standard of retention, we’ve frequently seen systems that involve nearly a million query samples in a 30-day window, meaning that special solutions are needed in order to avoid overloading users’ browsers.

The solution we’ve found lies in a hash ordering that's proven to be both surprisingly simple and efficient. In this Part 2 post, I’ll look at why it works so well.

Ordering with a Hash

VividCortex’s query samples are stored in MySQL tables. The simplified schema definition looks like this:

query  bigint PRIMARY
host   int    PRIMARY
ts     int    PRIMARY
sample blob

Our primary key for those tables is (query, host, ts), as you may have guessed with the PRIMARY keyword. When we load the query details page for a user, we know the query, host, and time range, so our queries use the primary key.

As mentioned above, in Part 1 of this blog post we wrote that the following condition solved our subsampling problem:

ORDER BY MD5(CONCAT(qs.ts, qs.host)) LIMIT <our limit>

One optimization that we’ve made so far is replacing the MD5 operation with a CRC32. It’s less expensive and produces the same end result. So, how does this work?

MD5 and CRC32 functions are hash functions that we can use for a randomly distributed ordering. They also deterministic; given the same inputs, we’ll get the same output, and therefore the same ordering.

Let’s dig into the details and see an example.

First, think about how samples are stored as rows for the following view:

Samples_in_rows_1.png

Here it is as a diagram:

Diagram_Samples.png

I’ve split up the time range into two chunks so we can think about how things look when we “zoom in.” Imagine there are two ranges to represent different zoom levels. The first includes both chunks. The second includes only the first chunk. In each chunk, I’ve listed four rows which represent samples, so there are eight samples total. Each sample also has a hash.

Let’s pick some samples! In each example, I’m limiting the count to three samples.

Picking 3 samples from timestamps 1 to 4 gives us the following samples:

  • (host 1, ts 4)
  • (host 1, ts 1)
  • (host 2, ts 4)

I’ve also bolded them in the diagram below.

Diagram_Samples_2.png

Now, “zooming in” to timestamps 1 to 2 and picking 3 samples will give us:

  • (host 1, ts 1)
  • (host 1, ts 2)
  • (host 2, ts 2)

Diagram_Samples_3.png

Notice how we’re still choosing the same samples in the first range that we saw before:

  • (host 1, ts 1)
  • (host 1, ts 2)

And we’re including a new sample within our smaller time range to add more “detail”:

  • (host 2, ts 2)

We still haven’t seen (host 2, ts 1) yet. How would we see that? It’s easy: zoom in even more so that we only see timestamp 1, and we’ll be able to capture that as well.

I hope this helps elucidate one method for using samples to manage massive data sets and query volumes. The best way to understand such a solution, though, is to see it actually put to use in a monitoring environment. In order to do so, you can request a free trial of VividCortex and experience what high-volume, highly-granular database monitoring is like, firsthand.


New UUID functions in MySQL 8.0.0

$
0
0

MySQL 8.0.0 introduces three new miscellaneous UUID functions of IS_UUID(), UUID_TO_BIN() and BIN_TO_UUID() joining the UUID() (in 5.0) and UUID_SHORT() (in 5.1) functions. See 8.0.0 Release Notes.

Thanks to the great work and hosting by Marcus Popp anybody can test out the SQL syntax of MySQL 8.0.0 using db4free without installing anything. If you want a minimal install Giuseppe Maxia provides docker minimal images of 5.0+ versions including 8.0.0.

A running docker container with MySQL 8.0 is as easy as:

The following script shows the usage and checks of these new functions.

Historically, to encode a UUID into a BINARY(16) datatype was to use UNHEX(REPLACE()) syntax. There was however no easy to unencode a BINARY(16) into the original value. BIN_TO_UUID() as shown in the output below solves this problem.

mysql> SELECT IS_UUID(1);
+------------+
| IS_UUID(1) |
+------------+
|          0 |
+------------+
1 row in set (0.01 sec)

mysql> SET @uuid='aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee';
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT IS_UUID(@uuid) AS is_uuid;
+---------+
| is_uuid |
+---------+
|       1 |
+---------+
1 row in set (0.01 sec)

mysql> SELECT IS_UUID(REPLACE(@uuid,'-','')) AS is_uuid;
+---------+
| is_uuid |
+---------+
|       1 |
+---------+
1 row in set (0.00 sec)

mysql> SELECT @uuid_bin := UUID_TO_BIN(@uuid) AS uuid_bin, LENGTH(@uuid_bin) AS len;
+------------------+------+
| uuid_bin         | len  |
+------------------+------+
| ���������������� |   16 |
+------------------+------+
1 row in set (0.00 sec)

mysql> SELECT @old_uuid_bin := UNHEX(REPLACE(@uuid,'-','')) AS old_uuid_bin, LENGTH(@old_uuid_bin) AS len;
+------------------+------+
| old_uuid_bin     | len  |
+------------------+------+
| ���������������� |   16 |
+------------------+------+
1 row in set (0.00 sec)

mysql> SELECT @uuid_bin = @old_uuid_bin;
+---------------------------+
| @uuid_bin = @old_uuid_bin |
+---------------------------+
|                         1 |
+---------------------------+
1 row in set (0.00 sec)

mysql> SELECT BIN_TO_UUID(@uuid_bin) AS uuid, HEX(@old_uuid_bin) AS uuid_old;
+--------------------------------------+----------------------------------+
| uuid                                 | uuid_old                         |
+--------------------------------------+----------------------------------+
| aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee | AAAAAAAABBBBCCCCDDDDEEEEEEEEEEEE |
+--------------------------------------+----------------------------------+
1 row in set (0.01 sec)

Watch the replay: MySQL Query Tuning Part 2 - Indexing and EXPLAIN

$
0
0

We’ve just completed Part 2 of our webinar trilogy on MySQL Query Tuning this week and if you didn’t get the chance to join us for the live sessions (or would like to watch them again), the recording is now available to view online as a replay.

As announced in our communications, these webinars are almost 1.5hrs long, as the content is quite dense (and we got some great questions from participants as well), so be sure to make sufficient time available to watch the replay ;-)

Watch the replay

About 40% of our audience indicated that they currently either use MySQL / Percona Server 5.5 (or earlier), MySQL / Percona Server 5.6 or MariaDB 10.1, so it was an interesting mix. We also found that the majority of participants don’t have a process to check for unused indexes, which was a good opportunity to explain why this might be a good thing to implement. And finally, 68% of the audience confirmed that they use EXPLAIN Analyzer to analyse query execution plans. You can view the detail of the polls further below.

Our colleague Krzysztof Książek, Senior Support Engineer at Severalnines, presents this webinar trilogy and this week he looked into answering questions such as why a given query might be slow, what the execution plan might look like, how JOINs might be processed, whether a given query is using the correct indexes, or whether it’s creating a temporary table.

In order to answer these questions, Krzysztof discussed how to use database indexes to speed up queries and, more specifically, he covered the different index types such as B-Tree, Fulltext and Hash, deepdive into B-Tree indexes, and discussed the indexes for MyISAM vs. InnoDB tables as well as some gotchas.

Watch the replay

And if you’re ready for Part 3 of the MySQL Query Tuning Trilogy, please do sign up for the webinar on October 25th, which will cover ‘working with optimizer and SQL tuning’.

Feedback detail of this week’s webinar:

MySQL 8.0: Testing Improvements

$
0
0

The first DMR of MySQL 8 was recently released. While a DMR (or Developer Milestone Release) is not yet a GA product, it does come with our commitment that each feature has been tested and qualified for inclusion.

In MySQL 8.0 we have made additional improvements to the MySQL test framework (MTR) and the test suite.…

Percona XtraDB Cluster 5.7.14-26.17 GA is now available

$
0
0
Percona XtraDB Cluster Reference Architecture

Percona XtraDB Cluster 5.7.14-26.17 GAThis Percona XtraDB Cluster 5.7.14-26.17 GA release is dedicated to the memory of Federico Goncalvez, our colleague with Percona’s Uruguayan team until his tragic death on September 6, 2016.

Fede, we miss you.

Percona announces the first general availability (GA) release in the Percona XtraDB Cluster 5.7 series on September 29, 2016. Binaries are available from the downloads area or our software repositories.

The full release notes are available here.

Percona XtraDB Cluster 5.7.14-26.17 GA is based on the following:

For information about the changes and new features introduced in Percona Server 5.7, see Changed in Percona Server 5.7.

Percona XtraDB Cluster 5.7.14-26.17 GA New Features

This is a list of the most important features introduced in Percona XtraDB Cluster 5.7 compared to version 5.6:

  • PXC Strict Mode saves your workload from experimental and unsupported features.
  • Support for monitoring Galera Library instruments and other wsrep instruments as part of Performance Schema.
  • Support for encrypted tablespaces in Multi-Master Topology, which enables Percona XtraDB Cluster to wire encrypted tablespace to new booting node.
  • Compatibility with ProxySQL, including a quick configuration script.
  • Support for monitoring Percona XtraDB Cluster nodes using Percona Monitoring and Management
  • More stable and robust operation with MySQL and Percona Server version 5.7.14, as well as Galera 3.17 compatibility. Includes all upstream bug fixes, improved logging and more.
  • Simplified packaging for Percona XtraDB Cluster to a single package that installs everything it needs, including the Galera library.
  • Support for latest Percona XtraBackup with enhanced security checks.
Bug Fixes
  • Fixed crash when a local transaction (such as EXPLAIN or SHOW) is interrupted by a replicated transaction with higher priority (like ALTER that changes table structure and can thus affect the result of the local transaction).
  • Fixed DONOR node getting stuck in Joined state after successful SST.
  • Fixed error message when altering non-existent table with pxc-strict-mode enabled.
  • Fixed path to the directory in percona-xtradb-cluster-shared.conf.
  • Fixed setting of seqno in grastate.dat to -1 on clean shutdown.
  • Fixed failure of asynchronous TOI actions (like DROP) for non-primary nodes.
  • Fixed replacing of my.cnf during upgrade from 5.6 to 5.7.
Security Fixes
  • CVE-2016-6662
  • CVE-2016-6663
  • CVE-2016-6664

For more information, see this blog post.

Other Improvements
  • Added support of defaults-group-suffix for SST scripts.

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!

Log Buffer #489: A Carnival of the Vanities for DBAs

$
0
0

This Log Buffer Edition collects blog posts fromOracle, SQL Server and MySQL.

Oracle:

Over the past 12 months there has been an increase in the number of Machine Learning notebooks becoming available.

Gitora helps PL/SQL developers manage their source code in Git easily. It helps them lock database objects to prevent edits from other users regardless of the editor they use.

One of the little myths of Oracle appeared on the Oracle-L list server a few days ago – the one that says: “you don’t need a histogram on a single column unique/primary key”.

How to Calculate the Mean, Median, and Mode in Oracle

Oracle Enterprise Manager Cloud Control: Write Powerful Scripts with EMCLI

SQL Server:

PowerShell Solutions – Several tips for daily tasks

Bones of SQL – Grouping By User-Defined Calendar Periods

On Being Economical with the Truth

How to Start Big Data with Apache Spark

Memory/Storage Technology Hierarchy and SQL Server

MySQL:

MySQL removes the FRM (7 years after Drizzle did)

SHOW WARNINGS can stall your MySQL server if compressed protocol is used

MySQL 8.0: Making User Management DDLs Atomic

Database Security – MySQL Upgrade Instructions for Zero-day Exploit

Showing the hidden tables in MySQL 8 data dictionary

Planets9s - 9 DevOps Tips for MySQL / MariaDB Galera Cluster, MySQL Query Tuning Part 2 and more!

$
0
0

Welcome to this week’s Planets9s, covering all the latest resources and technologies we create around automation and management of open source database infrastructures.

New webinar: 9 DevOps Tips for going in production with MySQL / MariaDB Galera Cluster

In this new webinar on October 11th, Johan Andersson, CTO at Severalnines, will guide you through 9 key DevOps tips to consider before taking Galera Cluster for MySQL / MariaDB into production. Monitoring, managing schema changes and pushing them in production, performance optimizations, configurations, version upgrades, backups; these are all aspects to consider before going live with Galera Cluster and Johan will share his 9 DevOps tips with you for a successful production environment.

Sign up for the webinar

Watch the replay: MySQL Query Tuning Part 2 - Indexing and EXPLAIN

You can now watch the replay of Part 2 of our webinar trilogy on MySQL Query Tuning, which covers Indexing as well as EXPLAIN, one of the most important tools in the DBA’s arsenal. Our colleague Krzysztof Książek, Senior Support Engineer at Severalnines, presents this webinar trilogy and this week he looked into answering questions such as why a given query might be slow, what the execution plan might look like, how JOINs might be processed, whether a given query is using the correct indexes, or whether it’s creating a temporary table. Find out more by watching the replay of this webinar.

Watch the replay

Download our whitepaper on Database Sharding with MySQL Fabric

This new whitepaper provides a close look at database sharding with MySQL Fabric. You will learn the basics of it, and also learn how to migrate to a sharded environment. It further discusses three different tools which are designed to help users shard their MySQL databases. And last but not least, it shows you how to set up a sharded MySQL setup based on MySQL Fabric and ProxySQL.

Download the whitepaper

Critical zero-day vulnerabilities exposed in MySQL

Database security notice: you can easily upgrade your MySQL and MariaDB servers with ClusterControl and this new blog post shows you how. You must have heard about the CVE-2016-6662, the recent zero-day exploit exposed in most of MySQL and its variants. The vulnerability flaw can be exploited by a remote attacker to inject malicious settings into your my.cnf,. We advise you to upgrade as soon as possible, if you haven’t done so yet, with these easy-to-follow instructions for ClusterControl users.

Read the blog

That’s it for this week! Feel free to share these resources with your colleagues and follow us in our social media channels.

Have a good end of the week,

Jean-Jérôme Schmidt
Planets9s Editor
Severalnines AB

Codership is hiring Software Packaging Engineer!

$
0
0

Software Packaging Engineer

Job Description & Main Responsibilities

 

Codership is looking for a part-time Build and Packaging Engineer. We use Jenkins to build various packages for multiple distros and the engineer will take ownership of the build pipeline and extend it to cover additional platforms and testing scenarios.

There are plenty of interesting problems to tackle on the job, from crafting .spec files with complex dependencies to automatically testing no-downtime rolling upgrades of a distributed system.

Main Responsibilities

  •  take the ownership of and maintain Galera Cluster packages on Linux (.RPM and .DEB) and BSD
  • maintain the automatic package building pipeline and extend it to cover additional platforms and testing scenarios

 

Desired Skills & Requirements

 

  • knowledge of package-management systems, spec files, build tools, dependencies and package scripting
  • understanding of related technologies such as firewalls, systemd and SELinux
  • exposure to automatic testing using continuous integration tools, virtual machines and containers
  • 2-4 years software packaging experience
  • good English command is required

The company is 100% remote. We use Jenkins, Bash, Python, Docker, Qemu and the Open Build Service in our build system.

Apply today and send your application and CV to jobs@galeracluster.com


Order from Chaos: Member Coordination in Group Replication

$
0
0

We are very excited about the next release of MySQL Group Replication 0.9.0 in MySQL 5.7.15 and the great work that has been done to improve its stability. Release after release, MySQL Group Replication becomes more stable and more user-friendly and has reached a maturity level that made us declare 0.9.0 a release candidate.…

The First Development Milestone for MySQL 8.0

$
0
0

MySQL 8.0.0 exists.

For general impressions we already have comments by Giuseppe Maxia and Stewart Smith and Serdar Yegulalp.

Two new features looked important to me: modern UCA collations, and roles. So I downloaded and tried them out.

Modern UCA collations

MySQL is going to switch to utf8mb4 for the default character set and add collations based on the the latest version of the Unicode Collation Algorithm (UCA 9.0.0). I still see messages indicating the default is still latin1, but they're incorrect, I can put 4-byte UTF-8 characters in columns that I created without explicitly saying utf8mb4.

The new collations are only for utf8mb4. That's suboptimal. People still have good reasons to use other character sets (I discussed some of them in an earlier blog post). And in any case, a collation that works for utf8mb4's repertoire will work for every character set that has a pure subset of that repertoire, which is to say, every character set.

The new collations are only for the generic "Default Unicode Collation Element Table" (DUCET), and for Latin-based alphabets. So there are no updates for "persian" or "sinhala".

For an example, the following table shows changes between the old Swedish collation (utf8mb4_swedish_ci) and the new one (utf8mb4_sv_0900_ai_ci). The "Rule" column has what Unicode says about certain Swedish primary (level-1) comparisons, the "Example" column has what an SQL comparison would look like, the "Old" column has the results I got with utf8mb4_swedish_ci, the "New" column has the results I got with utf8mb4_sv_0900_ai_ci.


Rule Example Old New
---------------------------- --------- ----- ----
ETH = D 'Ð' = 'D' FALSE TRUE
D STROKE = D 'Đ' = 'D' FALSE TRUE
THORN = TH 'Þ' = 'TH' FALSE TRUE
O DOUBLE ACUTE = O DIAERESIS 'Ő' = 'Ö' FALSE TRUE
U DOUBLE ACUTE = Y 'Ű' = 'Y' FALSE TRUE
L STROKE = L 'Ł' = 'L' FALSE TRUE
A DIAERESIS = E OGONEK 'Ä' = 'Ę' FALSE TRUE
OE = O DIAERESIS 'Œ' = 'Ö' FALSE TRUE
O CIRCUMFLEX = O DIAERESIS 'Ô' = 'Ö' FALSE TRUE

Most Swedes don't know about these rules, they apply to medieval texts or foreign names. But most Swedes do know that rules should cover the edge cases, not just the Stockholm phone book. Because it follows the Unicode rules, the new collation is better.

But the new collation's name is worse, for two reasons.

(1) The "_ai" suffix, meaning "accent insensitive", is Microsoftish. There is such a thing, but the definition of "accent" varies between languages and the factors that influence collations can be other things besides accents. Clearer suffixes for extra-sensitive collation names would be "w2" or "l2" (for weight=2 or level=2), and they're for sorting rather than searching unless you're Japanese, but a default = no-suffix-for-accents would have been okay.

(2) The "_sv" suffix, meaning "Swedish", is an unnecessary change. Compatibility with the previous suffix -- "swedish" -- would not have violated UCA specifications and would have been clearer for people who have used MySQL before.

For a second example, I looked at the new "Latin" collation, utf8mb4_la_0900_ai_ci. This time I couldn't find any rules file in the Unicode standard directory. There is a UCA chart for Latin but utf8mb4_la_0900_ai_ci obviously isn't following it at all. Instead it's like MySQL's old and silly "Roman" collation, where i=j and u=v. This is not an important collation. But MySQL claims the new collations follow UCA rules, and here is one that doesn't, so I worry about the others.

This has to be taken in context -- MySQL has far better support for character sets and collations than any other open-source DBMS, except sometimes MariaDB. And now it's a weenie bit more far better. Observations about paucity of new UCA collations, bad names, or standard non-compliance won't change that fact.

Roles

I discussed MariaDB's roles in 2014. MySQL's roles are already in the 8.0 documentation. Is MySQL making an improvement?

The first thing I noticed is that the syntax rules for roles are, too often, the same as the syntax rules for users. This is especially obvious when I ask for things that make no sense for roles, for example:

mysql>CREATE ROLE 'r'@'host';
OK 0 rows affected (0.1 seconds)

mysql>CREATE ROLE '';
Error 1396 (HY000) Operation CREATE USER failed for anonymous user

mysql>GRANT 'root'@'localhost' TO role_name;
OK 0 rows affected (0.1 seconds)

mysql>DROP USER role_name;
OK 0 rows affected (0.1 seconds)

Because of this, some non-standard limitations exist: maximum name length is 32, names are case sensitive, role names cannot be the same as user names, and there is no separate information_schema table

However, the DML statements that I tested for MariaDB do work with MySQL as well, and are often exactly the same:

MariaDB: CREATE [OR REPLACE] ROLE [IF NOT EXISTS] role_name [WITH ADMIN ...];
MySQL:   CREATE ROLE [IF NOT EXISTS] role_name [,role_name...];

MariaDB: DROP ROLE [IF EXISTS] role_name [,role_name...];
MySQL:   DROP ROLE [IF EXISTS] role_name [,role_name...];

MariaDB: SET DEFAULT ROLE {role_name|NONE} [FOR user_name];
MySQL:   SET DEFAULT ROLE ALL TO user_name [,user_name...];

MariaDB: SET ROLE {role_name|NONE};
MySQL:   SET ROLE {role_name|NONE};

MariaDB: SELECT CURRENT_ROLE() | CURRENT_ROLE;
MySQL:   SELECT CURRENT_ROLE();

MariaDB: [no exact equivalent]
MySQL:   GRANT CREATE ROLE ON *.* TO grantee;

MariaDB: SHOW GRANTS [FOR role_name];
MySQL:   SHOW GRANTS [FOR role_name];
MySQL:   SHOW GRANTS [FOR user_name USING role_name[,role_name...]];

MariaDB: GRANT role_name TO grantee [,grantee...] [WITH ADMIN OPTION];
MySQL:   GRANT role_name[,role_name...] TO grantee [,grantee...];

(The last GRANT example surprised me. MariaDB has trouble granting multiple roles in one statement, it's Bug#5772. MySQL appears to be "solving" it by making certain role names illegal unless they're delimited; I'm not sure that's the right way to solve it.)

Circular roles (GRANT r1 TO r2; GRANT r2 TO r1;) are allowed but I expect they'll be disallowed in a later version.

Example:

/* as a user with lots of privileges */
CREATE USER 'u'@'localhost';
CREATE ROLE r;
CREATE TABLE t1 (s1 INT);
CREATE TABLE t2 (s1 INT);
GRANT SELECT ON t1 TO r;
GRANT r TO 'u'@'localhost';
/* as user 'u'@'localhost' */
SET ROLE r;
SELECT * FROM t1;
SELECT * FROM t2;
/* The first SELECT succeeds, the second SELECT fails. */

To generalize: so far MySQL 8.0.0 allows creation of roles but they have to look like users. So the syntax is undesirable, but they work properly.

Again, remember the context. There's nothing wrong with a feature that's not ready, until MySQL declares that it's ready.

Typos

MySQL's announcement, buried in a section about minor fixes, says "Foreign key names as stored in the foreign_keys and foreign_key_column_usage tables are a maximum of 64 characters, per the SQL standard". Er, up to a point. The SQL standard says "In a regular identifier, the number of identifier parts shall be less than 128."

Us Too

We have a new-version announcement too. Version 1.0.3 of the Ocelot Graphical User Interface (ocelotgui) for MySQL and MariaDB came out on Tuesday September 27 2016. Some new items are ...

As well as getting result sets in the result-set widget, one can get them added to the history widget, with the same format as what the mysql client outputs.
shot_2016_0929_4

As well as predicting what the next word should be, Ocelot's syntax recognizer makes it possible to show hints if the user hovers over a word.
shot_2016_0929_3

Finally, there is a rudimentary formatter. Clicking the edit menu item Edit|Format will change indentation, make keywords upper case, etc. I say "rudimentary" because, without a standard to follow, one must depend on taste, and nobody shares the taste that's on display here.
shot_20160929_1shot_2016_0929_2

Documentation is now on ocelot.ca/index.htm. C++ source and Linux-ready packages are on github.com/ocelot-inc/ocelotgui.

OOW16 talk – MySQL X protocol – Talking to MySQL directly over the Wire

Percona Live Amsterdam and MariaDB Developer Meeting 2016: Tip to Stay Dry

$
0
0
Or should I say "to avoid getting soaked"... The Amsterdam weather forecasts for next week is out and even if it looks good for the Percona Live MySQL and (No)SQL Conference (Monday to Wednesday) and for the MariaDB Developer Meeting (Thursday to Saturday), it could still change (or you might suffer the rain in the week-end): Of course, this is not a problem during talks, and I take this

MySQL 8.0 and the thread sanitizer

$
0
0
MySQL 8.0 now supports the thread sanitizer.   This is good news as the thread sanitizer provides MySQL developers another tool to help find bugs in the multi-threaded MySQL server.  What happens when we build MySQL 8.0 with the thread sanitizer enabled and try to run some basic MySQL tests?  Unfortunately, no MySQL tests run since the MySQL bootstrap fails with lots of data races and other issues raised by the thread sanitizer.  When these issues are suppressed, some of the basic MySQL and InnoDB tests pass.  Some of these issues are real bugs and need to be investigated.

Both gcc 6.1 and clang 3.9 support the thread sanitizer.  Just add  the 'WITH_TSAN=ON' cmake option when configuring and building MySQL 8.0, and the MySQL code will be compiled with the thread sanitizer.

The next step after building MySQL is to run some MySQL tests.  Unfortunately, MySQL tests need to bootstrap the MySQL data directory, and there are lots of thread sanitizer issues during the bootstrap that prohibit the bootstrap to succeed.   This means that no MySQL tests can be run until these issues are fixed or suppressed.  MySQL 8.0 does not include a basic suppression file for the thread sanitizer as it does for the address sanitizer and for valgrind.  So, how many suppressions are needed to get a simple test to run?  The answer is about 4 or 5 suppressions (see below).  The problem is that the InnoDB suppression covers ANY data race in the InnoDB storage engine.  Since InnoDB is the primary storage engine for MySQL, this is not acceptable.  I hope that the InnoDB developers address this.

I used the following thread sanitizer suppressions when running the main and InnoDB MySQL test suites.  Anyone interesting in using the thread sanitizer to find bugs in MySQL 8.0 software can use these suppressions as a starting point in their investigation.  Good luck!

# ignore races in the pthread barrier implementation
race:pthread_barrier

# ignore possible locking deadlock
deadlock:plugin_thdvar_init

# ignore all races in the innodb storage engine.  this is overkill
race:innobase

# ignore races in the perf schema
race:^pfs
race:^PFS

# ignore race on charsets_dir
race:^charsets_dir$

# ignore race on THR_KEY_mysys_initialized. should be an atomic variable
race:^THR_KEY_mysys_initialized$

Perform Hot Backups of MySQL Databases with Percona XtraBackup on Ubuntu 16.04

$
0
0
Percona XtraBackup is an open source backup utility for MySQL. It supports all MySQL flavours like Percona Server, MariaDB, and (Oracle) MySQL. Percona Xtrabackup performs a Hot Backup for MySQL. In this tutorial, I will show you how to create a hot MySQL database backup with the OpenSource tool Percona XtraBackup on Ubuntu 16.04 (Xenial Xerus).

Speaking in October 2016

$
0
0
  • I’m thrilled to naturally be at Percona Live Europe Amsterdam from Oct 3-5 2016. I have previously talked about some of my sessions but I think there’s another one on the schedule already.
  • LinuxCon Europe – Oct 4-6 2016. I won’t be there for the whole conference, but hope to make the most of my day on Oct 6th.
  • MariaDB Developer’s meeting – Oct 6-8 2016 – skipping the first day, but will be there all day 2 and 3. I even have a session on day 3, focused on compatibility with MySQL, a topic I deeply care about (session schedule)
  • OSCON London – Oct 17-20 2016 – a bit of a late entrant, I do have a talk titled “Forking successfully”, and wonder if a branch makes more sense, how to fork, and what happens when parity comes?
  • October MySQL London Meetup – Oct 17 2016 – I’m already in London, I wouldn’t miss this meetup for the world! There’s no agenda yet, but I think the discussion should be fun.

MariaDB 10.2 Beta

$
0
0
Mon, 2016-10-03 05:53
Rasmus Johansson

With the release of MariaDB 10.2.2, the newest version of MariaDB has entered the beta stage. In this article, I’ll give an overview of the main new features in MariaDB 10.2. The focus of MariaDB 10.2 can be seen from the categories that the features fall into:

  • Analytics
  • Security
  • Consistency
  • Performance
  • Storage Engines
  • Lifted limitations


Analytics - Window functions
Window functions are popular in Business Intelligence where there's a desire to, for example, in a report table, include on every row, a calculation based on the other rows that compare a value of the current row with the other rows. MariaDB’s implementation now support all generally used Window Functions from the SQL standards. https://mariadb.com/kb/en/mariadb/window-functions/

Analytics - CTE
A typical query in many aspects that has needed some tricks before is to do a hierarchical query to fetch a parent and all its children in a tree like structure that could be for example the categories and subcategories (and their subcategories and so on) of a product catalog. This is now possible to do in a single query by making use of the recursive Common Table Expression WITH RECURSIVE. Both the standard non-recursive and recursive expressions are supported.

Security
Limits can now be set on user accounts for how many queries, updates or connections can be made for a specific user account per hour. Also SSL/TLS encryption options have been introduced for users, permitting only encrypted connections for a user, that the user make use of a certificate with certain specifics (issuer, subject) that can be set and that a specific cipher is used for encryption. https://mariadb.com/kb/en/mariadb/create-user/

MariaDB 10.2 introduces two new statements for user management as well. ALTER USER is used to, of course, change any settings on the user, like required authentication type or limitations on amount of queries per hour. SHOW CREATE USER logically shows the CREATE statement that would create the user you’re referring to.

Consistency - CHECK constraints, DEFAULT
A long lasting wish from users are met in MariaDB 10.2 where it’s finally possible to make use of CHECK constraints. With CHECK constraints you can put a condition on every value in a row to meet a certain criteria, for example that a column only permits values that are non-negative or that the value of one column has to be smaller than another column’s value.

MariaDB 10.2 supports the use of functions and expressions in the DEFAULT constraint of a column. Also, BLOB and TEXT columns can now have DEFAULT values. See CREATE TABLE for more information.

Performance
There are several things that add to improved performance, like the new InnoDB engine and optimizer changes, but there are also internal server changes that give a nice boost to the overall performance of the database server:

  • The creation of new connections inside the server has been modified so that the creation is much faster than before. When there are plenty of connection threads in the server, we’ve measured a significant speedup.

  • Temporary tables for InnoDB can be put in a separate location, which allows for using separate storage for them.


Storage Engines - InnoDB, CONNECT
InnoDB from MySQL 5.7 is included in MariaDB 10.2 and it has been merged with all MariaDB specific functionality like MariaDB’s encryption, compression, defragmentation. Also, Galera, the clustering technology is integrated with InnoDB.

MariaDB includes a storage engine for data integration called the CONNECT engine. With the CONNECT engine, it’s possible to connect to remote data sources and expose them as tables inside MariaDB. Together with MariaDB 10.2, a new JDBC table type has been introduced. It allows it to connect to other data sources, for example other databases over JDBC. The CONNECT engine with this feature is also available in MariaDB 10.0 and 10.1.

Lifted limitations

  • Some applications (especially financial ones) require more decimals than 30, which has been the limit so far in MariaDB. This limit has been raised to 38.

  • In MariaDB 10.2 the expression of Virtual Columns can be longer than 252 characters and the expressions can include other virtual columns. Also user defined functions are now supported in the expression.

  • VIEWs can now include subqueries in the FROM clause.

  • The same temporary tables can be used several times in a query. This has been a long lasting limitation in MariaDB and MySQL.

  • ANALYZE TABLE used to lock the whole table when analysing key distribution. Locking of the table is not needed anymore.

Other useful enhancements

  • libmysqlclient has been removed from the server. It has been replaced by MariaDB’s own Connector/C.

  • INFORMATION_SCHEMA includes USER_VARIABLES which lists all user defined variables.

  • EXPLAIN FORMAT=JSON has been expanded to include the used sort_key in filesort and outer_ref_condition in SELECTs.

  • Analytical query performance improvement - If a derived table, view or CTE includes a GROUP BY clause it would be internally processed with temporary tables, which would then be materialized and used by the parent query. If the parent query has restrictions on the GROUP BY columns, this new optimization applies them early to exclude non-matching groups from materialization.

About the Author

Rasmus Johansson's picture

Rasmus has worked with MariaDB since 2010 and was appointed VP Engineering in 2013. As such, he takes overall responsibility for the architecting and development of MariaDB Server, MariaDB Galera Cluster and MariaDB Enterprise.

Announcing Galera Cluster 5.7 Beta

$
0
0

Codership is pleased to announce a new beta release of Galera Cluster for MySQL 5.7, consisting of MySQL-wsrep 5.7.15 and Galera 3.18.

Galera Cluster for MySQL 5.7 contains enhancements in multiple key areas, including security, performance and monitoring.

This is a beta-quality release and should not be used in production, however we encourage you to give it a try and we welcome all feedback. You can use the bug tracker at https://github.com/codership/mysql-wsrep/issues to submit issues or you can email us at info@galeracluster.com.

This release incorporates all changes up to MySQL 5.7.15 and is available as targeted packages and package repositories for Ubuntu 16.06 and CentOS 7 that can be downloaded from http://www.galeracluster.com.

Notable changes in this release:

  • If needed, initialization of the initial MySQL database can be performed using the --initialize command:
sudo /usr/sbin/mysqld --user=mysql --initialize --log-error=/tmp/mysqld_initialize.log
  • On systemd systems, bootstrapping the first node of the cluster is performed using the following command:
  • sudo /usr/bin/mysqld_bootstrap
    

    Known issues with this release:

    • Mixed-version clusters containing both 5.6 and 5.7 nodes are not supported
    • GTID mode and associated options are not supported and may cause the applier thread to abort;
    • Running the mysqld_upgrade script should be done while the wsrep_provider is not loaded;
    • The --wsrep-replication-bundle option has no effect and may be removed in a future release;
    • InnoDB tablespaces outside of the data directory are not supported, as they may not get copied over during SST;
    • Compilation with DTrace enabled may fail, so -DENABLE_DTRACE=0 may be used to disable DTrace.
    • Packages for RHEL, Debian, and Ubuntu 14.04 will be provided with the GA release.

    Replacing JSON UDF calls with native function calls in MySQL 5.7

    $
    0
    0

    If you use JSON UDFs in MySQL 5.6 there are a few things to consider before upgrading to MySQL 5.7. From a schema perspective, if you have JSON stored in text columns you can decide when to convert those columns to the new JSON datatype after you upgrade, but due to namespace collisions and format differences it's probably not safe to upgrade without dropping some or all of the existing UDFs and updating your queries that use those UDFs.

    Read on for details...

    Namespace collisions

    There are 15 functions in JSON UDFs version 0.4.0. Nine of those names are used by native JSON functions in MySQL 5.7, so it's not possible to continue using those nine UDFs in MySQL 5.7. Therefore before you upgrade you should probably drop these UDFs:

    DROP FUNCTION IF EXISTS json_append; DROP FUNCTION IF EXISTS json_depth; DROP FUNCTION IF EXISTS json_extract; DROP FUNCTION IF EXISTS json_merge; DROP FUNCTION IF EXISTS json_remove; DROP FUNCTION IF EXISTS json_replace; DROP FUNCTION IF EXISTS json_search; DROP FUNCTION IF EXISTS json_set; DROP FUNCTION IF EXISTS json_valid;

    Path syntax

    Depending on which version of MySQL JSON UDFs you are using, you may need to rewrite your queries to use the new path syntax. If you are using version 0.2 or 0.3 then you're using this path syntax:

    json_extract(doc, keypart1, keypart2, ...)

    For example:

    ``` mysql> select json_extract('{"foo":"bar"}','foo'); +-------------------------------------+ | json_extract('{"foo":"bar"}','foo') | +-------------------------------------+ | bar | +-------------------------------------+ 1 row in set (0.00 sec)

    mysql> select json_extract('{"parent":{"child":"hello"}}','parent','child'); +---------------------------------------------------------------+ | json_extract('{"parent":{"child":"hello"}}','parent','child') | +---------------------------------------------------------------+ | hello | +---------------------------------------------------------------+ 1 row in set (0.00 sec) ```

    The native JSON functions use this path syntax:

    JSON_EXTRACT(json_doc, path[, path] ...)

    For example:

    ``` mysql> select json_extract('{"foo":"bar"}','$.foo'); +---------------------------------------+ | json_extract('{"foo":"bar"}','$.foo') | +---------------------------------------+ | "bar" | +---------------------------------------+ 1 row in set (0.00 sec)

    mysql> select json_extract('{"parent":{"child":"hello"}}','$.parent.child'); +---------------------------------------------------------------+ | json_extract('{"parent":{"child":"hello"}}','$.parent.child') | +---------------------------------------------------------------+ | "hello" | +---------------------------------------------------------------+ 1 row in set (0.00 sec) ```

    MySQL JSON UDFs version 0.4 had two copies of each UDF -- one for each path syntax -- so you only need to rewrite this part of your queries if you're using the old path syntax. The functions using the old path syntax are in libmy_json_udf and the functions using the new path syntax are in libmy_json_udf_path.

    Input differences

    The MySQL 5.7 native JSON functions have some input differences as compared to the JSON UDF functions with the same name. One fundamental difference is the support for input strings which are not valid JSON. In general, the UDFs return NULL when the input is not valid JSON, whereas the native functions return an error. If your input is a column of JSON datatype then this is not a concern, since the datatype enforces the validity of the JSON and will not store invalid JSON. If the input is text you need to be more careful.

    For example, none of these queries throw an error in MySQL 5.6 using JSON UDFs:

    ``` mysql> select json_extract('','foo'); +------------------------+ | json_extract('','foo') | +------------------------+ | NULL | +------------------------+ 1 row in set (0.00 sec)

    mysql> select json_extract('NOT JSON','foo'); +--------------------------------+ | json_extract('NOT JSON','foo') | +--------------------------------+ | NULL | +--------------------------------+ 1 row in set (0.00 sec) ```

    You can simply use COALESCE() if you want to replace the NULL output with the empty string:

    mysql> select coalesce(json_extract('NOT JSON','foo'),''); +---------------------------------------------+ | coalesce(json_extract('NOT JSON','foo'),'') | +---------------------------------------------+ | | +---------------------------------------------+ 1 row in set (0.00 sec)

    But in MySQL 5.7 with native functions these queries throw an error:

    mysql> select json_extract('','$.foo'); ERROR 3141 (22032): Invalid JSON text in argument 1 to function json_extract: "The document is empty." at position 0. mysql> select json_extract('NOT JSON','$.foo'); ERROR 3141 (22032): Invalid JSON text in argument 1 to function json_extract: "Invalid value." at position 0.

    One way around that is using a CASE statement along with the JSON_VALID() functions:

    ``` mysql> set @json = ''; Query OK, 0 rows affected (0.00 sec)

    mysql> select (case when json_valid(@json) then json_extract(@json,'$.foo') else '' end); +----------------------------------------------------------------------------+ | (case when json_valid(@json) then json_extract(@json,'$.foo') else '' end) | +----------------------------------------------------------------------------+ | | +----------------------------------------------------------------------------+ 1 row in set (0.00 sec)

    mysql> set @json = 'NOT JSON'; Query OK, 0 rows affected (0.01 sec)

    mysql> select (case when json_valid(@json) then json_extract(@json,'$.foo') else '' end); +----------------------------------------------------------------------------+ | (case when json_valid(@json) then json_extract(@json,'$.foo') else '' end) | +----------------------------------------------------------------------------+ | | +----------------------------------------------------------------------------+ 1 row in set (0.00 sec) ```

    Since the above queries return empty string if they encounter invalid JSON there is no need to use COALESCE().

    Output differences

    The MySQL 5.7 native JSON functions return JSON objects, whereas the JSON UDFs return text. For example a call to the JSON_EXTRACT() UDF in MySQL 5.6 may return foo, but the same function in MySQL 5.7 would return "foo". Therefore in order to replace a call to the UDF version of a function like JSON_EXTRACT() with the corresponding native function call, you should wrap that call with the JSON_UNQUOTE() function.

    Examples:

    MySQL 5.6

    mysql> select json_extract('{"foo":"bar"}','foo'); +-------------------------------------+ | json_extract('{"foo":"bar"}','foo') | +-------------------------------------+ | bar | +-------------------------------------+ 1 row in set (0.00 sec)

    MySQL 5.7

    ``` mysql> select json_extract('{"foo":"bar"}','$.foo'); +---------------------------------------+ | json_extract('{"foo":"bar"}','$.foo') | +---------------------------------------+ | "bar" | +---------------------------------------+ 1 row in set (0.12 sec)

    mysql> select json_unquote(json_extract('{"foo":"bar"}','$.foo')); +-----------------------------------------------------+ | json_unquote(json_extract('{"foo":"bar"}','$.foo')) | +-----------------------------------------------------+ | bar | +-----------------------------------------------------+ 1 row in set (0.00 sec) ```

    While you are re-writing those function calls, consider using the -> (added in 5.7.9) and ->> (added in 5.7.13) operators, which are shortcuts for JSON_EXTRACT() and JSON_UNQUOTE(JSON_EXTRACT()) respectively. For example, these three statements are equivalent:

    ``` select JSON_UNQUOTE( JSON_EXTRACT(my_column, '$.some_key') ) from my_table;

    select JSON_UNQUOTE(my_column -> '$.some_key') from my_table;

    select my_column->>'$.some_key' from my_table; ```

    Testing those out to confirm the output:

    ``` mysql> create temporary table if not exists json_test as select '{"foo":"bar"}' as json_val; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0

    mysql> select json_unquote(json_extract(json_val,'$.foo')) from json_test; +----------------------------------------------+ | json_unquote(json_extract(json_val,'$.foo')) | +----------------------------------------------+ | bar | +----------------------------------------------+ 1 row in set (0.03 sec)

    mysql> select json_unquote(json_val->'$.foo') from json_test; +---------------------------------+ | json_unquote(json_val->'$.foo') | +---------------------------------+ | bar | +---------------------------------+ 1 row in set (0.00 sec)

    mysql> select json_val->>'$.foo' from json_test; +--------------------+ | json_val->>'$.foo' | +--------------------+ | bar | +--------------------+ 1 row in set (0.00 sec) ```

    Sharding MySQL with MySQL Fabric and ProxySQL

    $
    0
    0

    There are numerous ways to migrate into MySQL Fabric. Most of them require serious changes in your application - you have to switch to the MySQL Fabric connector to actually benefit from the MySQL Fabric infrastructure. You may also have to implement some kind of data-awareness in your application as it will have to pass a sharding key (some value from the column which is used to shard a given table) when connecting to MySQL Fabric. This process may be not possible to do in a single step, so we prepared a proof of concept to show you how to migrate without application changes.

    The solution consists of several elements. At the backend, there’s MySQL Fabric with its sharding system of high availability groups and tools around it. Another layer is built using MySQL Router - it allows regular MySQL clients to connect to different high availability groups created in MySQL Fabric. It doesn’t solve the problem of routing queries to the correct shards though. This is where ProxySQL comes in to help - it allows us to perform a flawless failover (from the old database to the sharded setup), but also, it will route the queries to the correct shards exposed by the MySQL Router. Routing is based on ProxySQL’s ability to parse SQL and perform actions (including rerouting) on queries based on whether the query matches a regex or not.

    Initial environment will look as described in the chart below. We have two shards configured using MySQL Fabric - this brings us to the total of three high availability groups (two shards and a global group). Each such group is built on top of two MySQL nodes in master - slave replication. Within those groups MySQL Fabric will manage high availability by monitoring the status of MySQL, and promoting a slave to master if required. Each high availability group is configured in MySQL Router, which exposes all of them on different ports. We will split the sharded tables in half, each shard storing half of the sharded data set. Last remaining part of the setup is routing.

    ProxySQL gives us ability to change query routing based on regular expression matches. What we need to do is prepare a set of rules - one for every type of query which hits the sharded table. We need to prepare regular expressions which will distinguish which queries are to be routed to the first shard or the second shard. This process may be error prone, you need to test your rules before you actually apply them to production. Limitations may apply here too - your queries have to explicitly use a sharding key to identify rows - similar limitations apply to MySQL Fabric or any other sharding solution, so this is not a constraint induced by our setup. Additional query rules may have to be created for non-sharded, global tables.

    Once all query rules are ready and tested, a switchover has to happen - traffic has to be moved from the old setup based on MySQL replication and routed to our sharded setup, based on the rules we created - this again can be done using ProxySQL, without any interruption to your application (as long as you don’t use long transactions).

    When traffic hit the sharded setup, another phase begins - maintaining the sharded environment. MySQL Fabric gives us different tools for that - you can add hosts to high availability groups, you can promote hosts within a high availability group. You may also need to split shards. Some of those operations are transparent in our setup, some (like splitting or moving the shard) require detailed preparations as they cannot be executed easily using existing MySQL Fabric CLI commands.

    More details about our setup and migration from MySQL replication into a MySQL Fabric sharded environment can be found in our ebook.

    The ebook covers the entire process, and also includes an example script showing how you can extend MySQL Fabric and execute a shard split without affecting your traffic.

    Database Sharding with MySQL Fabric

    Why do we shard? How does sharding work? What are the different ways I can shard my database? This whitepaper goes through some of the theory behind sharding. It also discusses three different tools which are designed to help users shard their MySQL databases. And last but not least, it shows you how to set up a sharded MySQL setup based on MySQL Fabric and ProxySQL.

    Download Here

    Percona Live Europe 2016: “Become a MySQL DBA” with Severalnines’ Johan Andersson and Krzysztof Książek

    $
    0
    0
    Percona Live Europe

    Percona Live EuropeThe Percona Live Europe Open Source Database Conference 2016 in Amsterdam got off to a great start on Monday with a day of tutorials. One of the ones most anticipated was Become a MySQL DBA Part 1 and Part 2, given by Severalnines’ Johan Andersson (CTO) and Krzysztof Książek (Senior Support Engineer).

    This hands-on tutorial is intended to help you navigate your way through the steps that lead to becoming a MySQL DBA. Johan and Krzysztof discussed the most important aspects of managing MySQL infrastructure, as well as shared best practices and tips on how to perform the most common activities.

    They covered:

    • Monitoring and trending for your MySQL installation
    • Differences between NDB Vs. Galera
    • MySQL Cluster: Pros and Cons
    • Galera Cluster: Pros and Cons
    • How to ensure you are proactive in monitoring the health of your MySQL?
    • How to diagnose issues with your MySQL setup?
    • Slow queries performance problems – what to look for?
    • Error logs
    • Hardware and OS issues
    • Backups
    • Binary and logical backup
    • Most common maintenance operations
    • Schema changes
    • Batch operations
    • Replication topology changes
    • Database upgrades

    After their talk, Percona’s EMEA Field Marketing Manager Kamal Taibi was able to quickly chat with the two about their talk, and about the conference. Watch it below!

    Viewing all 18783 articles
    Browse latest View live


    <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>