Archive for the ‘MariaDB’ Category

Discussing the innodb_log_block_size variable

Tuesday, November 11th, 2014

Not a ground-breaking post here, but if you are interested in knowing more about the innodb_log_block_size variable, or if you use SSD cards and/or large InnoDB log files on ext4, then this is for you.

I’d read about it before briefly before, but didn’t give it too much thought until I ran across the following entry in an error log the other day:

InnoDB: Warning: innodb_log_block_size has been changed
from default value 512. (###EXPERIMENTAL### operation)

This got me wanting to know more.

Basically, this variable changes the size of transaction log records. Generally, the default of 512 is a good value. However, it has been found that setting it to 4096 has been beneficial when using SSD cards. (Note that while it is possible to set this to a value other than 512 or 4096, those are currently the only 2 values that make sense to use.)

Also, it has been found that 4096 is the best setting if you run ext4 along with innodb_flush_method=ALL_O_DIRECT (note both innodb_log_block_size and ALL_O_DIRECT are specific to XtraDB/XtraDB+; read: MariaDB and Percona server).

What is ALL_O_DIRECT and when it is useful?

“ALL_O_DIRECT: use O_DIRECT to open both data and log files, and use fsync() to flush the data files but not the log files. This option is recommended when InnoDB log files are big (more than 8GB), otherwise there might be even a performance degradation.”

http://www.percona.com/…/innodb_io.html#innodb_flush_method

Thus if you’re running large InnoDB log files (8G+) on ext4, you may want to consider ALL_O_DIRECT, and because you’re on ext4, you should set innodb_log_block_size=4096, the default log-block-size in ext4, in order to avoid the unaligned AIO/DIO warnings.

Likewise, if running with SSD cards, you’d likely see a performance improvement with innodb_log_block_size=4096 also.

If interested, there is a bit more about the innodb_log_block_size option here:

https://mariadb.com/…variables/#innodb_log_block_size
http://www.percona.com/…/innodb_io_55.html#innodb_log_block_size

Hope this helps.

 

MariaDB Launches Ambassadors Program

Tuesday, November 11th, 2014

It was announced today that the MariaDB Corporation is launching an Ambassadors Program on behalf of the MariaDB Foundation.

Colin Charles, Chief Evangelist at MariaDB Corporation said, “The MariaDB Ambassador Program is set up to recognize and support experienced contributors to the MariaDB and MySQL ecosystem who are responsible for representing, promoting and expanding the use of MariaDB and its ideals to the larger open source community and general public.”

He further added, “There are two distinct types of ambassadors, all of whom will be volunteers. Community Ambassadors will promote grassroots adoption in their specific region. Platform Ambassadors will contribute virtually through the creation of code, patches, features, and who lead MariaDB engineering efforts at their respective organizations. MariaDB Corporation will provide each Community Ambassador with funds to organize local MariaDB meetups and invite Platform Ambassadors to MariaDB Engineering meetings as guests.”

You can read the full press release here:

https://mariadb.com/news-events/press-releases/mariadb-launches-ambassadors-program

 

Disabling InnoDB in MySQL 5.6 and MariaDB 10.0

Sunday, November 9th, 2014

There are a few circumstances where one will not want to run with only MyISAM tables. In this case, it can be beneficial to completely disable InnoDB.

As InnoDB has become more prevalent, disabling it in MySQL requires a little more effort than before.

In MariaDB 10.0, you can still completely disable it as you have done in the past (just add the –skip-innodb option, specify default-storage-engine=MyISAM, and comment out other InnoDB options):

[mysqld]
skip-innodb
default-storage-engine=MyISAM

Alternatively, instead of –skip-innodb, you can instead use “innodb=OFF”:

[mysqld]
skip-innodb
default-storage-engine=MyISAM

In MySQL 5.6, the –skip-innodb option has been deprecated (though still currently works), and since InnoDB is the new “default” storage engine, you must set both “default-storage-engine” and the new “default-tmp-storage-engine” options to “MyISAM”. If you do not set the latter, you instance will not start, and the error log will simply complain that “Unknown/unsupported storage engine: InnoDB” and you won’t easily identify why:

2014-11-08 18:47:28 13524 [ERROR] Unknown/unsupported storage engine: InnoDB
2014-11-08 18:47:28 13524 [ERROR] Aborting

So, if you want to disable InnoDB in MySQL 5.6, you’ll need to specify the following:

default-storage-engine=MyISAM
default-tmp-storage-engine=MyISAM
innodb=OFF

For reference, this last part is documented in the manual here, but I felt a post was appropriate given the obscurity of this overall issue.

Also, if you disable InnoDB in MySQL, you may see an extraneous message in your error log, as described here. Also, in both MySQL and MariaDB, you’ll likely see a few strange messages after running mysql_upgrade, which I discuss in more detail here.

Hope this helps.

 

Resolving “Unknown storage engine ‘InnoDB’” Error when Running MyISAM-only and Upgrading to MySQL 5.6 or MariaDB 10.0

Sunday, November 9th, 2014

I know, what, MyISAM-only? Yes, it’s true, and it occurs more than you might think. :)

