During the last few months we had a lot of opportunities to present and discuss about a very powerful tool that will become more and more used in the architectures supporting MySQL, ProxySQL.

ProxySQL is becoming every day more flexible, solid, performant and used (http://www.proxysql.com/ and recent http://www.proxysql.com/compare).

This is it, the tool is a winner in comparing it with similar ones, and we all need to have a clear(er) idea on how integrate it in our architectures in order to achieve the best results.

The first to keep in mind is that ProxySQL is not natively supporting any high availability solution, in short we can setup a cluster of MySQL(s) and achieve 4 or even 5 nines of HA, but if we include ProxySQL, as it is, and as single …

Read the step by step tutorial to install MySQL on Ubuntu 16.04 and Debian OS. Also, find steps to setup, secure, and tune MySQL for performance.

The post Easy Steps to Install MySQL on Ubuntu 16.04 and Debian OS appeared first on Learn Programming and Software Testing.

I’m also wondering that if the partitions column should be ignored for NDB tables – as you said – , why in the “Optimizing MySQL Cluster Performance” white paper, “4.3 Distribution aware application” section, the partitions column in explain output was not ignored and was actually used to confirm the partitions and the distribution key(s) in NDB tables?! That’s really confusing !

LikeLike

Last week VividCortex's Preetam Jinka published a post on his personal blog examining how our engineering team had overcome a problem with MySQL replication by using a new parallelization policy introduced in MySQL 5.7: LOGICAL_CLOCK.

Image Credit

The solution we developed—which achieves faster replication via group commit and a carefully calibrated delay—can offer huge replication improvements, but its implementation isn't immediately obvious or intuitive. We thought it worthwhile to provide a fuller description of how we arrived at the solution Preetam outlined.

In my previous post, I talked about a funny replication breakage that I experienced with MariaDB.  So what about different versions of MySQL... > SELECT version(); +------------+ | version() | +------------+ | 5.6.35-log | +------------+ 1 row in set (0.00 sec) > SELECT * FROM test_jfg; +----+--------+-------------+ | id | status

In the first two blogs entries on this series we set up a connection to MySQL and sent off a query. Now we need to get the data back from the database and into the application.

An Embarrassment of RichesPHP has many options for what we want to do. But for the best place to start with was checking that rows were actually returned from a query. Below the results from a query are returned to a variable named $result. We can find out how many rows were returned from the server by examining $result->num_rows.

if (!$result = $mysqli->query($sql)) {

    // Again, do not do this on a public site, but we'll show you how
    // to get the error information
    echo "Error: Our query failed to execute and here is why: \n";
    echo "Query: " . $sql . "\n";
    echo "Errno: " . $mysqli->errno . "\n";
    echo "Error: " . $mysqli->error . "\n";
    exit;
}

// succeeded, but …

A funny replication breakage kept me at the office longer than expected today (Friday 13 is not kind with me).

So question of the day: can you guess what the below UPDATE statement does (or what is wrong with it)?

> CREATE TABLE test_jfg ( id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, status ENUM('a','b') NOT NULL DEFAULT 'a', txt TEXT); Query OK, 0

In this blog, I’ll look at the impact of swapping on MySQL performance. 

It’s common sense that when you’re running MySQL (or really any other DBMS) you don’t want to see any I/O in your swap space. Scaling the cache size (using

innodb_buffer_pool_size

 in MySQL’s case) is standard practice to make sure there is enough free memory so swapping isn’t needed.   

But what if you make some mistake or miscalculation, and swapping happens? How much does it really impact performance? This is exactly what I set out to investigate.

My test system has the following:

• 32GB of physical memory
• OS (and swap space) on a (pretty old) Intel 520 SSD device
• Database stored on Intel 750 NVMe storage

To simulate a worst case scenario, I’m using Uniform Sysbench Workload:

sysbench …

In MySQL 8.0 our plan is to drastically improve support for utf8. While utf8 support itself dates back to MySQL 4.1, there exist some limitations. The “sushi = beer” problem in the title refers to Bug #76553. Sushi and beer don’t even go well together, at least not to my taste:-) I will use this bug as an example to explain issues with utf8 collations in the past and our plans for utf8 support going forward.…

On February 3rd, just before Fosdem and the MySQL & Friends Devroom, MySQL’s Community Team is organizing the pre-Fosdem MySQL Day.

Today’s highlighted sessions are the one of Øystein Grøvlen:

• MySQL 8.0: Common Table Expressions (CTEs)
• Using Optimizer Hints to Improve MySQL Query Performance

Øystein is Senior Principal Software Engineer in the MySQL group at Oracle, where he works on the MySQL Query Optimizer.  

Dr. Grøvlen has a PhD in Computer Science from the Norwegian University of Science and Technology.  Before joining the MySQL team, he was a contributor on the Apache Derby …