The latest from the MySQL community

With SQLyog MySQL GUI 12.2.5, JSON comes to SQLyog. This is a new and major thing.  Also, Foreign Key management with NDB tables was added and the user- filter was improved in the User Manager. Additionally, some non-critical GUI bugs were fixed.

Changes as compared to MySQL GUI 12.2.4 include:

Features:

* Added basic support for the JSON datatype as of MySQL 5.7.8+ and MySQL Cluster 7.5.2+. The datatype is now available in the CREATE/ALTER TABLE dialog and JSON data will open in the BLOB-viewer. In the BLOB-viewer we have added validation that content is valid JSON. Also JSON-related keywords and functions are recognized in syntax highlighting and autocomplete. Also please see note at the bottom.
* SQLyog GUI now supports Foreign Key constraints between NDB tables for MySQL Cluster 7.3+.
* It is now possible to filter the users based on a string in the …

With SQLyog MySQL GUI 12.2.5, JSON comes to SQLyog. This is a new and major thing.  Also, Foreign Key management with NDB tables was added and the user- filter was improved in the User Manager. Additionally, some non-critical GUI bugs were fixed.

Changes as compared to MySQL GUI 12.2.4 include:

Features:

* Added basic support for the JSON datatype as of MySQL 5.7.8+ and MySQL Cluster 7.5.2+. The datatype is now available in the CREATE/ALTER TABLE dialog and JSON data will open in the BLOB-viewer. In the BLOB-viewer we have added validation that content is valid JSON. Also JSON-related keywords and functions are recognized in syntax highlighting and autocomplete. Also please see note at the bottom.
* SQLyog GUI now supports Foreign Key constraints between NDB tables for MySQL Cluster 7.3+.
* It is now possible to filter the users based on a string in the …

This blog post focuses on MySQL 5.7's newly improved features of security validation and password expiration.

The post Security Validation and Password Expiration in MySQL 5.7 appeared first on Datavail.

Introduction

A couple of months ago I decided to give myself a refresher on the mechanics of InnoDB. Having a high level understanding of what’s going on under the hood can help provide the context needed in order to resolve issues you may encounter as well as assist you in ensuring that your MySQL instance is running efficiently. Everyone can stand to go back to basics every now and then, as it can help you pick up concepts that you may have missed the last time you researched the topic.

This time around I decided to give myself a refresher by re-reading the MySQL 5.6 reference manual, chapter 14, which covers the InnoDB engine. Despite having a wealth of documented knowledge and insights, I found that a lot of the points in the documentations were unclear, leading me to do more research and experimentation in order to get a bit of clarity on some of the specifics that I felt were missing. In order to help make the information …

I have created a GitHub fork of MaxScale which does not include the 2.0 branch.  The repository is called GPLScale.

There is a big potential problem with this.  Take for example the file server/core/utils.c, which now has a new license:
https://github.com/mariadb-corporation/MaxScale/blob/2.0/server/core/utils.c

This file WAS covered under GPL:
  https://github.com/mariadb-corporation/MaxScale/blob/cb3213af6382c380df9fc47347764f087ae7ecb4/server/core/utils.c

When there is a bugfix in 2.0 for server code that existed in 1.0, can that code be backported directly into GPLscale?

a) util.c in 2.0 is clearly …

I have created a GitHub fork of MaxScale which does not include the 2.0 branch.  The repository is called GPLScale.

There is a big potential problem with this.  Take for example the file server/core/utils.c, which now has a new license:
https://github.com/mariadb-corporation/MaxScale/blob/2.0/server/core/utils.c

This file WAS covered under GPL:
  https://github.com/mariadb-corporation/MaxScale/blob/cb3213af6382c380df9fc47347764f087ae7ecb4/server/core/utils.c

When there is a bugfix in 2.0 for server code that existed in 1.0, can that code be backported directly into GPLscale?

a) util.c in 2.0 is clearly …

In this blog post, we’ll discuss how we’ve improved TokuDB and PerconaFT fragmented data file performance.

Through our internal benchmarking and some user reports, we have found that with long term heavy write use TokuDB/PerconaFT performance can degrade significantly on large data files. Using smaller node sizes makes the problem worse (which is one of our performance tuning recommendations when you have faster storage). The problem manifests as low CPU utilization, a drop in overall TPS and high client response times during prolonged checkpointing.

This post explains a little about how PerconaFT structures dictionary files and where the current implementation breaks down. Hopefully, it explains the nature of the issue, and how our solution helps addresses it. It also provides some contrived benchmarks that prove the solution.

PerconaFT map file disk format

NOTE. …

Storing documents is convenient: no need to define a schema up-front, no downtime for schema changes, no normalization, no slow joins – true or not, you name it. But what about search if you do not know how your data is structured? For example, the famous SFW-construct requires listing the columns to search: SELECT … FROM … WHERE some_column = ‘Jippie’ . Given that JSON data can have no schema how to write a query without knowing any field names, where is SELECT … FROM … WHERE * = ‘Jippie’? JSON_SEARCH() gets you started but there are gaps if you think about it for a minute.

There are many reasons why you may not know the structure of the data you operate on. Maybe, you have gathered documents using different “schema versions” over time, maybe, there is simply no common structure because the data comes from …

In this blog post, we’ll discuss how to improve the performance of slow MySQL queries using Apache Spark.

Introduction

In my previous blog post, I wrote about using Apache Spark with MySQL for data analysis and showed how to transform and analyze a large volume of data (text files) with Apache Spark. Vadim also performed a benchmark comparing performance of MySQL and Spark with Parquet columnar format (using Air traffic performance data). That works great, but what if we don’t want to move our data from MySQL to another storage (i.e., …

The MariaDB project is pleased to announce the immediate availability of MariaDB Galera Cluster 5.5.51 Stable (GA), and MariaDB Connector/J 1.5.1 Release Candidate (RC). See the release notes and changelogs for details on these releases. Download MariaDB Galera Cluster 5.5.51 Release Notes Changelog What is MariaDB Galera Cluster? MariaDB APT and YUM Repository Configuration Generator […]

The post MariaDB Galera Cluster 5.5.51 and Connector/J 1.5.1 now available appeared first on MariaDB.org.