If you do run MyISAM-only, it’s common to have disabled InnoDB altogether (–skip-innodb) to avoid allocating any RAM to it, and to avoid unnecessary files required for backups, and so forth. (See this post if interested in disabling InnoDB in MySQL 5.6 and/or MariaDB 10.0.)

One improvement in MySQL 5.6 and MariaDB 10.0 is the addition of some system tables. The 2 that are in both are `innodb_table_stats` and `innodb_index_stats`, both of which have an engine type of InnoDB. (The 1 additional system table in MariaDB 10.0 is `gtid_slave_pos`, and the 3 additional system tables in MySQL 5.6 are `slave_master_info`, `slave_relay_log_info`, and `slave_worker_info`.)

The issue, with regards to running MyISAM-only, is that these new tables are of type InnoDB by default. So if you’re running MyISAM only, you’ll see some errors and warnings when running mysql_upgrade, and/or examining your error log.

When running mysql_upgrade, you’ll see entries like (in both MySQL and MariaDB):

mysql.innodb_index_stats
Error    : Unknown storage engine 'InnoDB'
error    : Corrupt
mysql.innodb_table_stats
Error    : Unknown storage engine 'InnoDB'
error    : Corrupt

On the other hand, if looking in your error log, you might see something like this in MySQL:

[Warning] Info table is not ready to be used.
Table 'mysql.slave_master_info' cannot be opened.
[Warning] Info table is not ready to be used.
Table 'mysql.slave_relay_log_info' cannot be opened.

Or this in MariaDB:

[Warning] Failed to load slave replication state from
table mysql.gtid_slave_pos: 1286: Unknown storage engine 'InnoDB'

So what to do if you want to fix this?

If you do not want the new tables at all, you can simply delete the .frm and .ibd files. This is probably fine for the 2 innodb_*_stats tables, since you’re not using InnoDB. However, you may want the other tables, depending on your replication needs, so this might not be an option for them.

Thus if you want one or more of these tables, then you can re-create them as MyISAM tables using CREATE TABLE statements (I’ll provide current ones at the end). Alternatively, you can temporarily enable InnoDB, ALTER the tables from InnoDB to MyISAM using “ALTER TABLE `table_name` ENGINE=MyISAM”, then disable InnoDB again.

MariaDB 10.0.14 SHOW CREATE outputs:

