MariaDB 10.4.6 發布了,MariaDB 10.4.6 是一個 GA 穩定版。MariaDB主要由開源社區在維護,採用 GPL 授權許可。
發布日期: 2019.06.18
MariaDB 10.4 是 MariaDB 10.3 的演進版,帶來了幾個全新功能,並且具有 MySQL 的後端和重新實現的功能。
COMPLEMENTARY_FOR_QUERIES
and PREFERABLY_FOR_QUERIES
(MDEV-17255)ANALYZE
will use the whole table), but one can also set analyze to only use a sample of table data to collect the statistics.optimize_join_buffer_size
now defaults to on
(MDEV-17903)rowid_filter
and condition_pushdown_from_having
CAST
target — CAST(x AS INTERVAL DAY_SECOND(N))
(MDEV-17776)IF NOT EXISTS
clause added to INSTALL PLUGIN and IF EXISTS
clause added to UNINSTALL PLUGIN and UNINSTALL SONAME (MDEV-16294)For a list of all new variables, see System Variables Added in MariaDB 10.4 and Status Variables Added in MariaDB 10.4.
TIME_ROUND_FRACTIONAL
(MDEV-16991)200
(previously 0
) (MDEV-18551)ON
(MDEV-18439)Galera 4 version 26.4.0 has been added to MariaDB 10.4
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:
wsrep_provider=none
mysql_upgrade
for the serverAfter 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.
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 bytesrows
: number of rows affected by the transactionstatements
: number of SQL statements executed in the multi-statement transactionwsrep_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.
LOAD DATA
execution will conflict with streaming replication, and should not be used if streaming replication is configuredSELECT 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 所做更改的完整列表,請參閱更新日誌。
[admin
]