设为首页收藏本站

LUPA开源社区

 找回密码
 注册
文章 帖子 博客
LUPA开源社区 首页 业界资讯 软件追踪 查看内容

MariaDB 10.4首个GA版本10.4.6发布,带来多项更新

2019-6-19 09:46| 发布者: joejoe0332| 查看: 286| 评论: 0|原作者: oschina|来自: oschina

摘要: MariaDB 10.4.6 发布了,MariaDB 10.4.6是一个 GA 稳定版。MariaDB主要由开源社区在维护,采用 GPL 授权许可。 发布日期:2019.06.18 MariaDB 10.4 是 MariaDB 10.3 的演进版,带来了几个全新功能,并且具有 MySQL 的 ...

MariaDB 10.4.6 发布了,MariaDB 10.4.6 是一个 GA 稳定版。MariaDB主要由开源社区在维护,采用 GPL 授权许可。

发布日期: 2019.06.18

MariaDB 10.4 是 MariaDB 10.3 的演进版,带来了几个全新功能,并且具有 MySQL 的后端和重新实现的功能。

Authentication

InnoDB

Optimizer

Syntax

Variables

For a list of all new variables, see System Variables Added in MariaDB 10.4 and Status Variables Added in MariaDB 10.4.

Galera

Galera 4 version 26.4.0 has been added to MariaDB 10.4

Upgrading to Galera 4 version 26.4.0

Rolling upgrades from earlier 10.3 (or older) MariaDB releases are not supported in this release. For upgrading a 10.3-based cluster, any applications accessing the cluster should be stopped and the cluster shut down. Then for each cluster node the following procedure should be carried out:

  • Install MariaDB 10.4.2 and Galera 4 version 26.4.0
  • Start MariaDB server, but make sure it is not trying to connect to the cluster by configuring wsrep_provider=none
  • While MariaDB server is running, run mysql_upgrade for the server
  • Stop MariaDB server

After that, you can bootstrap the cluster. If there was ongoing application load on the cluster during the initial cluster shutdown phase, you should make sure to bootstrap the cluster with the node which was shutdown last.

We are working on rolling upgrade support for the final GA version of MariaDB 10.4. With a rolling upgrade, a live cluster can be upgraded node by node, and the cluster is able to process application load when having a hybrid setup of 10.3 and 10.4 nodes.

New Features in Galera 26.4.0

The ‘mysql’ schema contains new Galera replication related tables:

  • wsrep_cluster
  • wsrep_cluster_members
  • wsrep_streaming_log

End users may read but not modify these tables.

The new streaming replication feature allows replicating transactions of unlimited size. With streaming replication, a cluster is replicating a transaction in small fragments during transaction execution. This transaction fragmenting is controlled by two new configuration variables:

  • wsrep_trx_fragment_unit (bytes, rows, statements) defines the metrics for how to measure transaction size limit for fragmenting. Possible values are:
    • bytes: transaction’s binlog events buffer size in bytes
    • rows: number of rows affected by the transaction
    • statements: number of SQL statements executed in the multi-statement transaction
  • wsrep_trx_fragment_size defines the limit for fragmenting. When a transaction’s size, in terms of the configured fragment unit, has grown over this limit, a new fragment will be replicated.

Transactions replicated through galera replication will now process the commit phase using MariaDB's group commit logic. This will affect transaction throughput, especially when binary logging is enabled in the cluster.

Limitations in Galera 26.4.0

  • Upgrading from 10.3 version 25.3.25 to 10.4 version 26.4.0 must happen on a stopped cluster. Only after all nodes have been upgraded to MariaDB 10.4 and Galera 26.4.0 can the cluster be started up
  • Splitting transactions of LOAD DATA execution will conflict with streaming replication, and should not be used if streaming replication is configured

General

  • Crash safe Aria-based system tables (MDEV-16421)
  • Added Linux abstract socket support (MDEV-15655)
  • Enabled C++11 (MDEV-16410)
  • Performance improvements in Unicode collations (MDEV-17534MDEV-17511MDEV-17502MDEV-17474)
  • User data type plugins (MDEV-4912, in progress)
  • Improvements with SQL standard INTERVAL support to help functions TIMESTAMP() and ADDTIME() return more predictable results.
    • Historically, MariaDB uses the TIME data type for both "time of the day" values and "duration" values. In the first meaning the natural value range is from '00:00:00' to '23:59:59.999999', in the second meaning the range is from '-838:59:59.999999' to '+838:59:59.999999'.
    • To remove this ambiguity and for the SQL standard conformance we plan to introduce a dedicated data type INTERVAL that will be able to store values in the range at least from '-87649415:59:59.999999' to '+87649415:59:59.999999', which will be enough to represent the time difference between TIMESTAMP'0001-01-01 00:00:00' and TIMESTAMP'9999-12-31 23:59:59.999999'.
    • As a first step we support this range of values for intermediate calculations when TIME-alike string and numeric values are used in INTERVAL (i.e. duration) context, e.g. as the second argument of SQL functions TIMESTAMP(ts,interval) and ADDTIME(ts,interval), so the following can now be calculated:
SELECT ADDTIME(TIMESTAMP'0001-01-01 00:00:00', '87649415:59:59.999999');
-> '9999-12-31 23:59:59.999999'  

SELECT TIMESTAMP(DATE'0001-01-01', '87649415:59:59.999999')
-> '9999-12-31 23:59:59.999999'  

SELECT ADDTIME(TIME'-838:59:59.999999', '1677:59:59.999998');
-> '838:59:59.999999'  

有关 MariaDB 10.4.6 所做更改的完整列表,请参阅更新日志


酷毙

雷人

鲜花

鸡蛋

漂亮
  • 快毕业了,没工作经验,
    找份工作好难啊?
    赶紧去人才芯片公司磨练吧!!

最新评论

关于LUPA|人才芯片工程|人才招聘|LUPA认证|LUPA教育|LUPA开源社区 ( 浙B2-20090187 浙公网安备 33010602006705号   

返回顶部