CREATE TABLE `gtid_slave_pos` (
  `domain_id` int(10) unsigned NOT NULL,
  `sub_id` bigint(20) unsigned NOT NULL,
  `server_id` int(10) unsigned NOT NULL,
  `seq_no` bigint(20) unsigned NOT NULL,
  PRIMARY KEY (`domain_id`,`sub_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='Replication slave GTID state';
CREATE TABLE `innodb_index_stats` (
  `database_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `table_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `index_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `stat_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `stat_value` bigint(20) unsigned NOT NULL,
  `sample_size` bigint(20) unsigned DEFAULT NULL,
  `stat_description` varchar(1024) COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`database_name`,`table_name`,`index_name`,`stat_name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
CREATE TABLE `innodb_table_stats` (
  `database_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `table_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `n_rows` bigint(20) unsigned NOT NULL,
  `clustered_index_size` bigint(20) unsigned NOT NULL,
  `sum_of_other_index_sizes` bigint(20) unsigned NOT NULL,
  PRIMARY KEY (`database_name`,`table_name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

MySQL 5.6.21 SHOW CREATE outputs:

CREATE TABLE `innodb_index_stats` (
  `database_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `table_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `index_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `stat_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `stat_value` bigint(20) unsigned NOT NULL,
  `sample_size` bigint(20) unsigned DEFAULT NULL,
  `stat_description` varchar(1024) COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`database_name`,`table_name`,`index_name`,`stat_name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0;
CREATE TABLE `innodb_table_stats` (
  `database_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `table_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `n_rows` bigint(20) unsigned NOT NULL,
  `clustered_index_size` bigint(20) unsigned NOT NULL,
  `sum_of_other_index_sizes` bigint(20) unsigned NOT NULL,
  PRIMARY KEY (`database_name`,`table_name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0;
CREATE TABLE `slave_master_info` (
  `Master_id` int(10) unsigned NOT NULL,
  `Number_of_lines` int(10) unsigned NOT NULL,
  `Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `Master_log_pos` bigint(20) unsigned NOT NULL,
  `Host` text CHARACTER SET utf8 COLLATE utf8_bin,
  `User_name` text CHARACTER SET utf8 COLLATE utf8_bin,
  `User_password` text CHARACTER SET utf8 COLLATE utf8_bin,
  `Port` int(10) unsigned NOT NULL,
  `Connect_retry` int(10) unsigned NOT NULL,
  `Enabled_ssl` tinyint(1) NOT NULL,
  `Ssl_ca` text CHARACTER SET utf8 COLLATE utf8_bin,
  `Ssl_capath` text CHARACTER SET utf8 COLLATE utf8_bin,
  `Ssl_cert` text CHARACTER SET utf8 COLLATE utf8_bin,
  `Ssl_cipher` text CHARACTER SET utf8 COLLATE utf8_bin,
  `Ssl_key` text CHARACTER SET utf8 COLLATE utf8_bin,
  `Ssl_verify_servert_cert` tinyint(1) NOT NULL,
  `Heartbeat` float NOT NULL,
  `Bind` text CHARACTER SET utf8 COLLATE utf8_bin,
  `Ignored_server_ids` text CHARACTER SET utf8 COLLATE utf8_bin,
  `Uuid` text CHARACTER SET utf8 COLLATE utf8_bin,
  `Retry_count` bigint(20) unsigned NOT NULL,
  `Ssl_crl` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The file used for the Certificate Revocation List (CRL)',
  `Ssl_crlpath` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The path used for Certificate Revocation List (CRL) files',
  PRIMARY KEY (`Master_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Master Information';
CREATE TABLE `slave_relay_log_info` (
  `Master_id` int(10) unsigned NOT NULL,
  `Number_of_lines` int(10) unsigned NOT NULL,
  `Relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `Relay_log_pos` bigint(20) unsigned NOT NULL,
  `Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `Master_log_pos` bigint(20) unsigned NOT NULL,
  `Sql_delay` int(11) NOT NULL,
  PRIMARY KEY (`Master_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Relay Log Information';
CREATE TABLE `slave_worker_info` (
  `Id` int(10) unsigned NOT NULL,
  `Relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `Relay_log_pos` bigint(20) unsigned NOT NULL,
  `Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `Master_log_pos` bigint(20) unsigned NOT NULL,
  `Checkpoint_relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `Checkpoint_relay_log_pos` bigint(20) unsigned NOT NULL,
  `Checkpoint_master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `Checkpoint_master_log_pos` bigint(20) unsigned NOT NULL,
  `Checkpoint_seqno` int(10) unsigned NOT NULL,
  `Checkpoint_group_size` int(10) unsigned NOT NULL,
  `Checkpoint_group_bitmap` blob NOT NULL,
  PRIMARY KEY (`Id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Worker Information';

Hope this helps.

 

Stopping a Runaway Rollback due to Failing Mass Import or ALTER TABLE

Wednesday, November 5th, 2014

I ran into this the other day, and while the solution is documented in the manual, it was kind of buried, so I thought I’d mention it here (and hopefully make it easier for others searching for this in the future).

In this specific instance, one was running a huge LOAD DATA (10 hours into it) and had to terminate the LOAD DATA command.

Terminating the command is one thing, but preventing InnoDB from trying to undo the rows that were inserted is another.

In this case, the LOAD DATA will easily re-create the table in question, so the existing table can be “thrown out”, so to speak. This, of course, is a *critical* requirement for this operation (i.e., that you can easily re-create the table – either from a load, backup, dump, etc.).

Per the manual:

“If you know that a given table is causing a crash on rollback, you can drop it. You can also use this to stop a runaway rollback caused by a failing mass import or ALTER TABLE: kill the mysqld process and set innodb_force_recovery to 3 to bring the database up without the rollback, then DROP the table that is causing the runaway rollback.”

https://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

Then, once the table is dropped:

  1. stop mysql
  2. remove the innodb_force_recovery=3 from config file
  3. start mysql
  4. re-create the table/re-run ALTER TABLE

This will allow you to be back up where you started, aside from re-creating the table, in minutes, as opposed to who knows how long for the runaway rollback to complete (I’ve seen 24-30+ hours in more extreme cases).

Hope this helps.

 

MariaDB 10.1.1 Overview and Highlights

Saturday, October 25th, 2014

MariaDB 10.1.1 was recently released, and is available for download here:

https://downloads.mariadb.org/mariadb/10.1.1/

This is the second alpha release of MariaDB 10.1, so there are a lot of new changes and functionalities added, and many, many bugs fixed (I counted 637). Since it’s alpha, I’ll only cover the major changes and additions, as there are a lot of great new features, and omit covering any of the bug fixes (feel free to browse them all here).

To me, these are the highlights of the new features:

And here are other new features of note:

You can read more about the 10.1.1 release here:

https://mariadb.com/kb/en/mariadb-1011-release-notes/

And if interested, you can review the full list of changes in 10.1.1 (changelogs) here:

https://mariadb.com/kb/en/mariadb-1011-changelog/

Hope this helps.

 

Ignoring the lost+found Directory in your Datadir

Wednesday, October 15th, 2014

I still get asked about the lost+found directory enough, and so I wanted to provide a current update.

The lost+found directory is a filesystem directory created at the root level of a mapped drive. Thus this is common to see if you create your mysql datadir at the root level of a mapped drive.

In the past, you could ignore it, if it wasn’t too problematic for you, or you could move your datadir down a level, and then it wouldn’t be created in the datadir anymore.

However, there is now the –ignore-db-dir option. It is actually not too new (it’s been in MariaDB since 5.3.9 and 5.5.28, and in MySQL as of 5.6.3), but I don’t think many are too familiar with it.

But when you do run into this problem, some/many would prefer to add a single line to the config file rather than move the datadir.

To do this, just add the following option to your my.cnf file, under the [mysqld] section (it cannot be set dynamically):

ignore-db-dir=lost+found

And just to show the example:

Before updating my.cnf file:

mysql> select version();
+--------------------+
| version()          |
+--------------------+
| 5.5.40-MariaDB-log |
+--------------------+

mysql> show global variables like 'ignore_db_dirs';
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| ignore_db_dirs |       |
+----------------+-------+

Update my.cnf file and restart mysqld:

mysql> show global variables like 'ignore_db_dirs';
+----------------+------------+
| Variable_name  | Value      |
+----------------+------------+
| ignore_db_dirs | lost+found |
+----------------+------------+

mysql> use lost+found
ERROR 1102 (42000): Incorrect database name 'lost+found'

Now you see the lost+found directory is ignored now.

Of course, you can omit multiple directories. However, if you need to add more than one, then you *must* use multiple instances of the ignore_db_dirs= option, one for each directory you want to ignore. That is, you cannot separate them by comma, even though that is how it will be displayed when you have more than one being ignored (I think it treats the comma as part of the name, so then neither of the dirs you want to ignore would be ignored):

For instance, if I want to ignore both “lost+found” and “test”, then you must add the following to the config file:

ignore-db-dir=lost+found
ignore-db-dir=test

Then restart mysqld:

mysql> show global variables like 'ignore_db_dirs';
+----------------+-----------------+
| Variable_name  | Value           |
+----------------+-----------------+
| ignore_db_dirs | lost+found,test |
+----------------+-----------------+

Hope this helps.

 

MariaDB 5.5.40 Overview and Highlights

Friday, October 10th, 2014

MariaDB 5.5.40 was recently released (it is the latest MariaDB 5.5), and is available for download here:

https://downloads.mariadb.org/mariadb/5.5.40/

This is a maintenance release, and so there are not too many big changes of note, just a number of normal bug fixes. However, there are a few items worth mentioning:

If interested, the official MariaDB 5.5.40 release notes are here:

https://mariadb.com/kb/en/mariadb/development/release-notes/mariadb-5540-release-notes/

And the full list of fixed bugs and changes in MariaDB 5.5.40 can be found here:

https://mariadb.com/kb/en/mariadb/development/changelogs/mariadb-5540-changelog/

Hope this helps.

 

MariaDB 10.0.14 Overview and Highlights

Tuesday, October 7th, 2014

MariaDB 10.0.14 was recently released, and is available for download here:

https://downloads.mariadb.org/mariadb/10.0.14/

This is the fifth GA release of MariaDB 10.0, and 15th overall release of MariaDB 10.0.

This is primarily a bug-fix release. (MariaDB 10.0 is the current stable series of MariaDB. It is an evolution of the MariaDB 5.5 with several entirely new features not found anywhere else and with backported and reimplemented features from MySQL 5.6.)

Here are the main items of note:

  1. TokuDB upgraded to 7.5.0
  2. XtraDB upgraded to 5.6.20-68.0
  3. InnoDB upgraded to 5.6.20
  4. Spider upgraded to 3.2.11
  5. SphinxSE upgraded to 2.1.9
  6. The Feedback plugin now includes statistics on collation usage.
  7. Error log has a flood protection that is activated after 10 identical unsafe warnings and disables them for the next 5 minutes.
  8. Many fixes and optimizations for the Power8 platform.
  9. As per the MariaDB Deprecation Policy, this will be the last release of MariaDB 10.0 for both Ubuntu 13.10 “Saucy” and Mint 16 “Petra”.
  10. With the recent release of CentOS 7 and RHEL 7, we are pleased to now provide packages for both distributions. Instructions for how to enable the repositories can be found by visiting the “Installing MariaDB with YUM” page and the repository configuration tool.
  11. Crash in GROUP_CONCAT(IF () ORDER BY 1) (MDEV-6743)
  12. Server crashes in my_hash_first if shutdown is performed when FLUSH LOGS is running (MDEV-6616)
  13. Slave replicating using GTID doesn’t recover correctly when master crashes in the middle of transaction (MDEV-6462)
  14. MariaDB crash on Power8 when built with advance tool chain (MDEV-6450)

As always, it’s great to see all of the fixes alone from TokuDB, XtraDB, InnoDB, Spider, and Sphinx (and thus if you’re relying on any of these technologies, I would consider upgrading). The Power8 enhancements are very nice to see also! (If you’re running Power8 and looking for performance improvements, then you should definitely look into upgrading.) The crash fixes are mostly obscure, but double-check them, just in case they might affect you currently, and if so, then plan to upgrade.

You can read more about the 10.0.14 release here:

https://mariadb.com/kb/en/mariadb-10014-release-notes/

And if interested, you can review the full list of changes in 10.0.14 (changelogs) here:

https://mariadb.com/kb/en/mariadb-10014-changelog/

Hope this helps.

 

MySQL 5.7.5 Overview and Highlights

Tuesday, October 7th, 2014

MySQL 5.7.5 was recently released (it is the latest MySQL 5.7, and is the “m15″ or “Milestone 15″ release), and is available for download here and here.

As for the fixes/changes, there are quite a few (the official release was split into 3 separate emails), which is expected in such an early milestone release.

The main highlights for me were (though the enhancements, and potentially impactful changes, are definitely not limited to this list):

  • InnoDB: The innodb_buffer_pool_size parameter is now dynamic, allowing you to resize the buffer pool without restarting the server. The resizing operation, which involves moving pages to a new location in memory, is performed chunks. Chunk size is configurable using the new innodb_buffer_pool_chunk_size configuration option. You can monitor resizing progress using the new Innodb_buffer_pool_resize_status status variable. For more information, see Resizing the InnoDB Buffer Pool Online.
  • Replication: When replicating from a master running a version earlier than MySQL 5.6.0 [Read "5.5" or "5.1"] to a slave running MySQL 5.6.0 or later, the slave requires the master_uuid value, which is the server_uuid value from the master. The master_uuid value is unsupported on the older master, and in such a replication situation could become invalid on the newer slave. A check for empty master_uuid now ensures that the slave uses an empty value for master_uuid. (Bug #18338203)
  • Incompatible Change: mysql_install_db has been rewritten from Perl into C++. This enables it to be provided as an executable binary and eliminates its dependency on having Perl installed.
  • MySQL builds on Windows using Visual Studio now require Visual Studio 2013 or later. The previous requirement was Visual Studio 2010 or later. (Bug #18404381)
  • Now, MYSQL_MAINTAINER_MODE is on by default when compiling debug builds with GCC, and MYSQL_MAINTAINER_MODE enbles -Werror regardless of whether GCC or Clang is used.
  • MySQL now includes DTrace support on Oracle Linux 6 or higher with UEK kernel. If DTrace is present, server builds will detect it with no special CMake options required.
  • Incompatible Change: A new log record type (MLOG_FILE_NAME) is used to identify file-per-table tablespaces that have been modified since the last checkpoint. This enhancement simplifies tablespace discovery during crash recovery and eliminates scans on the file system prior to redo log application. For more information about the benefits of this enhancement, see Tablespace Discovery During Crash Recovery. This enhancement changes the redo log format, requiring that MySQL be shut down cleanly before upgrading to or downgrading from MySQL 5.7.5.
  • Incompatible Change: The InnoDB storage engine can no longer be disabled. The –skip-innodb option is deprecated and has no effect, and its use results in a warning. It will be removed in a future MySQL release. This also applies to its synonyms (–innodb=OFF, –disable-innodb, and so forth). A new innodb_lock_no_retry flag for the –debug option is now available.
  • Incompatible Change: The Performance Schema now provides a user_variables_by_thread table that exposes user-defined variables. For more information, see Performance Schema Connection Attribute Tables. In consequence of this change, the server now limits user-defined variable names to a maximum of 64 characters, the length of the VARIABLE_NAME column in the table. Previously, the server did not enforce a limit.
  • The optimizer computes more accurate costs for semi-join materialization. (Bug #18558561)
  • To generate execution plans, the optimizer uses a cost model that is based on estimates of the cost of various operations that occur during query execution. The optimizer has a set of compiled-in default “cost constants” available to it to make decisions regarding execution plans. The optimizer now has in addition a database of cost estimates to use during execution plan construction. These estimates are stored in the server_cost and engine_cost tables in the mysql system database and are configurable at any time: Any non-NULL cost estimate stored in the cost model tables overrides the corresponding compiled-in default estimate. Any NULL estimate indicates to the optimizer to use the compiled-in default. Implementation and testing is ongoing to make it safe for DBAs to change these values. Currently, changing them should be considered at your own risk. If you upgrade to this release of MySQL from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate these changes into the mysql database.
  • The optimizer now uses more exact index statistics. Currently, the improved values are used by InnoDB, with these effects: 1) In many cases, better execution plans result for queries for which previously a less optimal join index or table join order was chosen. 2) The row estimates in EXPLAIN output are more accurate, as well as the filter values in some cases. 3) Cardinality estimates in the index statistics displayed by SHOW INDEX are more accurate for InnoDB tables.
  • During query execution plan construction, the optimizer now uses condition filtering to make better use of all conditions on a table in determining the estimate of qualifying rows that will be joined to the next table. For example, even though there might be an index that can be used to select rows, there might also be additional conditions in the WHERE clause that can further restrict the estimate for qualifying rows. Use of additional conditions is controlled by the condition_fanout_filter flag of the optimizer_switch system variable. This flag is on by default but can be disabled to suppress use of condition filtering (for example, for a query that is found to perform better without it).
  • Security Note: Incompatible Change: MySQL 5.6 deprecated passwords that used the older pre-4.1 password hashing format. Support for these passwords is now removed, which involves the following changes. Applications that use any feature no longer supported must be modified. The mysql_old_password authentication plugin is removed. The –secure-auth option to the server and client programs is the default, but is now a no-op. It is deprecated and will be removed in a future MySQL release. The –skip-secure-auth option to the server and client programs is no longer supported and using it produces an error.
  • Incompatible Change: Strict SQL mode for transactional storage engines (STRICT_TRANS_TABLES) is now enabled by default.
  • InnoDB: SPATIAL indexes can now be used for InnoDB tables. InnoDB supports indexing of spatial data types, including use of ALTER TABLE … ALGORITHM=INPLACE for online operations (ADD SPATIAL INDEX). To support transaction isolation properties, InnoDB uses predicate locking. A predicate lock locks the minimum bounding rectangle (MBR) used for a query so that other transactions cannot insert or modify a row that would match the query condition.
  • Incompatible Change: Previously, mysql_upgrade performed an upgrade by invoking the mysql and mysqlcheck clients. mysql_upgrade has been reimplemented to generate the required SQL statements itself and execute them by communicating directly with server.
  • Incompatible Change: In MySQL 5.6.6, the YEAR(2) data type was deprecated. Support for YEAR(2) has now been removed. Once you upgrade to MySQL 5.7.5 or newer, any remaining YEAR(2) columns must be converted to YEAR(4) to become usable again. For conversion strategies, see YEAR(2) Limitations and Migrating to YEAR(4). For example, run mysql_upgrade after upgrading.
  • Incompatible Change: The GET_LOCK() has been reimplemented using the metadata locking (MDL) subsystem and its capabilities have been extended.
  • InnoDB: For optimal shutdown and recovery performance, shutdown and recovery phases are now supported by the multi-threaded page cleaner feature (innodb_page_cleaners) that was introduced in MySQL 5.7.4. (Bug #18805275)
  • InnoDB: Instead of inserting one index record at a time, InnoDB now performs a bulk load when creating or rebuilding indexes. This method of index creation is also known as a “sorted index build”. This enhancement, which improves the efficiency of index creation, also applies to full-text indexes.
  • InnoDB: InnoDB memory allocations now are instrumented for the Performance Schema and will appear in the memory summary tables.
  • InnoDB: You can now truncate undo logs that reside in undo tablespaces. This feature is enabled using the innodb_undo_log_truncate configuration option. For more information, see Truncating Undo Logs That Reside in Undo Tablespaces.
  • InnoDB: Work was done to introduce the notion of attachable transactions in InnoDB (for AutoCommit / ReadOnly / ReadCommitted / NonLocking transactions). This is used to read from InnoDB Data Dictionary tables. Along with this, attachable transactions were exposed to the server. Data Dictionary access code will use them to read Data Dictionary data.
  • Replication: Retrying of transactions is now supported when multi-threading is enabled on a slave. In previous versions, slave_transaction_retries was treated as equal to 0 when using multi-threaded slaves. (Bug #16390504, Bug #68465)
  • Replication: Global transaction identifiers (GTIDs) are now logged in a MySQL system table whenever they are enabled on the server, which lifts a previous requirement to use binary logging when replicating with GTIDs. If binary logging is disabled, the server stores the GTID for each transaction in the mysql.gtid_executed table as the transaction is executed. If binary logging is enabled, then, whenever the binary log is rotated or the server is shut down, the server also writes into the new binary log the GTIDs for all transactions from the previous binary log.
  • Replication: The new variable simplified_binlog_gtid_recovery can be used to change the way binary log files are searched for previous GTIDs during recovery, speeding up the process when a large number of binary log files exist. (Bug #69097, Bug #16741603, Bug #74071, Bug #19686914)
  • Replication: Multi-threaded slaves can use the new slave_preserve_commit_order variable to ensure that the order which transactions were committed on the master is preserved on the slave. This prevents the slave from entering a state that the master was not in and is well suited to using multi-threaded slaves for replication read scale-out.
  • Replication: The new options binlog_group_commit_sync_delay and binlog_group_commit_sync_no_delay_count provide a way to configure the synchronization of the binary log. This enables more transactions to be synchronized together to disk at once, reducing the overall time to commit a group of transactions because the larger groups require fewer time units per group.
  • Replication: To make monitoring of a replication setup easier, various replication related variables have been moved to the performance_schema tables. This is particularly helpful for monitoring multi-source replication.
  • The mysqladmin flush-logs command now permits optional log types to be given, to specify which logs to flush. Following the flush-logs command, you can provide a space-separated list of one or more of the following log types: binary, engine, error, general, relay, slow. These correspond to the log types that can be specified for the FLUSH LOGS SQL statement. Thanks to Daniël van Eeden for the patch. (Bug #60878, Bug #12368203)
  • Scalability for InnoDB tables was improved by avoiding THR_LOCK locks. As a result of this change, DML statements for InnoDB tables that previously waited for a THR_LOCK lock will wait for a metadata lock. (Bug #42147, Bug #11751331)
  • The Boost.Geometry library now is required to build MySQL.

And that pretty much just covers the highlights of the “Functionality Added or Changed” section. I’m not even getting into the “Bugs Fixed” section, of which there were 296 (many InnoDB & Replication)! So there has been a lot going on in this release. If you’re running some 5.7 version, then you should definitely upgrade. (But this should not be used for production systems yet, of course.)

You can view the full 5.7.5 changelogs here:

http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-5.html

Hope this helps.

 


Period Panties by Period Panteez Menstrual Underwear Menstruation PMS Panty