未加星标

MySQL InnoDB Cluster What’s new in the 8.0.13 (GA) release

字体大小 | |
[数据库(综合) 所属分类 数据库(综合) | 发布者 店小二04 | 时间 2018 | 作者 红领巾 ] 0人收藏点击收藏

The mysql Development Team is very happy to announce the second 8.0 Maintenance Release of InnoDB Cluster!

In addition to bug fixes, 8.0.13 brings some new exciting features:

Defining the next primary instance “in line” Defining the behavior of a server whenever it drops out of the cluster Improved command line integration for DevOps type usage

Here are the highlights of this release!

MySQL Shell

For this release, we have focused on extending the AdminAPI to support and make use of new Group Replication features, but also to improve the Shell itself in regards to DevOps usage. On top of that, many bug fixes were addressed.

Define the next primary instance “in line”

A default cluster setup runs in single-primary mode, i.e. the cluster has a single-primary server that accepts read and writequeries (R/W). All the remaining members accept only read queries (R/O).

Upon a failure of the primary member, an automatic primary election mechanism takes place and chooses a new primary. This mechanism decides which of the members shall become the new primary by picking the one with the lowest value of server UUID .

Up to now, it was impossible to control the outcome of the primary election algorithm in single-primary mode. However, that’s a very desired functionality in production environments… Many scenarios would benefitor even require, the ability to choose which shall be the next elected primary.

For example, a DBA should be able to decide beforehand which shall be the primary whenever a planned maintenance operation on the current primary happens. Also, if a cluster is deployed in different data centers, the DBAs should be able to ensure that a specific set of servers have precedence over other in the election process thus ensuring that primaries are always in a particular data center. Last but not least, it’s common that primaries benefit from being run in machines with higher capacities thereby it is an asset to ensure which members shall be elected as primaries in the event of failures.

Summarizing, there are two important user stories regarding the primary election:

As a DBA, I want to be able to define which member of a cluster shall be elected as next primary. As a DBA, I want to be able to define the order of priorities for the election of new primaries of a cluster, based on a numeric value.

In 8.0.13, we have introduced an option that allows influencing the primary election by providing a member weight value for each cluster member. The member with the highest weight value is elected as the new primary.

In order to support this feature, the following AdminAPI commands have been extended with a new option memberWeight that allows setting the weight value for the target instance:

dba.createCluster() <Cluster.>addInstance()
MySQL InnoDB Cluster   What’s new in the 8.0.13 (GA) release

MySQL InnoDB Cluster   What’s new in the 8.0.13 (GA) release

MySQL InnoDB Cluster   What’s new in the 8.0.13 (GA) release
MySQL InnoDB Cluster   What’s new in the 8.0.13 (GA) release

Note: When the primary election takes place, if multiple servers have the same memberWeight value, the servers are then prioritized based on their server UUID in lexicographical order (the lowest) and by picking the first one.

Define the behavior of a server whenever it drops out of the cluster

The default behavior when a server leaves a cluster unintentionally, i.e. not manually removed by the user (DBA), is to switch itself automatically to super-read-only mode.

The reason for such behavior relies on the premise that an instance that left a cluster shall not receive any updates, thus safeness is improved.

However, even though updates to servers that left a cluster are blocked, reads are not, thereby the chance of stale-reads increases. Also, if an instance gets stuck on a minority partition, it will still be readable, thus allowing stale reads as well.

To minimize the possibility of stale reads, Group Replication has introduced an option to allow defining what should be the behavior when an instance leaves a cluster unintentionally. Apart from the behavior on which the instance sets itself to super-read-only, a new one was added that makes the instance to automatically shut itself down on that event.

Summarizing, the user stories for this new feature are:

As a DBA, I want to be able to define if an instance should automatically set itself to super-read-only when it involuntarily leaves a cluster. As a DBA, I want to be able to define if an instance should automatically shutdown when it involuntarily leaves a cluster.

In order to support this feature, the following AdminAPI commands have been extended with a new option exitStateAction that allows defining the behavior of a server whenever it drops the cluster unintentionally:

dba.createCluster() <Cluster.>addInstance()
MySQL InnoDB Cluster   What’s new in the 8.0.13 (GA) release

MySQL InnoDB Cluster   What’s new in the 8.0.13 (GA) release

MySQL InnoDB Cluster   What’s new in the 8.0.13 (GA) release
Improved command line integration for DevOps type usage

MySQL Shell is an interactive javascript, python, and SQL command-line client supporting development and administration for the MySQL Server and InnoDB clusters. The Shell provides a natural interface for all ‘development and operations’ (DevOps) tasks related to MySQL, by supporting scripting with development and administration APIs.

However, apart from being a command-line client, the Shell is also a console interface.

Until now, the support for using the shell as a console interface was quite limited since its usage was confined to the batch script execution via cmdline with the --execute(-e) option.

For example, to create a cluster via cmdline, the DBA would call the shell as follows:

$ mysqlsh myAdmin@localhost:3306 -e "dba.createCluster('testCluster', {memberWeight: 65, exitStateAction: 'READ_ONLY'});"

This is neither acceptable nor a norm of general usage of a console interface. Plus, complex quoting patterns will certainly become troublesome.

In 8.0.13, we have introduced a general purpose command line handling mechanism which can be used to invoke built-in shell commands, with arbitrary parameters, in a syntax that requires minimal extra typing, quoting and escaping.

Creating a cluster via cmdline, can now be done as follows:

$ mysqlsh myAdmin@localhost:3306 -- dba create-cluster testCluster --member-weight=65 --exit-state-action=READ_ONLY

Stay tuned for a new blog post coming soon covering all the details of the API Command Line Integration for DevOps !

MySQL Router Source code moved to mysql-server repo

A lot of work went into moving the source-code of MySQL Router into the MySQL Server’s source-tree

As a result of this change:

package names are more aligned, MySQL Router is always released in sync with MySQL Server, code between both products can be

本文数据库(综合)相关术语:系统安全软件

代码区博客精选文章
分页:12
转载请注明
本文标题:MySQL InnoDB Cluster What’s new in the 8.0.13 (GA) release
本站链接:https://www.codesec.net/view/621018.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(综合) | 评论(0) | 阅读(61)