Showing entries 7163 to 7172 of 44074
« 10 Newer Entries | 10 Older Entries »
9 DevOps Tips for going in production with MySQL / MariaDB Galera Cluster: webinar replay

Many thanks to everyone who participated in this week’s webinar on ‘9 DevOps Tips for going in production with MySQL / MariaDB Galera Cluster’.

The replay and slides are now available to watch and read online:

Watch the replay Read the slides

Galera Cluster for MySQL / MariaDB is easy to deploy, but how does it behave under real workload, scale, and during long term operation?

This is where monitoring, managing schema changes and pushing them in production, performance optimizations, configurations, version upgrades and performing backups come in.

During this webinar, our CTO Johan Andersson walked us through his tips & tricks on important aspects to …

[Read more]
Announcing MySQL Server 5.7.16, 5.6.34, and 5.5.53

MySQL Server 5.7.16, 5.6.34, and 5.5.53, new versions of the popular Open Source Database Management System, have been released. These releases are recommended for use on production systems. For an overview of what’s new, please see http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html For information on installing the release on new servers, please see the MySQL installation documentation at […]

MySQL 5.7 Performance Tuning Immediately After Installation

This blog updates Stephane Combaudon’s blog on MySQL performance tuning, and covers MySQL 5.7 performance tuning immediately after installation.

A few years ago, Stephane Combaudon wrote a blog post on Ten MySQL performance tuning settings after installation that covers the (now) older versions of MySQL: 5.1, 5.5 and 5.6. In this post, I will look into what to tune in MySQL 5.7 (with a focus on InnoDB).

The good news is that MySQL 5.7 has significantly better default values. Morgan Tocker created a page with a complete list of features in MySQL 5.7, and is a great reference point. For example, the …

[Read more]
Encrypt your –defaults-file

Encrypt your credentials using GPG

This blog post will look how to use encryption to secure your database credentials.

In the recent blog post Use MySQL Shell Securely from Bash, there are some good examples of how you might avoid using a ~/.my.cnf – but you still need to put that password down on disk in the script. MySQL 5.6.6 and later introduced the  –login-path option, which is a handy way to store per-connection entries and keep the credentials in an encrypted format. This is a great improvement, but as shown in Get MySQL Passwords in Plain Text from .mylogin.cnf, …

[Read more]
NomadPHP and MySQL JSON Lightening Talk

I will be presenting a short lightening talk on MySQL's JSON Data Type for NomandPHP on Thursday the 13th of October. Chuck Reeves will be doing the main presentation on How the 3rd Normal Form Destroyed a Family. Get your tickets here.

MySQL 8.0 Labs – Descending Indexes in MySQL

Starting with the 8.0 optimizer labs release the MySQL server now supports descending indexes. As I will detail in this post, this new feature can be used to eliminate the need for sorting results, and lead to performance improvements in a number of queries.…

Using the loose_ option prefix in my.cnf

In this blog post, I’ll look at how to use the loose_ option prefix in my.cnf in MySQL.

mysqld throws errors at startup – and refuses to start up – if a non-existent options are defined in the my.cnf file.

For example:

2016-10-05 15:56:07 23864 [ERROR] /usr/sbin/mysqld: unknown variable 'bogus_option=1'

The MySQL manual has a solution: use the loose_ prefix option in my.cnf file.

In the prior example, if we specify loose_bogus_option=1 in the my.cnf file, instead of bogus_option=1, mysqld starts successfully and ignores that option.

This is useful in three situations:

  1. Using …
[Read more]
MySQL 8.0: The end of MyISAM

This blog discusses the gradual end of MyISAM in MySQL.

The story that started 20 years ago is coming to its end. I’m talking about the old MyISAM storage engine that was the only storage provided by MySQL in 1995, and was available in MySQL for 20+ years. Actually, part of my job as a MySQL consultant for 10+ years was to discover MyISAM tables and advise customers how to convert those to InnoDB.

(Check your MySQL installation, you may still have MyISAM tables).

MySQL 5.7 still used MyISAM storage for the system tables in the MySQL schema.

In MySQL 8.0 (DMR version as of writing), the MyISAM storage engine is still available. But in a very limited scope:

  • After …
[Read more]
PS_history 2.0 was released last week with MySQL 8 support and bundled sys_history

PS_history is a tool which collects historical snapshots of the PERFORMANCE_SCHEMA (P_S). This allows you to trend P_S values over time, for example, it is possible to look at the 95 th percentile response time for a query over time.

PS_history is stored procedure and event based, and thus it resides entirely inside of the database with no external dependencies. It uses a clever technique to capture all of the P_S data in one consistent snapshot. This ensures that all of the sys_history views (bundled now with PS_history) have a consistent set of data.

By default, as long as the event_schedule is enabled, PS_history will collect data every 30 seconds. If a snapshot takes 30 seconds, there will be a 30 second delay before the next snapshot starts. This value can be changed by calling the `ps_history`.`set_collection_interval`(N) where N is the number of seconds between samples.

The `sys_history` schema is …

[Read more]
PS_history 2.0 was released last week with MySQL 8 support and bundled sys_history

PS_history is a tool which collects historical snapshots of the PERFORMANCE_SCHEMA (P_S). This allows you to trend P_S values over time, for example, it is possible to look at the 95 th percentile response time for a query over time.

PS_history is stored procedure and event based, and thus it resides entirely inside of the database with no external dependencies. It uses a clever technique to capture all of the P_S data in one consistent snapshot. This ensures that all of the sys_history views (bundled now with PS_history) have a consistent set of data.

By default, as long as the event_schedule is enabled, PS_history will collect data every 30 seconds. If a snapshot takes 30 seconds, there will be a 30 second delay before the next snapshot starts. This value can be changed by calling the `ps_history`.`set_collection_interval`(N) where N is the number of seconds between samples.

The `sys_history` schema is …

[Read more]
Showing entries 7163 to 7172 of 44074
« 10 Newer Entries | 10 Older Entries »