Dear MySQL Users,
MySQL Cluster is the distributed database combining massive
scalability and high availability. It provides in-memory
real-time access with transactional consistency across
partitioned and distributed datasets. It is designed for
mission critical applications.
MySQL Cluster has replication between clusters across multiple
geographical sites built-in. A shared nothing architecture with
data locality awareness make it the perfect choice for running
on commodity hardware and in globally distributed cloud
infrastructure.
This storage engine provides:
- In-Memory storage - Real-time performance (with optional
checkpointing to disk)
- Transparent Auto-Sharding - Read & write scalability
- Active-Active/Multi-Master geographic replication
- Transactional consistency across partitioned and distributed datasets
- Parallel cross partition queries such as joins
- 99.9999% High Availability with no single point of failure
and on-line maintenance
- NoSQL and SQL APIs (including C++, Java, http, Memcached
and JavaScript/Node.js)
MySQL Cluster 8.0.16-dmr has been released and can be downloaded from
http://www.mysql.com/downloads/cluster/
where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.
The release notes are available from
http://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/index.html
MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.
More details can be found at
http://www.mysql.com/products/cluster/
Enjoy !
Changes in MySQL NDB Cluster 8.0.16 (2019-04-25, Development Milestone)
MySQL NDB Cluster 8.0.16 is a new development release of NDB
8.0, based on MySQL Server 8.0 and including features in
version 8.0 of the NDB storage engine, as well as fixing
recently discovered bugs in previous NDB Cluster releases.
Obtaining NDB Cluster 8.0. NDB Cluster 8.0 source code and
binaries can be obtained from
https://dev.mysql.com/downloads/cluster/.
For an overview of changes made in NDB Cluster 8.0, see What
is New in NDB Cluster
(http://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-what-is-new.html).
This release also incorporates all bug fixes and changes made
in previous NDB Cluster releases, as well as all bug fixes
and feature changes which were added in mainline MySQL 8.0
through MySQL 8.0.16 (see Changes in MySQL 8.0.16 (2019-04-25,
General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-16.html)).
* Deprecation and Removal Notes
* SQL Syntax Notes
* Functionality Added or Changed
* Bugs Fixed
Deprecation and Removal Notes
* Incompatible Change: Distribution of privileges amongst
MySQL servers connected to NDB Cluster, as implemented in
NDB 7.6 and earlier, does not function in NDB 8.0, and
most code supporting these has now been removed. When a
mysqld detects such tables in NDB, it creates shadow
tables local to itself using the InnoDB storage engine;
these shadow tables are created on each MySQL server
connected to an NDB cluster. Privilege tables using the
NDB storage engine are not employed for access control;
once all connected MySQL servers are upgraded, the
privilege tables in NDB can be removed safely using
ndb_drop_table.
For compatibility reasons, ndb_restore
--restore-privilege-tables can still be used to restore
distributed privilege tables present in a backup taken
from a previous release of NDB Cluster to a cluster
running NDB 8.0. These tables are handled as described in
the preceeding paragraph.
For additional information regarding upgrades from
previous NDB Cluster release series to NDB 8.0, see
Upgrading and Downgrading NDB Cluster
(http://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-upgrade-downgrade.html).
SQL Syntax Notes
* Incompatible Change: For consistency with InnoDB, the NDB
storage engine now uses a generated constraint name if
the CONSTRAINT symbol clause is not specified, or the
CONSTRAINT keyword is specified without a symbol. In
previous NDB releases, NDB used the FOREIGN KEY
index_name value.
This change described above may introduce
incompatibilities for applications that depend on the
previous foreign key constraint naming behavior. (Bug
#29173134)
Functionality Added or Changed
* Allocation of resources in the transaction corrdinator
(see The DBTC Block
(http://dev.mysql.com/doc/ndb-internals/en/ndb-internals-kernel-blocks-dbtc.html))
is now performed using dynamic memory pools. This means
that resource allocation determined by data node
configuration parameters such as those discussed in
Transaction parameters
(http://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbd-definition.html#mysql-cluster-transaction-parameters)
and Transaction temporary storage
(http://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbd-definition.html#mysql-cluster-transaction-temporary-storage)
is now limited so as not to exceed the total
resources available to the transaction coordinator.
As part of this work, several new data node parameters
controlling transactional resources in DBTC, listed here,
have also been added. For more information about these
new parameters, see Transaction resource allocation
parameters
(http://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbd-definition.html#mysql-cluster-transaction-resource-allocation).
(Bug #29164271, Bug #29194843)
References: See also: Bug #29131828.
* NDB backups can now be performed in a parallel fashion on
individual data nodes using multiple local data managers
(LDMs). (Previously, backups were done in parallel across
data nodes, but were always serial within data node
processes.) No special syntax is required for the START
BACKUP command in the ndb_mgm client to enable this
feature, but all data nodes must be using multiple LDMs.
This means that data nodes must be running ndbmtd and
they must be configured to use multiple LDMs prior to
taking the backup (see Multi-Threading Configuration
Parameters (ndbmtd)
(http://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbd-definition.html#mysql-cluster-ndbd-definition-ndbmtd-parameters)).
ndb_restore also now detects such a backup and
automatically attempts to restore it in parallel. It is
also possible to restore backups taken in parallel to a
previous version of NDB Cluster by slightly modifying the
usual restore procedure.
For more information about taking and restoring NDB
Cluster backups that were created using parallelism on
the data nodes, see Taking an NDB with Parallel Data
Nodes
(http://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-backup-parallel-data-nodes.html),
and Restoring from a backup taken in parallel
(http://dev.mysql.com/doc/refman/8.0/en/ndb-restore-parallel-data-node-backup.html).
(Bug #28563639, Bug #28993400)
* The compile-cluster script included in the NDB source
distribution no longer supports in-source builds.
* Building with CMake3 is now supported by the
compile-cluster script included in the NDB source
distribution.
* NDB now implements a metadata change monitor thread for
detecting changes made to metadata for data objects such
as tables, tablespaces, and log file groups with the
MySQL data dictionary. This thread runs in the
background, checking every 60 seconds for inconsistencies
between the NDB dictionary and the MySQL data dictionary.
The monitor polling interval can be adjusted by setting
the value of the ndb_metadata_check_interval system
variable, and can be disabled altogether by setting
ndb_metadata_check to OFF. The number of times that
inconsistencies have been detected since mysqld was last
started is shown as the status variable,
Ndb_metadata_detected_count.
* Condition pushdown is no longer limited to predicate
terms referring to column values from the same table to
which the condition was being pushed; column values from
tables earlier in the query plan can now also be referred
to from pushed conditions. This lets the data nodes
filter out more rows (in parallel), leaving less work to
be performed by a single mysqld process, which is
expected to provide significant improvements in query
performance.
For more information, see Engine Condition Pushdown
Optimization
(http://dev.mysql.com/doc/refman/8.0/en/condition-pushdown-optimization.html).
Bugs Fixed
* Important Change; NDB Disk Data: mysqldump terminated
unexpectedly when attempting to dump NDB disk data
tables. The underlying reason for this was that mysqldump
expected to find information relating to undo log buffers
in the EXTRA column of the INFORMATION_SCHEMA.FILES table
but this information had been removed in NDB 8.0.13. This
information is now restored to the EXTRA column. (Bug
#28800252)
* Important Change: When restoring to a cluster using data
node IDs different from those in the original cluster,
ndb_restore tried to open files corresponding to node ID
0. To keep this from happening, the --nodeid and
--backupid options---neither of which has a default
value---are both now explicitly required when invoking
ndb_restore. (Bug #28813708)
* Important Change: Starting with this release, the default
value of the ndb_log_bin system variable is now FALSE.
(Bug #27135706)
* Packaging; MySQL NDB ClusterJ: libndbclient was missing
from builds on some platforms. (Bug #28997603)
* NDB Disk Data: When a log file group had more than 18
undo logs, it was not possible to restart the cluster.
(Bug #251155785)
References: See also: Bug #28922609.
* NDB Disk Data: Concurrent CREATE TABLE statements using
tablespaces caused deadlocks between metadata locks. This
occurred when Ndb_metadata_change_monitor acquired
exclusive metadata locks on tablespaces and logfile
groups after detecting metadata changes, due to the fact
that each exclusive metadata lock in turn acquired a
global schema lock. This fix attempts to solve that issue
by downgrading the locks taken by
Ndb_metadata_change_monitor to MDL_SHARED_READ. (Bug
#29175268)
References: See also: Bug #29394407.
* NDB Disk Data: The error message returned when validation
of MaxNoOfOpenFiles in relation to InitialNoOfOpenFiles
failed has been improved to make the nature of the
problem clearer to users. (Bug #28943749)
* NDB Disk Data: Schema distribution of ALTER TABLESPACE
and ALTER LOGFILE GROUP statements failed on a
participant MySQL server if the referenced tablespace or
log file group did not exist in its data dictionary. Now
in such cases, the effects of the statement are
distributed successfully regardless of any initial
mismatch between MySQL servers. (Bug #28866336)
* NDB Disk Data: Repeated execution of ALTER TABLESPACE ...
ADD DATAFILE against the same tablespace caused data
nodes to hang and left them, after being killed manually,
unable to restart. (Bug #22605467)
* NDB Replication: A DROP DATABASE operation involving
certain very large tables could lead to an unplanned
shutdown of the cluster. (Bug #28855062)
* NDB Replication: When writes on the master---done in such
a way that multiple changes affecting BLOB column values
belonging to the same primary key were part of the same
epoch---were replicated to the slave, Error 1022 occurred
due to constraint violations in the NDB$BLOB_id_part
table. (Bug #28746560)
* NDB Cluster APIs: NDB now identifies short-lived
transactions not needing the reduction of lock contention
provided by NdbBlob::close() and no longer invokes this
method in cases (such as when autocommit is enabled) in
which unlocking merely causes extra work and round trips
to be performed prior to committing or aborting the
transaction. (Bug #29305592)
References: See also: Bug #49190, Bug #11757181.
* NDB Cluster APIs: When the most recently failed operation
was released, the pointer to it held by NdbTransaction
became invalid and when accessed led to failure of the
NDB API application. (Bug #29275244)
* NDB Cluster APIs: When the NDB kernel's SUMA block sends
a TE_ALTER event, it does not keep track of when all
fragments of the event are sent. When NDB receives the
event, it buffers the fragments, and processes the event
when all fragments have arrived. An issue could possibly
arise for very large table definitions, when the time
between transmission and reception could span multiple
epochs; during this time, SUMA could send a
SUB_GCP_COMPLETE_REP signal to indicate that it has sent
all data for an epoch, even though in this case that is
not entirely true since there may be fragments of a
TE_ALTER event still waiting on the data node to be sent.
Reception of the SUB_GCP_COMPLETE_REP leads to closing
the buffers for that epoch. Thus, when TE_ALTER finally
arrives, NDB assumes that it is a duplicate from an
earlier epoch, and silently discards it.
We fix the problem by making sure that the SUMA kernel
block never sends a SUB_GCP_COMPLETE_REP for any epoch in
which there are unsent fragments for a SUB_TABLE_DATA
signal.
This issue could have an impact on NDB API applications
making use of TE_ALTER events. (SQL nodes do not make any
use of TE_ALTER events and so they and applications using
them were not affected.) (Bug #28836474)
* When a pushed join executing in the DBSPJ block had to
store correlation IDs during query execution, memory for
these was allocated for the lifetime of the entire query
execution, even though these specific correlation IDs are
required only when producing the most recent batch in the
result set. Subsequent batches require additional
correlation IDs to be stored and allocated; thus, if the
query took sufficiently long to complete, this led to
exhaustion of query memory (error 20008). Now in such
cases, memory is allocated only for the lifetime of the
current result batch, and is freed and made available for
re-use following completion of the batch. (Bug #29336777)
References: See also: Bug #26995027.
* When comparing or hashing a fixed-length string that used
a NO_PAD collation, any trailing padding characters
(typically spaces) were sent to the hashing and
comparison functions such that they became significant,
even though they were not supposed to be. Now any such
trailing spaces are trimmed from a fixed-length string
whenever a NO_PAD collation is specified.
Note
Since NO_PAD collations were introduced as part of
UCA-9.0 collations in MySQL 8.0, there should be no
impact relating to this fix on upgrades to NDB 8.0 from
previous GA releases of NDB Cluster.
(Bug #29322313)
* When a NOT IN or NOT BETWEEN predicate was evaluated as a
pushed condition, NULL values were not eliminated by the
condition as specified in the SQL standard. (Bug
#29232744)
References: See also: Bug #28672214.
* Internally, NDB treats NULL as less than any other value,
and predicates of the form column < value or column <=
value are checked for possible nulls. Predicates of the
form value > column or value >= column were not checked,
which could lead to errors. Now in such cases, these
predicates are rewritten so that the column comes first,
so that they are also checked for the presence of NULL.
(Bug #29231709)
References: See also: Bug #92407, Bug #28643463.
* After folding of constants was implemented in the MySQL
Optimizer, a condition containing a DATE or DATETIME
literal could no longer be pushed down by NDB. (Bug
#29161281)
* When a join condition made a comparison between a column
of a temporal data type such as DATE or DATETIME and a
constant of the same type, the predicate was pushed if
the condition was expressed in the form column operator
constant, but not when in inverted order (as constant
inverse_operator column). (Bug #29058732)
* When processing a pushed condition, NDB did not detect
errors or warnings thrown when a literal value being
compared was outside the range of the data type it was
being compared with,and thus truncated. This could lead
to excess or missing rows in the result. (Bug #29054626)
* If an EQ_REF or REF key in the child of a pushed join
referred to any columns of a table not a member of the
pushed join, this table was not an NDB table (because its
format was of nonnative endianness), and the data type of
the column being joined on was stored in an
endian-sensitive format, then the key generated was
generated, likely resulting in the return of an (invalid)
empty join result.
Since only big endian platforms may store tables in
nonnative (little endian) formats, this issue was
expected only on such platforms, most notably SPARC, and
not on x86 platforms. (Bug #29010641)
* API and data nodes running NDB 7.6 and later could not
use an existing parsed configuration from an earlier
release series due to being overly strict with regard to
having values defined for configuration parameters new to
the later release, which placed a restriction on possible
upgrade paths. Now NDB 7.6 and later are less strict
about having all new parameters specified explicitly in
the configuration which they are served, and use
hard-coded default values in such cases. (Bug #28993400)
* NDB 7.6 SQL nodes hung when trying to connect to an NDB
8.0 cluster. (Bug #28985685)
* The schema distribution data maintained in the NDB binary
logging thread keeping track of the number of subscribers
to the NDB schema table always allocated some memory
structures for 256 data nodes regardless of the actual
number of nodes. Now NDB allocates only as many of these
structures as are actually needed. (Bug #28949523)
* Added DUMP 406 (NdbfsDumpRequests) to provide NDB file
system information to global checkpoint and local
checkpoint stall reports in the node logs. (Bug
#28922609)
* When a joined table was eliminated early as not pushable,
it could not be referred to in any subsequent join
conditions from other tables without eliminating those
conditions from consideration even if those conditions
were otherwise pushable. (Bug #28898811)
* When starting or restarting an SQL node and connecting to
a cluster where NDB was already started, NDB reported
Error 4009 Cluster Failure because it could not acquire a
global schema lock. This was because the MySQL Server as
part of initialization acquires exclusive metadata locks
in order to modify internal data structures, and the
ndbcluster plugin acquires the global schema lock. If the
connection to NDB was not yet properly set up during
mysqld initialization, mysqld received a warning from
ndbcluster when the latter failed to acquire global
schema lock, and printed it to the log file, causing an
unexpected error in the log. This is fixed by not pushing
any warnings to background threads when failure to
acquire a global schema lock occurs and pushing the NDB
error as a warning instead. (Bug #28898544)
* A race condition between the DBACC and DBLQH kernel
blocks occurred when different operations in a
transaction on the same row were concurrently being
prepared and aborted. This could result in DBTUP
attempting to prepare an operation when a preceding
operation had been aborted, which was unexpected and
could thus lead to undefined behavior including potential
data node failures. To solve this issue, DBACC and DBLQH
now check that all dependencies are still valid before
attempting to prepare an operation.
Note
This fix also supersedes a previous one made for a
related issue which was originally reported as Bug
#28500861.
(Bug #28893633)
* Where a data node was restarted after a configuration
change whose result was a decrease in the sum of
MaxNoOfTables, MaxNoOfOrderedIndexes, and
MaxNoOfUniqueHashIndexes, it sometimes failed with a
misleading error message which suggested both a temporary
error and a bug, neither of which was the case.
The failure itself is expected, being due to the fact
that there is at least one table object with an ID
greater than the (new) sum of the parameters just
mentioned, and that this table cannot be restored since
the maximum value for the ID allowed is limited by that
sum. The error message has been changed to reflect this,
and now indicates that this is a permanent error due to a
problem configuration. (Bug #28884880)
* The ndbinfo.cpustat table reported inaccurate information
regarding send threads. (Bug #28884157)
* Execution of an LCP_COMPLETE_REP signal from the master
while the LCP status was IDLE led to an assertion. (Bug
#28871889)
* NDB now provides on-the-fly .frm file translation during
discovery of tables created in versions of the software
that did not support the MySQL Data Dictionary.
Previously, such translation of tables that had old-style
metadata was supported only during schema synchronization
during MySQL server startup, but not subsequently, which
led to errors when NDB tables having old-style metadata,
created by ndb_restore and other such tools after mysqld
had been started, were accessed using SHOW CREATE TABLE
or SELECT; these tables were usable only after restarting
mysqld. With this fix, the restart is no longer required.
(Bug #28841009)
* An in-place upgrade to an NDB 8.0 release from an earlier
relase did not remove .ndb files, even though these are
no longer used in NDB 8.0. (Bug #28832816)
* Removed storage/ndb/demos and the demonstration scripts
and support files it contained from the source tree.
These were obsolete and unmaintained, and did not
function with any current version of NDB Cluster.
Also removed storage/ndb/include/newtonapi, which
included files relating to an obsolete and unmaintained
API not supported in any release of NDB Cluster, as well
as references elsewhere to these files. (Bug #28808766)
* There was no version compatibility table for NDB 8.x;
this meant that API nodes running NDB 8.0.13 or 7.6.x
could not connect to data nodes running NDB 8.0.14. This
issue manifested itself for NDB API users as a failure in
wait_until_ready(). (Bug #28776365)
References: See also: Bug #18886034, Bug #18874849.
* Issuing a STOP command in the ndb_mgm client caused
ndbmtd processes which had recently been added to the
cluster to hang in Phase 4 during shutdown. (Bug
#28772867)
* A fix for a previous issue disabled the usage of pushed
conditions for lookup type (eq_ref) operations in pushed
joins. It was thought at the time that not pushing a
lookup condition would not have any measurable impact on
performance, since only a single row could be eliminated
if the condition failed. The solution implemented at that
time did not take into account the possibility that, in a
pushed join, a lookup operation could be a parent
operation for other lookups, and even scan operations,
which meant that eliminating a single row could actually
result in an entire branch being eliminated in error.
(Bug #28728603)
References: This issue is a regression of: Bug #27397802.
* When only the management server but no data nodes were
started, RESTART ALL timed out and eventually failed.
This was because, as part of a restart, ndb_mgmd starts a
timer, sends a STOP_REQ signal to all the data nodes, and
waits for all of them to reach node state SL_CMVMI. The
issue arose becaue no STOP_REQ signals were ever sent,
and thus no data nodes reached SL_CMVMI. This meant that
the timer always expired, causing the restart to fail.
(Bug #28728485, Bug #28698831)
References: See also: Bug #11757421.
* The pushability of a condition to NDB was limited in that
all predicates joined by a logical AND within a given
condition had to be pushable to NDB in order for the
entire condition to be pushed. In some cases this
severely restricted the pushability of conditions. This
fix breaks up the condition into its components, and
evaluates the pushability of each predicate; if some of
the predicates cannot be pushed, they are returned as a
remainder condition which can be evaluated by the MySQL
server. (Bug #28728007)
* Running ANALYZE TABLE on an NDB table with an index
having longer than the supported maximum length caused
data nodes to fail. (Bug #28714864)
* It was possible in certain cases for nodes to hang during
an initial restart. (Bug #28698831)
References: See also: Bug #27622643.
* When a condition was pushed to a storage engine, it was
re-evaluated by the server, in spite of the fact that
only rows matching the pushed condition should ever be
returned to the server in such cases. (Bug #28672214)
* In some cases, one and sometimes more data nodes
underwent an unplanned shutdown while running
ndb_restore. This occurred most often, but was not always
restircted to, when restoring to a cluster having a
different number of data nodes from the cluster on which
the original backup had been taken.
The root cause of this issue was exhaustion of the pool
of SafeCounter objects, used by the DBDICT kernel block
as part of executing schema transactions, and taken from
a per-block-instance pool shared with protocols used for
NDB event setup and subscription processing. The
concurrency of event setup and subscription processing is
such that the SafeCounter pool can be exhausted; event
and subscription processing can handle pool exhaustion,
but schema transaction processing could not, which could
result in the node shutdown experienced during
restoration.
This problem is solved by giving DBDICT schema
transactions an isolated pool of reserved SafeCounters
which cannot be exhausted by concurrent NDB event
activity. (Bug #28595915)
* When a backup aborted due to buffer exhaustion,
synchronization of the signal queues prior to the
expected drop of triggers for insert, update, and delete
operations resulted in abort signals being processed
before the STOP_BACKUP phase could continue. The abort
changed the backup status to ABORT_BACKUP_ORD, which led
to an unplanned shutdown of the data node since resuming
STOP_BACKUP requires that the state be STOP_BACKUP_REQ.
Now the backup status is not set to STOP_BACKUP_REQ
(requesting the backup to continue) until after signal
queue synchronization is complete. (Bug #28563639)
* The output of ndb_config --configinfo --xml --query-all
now shows that configuration changes for the ThreadConfig
and MaxNoOfExecutionThreads data node parameters require
system initial restarts (restart="system"
initial="true"). (Bug #28494286)
* After a commit failed due to an error, mysqld shut down
unexpectedly while trying to get the name of the table
involved. This was due to an issue in the internal
function ndbcluster_print_error(). (Bug #28435082)
* API nodes should observe that a node is moving through
SL_STOPPING phases (graceful stop) and stop using the
node for new transactions, which minimizes potential
disruption in the later phases of the node shutdown
process. API nodes were only informed of node state
changes via periodic heartbeat signals, and so might not
be able to avoid interacting with the node shutting down.
This generated unnecessary failures when the heartbeat
interval was long. Now when a data node is being
gracefully stopped, all API nodes are notified directly,
allowing them to experience minimal disruption. (Bug
#28380808)
* ndb_config --diff-default failed when trying to read a
parameter whose default value was the empty string ("").
(Bug #27972537)
* ndb_restore did not restore autoincrement values
correctly when one or more staging tables were in use. As
part of this fix, we also in such cases block applying of
the SYSTAB_0 backup log, whose content continued to be
applied directly based on the table ID, which could
ovewrite the autoincrement values stored in SYSTAB_0 for
unrelated tables. (Bug #27917769, Bug #27831990)
References: See also: Bug #27832033.
* ndb_restore employed a mechanism for restoring
autoincrement values which was not atomic, and thus could
yield incorrect autoincrement values being restored when
multiple instances of ndb_restore were used in parallel.
(Bug #27832033)
References: See also: Bug #27917769, Bug #27831990.
* Executing SELECT * FROM INFORMATION_SCHEMA.TABLES caused
SQL nodes to restart in some cases. (Bug #27613173)
* An NDB table having both a foreign key on another NDB
table using ON DELETE CASCADE and one or more TEXT or
BLOB columns leaked memory. (Bug #27484882)
* When tables with BLOB columns were dropped and then
re-created with a different number of BLOB columns the
event definitions for monitoring table changes could
become inconsistent in certain error situations involving
communication errors when the expected cleanup of the
corresponding events was not performed. In particular,
when the new versions of the tables had more BLOB columns
than the original tables, some events could be missing.
(Bug #27072756)
* When query memory was exhausted in the DBSPJ kernel block
while storing correlation IDs for deferred operations,
the query was aborted with error status 20000 Query
aborted due to out of query memory. (Bug #26995027)
References: See also: Bug #86537.
* When running a cluster with 4 or more data nodes under
very high loads, data nodes could sometimes fail with
Error 899 Rowid already allocated. (Bug #25960230)
* mysqld shut down unexpectedly when a purge of the binary
log was requested before the server had completely
started, and it was thus not yet ready to delete rows
from the ndb_binlog_index table. Now when this occurs,
requests for any needed purges of the ndb_binlog_index
table are saved in a queue and held for execution when
the server has completely started. (Bug #25817834)
* MaxBufferedEpochs is used on data nodes to avoid
excessive buffering of row changes due to lagging NDB
event API subscribers; when epoch acjknowledgements from
one or more subscribers lag by this number of epochs, an
asynchronous disconnection is triggered, allowing the
data node to release the buffer space used for
subscriptions. Since this disconnection is asynchronous,
it may be the case that it has not completed before
additional new epochs are completed on the data node,
resulting in new epochs not being able to seize GCP
completion records, generating warnings such as those
shown here:
[ndbd] ERROR -- c_gcp_list.seize() failed...
...
[ndbd] WARNING -- ACK wo/ gcp record...
And leading to the following warning:
Disconnecting node %u because it has exceeded MaxBufferedEpochs
(100 > 100), epoch ....
This fix performs the following modifications:
+ Modifies the size of the GCP completion record pool
to ensure that there is always some extra headroom
to account for the asynchronous nature of the
disconnect processing previously described, thus
avoiding c_gcp_list seize failures.
+ Modifies the wording of the MaxBufferedEpochs
warning to avoid the contradictory phrase "100 >
100".
(Bug #20344149)
* Asynchronous disconnection of mysqld from the cluster
caused any subsequent attempt to start an NDB API
transaction to fail. If this occurred during a bulk
delete operation, the SQL layer called
HA::end_bulk_delete(), whose implementation by
ha_ndbcluster assumed that a transaction had been
started, and could fail if this was not the case. This
problem is fixed by checking that the transaction pointer
used by this method is set before referencing it. (Bug
#20116393)
* Removed warnings raised when compiling NDB with Clang 6.
(Bug #93634, Bug #29112560)
* When executing the redo log in debug mode it was possible
for a data node to fail when deallocating a row. (Bug
#93273, Bug #28955797)
Enjoy and thanks for the support!
On Behalf of MySQL/ORACLE RE Team
Sreedhar S
↧
MySQL Cluster 8.0.16-dmr has been released (no replies)
↧
MySQL Community Server 5.7.26 has been released (no replies)
Dear MySQL users, MySQL Server 5.7.26, a new version of the popular Open Source Database Management System, has been released. MySQL 5.7.26 is recommended for use on production systems. For an overview of what's new in MySQL 5.7, please see http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html For information on installing MySQL 5.7.26 on new servers, please see the MySQL installation documentation at http://dev.mysql.com/doc/refman/5.7/en/installing.html MySQL Server 5.7.26 is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/mysql/ MySQL Server 5.7.26 is also available from our repository for Linux platforms, go here for details: http://dev.mysql.com/downloads/repo/ Windows packages are available via the Installer for Windows or .ZIP (no-install) packages for more advanced needs. The point and click configuration wizards and all MySQL products are available in the unified Installer for Windows: http://dev.mysql.com/downloads/installer/ 5.7.26 also comes with a web installer as an alternative to the full installer. The web installer doesn't come bundled with any actual products and instead relies on download-on-demand to fetch only the products you choose to install. This makes the initial download much smaller but increases install time as the individual products will need to be downloaded. We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc.: http://bugs.mysql.com/report.php The following link lists the changes in the MySQL 5.7 since the release of MySQL 5.7.25. It may also be viewed online at http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-26.html Enjoy! ============================================================================== Changes in MySQL 5.7.26 (2019-04-25, General Availability) Beginning with MySQL 5.7.26, Oracle no longer provides binaries for SUSE 11. * Security Notes * Bugs Fixed Security Notes * The linked OpenSSL library for the MySQL Commercial Server has been updated to version 1.0.2r. Issues fixed in the new OpenSSL version are described at http://www.openssl.org/news/vulnerabilities.html. This change does not affect the Oracle-produced MySQL Community build of MySQL Server, which uses the yaSSL library instead. (Bug #28988091) Bugs Fixed * Important Note: The libevent library included with the MySQL Server was upgraded to version 2.1.8. (Bug #28207237, Bug #29041505, Bug #29055011) * InnoDB: Optimized InnoDB internal temporary tables did not support in-place UPDATE operations, which caused the number of delete-marked records to increase continuously. The large number of delete-marked records could cause longer than expected query execution times. (Bug #29207450) * InnoDB: The base column information for a generated column was not stored. (Bug #29021730) * InnoDB: Assertion code related to the innodb_flush_method O_DIRECT_NO_FSYNC setting was no longer valid due to a recent modification to that setting. Assertion code was revised. (Bug #29007731) References: See also: Bug #27309336. * InnoDB: Memory leaks discovered in the innochecksum utility were removed. (Bug #28917614, Bug #93164) * InnoDB: A DDL operation that followed a failed attempt to create an index on a virtual column resulted in an assertion failure. (Bug #28825718) * InnoDB: A Linux AIO handler function failed to check if completed I/O events succeeded. Thanks to Wei Zhao for the contribution. (Bug #27850600, Bug #90402) * InnoDB: A function called by a CREATE TABLE thread attempted to access a table object after it was freed by a background thread. Thanks to Yan Huang for the patch. (Bug #27373959, Bug #89126) * InnoDB: Two sessions concurrently executing an INSERT ... ON DUPLICATE KEY UPDATE operation generated a deadlock. During partial rollback of a tuple, another session could update it. The fix for this bug reverts fixes for Bug #11758237, Bug #17604730, and Bug #20040791. (Bug #25966845) * InnoDB: When the method used to access a joined table was const, InnoDB attempted to unlock the matching row multiple times. (Bug #20939184) * InnoDB: The INDEX_LENGTH value in INFORMATION_SCHEMA.TABLES was not updated when adding an index. (Bug #19811005) * Partitioning: An AUTO_INCREMENT key added to a partitioned table by an ALTER TABLE statement using ALGORITHM=INPLACE restarted on each partition. (Bug #92241, Bug #28573894) * Replication: If the WAIT_FOR_EXECUTED_GTID_SET() function was used with a timeout value including a fractional part (for example, 1.5), an error in the casting logic meant that the timeout was rounded down to the nearest whole second, and to zero for values less than 1 second (for example, 0.1). The casting logic has now been corrected so that the timeout value is applied as originally specified with no rounding. Thanks to Dirkjan Bussink for the contribution. (Bug #29324564, Bug #94247) * Replication: Depending on the value of group_replication_exit_state_action, the behavior of members exiting a group was not consistent. To harmonize the behavior of members exiting the group regardless of the error scenario, now when a member with group_replication_exit_state_action=READ_ONLY exits the group unintentionally, the super_read_only mode that the member had when started is restored. This makes the behavior consistent with that of a member with group_replication_exit_state_action=ABORT_SERVER. (Bug #28971639, Bug #28526591) * Replication: Whenever you use group_replication_allow_local_disjoint_gtids_join, which is deprecated, a log message is added. (Bug #28971624) * Replication: On overloaded servers there was a possibility that when a member joined the group, the VIEW_CHANGE_LOG_EVENT event which marks that point was not logged in the correct place. This could lead to errors in the data transfer to the newly joining server and data divergence. Now, the VIEW_CHANGE_LOG_EVENT event is logged in the correct place in the binary log. In addition, warnings are logged about the delay in logging the event. (Bug #28971594) * Replication: If an applier thread was stopped while it was in the process of opening a table, no error was set, which could result in a segmentation fault or assertion depending on the build type. Error handling is now correctly activated in this situation. (Bug #28864557) * Replication: With GTIDs in use on the server, the master info log on a replication slave was being synchronized every time the master skipped a transaction using the auto-skip function. The process ends with a dummy heartbeat which is sent to the slave and caused a forced flush to the log, and this could have a large cumulative impact on the write load on the slave. The same issue could occur in a circular replication topology with events that originated from the same server and were therefore ignored, which were also handled by the slave with a forced flush to the log. The slave handling code has now been changed to remove the forced flush for heartbeat events and for ignored events received through circular replication, so that the master info log is only synchronized when appropriate (for example, when a CHANGE MASTER statement is issued, or the binary log is rotated). (Bug #28815555, Bug #85158) * Replication: In a replication group configured in single-primary mode (group_replication_single_primary_mode=ON, which is the default), if severe network delays affected the group, it was possible for the primary and the secondaries to reach different decisions on a transaction, which could lead to divergence in the gtid_executed sets on the members. The issue has now been fixed. (Bug #28768550, Bug #28966455, Bug #92690) * Replication: GRANT statements that were written to the binary log were logged incorrectly in some cases, which could result in a GRANT statement that executed successfully on the master causing an error on the replication slave. (Bug #28643405, Bug #29155451, Bug #93750) * Replication: If a storage engine has the capability to log in STATEMENT format but not in ROW format, when binlog_format is set to STATEMENT, an unsafe SQL statement should be logged and a warning message should be written to the error log. However, such statements were instead not executed and an error message was written to the error log, which is the correct behavior when binlog_format is set to MIXED or ROW. The issue has now been corrected so that unsafe statements are logged with a warning as expected when binlog_format is set to STATEMENT. (Bug #28429993, Bug #73936) * Microsoft Windows: Validity testing for the named_pipe_full_access_group system variable did not account for NULL values. (Bug #29256690) * The authentication_ldap_simple plugin could enforce authentication incorrectly. (Bug #29637712) * On the Fedora 29 platform, the compat-openssl10-devel build dependency was changed to openssl-devel. (Bug #29278747) * If CMake finds a libtirpc library that is too old to work with MySQL, it tries to use Sun RPC from glibc instead. (Bug #29240701) * With the --users option, mysqlpump wrote CREATE USER and GRANT statements to the output, but too late to apply to the other objects created by the dump. Consequently, restoring the dump file created the user accounts too late to apply to other objects created by the file. mysqlpump now writes user accounts to the dump file before other objects. (Bug #29023216) * A damaged mysql.user table could cause a server exit. (Bug #28986737) * The CMake check for tirpc headers now falls back to using pkgconfig, to enable finding the headers on more Linux platforms. This requires that pkgconfig be installed. (Bug #28970313, Bug #93341, Bug #28997093) * An attempt to access a null pointer could occur during prepared statement execution. (Bug #28692136) * The Aborted_connects status variable was not incremented for unsuccessful connection attempts, if connections were managed by the thread_pool plugin. (Bug #28490126) * mysqladmin shutdown did not wait for mysqld to shut down. (Bug #28466137, Bug #91803) References: This issue is a regression of: Bug #25364806. * Repeated invocations of stored procedures which executed queries undergoing short-circuit evaluation were not always handled correctly. (Bug #28379655) * Keyring migration should require only read access to the source keyring, but failed unless the user had write access. (Bug #28339014) * If a user performing a keyring migration did not have write access to the keyring file, the migration failed but reported success in its final error log message. (Bug #28330922) * During FLUSH STATUS execution, the Performance Schema unnecessarily aggregated session status to global status, causing double counts for some status variables. (Bug #28291258, Bug #91541) * Some status variable values could temporarily increase before returning to their original value. (Bug #27839644, Bug #90351) * Executing ALTER INSTANCE ROTATE INNODB MASTER KEY and migrating keys from the keyring_file plugin to the keyring_encrypted_file plugin could make encrypted tables unusable. (Bug #27760952) * The binary file for the udf_example user-defined function was omitted from binary distributions. (Bug #26115002, Bug #29178542) * When the server was started with the --skip-name-resolve option, spurious warnings could be written to the error log about ignoring accounts with a host name part of localhost. (The accounts in fact were used and not ignored.) (Bug #23329861, Bug #81441) * Installing and uninstalling a plugin concurrently with client connection activity could cause a server exit. (Bug #22980441) * Some queries involving complex joins leaked file handles. (Bug #90902, Bug #28039829) On Behalf of MySQL Release Engineering Team, Surabhi Bhat
↧
↧
MySQL Connector/NET 8.0.16 has been released (no replies)
Dear MySQL users, MySQL Connector/NET 8.0.16 is the fourth version to support Entity Framework Core 2.1 and the sixth general availability release of MySQL Connector/NET to add support for the new X DevAPI, which enables application developers to write code that combines the strengths of the relational and document models using a modern, NoSQL-like syntax that does not assume previous experience writing traditional SQL. To learn more about how to write applications using the X DevAPI, see http://dev.mysql.com/doc/x-devapi-userguide/en/index.html. For more information about how the X DevAPI is implemented in Connector/NET, see http://dev.mysql.com/doc/dev/connector-net. NuGet packages provide functionality at a project level. To get the full set of features available in Connector/NET such as availability in the GAC, integration with Visual Studio's Entity Framework Designer and integration with MySQL for Visual Studio, installation through the MySQL Installer or the stand-alone MSI is required. Please note that the X DevAPI requires at least MySQL Server version 8.0 or higher with the X Plugin enabled. For general documentation about how to get started using MySQL as a document store, see http://dev.mysql.com/doc/refman/8.0/en/document-store.html. To download MySQL Connector/NET 8.0.16, see http://dev.mysql.com/downloads/connector/net/ Installation instructions can be found at https://dev.mysql.com/doc/connector-net/en/connector-net-installation.html Changes in MySQL Connector/NET 8.0.16 ( 2019-04-25, General Availability ) * Functionality Added or Changed * Bugs Fixed Functionality Added or Changed * Document Store: Support was added for the -> operator to be used with JSON document paths in relational statements. For example: table.Select().Where("additionalinfo->$.hobbies = 'Reading'"); (Bug #29347028) * Document Store: The performance for statements that are executed repeatedly (two or more times) is improved by using server-side prepared statements for the second and subsequent executions. This happens internally; applications need take no action and API behavior should be the same as previously. For statements that change, repreparation occurs as needed. Providing different data values or different OFFSET or LIMIT clause values does not count as a change. Instead, the new values are passed to a new invocation of the previously prepared statement. * Document Store: Connector/NET now supports the ability to send connection attributes (key-value pairs that application programs can pass to the server at connect time). Connector/NET defines a default set of attributes, which can be disabled or enabled. In addition, applications can specify attributes to be passed together with the default attributes. The default behavior is to send the default attribute set. The aggregate size of connection attribute data sent by a client is limited by the value of the performance_schema_session_connect_attrs_size server variable. The total size of the data package should be less than the value of the server variable. For X DevAPI applications, specify connection attributes as a connection-attributes parameter in a connection string. For usage information, see Options for X Protocol Only ( http://dev.mysql.com/doc/connector-net/en/connector-net-8-0-connection-options.html#connector-net-8-0-connection-options-xprotocol ). For general information about connection attributes, see Performance Schema Connection Attribute Tables ( http://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html ). * Document Store: Connector/NET now has improved support for resetting sessions in connection pools. Returning a session to the pool drops session-related objects such as temporary tables, session variables, and transactions, but the connection remains open and authenticated so that reauthentication is not required when the session is reused. * Connector/NET applications now can use certificates in PEM format to validate SSL connections in addition to the native PFX format (see Tutorial: Using SSL with Connector/NET ( http://dev.mysql.com/doc/connector-net/en/connector-net-tutorials-ssl.html )). PEM support applies to both classic MySQL protocol and X Protocol connections. Bugs Fixed * Document Store: All methods able to execute a statement were unable to execute the same statement a second time. Now, the values and binding parameters remain available after the method is executed and string parameters are no longer converted to numbers. Both changes enable a follow-on execution to reuse the previous parameters. (Bug #29249857, Bug #29304767) * An exception was generated when the MySqlDbType enumeration was given an explicit value and then passed as a parameter to the MySqlCommand.Prepare method. (Bug #28834253, Bug #92912) * Validation was added to ensure that when a column is of type TIME and the value is 00:00:00, it takes the value instead of setting NULL. (Bug #28383726, Bug #91752) On Behalf of MySQL Release Engineering Team, Surabhi Bhat
↧
MySQL Connector/C++ 8.0.16 has been released (no replies)
Dear MySQL users,
MySQL Connector/C++ 8.0.16 is a new release version of the MySQL
Connector/C++ 8.0 series.
Connector/C++ 8.0 can be used to access MySQL implementing Document
Store or in a traditional way, using SQL queries. It allows writing
both C++ and plain C applications using X DevAPI and X DevAPI for C.
It also supports the legacy API of Connector/C++ 1.1 based on JDBC4.
To learn more about how to write applications using X DevAPI, see
"X DevAPI User Guide" at
https://dev.mysql.com/doc/x-devapi-userguide/en/
See also "X DevAPI Reference" at
https://dev.mysql.com/doc/dev/connector-cpp/devapi_ref.html
and "X DevAPI for C Reference" at
https://dev.mysql.com/doc/dev/connector-cpp/xapi_ref.html
For generic information on using Connector/C++ 8.0, see
https://dev.mysql.com/doc/dev/connector-cpp/
For general documentation about how to get started using MySQL
as a document store, see
http://dev.mysql.com/doc/refman/8.0/en/document-store.html
To download MySQL Connector/C++ 8.0.16, see the "Generally Available (GA)
Releases" tab at
https://dev.mysql.com/downloads/connector/cpp/
Enjoy and thanks for the support!
On Behalf of Oracle/MySQL Release Engineering Team,
Kent Boortz
MySQL Connector/C++ 8.0.16 is a new release version of the MySQL
Connector/C++ 8.0 series.
Connector/C++ 8.0 can be used to access MySQL implementing Document
Store or in a traditional way, using SQL queries. It allows writing
both C++ and plain C applications using X DevAPI and X DevAPI for C.
It also supports the legacy API of Connector/C++ 1.1 based on JDBC4.
To learn more about how to write applications using X DevAPI, see
"X DevAPI User Guide" at
https://dev.mysql.com/doc/x-devapi-userguide/en/
See also "X DevAPI Reference" at
https://dev.mysql.com/doc/dev/connector-cpp/devapi_ref.html
and "X DevAPI for C Reference" at
https://dev.mysql.com/doc/dev/connector-cpp/xapi_ref.html
For generic information on using Connector/C++ 8.0, see
https://dev.mysql.com/doc/dev/connector-cpp/
For general documentation about how to get started using MySQL
as a document store, see
http://dev.mysql.com/doc/refman/8.0/en/document-store.html
To download MySQL Connector/C++ 8.0.16, see the "Generally Available (GA)
Releases" tab at
https://dev.mysql.com/downloads/connector/cpp/
Changes in MySQL Connector/C++ 8.0.16 (2019-04-25, General Availability)
* Character Set Support
* Compilation Notes
* Configuration Notes
* Packaging Notes
* Prepared Statement Notes
* X DevAPI Notes
* X DevAPI for C Notes
* Functionality Added or Changed
* Bugs Fixed
Character Set Support
* Connector/C++ supports all Unicode character sets for
connections to servers for MySQL 8.0.14 and higher, but
previously had Unicode support limited to the utf8
character set for servers older than MySQL 8.0.14.
Connector/C++ now supports all Unicode character sets for
older servers, including utf8mb4, utf16, utf16le, utf32,
and ucs2. (Bug #28966038)
Compilation Notes
* Thanks to Daniël van Eeden, who contributed a code change
to use the stdbool.h header file rather than a bool
typedef. (Bug #29167120, Bug #93803)
* Thanks to Daniël van Eeden, who contributed a code change
to use lib instead of lib64 on 64-bit FreeBSD.
(Bug #29167098, Bug #93801)
* Previously, for Connector/C++ applications that used the
legacy JDBC API, source files had to use this set of
#include directives:
#include <jdbc/mysql_driver.h>
#include <jdbc/mysql_connection.h>
#include <jdbc/cppconn/*.h>
Now a single #include directive suffices:
#include <mysql/jdbc.h>
Configuration Notes
* Thanks to Daniël van Eeden, who contributed a code change
to build the documentation as part of the all target if
Connector/C++ is configured with -DWITH_DOC=ON.
(Bug #29167107, Bug #93802)
* Previously, for Connector/C++ 8.0 applications that use
the legacy JDBC connector, only static linking to the
MySQL client library was supported. The
MYSQLCLIENT_STATIC_LINKING and MYSQLCLIENT_STATIC_BINDING
CMake options are now available to permit dynamic
linking. By default, MYSQLCLIENT_STATIC_LINKING is
enabled, to use static linking to the client library.
Disable this option to use dynamic linking. If
MYSQLCLIENT_STATIC_LINKING is enabled,
MYSQLCLIENT_STATIC_BINDING may also be used. If
MYSQLCLIENT_STATIC_BINDING is enabled (the default),
Connector/C++ is linked to the shared MySQL client
library. Otherwise, the shared MySQL client library is
loaded and mapped at runtime.
* Connector/C++ 8.0 configuration now requires a minimum
CMake version of 3.0.
Packaging Notes
* Connector/C++ debug packages are now available for Linux
and Windows, The packages enable symbolic debugging using
tools such as gdb on Linux and windbg on Windows, as well
as obtaining symbolic information about connector code
locations from application crash dumps. Use of the debug
packages requires that you have installed and configured
the Connector/C++ sources.
(Bug #29117059, Bug #93645, Bug #26128420, Bug #86415)
* For improved GitHub friendliness, Community Connector/C++
source distributions now include a CONTRIBUTING.md
markdown file. CONTRIBUTING.md contains guidelines
intended to be helpful to contributors.
* The Protobuf sources bundled in the Connector/C++ source
tree were updated to Protobuf 3.6.1. (Only the parts
needed for Connector/C++ are included, to reduce
compilation time.)
Prepared Statement Notes
* For X DevAPI and X DevAPI for C, performance for
statements that are executed repeatedly (two or more
times) is improved by using server-side prepared
statements for the second and subsequent executions. This
happens internally; applications need take no action and
API behavior should be the same as previously. For
statements that change, repreparation occurs as needed.
Providing different data values or different OFFSET or
LIMIT clause values does not count as a change. Instead,
the new values are passed to a new invocation of the
previously prepared statement.
X DevAPI Notes
* For X DevAPI and X DevAPI for C applications,
Connector/C++ now supports the ability to send connection
attributes (key-value pairs that application programs can
pass to the server at connect time). Connector/C++
defines a default set of attributes, which can be
disabled or enabled. In addition, applications can
specify attributes to be passed in addition to the
default attributes. The default behavior is to send the
default attribute set.
+ For X DevAPI applications, specify connection
attributes as a connection-attributes parameter in a
connection string, or by using a
SessionOption::CONNECTION_ATTRIBUTES option for the
SessionSettings constructor.
The connection-attributes parameter value must be
empty (the same as specifying true), a Boolean value
(true or false to enable or disable the default
attribute set), or a list or zero or more key=value
specifiers separated by commas (to be sent in
addition to the default attribute set). Within a
list, a missing key value evaluates as an empty
string. Examples:
"mysqlx://user@host?connection-attributes"
"mysqlx://user@host?connection-attributes=true"
"mysqlx://user@host?connection-attributes=false"
"mysqlx://user@host?connection-attributes=[attr1=val1,attr2,attr3=]"
"mysqlx://user@host?connection-attributes=[]"
The SessionOption::CONNECTION_ATTRIBUTES option
value must be a Boolean value (true or false to
enable or disable the default attribute set), or a
DbDoc or JSON string (to be sent in addition to the
default attribute set). Examples:
Session sess(..., SessionOption::CONNECTION_ATTRIBUTES, false);
Session sess(..., SessionOption::CONNECTION_ATTRIBUTES, attr_doc );
Session sess(..., SessionOption::CONNECTION_ATTRIBUTES,
R"({ "attr1": "val1", "attr2" : "val2" })"
);
+ For X DevAPI for C applications, specify connection
attributes using the OPT_CONNECTION_ATTRIBUTES()
macro for the mysqlx_session_option_set() function.
The option value must be null (to disable the
default attribute set) or a JSON string (to be sent
in addition to the default attribute set). Examples:
mysqlx_session_option_set(opts, OPT_CONNECTION_ATTRIBUTES(nullptr));
mysqlx_session_option_set(opts,
OPT_CONNECTION_ATTRIBUTES("{ \"attr1\": \"val1\", \"attr2\" : \"val2\" }")
);
Application-defined attribute names cannot begin with _
because such names are reserved for internal attributes.
If connection attributes are not specified in a valid
way, an error occurs and the connection attempt fails.
For general information about connection attributes, see
Performance Schema Connection Attribute Tables
(http://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html).
X DevAPI for C Notes
* The signatures for several X DevAPI for C functions have
been changed to enable better error information to be
returned to applications by means of a mysqlx_error_t
handle. These functions are affected:
mysqlx_client_t*
mysqlx_get_client_from_url(
const char *conn_string,
const char *client_opts,
mysqlx_error_t **error
)
mysqlx_client_t*
mysqlx_get_client_from_options(
mysqlx_session_options_t *opt,
mysqlx_error_t **error
)
mysqlx_session_t*
mysqlx_get_session(
const char *host, int port,
const char *user, const char *password,
const char *database,
mysqlx_error_t **error
)
mysqlx_session_t*
mysqlx_get_session_from_url(
const char *conn_string,
mysqlx_error_t **error
)
mysqlx_session_t*
mysqlx_get_session_from_options(
mysqlx_session_options_t *opt,
mysqlx_error_t **error
)
mysqlx_session_t *
mysqlx_get_session_from_client(
mysqlx_client_t *cli,
mysqlx_error_t **error
)
The final argument in each case is a mysqlx_error_t
handle into which Connector/C++ stores error information.
If the argument is a null pointer, Connector/C++ ignores
it. The application is responsible to free non-null
handles by passing them to mysqlx_free().
The signature for mysqlx_free() has also been changed to
accept a void * argument so that it can accept a handle
of any type. Consequently, other type-specific free
functions, such as mysqlx_free_options(), are no longer
needed and are deprecated.
The preceding modifications change the Connector/C++ API,
which has these implications:
+ The modifications change the ABI, so the ABI version
is changed from 1 to 2. This changes the connector
library names.
+ X DevAPI for C applications to be compiled against
the new API must be modified to use the new function
signatures. (X DevAPI applications should build
without change.)
+ Applications built against the old ABI will not run
with the new connector library.
+ The API change and ABI version change do not affect
the legacy JDBC interface, so library names for the
legacy JDBC connector library do not change and
legacy application need not be changed.
+ It is possible to install both the old and new
libraries. However, installers may remove the old
libraries, so they may need to be re-added manually
after installing the new libraries.
Functionality Added or Changed
* Thanks to Daniël van Eeden, who contributed documentation
for the mysqlx_column_get_collation() function and
various corrections in the developer documentation.
(Bug #29123114, Bug #93665, Bug #29115285, Bug #93640,
Bug #29122490, Bug #93663)
* Connector/C++ now has improved support for resetting
sessions in connection pools. Returning a session to the
pool drops session-related objects such as temporary
tables, session variables, and transactions, but the
connection remains open and authenticated so that
reauthentication is not required when the session is
reused.
Bugs Fixed
* Previously, for the SSL_MODE_VERIFY_IDENTITY connection
option, Connector/C++ checked whether the host name that
it used for connecting matched the Common Name value in
the certificate but not the Subject Alternative Name
value. Now, if used with OpenSSL 1.0.2 or higher,
Connector/C++ checks whether the host name matches either
the Subject Alternative Name value or the Common Name
value in the server certificate.
(Bug #28964313, Bug #93301)
* After repeated calls, mysqlx_get_session_from_client()
could hang. (Bug #28587287)
* The SessionSettings/ClientSettings iterator
implementation was incomplete. (Bug #28502574)
Enjoy and thanks for the support!
On Behalf of Oracle/MySQL Release Engineering Team,
Kent Boortz
↧
MySQL Community Server 5.6.44 has been released (no replies)
Dear MySQL users, MySQL Server 5.6.44, a new version of the popular Open Source Database Management System, has been released. MySQL 5.6.44 is recommended for use on production systems. For an overview of what's new in MySQL 5.6, please see http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html Starting with 5.6.11, Microsoft Windows packages for MySQL 5.6 are available both as a "full" installer and as a "web" installer. The full installer is significantly larger and comes bundled with the latest software releases available. This bundle makes it easy to download and configure a full server and development suite. The web installer doesn't come bundled with any actual products and instead relies on download-on-demand to fetch only the products you choose to install. This makes the initial download much smaller but increases install time as the individual products will need to be downloaded. For information on installing MySQL 5.6.44 on new servers or upgrading to MySQL 5.6.44 from previous MySQL releases, please see http://dev.mysql.com/doc/refman/5.6/en/installing.html MySQL Server 5.6.44, is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/mysql We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc: http://bugs.mysql.com/report.php The following link lists the changes in the MySQL 5.6 since the release of MySQL 5.6.43. It may also be viewed online at http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-44.html Enjoy! Changes in MySQL 5.6.44 (2019-04-25, General Availability) Beginning with MySQL 5.6.44, Oracle no longer provides binaries for SUSE 11. Security Notes * The linked OpenSSL library for the MySQL Commercial Server has been updated to version 1.0.2r. Issues fixed in the new OpenSSL version are described at http://www.openssl.org/news/vulnerabilities.html. This change does not affect the Oracle-produced MySQL Community build of MySQL Server, which uses the yaSSL library instead. (Bug #28988091) Bugs Fixed * Important Note: The libevent library included with the MySQL Server was upgraded to version 2.1.8. (Bug #28207237, Bug #29041505, Bug #29055011) * InnoDB: The INDEX_LENGTH value in INFORMATION_SCHEMA.TABLES was not updated when adding an index. (Bug #19811005) * Partitioning: An AUTO_INCREMENT key added to a partitioned table by an ALTER TABLE statement using ALGORITHM=INPLACE restarted on each partition. (Bug #92241, Bug #28573894) * Replication: If an applier thread was stopped while it was in the process of opening a table, no error was set, which could result in a segmentation fault or assertion depending on the build type. Error handling is now correctly activated in this situation. (Bug #28864557) * Replication: If a storage engine has the capability to log in STATEMENT format but not in ROW format, when binlog_format is set to STATEMENT, an unsafe SQL statement should be logged and a warning message should be written to the error log. However, such statements were instead not executed and an error message was written to the error log, which is the correct behavior when binlog_format is set to MIXED or ROW. The issue has now been corrected so that unsafe statements are logged with a warning as expected when binlog_format is set to STATEMENT. (Bug #28429993, Bug #73936) * Microsoft Windows: Validity testing for the named_pipe_full_access_group system variable did not account for NULL values. (Bug #29256690) * MySQL 5.6 did not build with maintainer mode enabled with GCC 7. (Bug #29048768) * A damaged mysql.user table could cause a server exit. (Bug #28986737) * mysqladmin shutdown did not wait for mysqld to shut down. (Bug #28466137, Bug #91803) References: This issue is a regression of: Bug #25364806. * Some status variable values could temporarily increase before returning to their original value. (Bug #27839644, Bug #90351) * The binary file for the udf_example user-defined function was omitted from binary distributions. (Bug #26115002, Bug #29178542) * Compiling the InnoDB memcached plugin did not work on some platforms where MySQL was configured using -DWITH_LIBEVENT=system, for libevent version 2.0 or higher. (Bug #80073, Bug #22573379, Bug #23567441) On Behalf of MySQL/ORACLE RE Team Gipson Pulla
↧
↧
MySQL Connector/Node.js 8.0.16 has been released (no replies)
Dear MySQL users, MySQL Connector/Node.js is a new Node.js driver for use with the X DevAPI. This release, v8.0.16, is a maintenance release of the MySQL Connector/Node.js 8.0 series. The X DevAPI enables application developers to write code that combines the strengths of the relational and document models using a modern, NoSQL-like syntax that does not assume previous experience writing traditional SQL. MySQL Connector/Node.js can be downloaded through npm (see https://www.npmjs.com/package/@mysql/xdevapi for details) or from https://dev.mysql.com/downloads/connector/nodejs/. To learn more about how to write applications using the X DevAPI, see http://dev.mysql.com/doc/x-devapi-userguide/en/. For more information about how the X DevAPI is implemented in MySQL Connector/Node.js, and its usage, see http://dev.mysql.com/doc/dev/connector-nodejs/. Please note that the X DevAPI requires at least MySQL Server version 8.0 or higher with the X Plugin enabled. For general documentation about how to get started using MySQL as a document store, see http://dev.mysql.com/doc/refman/8.0/en/document-store.html. Changes in MySQL Connector/Node.js 8.0.16 (2019-04-25, General Availability) X DevAPI Notes * Connector/Node.js now supports connection attributes as key-value pairs that application programs can pass to the server. Connector/Node.js defines a default set of attributes, which can be disabled or enabled. In addition to these default attributes, applications can also provide their own set of custom attributes. + Specify connection attributes as a connection-attributes parameter in a connection string, or by using the connectionAttributes property using either a plain JavaScript object or JSON notation to specify the connection configuration options. The connection-attributes parameter value must be either empty (the same as specifying true), a Boolean value (true or false to enable or disable the default attribute set), or a list of zero or more key=value pair specifiers separated by commas (to be sent in addition to the default attribute set). Within a list, a missing key value evaluates as NULL. The connectionAttributes property allows passing user-defined attributes to the application using either a plain JavaScript object or JSON notation to specify the connection configuration options. Define each attribute in a nested object under connectionAttributes where the property names matches the attribute names, and the property values match the attribute values. Unlike connection-attributes, and while using plain JavaScript objects or JSON notation, if the connectionAttributes object contains duplicate keys then no error is thrown and the last value specified for a duplicate object key is chosen as the effective attribute value. Examples: Not sending the default client-defined attributes: mysqlx.getSession('{ "user": "root", "connectionAttributes": false }') mysqlx.getSession('mysqlx://root@localhost?connection-attributes=false ') mysqlx.getSession({ user: 'root', connectionAttributes: { foo: 'bar', baz: 'qux', quux: '' } }) mysqlx.getSession('mysqlx://root@localhost?connection-attributes=[foo= bar,baz=qux,quux]') Application-defined attribute names cannot begin with _ because such names are reserved for internal attributes. If connection attributes are not specified in a valid way, an error occurs and the connection attempt fails. For general information about connection attributes, see Performance Schema Connection Attribute Tables (http://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html). Functionality Added or Changed * Optimized the reuse of existing connections through client.getSession() by only re-authenticating if required. * For X DevAPI, performance for statements that are executed repeatedly (two or more times) is improved by using server-side prepared statements for the second and subsequent executions. This happens internally; applications need take no action and API behavior should be the same as previously. For statements that change, repreparation occurs as needed. Providing different data values or different offset() or limit() values does not count as a change. Instead, the new values are passed to a new invocation of the previously prepared statement. Bugs Fixed * Idle pooled connections to MySQL Server were not reused, and instead new connections had to be recreated. (Bug #29436892) * Executing client.close() would not close all associated connections in the connection pool. (Bug #29428477) * connectTimeout instead of maxIdleTime determined whether idle connections in the connection pool were reused rather than creating new connections. (Bug #29427271) * Released connections from the connection pool were not being reset and reused; instead new connections were being made. (Bug #29392088) * Date values in documents were converted to empty objects when inserted into a collection. (Bug #29179767, Bug #93839) * A queueTimeout value other than 0 (infinite) prevented the acquisition of old released connections from the connection pool. (Bug #29179372, Bug #93841) On Behalf of MySQL/ORACLE RE Team Gipson Pulla
↧
MySQL Connector/ODBC 8.0.16 has been released (no replies)
Dear MySQL users, MySQL Connector/ODBC 8.0.16 is a new version in the MySQL Connector/ODBC 8.0 series, the ODBC driver for the MySQL Server. The available downloads include both a Unicode driver and an ANSI driver based on the same modern codebase. Please select the driver type you need based on the type of your application - Unicode or ANSI. Server-side prepared statements are enabled by default. It is suitable for use with the latest MySQL server version 8.0. This release of the MySQL ODBC driver is conforming to the ODBC 3.8 specification. It contains implementations of key 3.8 features, including self-identification as a ODBC 3.8 driver, streaming of output parameters (supported for binary types only), and support of the SQL_ATTR_RESET_CONNECTION connection attribute (for the Unicode driver only). The release is now available in source and binary form for a number of platforms from our download pages at https://dev.mysql.com/downloads/connector/odbc/ For information on installing, please see the documentation at https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-installation.html Enjoy and thanks for the support! ================================================== Changes in MySQL Connector/ODBC 8.0.16 (2019-04-25, General Availability) Bugs Fixed * Connector/ODBC 8.0 is now built with OpenSSL 1.0.2R. Issues fixed in the new OpenSSL version are described at http://www.openssl.org/news/vulnerabilities.html. (Bug #29538143) * An exception was emitted when fetching contents of a BLOB/TEXT records after executing a statement as a server-side prepared statement with a bound parameter. The workaround is not using parameters or specifying NO_SSPS=1 in the connection string; this allows the driver to fetch the data. (Bug #29282638, Bug #29512548, Bug #28790708, Bug #93895, Bug #94545, Bug #92078) On Behalf of Oracle/MySQL Release Engineering Team, Hery Ramilison
↧
MySQL Connector/J 8.0.16 has been released (no replies)
Dear MySQL users, MySQL Connector/J Version 8.0.16 is the GA release of the 8.0 branch of MySQL Connector/J. It is suitable for use with MySQL Server versions 8.0, 5.7 and 5.6. It supports the Java Database Connectivity (JDBC) 4.2 API, and implements the X DevAPI. This release includes the following new features and changes, also described in more detail on https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-16.html As always, we recommend that you check the "CHANGES" file in the download archive to be aware of changes in behavior that might affect your application. To download MySQL Connector/J 8.0.16 GA, see the "Generally Available (GA) Releases" tab at http://dev.mysql.com/downloads/connector/j/ Enjoy! ----------------------------------------------------------------------- Changes in MySQL Connector/J 8.0.16 (2019-04-25, General Availability) Functionality Added or Changed * X DevAPI: Added BigInteger, BigDecimal, and Character as supported classes whose instances can be passed to a Table as Expression instances. Also made the error message clearer when applications try to pass instances of unsupported classes. (Bug #25650912) * X DevAPI: Connector/J now supports the ability to send connection attributes (http://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html) (key-value pairs that application programs can pass to the server at connect time) for X Protocol connections. Connector/J defines a default set of attributes (http://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html#performance-schema-connection-attributes-cj), which can be disabled or enabled. In addition, applications can specify attributes to be passed in addition to the default attributes. The default behavior is to send the default attribute set. See the description for the new configuration property xdevapi.connect-attributes for details. Note The aggregate size of connection attribute data sent by a client is limited by the value of the performance_schema_session_connect_attrs_size server variable. The total size of the data package should be less than the value of the server variable, or the attribute data will be truncated. * X DevAPI: When using X DevAPI, performance for statements that are executed repeatedly (two or more times) is improved by using server-side prepared statements for the second and subsequent executions. See Working with Prepared Statements (http://dev.mysql.com/doc/x-devapi-userguide/en/working-with-prepared-statements.html) in the X DevAPI User Guide (http://dev.mysql.com/doc/x-devapi-userguide/en/) for details. * The version number has been removed from the name of the Connector/J JAR archive within the RPM packages for Connector/J. That makes upgrading Connector/J with RPM packages easier. (Bug #29384853) * The collation utf8mb4_zh_0900_as_cs has been added to the CharsetMapping class. (Bug #29244101) * The following third-party libraries have been removed from the distribution bundles for Connector/J: + Google protobuf for Java (required for using X DevAPI and for building Connector/J from source) + C3P0 (required for building Connector/J from source) + JBoss common JDBC wrapper (required for building Connector/J from source) + Simple Logging Facade API (required for using the logging capabilities provided by the default implementation of org.slf4j.Logger.Slf4JLogger by Connector/J, and for building Connector/J from source) Users who need those libraries have to obtain them on their own. See Installing Connector/J from a Binary Distribution (http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-binary-installation.html) and Installing from Source (http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-installing-source.html) for details. Bugs Fixed * X DevAPI: The method unquoteWorkaround() has been removed from the ExprParser class, as the workaround is no longer needed, and it actually produced wrong results in some cases. (Bug #29257922) * X DevAPI: Connector/J threw an error when a JSON document contained only a field with an empty array as its value. With this fix, Connector/J now takes that as a valid JSON document. (Bug #28834959, Bug #92819) * getByte() calls failed on table columns of the BINARY data type. This was due to issues with string conversion, which has been corrected with this fix. (Bug #25650385) * X DevAPI: Any statements sent after a failed procedure call caused Connector/J to hang. This was because after the failed call, Connector/J was not aware that the result streamer had already been closed by the server. With this fix, an error is thrown when the procedure call fails, and the result streamer is nullified. (Bug #22038729) * X DevAPI: Unary negative and positive operators inside expressions were parsed wrongly as binary minus and plus operators. (Bug #21921956) * Because the SHOW PROCESSLIST (http://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) statement might cause the server to fail sometimes, Connector/J now avoids using the statement, but queries the performance scheme instead for the information it needs. (Bug #29329326) * Some unnecessary information has been removed from the Connector/J log. (Bug #29318273) * In the DatabaseMetaDataUsingInfoSchema interface, the getProcedureColumns() and getFunctionColumns() methods returned wrong results for the PRECISION column, and the getColumns() and getVersionColumns() methods returned wrong results for the COLUMN_SIZE column. The errors were due to the wrong handling of the temporal type precision by Connector/J, which has now been fixed. (Bug #29186870) * For an SSL connection, after a client disconnected from a server by calling Connection.close(), the TCP connection remained in the TIME_WAIT (http://dev.mysql.com/doc/refman/8.0/en/can-not-connect-to-server.html) state on the server side. With this fix, the connection remains in the TIME_WAIT (http://dev.mysql.com/doc/refman/8.0/en/can-not-connect-to-server.html) state on the client side instead, in most cases. (Bug #29054329, Bug #93590) * The function LoadBalancedConnectionProxy.getGlobalBlacklist() always returned an empty map, thus there was never a blacklist for load-balanced connections. (Bug #28860051, Bug #93007) * The redundant file, changelog.gz, has been removed from the Debian 9 package for Connector/J. The file repeated the contents of the CHANGES.gz file. (Bug #27786499) * Using getBytes() to retrieve TEXT data resulted in a NumberFormatException. With this fix, the proper exception (SQLDataException), is now thrown. (Bug #27784363) * A changeUser() call failed with a java.io.IOException when the configuration property enablePacketDebug was set to true for a connection. (Bug #25642021) * bindings.getBoolean() always returned false. It was due to a mishandling of data types, which has been corrected with this fix. (Bug #22931700) Enjoy and thanks for the support! On Behalf of MySQL/ORACLE RE Team Sreedhar S
↧
MySQL Shell 8.0.16 for MySQL Server 8.0 and 5.7 has been released (no replies)
Dear MySQL users, MySQL Shell 8.0.16 is a maintenance release of MySQL Shell 8.0 Series (a component of the MySQL Server). The MySQL Shell is provided under Oracle's dual-license. MySQL Shell 8.0 is highly recommended for use with MySQL Server 8.0 and 5.7. Please upgrade to MySQL Shell 8.0.16. MySQL Shell is an interactive JavaScript, Python and SQL console interface, supporting development and administration for the MySQL Server. It provides APIs implemented in JavaScript and Python that enable you to work with MySQL InnoDB cluster and use MySQL as a document store. The AdminAPI enables you to work with MySQL InnoDB cluster, providing an integrated solution for high availability and scalability using InnoDB based MySQL databases, without requiring advanced MySQL expertise. For more information about how to configure and work with MySQL InnoDB cluster see https://dev.mysql.com/doc/refman/en/mysql-innodb-cluster-userguide.html The X DevAPI enables you to create "schema-less" JSON document collections and perform Create, Update, Read, Delete (CRUD) operations on those collections from your favorite scripting language. For more information about how to use MySQL Shell and the MySQL Document Store support see https://dev.mysql.com/doc/refman/en/document-store.html For more information about the X DevAPI see https://dev.mysql.com/doc/x-devapi-userguide/en/ If you want to write applications that use the the CRUD based X DevAPI you can also use the latest MySQL Connectors for your language of choice. For more information about Connectors see https://dev.mysql.com/doc/index-connectors.html For more information on the APIs provided with MySQL Shell see https://dev.mysql.com/doc/dev/mysqlsh-api-javascript/8.0/ and https://dev.mysql.com/doc/dev/mysqlsh-api-python/8.0/ Using MySQL Shell's SQL mode you can communicate with servers using the legacy MySQL protocol. Additionally, MySQL Shell provides partial compatibility with the mysql client by supporting many of the same command line options. For full documentation on MySQL Server, MySQL Shell and related topics, see https://dev.mysql.com/doc/mysql-shell/8.0/en/ For more information about how to download MySQL Shell 8.0.16, see the "Generally Available (GA) Releases" tab at http://dev.mysql.com/downloads/shell/ We welcome and appreciate your feedback and bug reports, see http://bugs.mysql.com/ Enjoy and thanks for the support! Changes in MySQL Shell 8.0.16 (2019-04-25, General Availability) * Functionality Added or Changed * Bugs Fixed Functionality Added or Changed * Important Change: Attempting to connect to an X Protocol port, 33060 by default, using the classic MySQL protocol resulted in the following error: ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 This was because of differences in X Protocol and classic MySQL protocol clients expectations on how connections were initialized. Now, in such a situation the generated error message is ERROR 2007 (HY000): Protocol mismatch; server version = 11, client version = 10. If you encounter this error then you are probably trying to use the wrong port for the protocol your client is using. As part of this improvement the mysqlx_enable_hello_notice system variable has been added, which controls messages sent to classic MySQL protocol clients that try to connect over X Protocol. When enabled, clients which do not support X Protocol that attempt to connect to the server X Protocol port receive an error explaining they are using the wrong protocol. Set mysqlx_enable_hello_notice to false to permit clients which do not recognize the hello message to still connect. * MySQL Shell's upgrade checker utility can now check the configuration file (my.cnf or my.ini) for the server instance. The utility checks for any system variables that are defined in the configuration file but have been removed in the target MySQL Server release, and also for any system variables that are not defined in the configuration file and will have a different default value in the target MySQL Server release. For these checks, when you invoke checkForServerUpgrade(), you must provide the file path to the configuration file. If you omit the file path and the upgrade checker utility needs to run a check that requires the configuration file, that check fails with a message informing you that you must specify the file path. (Bug #27801824, Bug #29222179) * MySQL InnoDB cluster automatically and transparently manages the communication protocol versions of its members, whenever the cluster topology is changed using AdminAPI operations. An InnoDB cluster always uses the most recent communication protocol version that is supported by all instances that are part of the cluster or joining it. + When an instance is added to, removed from, or rejoins the cluster, or a rescan or reboot operation is carried out on the cluster, the communication protocol version is automatically set to a version supported by the instance that is now at the earliest MySQL Server version. + When you carry out a rolling upgrade by removing instances from the cluster, upgrading them, and adding them back into the cluster, the communication protocol version is automatically upgraded when the last remaining instance at the old MySQL Server version is removed from the cluster prior to its upgrade. To see the communication protocol version in use in an InnoDB cluster, use the Cluster.status() function with the 'extended' option enabled. The communication protocol version is returned in the 'GRProtocolVersion' field, provided that the cluster has quorum and no cluster members are unreachable. * MySQL Shell now has a framework and commands that you can use to set up and run reports to display live information from a MySQL server, such as status and performance information. Reports can be run once using the MySQL Shell \show command, or run then refreshed continuously in a MySQL Shell session using the \watch command. They can also be accessed as API functions in the shell.reports object. The reporting facility supports both built-in reports and user-defined reports. User-defined reports can be created in the supported scripting languages JavaScript and Python, and can be run in any MySQL Shell mode (JavaScript, Python, or SQL), regardless of the language that the report was written in. Reports can be saved in a folder in the MySQL Shell configuration path and automatically loaded at startup. You can also create a report directly in the MySQL Shell prompt. You register a report to MySQL Shell using the shell.registerReport method to provide information about the report and the options and arguments that it supports. For more information, see Reporting with MySQL Shell (http://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-reporting.html). * When running MySQL Shell in interactive mode, you can now execute an SQL statement without switching to SQL mode and back again afterwards. This function enables you to conveniently issue some SQL statements in the context of a longer AdminAPI workflow in JavaScript or Python mode. Use the \sql command immediately followed by the SQL statement, for example: \sql select * from sakila.actor limit 3; The SQL statement does not need any additional quoting, and the statement delimiter is optional. With this format, MySQL Shell does not switch mode as it would if you entered the \sql command. After the SQL statement has been executed, MySQL Shell remains in JavaScript or Python mode. You cannot use multiple line mode when you use the \sql command with a query to execute single SQL statements while another language is active. The command only accepts a single SQL query on a single line. * MySQL Shell history is now split per active language which the command was issued under. This means that your history now matches the active language, for example when you are running in JavaScript mode having issued \js, the history contains the previous JavaScript statements you issued, and when you issue \sql to change to SQL mode your history contains the previous SQL statements you issued. Similarly, now any history related commands such as \history clear or \history delete are performed on the history of the current active language. When you install this version, any existing MySQL Shell history files are duplicated to ensure that existing history is not lost. Subsequent operations are then added to the language specific history file. * The new autoRejoinTries option enables you to configure how many times an instance tries to rejoin a group after being expelled. In scenarios where network glitches happen but recover quickly, setting this option prevents you from having to manually add the expelled instance back to the group. The autoRejoinTries option accepts positive integer values between 0 and 2016 and the default value is 0, which means that instances do not try to automatically rejoin. Set the value to a valid integer to configure the number of attempts expelled instances should make to rejoin the group. You can pass the autoRejoinTries option to these AdminAPI operations: + dba.createCluster() + Cluster.addInstance() + Cluster.setOption() + Cluster.setInstanceOption() When you configure the autoRejoinTries option, it sets the group_replication_autorejoin_tries system variable. Passing the option to dba.createCluster(), Cluster.addInstance() or Cluster.setInstanceOption() configures the automatic rejoin for specific cluster instances. Passing the option to Cluster.setOption() configures the automatic rejoin for all cluster instances. For more information, see Responses to Failure Detection and Network Partitioning (http://dev.mysql.com/doc/refman/8.0/en/group-replication-responses-failure.html). * When resultFormat was set to json or json/raw, every result was being returned as a JSON document. This behavior was expected when JSON wrapping is off (in other words the --json command option was not used when starting MySQL Shell). Now, for consistency reasons when JSON wrapping is off and resultFormat is set to json or json/raw, every record is printed in a separate document and statistics and warnings are printed in plain text. For example if MySQL Shell is started without --json and resultFormat=json/raw: mysqlsh-sql> SHOW DATABASES; {"Database":"information_schema"} {"Database":"mysql"} {"Database":"performance_schema"} {"Database":"sys"} 4 rows in set (0.0035 sec) If MySQL Shell is started with --json and with resultFormat=json/raw: mysqlsh-sql> SHOW DATABASES; { "hasData": true, "rows": [ { "Database": "information_schema" }, { "Database": "mysql" }, { "Database": "performance_schema" }, { "Database": "sys" } ], "executionTime": "0.0018 sec", "affectedRowCount": 0, "affectedItemsCount": 0, "warningCount": 0, "warningsCount": 0, "warnings": [], "info": "", "autoIncrementValue": 0 } * AdminAPI now reports information about the version of MySQL running on instances. This information is available from the following operations: + Cluster.status() + Cluster.describe() + Cluster.rescan() See Checking the MySQL Version on Instances (http://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working- with-cluster.html#checking-version-on-instances) for more information. Bugs Fixed * Removing an instance from a cluster when the instance to be removed had no user defined for the group_replication_recovery channel resulted in dropping users on the remaining instances of the cluster. (Bug #29617572) * MySQL Shell could be installed in an environment where Python was not present, but the application has a dependency on many standard Python modules, resulting in error messages at startup. The RPM and Debian packages for MySQL Shell now explicitly specify the dependency on Python. (Bug #29469201) * The MSI file that is used by Windows Installer to install MySQL Shell now adds the path to the application binary (mysqlsh) to the Windows PATH environment variable, so that the application can be started from a command prompt. (Bug #29457639) * In the instructions to build MySQL Shell from source (the INSTALL document), the required version of the optional V8 dependency has been updated from 3.28.71.19 to 6.7.288.46. Thanks to Evgeniy Patlan for spotting this. (Bug #29430049, Bug #94529) * The failoverConsistency option has been deprecated and a new option named consistency has been added, to make it more consistent with the target Group Replication group_replication_consistency system variable name. The MySQL Shell online documentation now also correctly describes all of the values you can assign to the consistency option. (Bug #29356599) * The dba.configureLocalInstance() operation would remove any section that did not start with mysqld from the provided option file. This could remove sections such as the client section from the option file. (Bug #29349014) * MySQL Shell's upgrade checker utility checkForServerUpgrade() could incorrectly report a schema inconsistency error for a table whose name included a special character such as a hyphen. (Bug #29346836, Bug #94303) * When an instance with X Plugin disabled was added to an InnoDB cluster, if the instance was later removed from the cluster using Cluster.removeInstance() the operation failed with LogicError "get_string(7): field is NULL". This was a regression introduced by the fix for Bug#27677227. (Bug #29304183) * There was an inconsistency between the behavior of dba.checkInstanceConfiguration() and the commands to add instances to the cluster (dba.createCluster() and Cluster.addInstance()) regarding the localhost and loopback address validation. In particular, a simple error was printed by dba.checkInstanceConfiguration() but the execution of the operation continued showing that everything was correct at the end of the operation, while an error was issued and the execution stopped for dba.createCluster() and Cluster.addInstance(). As part of fixing this issue, it was decided that the existing localhost and loopback address validations are no longer needed and should be removed. In particular, whatever address is specified for report_host, even if it is localhost or the loopback address (127.0.0.1), should be allowed, because it was explicitly specified by the user to use it. (Bug #29279941) * The dba.rebootClusterFromCompleteOutage() operation was not preserving the existing Group Replication configurations previously set for the instances. In particular, the Group Replication local address and exit state action values were being changed. Now all settings are read at the time of rebooting the cluster. (Bug #29265869) * On Windows, MySQL Shell's upgrade checker utility checkForServerUpgrade() incorrectly reported a schema inconsistency error for partitioned tables. (Bug #29256562) * Using either Cluster.setOption() or Cluster.setInstanceOption() to set an option which only exists in MySQL 8.0 on an instance running MySQL 5.7 was not being caught correctly. (Bug #29246657) * On Debian-based platforms (such as Ubuntu), if the hostname resolved to 127.0.1.1 - which is the default on these platforms - it was not possible to create a cluster using the default settings. Now, in such situations a proper validation of the instance is performed before creating a cluster and adding instances to it. (Bug #29246110) * MySQL Shell stopped unexpectedly if Python code was running in interactive mode and threw exceptions from C++ libraries. These exceptions are now caught and translated to Python's built-in RuntimeError exceptions. (Bug #29057116) * The dba.checkInstanceConfiguration() operation did not validate host restrictions for the account provided for cluster administration, for example if the account could actually connect to all of the instances in the cluster. In particular, now an error is issued if the provided user account is only able to connect through localhost. (Bug #29018457) * When a connection is specified using key-value pairs in MySQL Shell's shell.connect() method, the host name cannot be an empty string. MySQL Shell now handles this situation consistently and returns an error if the supplied host name is an empty string. (Bug #28899522) * InnoDB cluster configured auto_increment_increment and auto_increment_offset on instances for clusters running in multi-primary mode and consisting of up to 7 instances based on the logic described at InnoDB cluster and Auto-increment (http://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-with- cluster.html#mysql-innodb-cluster-auto-increment). But Group Replication permits groups to contain up to 9 members, and Cluster.addInstance() and Cluster.removeInstance() were not following the logic used for other operations. Now, InnoDB cluster uses the same logic for auto increment regardless of the operation used and correctly handles multi-primary clusters with more than 7 instances. (Bug #28812763) * MySQL Shell's JSON import utility can now accept input from FIFO special files (named pipes) when you invoke the utility using the util.importJSON function, so you can carry out large imports by this method without needing to put the data into a file. (Bug #28785527) * When you use the MySQL Shell command \help (or \h, or \?) with a search pattern to search for help on a specific subject, multiple help topic titles can match the pattern and be returned as a list, to be selected by entering the command again with an extended search pattern. With this system, it was possible for help topics with a single-word title to be inaccessible from such a list because there was nothing further to add to the search pattern. To avoid this situation, the handling of multiple matches has now been improved. If a topic title is found that matches the given search pattern exactly (case-sensitive in the event of multiple topic matches, and case-insensitive in the event of no case-sensitive matches), the topic is identified as the exact match and its help data is printed. The rest of the topics with pattern matches in their titles are listed in a "see also" section and can be selected by further pattern matching. (Bug #28393119) * MySQL Shell uses the host value of the provided connection parameters as the target hostname used for AdminAPI operations, namely to register the instance in the metadata (for the dba.createCluster() and cluster.addInstance() operations). However, the host used for the connection parameters might not match the hostname that is used or reported by Group Replication, which uses the value of the report_host system variable when it is defined (in other words it is not NULL), otherwise the value of hostname is used. Therefore, AdminAPI now follows the same logic to register the target instance in the metadata and as the default value for the group_replication_local_address variable on instances, instead of using the host value from the instance connection parameters. During this fix it was detected that when the report_host variable was set to empty, Group Replication uses an empty value for the host but AdminAPI (for example in commands such as dba.checkInstanceConfiguration(), dba.configureInstance(), dba.createCluster()) reports the hostname as the value used which is inconsistent with the value reported by Group Replication. An error is now issued by AdminAPI if an empty value is set for the report_host system variable. (Bug #28285389) * In the event that dba.createCluster() failed and a rollback was performed to remove the created replication (recovery) users, the account created at localhost and any of the ipWhitelist addresses were not being removed. The fix ensures that the replication accounts are removed whenever a rollback related to dba.createCluster() is performed. This work was based on a code contribution from Bin Hong. (Bug #94182, Bug #29308037) On Behalf of Oracle/MySQL Release Engineering Team, Nawaz Nazeer Ahamed
↧
↧
MySQL Cluster 7.4.24 has been released (no replies)
Dear MySQL Users,
MySQL Cluster is the distributed, shared-nothing variant of MySQL. This
storage engine provides:
- In-Memory storage - Real-time performance
- Transparent Auto-Sharding - Read & write scalability
- Active-Active/Multi-Master geographic replication
- 99.999% High Availability with no single point of failure
and on-line maintenance
- NoSQL and SQL APIs (including C++, Java, http, Memcached
and JavaScript/Node.js)
MySQL Cluster 7.4 makes significant advances in performance; operational
efficiency (such as enhanced reporting and faster restarts and upgrades)
and conflict detection and resolution for active-active replication
between MySQL Clusters.
MySQL Cluster 7.4.24 has been released and can be downloaded from
http://www.mysql.com/downloads/cluster/
where you will also find Quick Start guides to help you get your first
MySQL Cluster database up and running.
The release notes are available from
http://dev.mysql.com/doc/relnotes/mysql-cluster/7.4/en/index.html
MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.
More details can be found at
http://www.mysql.com/products/cluster/
Enjoy !
==============================================================================
Changes in MySQL NDB Cluster 7.4.24 (5.6.44-ndb-7.4.24) (2019-04-26, General Availability)
MySQL NDB Cluster 7.4.24 is a new release of MySQL NDB
Cluster 7.4, based on MySQL Server 5.6 and including features
in version 7.4 of the NDB storage engine, as well as fixing
recently discovered bugs in previous NDB Cluster releases.
Obtaining MySQL NDB Cluster 7.4. MySQL NDB Cluster 7.4
source code and binaries can be obtained from
https://dev.mysql.com/downloads/cluster/.
For an overview of changes made in MySQL NDB Cluster 7.4, see
What is New in NDB Cluster 7.4
(http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-what-is-new-7-4.html).
This release also incorporates all bug fixes and changes made
in previous NDB Cluster releases, as well as all bug fixes
and feature changes which were added in mainline MySQL 5.6
through MySQL 5.6.44 (see Changes in MySQL 5.6.44 (2019-04-25,
General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-44.html)).
Functionality Added or Changed
* Building with CMake3 is now supported by the
compile-cluster script included in the NDB source
distribution.
Bugs Fixed
* When a pushed join executing in the DBSPJ block had to
store correlation IDs during query execution, memory for
these was allocated for the lifetime of the entire query
execution, even though these specific correlation IDs are
required only when producing the most recent batch in the
result set. Subsequent batches require additional
correlation IDs to be stored and allocated; thus, if the
query took sufficiently long to complete, this led to
exhaustion of query memory (error 20008). Now in such
cases, memory is allocated only for the lifetime of the
current result batch, and is freed and made available for
re-use following completion of the batch. (Bug #29336777)
References: See also: Bug #26995027.
* In some cases, one and sometimes more data nodes
underwent an unplanned shutdown while running
ndb_restore. This occurred most often, but was not always
restircted to, when restoring to a cluster having a
different number of data nodes from the cluster on which
the original backup had been taken.
The root cause of this issue was exhaustion of the pool
of SafeCounter objects, used by the DBDICT kernel block
as part of executing schema transactions, and taken from
a per-block-instance pool shared with protocols used for
NDB event setup and subscription processing. The
concurrency of event setup and subscription processing is
such that the SafeCounter pool can be exhausted; event
and subscription processing can handle pool exhaustion,
but schema transaction processing could not, which could
result in the node shutdown experienced during
restoration.
This problem is solved by giving DBDICT schema
transactions an isolated pool of reserved SafeCounters
which cannot be exhausted by concurrent NDB event
activity. (Bug #28595915)
* ndb_restore did not restore autoincrement values
correctly when one or more staging tables were in use. As
part of this fix, we also in such cases block applying of
the SYSTAB_0 backup log, whose content continued to be
applied directly based on the table ID, which could
ovewrite the autoincrement values stored in SYSTAB_0 for
unrelated tables. (Bug #27917769, Bug #27831990)
References: See also: Bug #27832033.
* ndb_restore employed a mechanism for restoring
autoincrement values which was not atomic, and thus could
yield incorrect autoincrement values being restored when
multiple instances of ndb_restore were used in parallel.
(Bug #27832033)
References: See also: Bug #27917769, Bug #27831990.
* An NDB table having both a foreign key on another NDB
table using ON DELETE CASCADE and one or more TEXT or
BLOB columns leaked memory. (Bug #27484882)
* When executing the redo log in debug mode it was possible
for a data node to fail when deallocating a row. (Bug
#93273, Bug #28955797)
On Behalf of Oracle/MySQL Release Engineering Team,
Hery Ramilison
↧
MySQL Cluster 7.3.25 has been released (no replies)
Dear MySQL Users,
MySQL Cluster is the distributed, shared-nothing variant of MySQL. This
storage engine provides:
- In-Memory storage - Real-time performance (with optional
checkpointing to disk)
- Transparent Auto-Sharding - Read & write scalability
- Active-Active/Multi-Master geographic replication
- 99.999% High Availability with no single point of failure
and on-line maintenance
- NoSQL and SQL APIs (including C++, Java, http, Memcached
and JavaScript/Node.js)
MySQL Cluster 7.3.25 has been released and can be downloaded from
http://www.mysql.com/downloads/cluster/
where you will also find Quick Start guides to help you get your first
MySQL Cluster database up and running.
The release notes are available from
http://dev.mysql.com/doc/relnotes/mysql-cluster/7.3/en/index.html
MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.
More details can be found at
http://www.mysql.com/products/cluster/
Enjoy !
==============================================================================
Changes in MySQL NDB Cluster 7.3.25 (5.6.44-ndb-7.3.25) (2019-04-26, General Availability)
MySQL NDB Cluster 7.3.25 is a new release of NDB Cluster, based on
MySQL Server 5.6 and including features from version 7.3 of the NDB
storage engine, as well as fixing a number of recently discovered
bugs in previous NDB Cluster releases.
Obtaining MySQL NDB Cluster 7.3. MySQL NDB Cluster 7.3 source code
and binaries can be obtained from
https://dev.mysql.com/downloads/cluster/.
For an overview of changes made in MySQL NDB Cluster 7.3, see What is
New in NDB Cluster 7.3
(http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-what-is-new-7-3.html).
This release also incorporates all bug fixes and changes made in
previous NDB Cluster releases, as well as all bug fixes and feature
changes which were added in mainline MySQL 5.6 through MySQL 5.6.44
(see Changes in MySQL 5.6.44 (2019-04-25, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-44.html)).
Functionality Added or Changed
* Building with CMake3 is now supported by the
compile-cluster script included in the NDB source distribution.
Bugs Fixed
* An NDB table having both a foreign key on another NDB
table using ON DELETE CASCADE and one or more TEXT or BLOB
columns leaked memory. (Bug #27484882)
Enjoy and thanks for the support!
On behalf of the MySQL Release Team,
Nawaz Nazeer Ahamed
↧
MySQL Cluster 7.5.14 has been released (no replies)
Dear MySQL Users,
MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:
- In-Memory storage - Real-time performance (with optional
check pointing to disk)
- Transparent Auto-Sharding - Read & write scalability
- Active-Active/Multi-Master geographic replication
- 99.999% High Availability with no single point of failure
and on-line maintenance
- NoSQL and SQL APIs (including C++, Java, http, Memcached
and JavaScript/Node.js)
MySQL Cluster 7.5.14 has been released and can be downloaded from
http://www.mysql.com/downloads/cluster/
where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.
The release notes are available from
http://dev.mysql.com/doc/relnotes/mysql-cluster/7.5/en/index.html
MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.
More details can be found at
http://www.mysql.com/products/cluster/
Enjoy !
==============================================================================
Changes in MySQL NDB Cluster 7.5.14 (5.7.26-ndb-7.5.14) (2019-04-26, General Availability)
MySQL NDB Cluster 7.5.14 is a new release of MySQL NDB
Cluster 7.5, based on MySQL Server 5.7 and including features
in version 7.5 of the NDB
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
storage engine, as well as fixing recently discovered bugs in
previous NDB Cluster releases.
Obtaining MySQL NDB Cluster 7.5. MySQL NDB Cluster 7.5
source code and binaries can be obtained from
https://dev.mysql.com/downloads/cluster/.
For an overview of changes made in MySQL NDB Cluster 7.5, see
What is New in NDB Cluster 7.5
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-5.html).
This release also incorporates all bug fixes and changes made
in previous NDB Cluster releases, as well as all bug fixes
and feature changes which were added in mainline MySQL 5.7
through MySQL 5.7.26 (see Changes in MySQL 5.7.26 (2019-04-26, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-26.html)).
Bugs Fixed
* NDB Disk Data: NDB did not validate MaxNoOfOpenFiles
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd-maxnoofopenfiles)
in relation to InitialNoOfOpenFiles
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd-initialnoofopenfiles)
correctly, leading data nodes to fail with an error
message that did not make the nature of the problem clear
to users. (Bug #28943749)
* NDB Disk Data: Repeated execution of ALTER TABLESPACE ...
ADD DATAFILE
(http://dev.mysql.com/doc/refman/5.7/en/alter-tablespace.html)
against the same tablespace caused data nodes to hang and
left them, after being killed manually, unable to restart.
(Bug #22605467)
* NDB Cluster APIs: NDB now identifies short-lived
transactions not needing the reduction of lock contention
provided by NdbBlob::close()
(http://dev.mysql.com/doc/ndbapi/en/ndb-ndbblob-close.html)
and no longer invokes this method in cases (such as when
autocommit is enabled) in which unlocking merely causes
extra work and round trips to be performed prior to
committing or aborting the transaction. (Bug #29305592)
References: See also: Bug #49190, Bug #11757181.
* NDB Cluster APIs: When the most recently failed operation
was released, the pointer to it held by NdbTransaction
(http://dev.mysql.com/doc/ndbapi/en/ndb-ndbtransaction.html)
became invalid and when accessed led to failure of the NDB
API application. (Bug #29275244)
* When a pushed join executing in the DBSPJ block had to
store correlation IDs during query execution, memory for
these was allocated for the lifetime of the entire query
execution, even though these specific correlation IDs are
required only when producing the most recent batch in the
result set. Subsequent batches require additional
correlation IDs to be stored and allocated; thus, if the
query took sufficiently long to complete, this led to
exhaustion of query memory (error 20008). Now in such
cases, memory is allocated only for the lifetime of the
current result batch, and is freed and made available for
re-use following completion of the batch. (Bug #29336777)
References: See also: Bug #26995027.
* Added DUMP 406 (NdbfsDumpRequests) to provide NDB file
system information to global checkpoint and local
checkpoint stall reports in the node logs. (Bug
#28922609)
* A race condition between the DBACC and DBLQH kernel
blocks occurred when different operations in a
transaction on the same row were concurrently being
prepared and aborted. This could result in DBTUP
attempting to prepare an operation when a preceding
operation had been aborted, which was unexpected and
could thus lead to undefined behavior including potential
data node failures. To solve this issue, DBACC and DBLQH
now check that all dependencies are still valid before
attempting to prepare an operation.
Note
This fix also supersedes a previous one made for a
related issue which was originally reported as Bug
#28500861.
(Bug #28893633)
* The ndbinfo.cpustat
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbinfo-cpustat.html)
table reported inaccurate information
regarding send threads. (Bug #28884157)
* In some cases, one and sometimes more data nodes
underwent an unplanned shutdown while running
ndb_restore. This occurred most often, but was not always
restircted to, when restoring to a cluster having a
different number of data nodes from the cluster on which
the original backup had been taken.
The root cause of this issue was exhaustion of the pool
of SafeCounter objects, used by the DBDICT kernel block
as part of executing schema transactions, and taken from
a per-block-instance pool shared with protocols used for
NDB event setup and subscription processing. The
concurrency of event setup and subscription processing is
such that the SafeCounter pool can be exhausted; event
and subscription processing can handle pool exhaustion,
but schema transaction processing could not, which could
result in the node shutdown experienced during
restoration.
This problem is solved by giving DBDICT schema
transactions an isolated pool of reserved SafeCounters
which cannot be exhausted by concurrent NDB event
activity. (Bug #28595915)
* After a commit failed due to an error, mysqld shut down
unexpectedly while trying to get the name of the table
involved. This was due to an issue in the internal
function ndbcluster_print_error(). (Bug #28435082)
* ndb_restore did not restore autoincrement values
correctly when one or more staging tables were in use. As
part of this fix, we also in such cases block applying of
the SYSTAB_0 backup log, whose content continued to be
applied directly based on the table ID, which could
ovewrite the autoincrement values stored in SYSTAB_0 for
unrelated tables. (Bug #27917769, Bug #27831990)
References: See also: Bug #27832033.
* ndb_restore employed a mechanism for restoring
autoincrement values which was not atomic, and thus could
yield incorrect autoincrement values being restored when
multiple instances of ndb_restore were used in parallel.
(Bug #27832033)
References: See also: Bug #27917769, Bug #27831990.
* An NDB table having both a foreign key on another NDB
table using ON DELETE CASCADE and one or more TEXT
(http://dev.mysql.com/doc/refman/5.7/en/blob.html) or
BLOB (http://dev.mysql.com/doc/refman/5.7/en/blob.html)
columns leaked memory. (Bug #27484882)
* When query memory was exhausted in the DBSPJ kernel block
while storing correlation IDs for deferred operations,
the query was aborted with error status 20000 Query
aborted due to out of query memory. (Bug #26995027)
References: See also: Bug #86537.
* MaxBufferedEpochs
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd-maxbufferedepochs)
is used on data nodes to avoid excessive buffering of row
changes due to lagging NDB event API subscribers; when
epoch acjknowledgements from one or more subscribers lag
by this number of epochs, an asynchronous disconnection
is triggered, allowing the data node to release the
buffer space used for subscriptions. Since this
disconnection is asynchronous, it may be the case that it
has not completed before additional new epochs are
completed on the data node, resulting in new epochs not
being able to seize GCP completion records, generating
warnings such as those shown here:
[ndbd] ERROR -- c_gcp_list.seize() failed...
...
[ndbd] WARNING -- ACK wo/ gcp record...
And leading to the following warning:
Disconnecting node %u because it has exceeded MaxBufferedEpochs
(100 > 100), epoch ....
This fix performs the following modifications:
+ Modifies the size of the GCP completion record pool
to ensure that there is always some extra headroom
to account for the asynchronous nature of the
disconnect processing previously described, thus
avoiding c_gcp_list seize failures.
+ Modifies the wording of the MaxBufferedEpochs
warning to avoid the contradictory phrase "100 >
100".
(Bug #20344149)
* When executing the redo log in debug mode it was possible
for a data node to fail when deallocating a row. (Bug
#93273, Bug #28955797)
Enjoy and thanks for the support!
On Behalf of MySQL/ORACLE RE Team
Sreedhar S
↧
MySQL Cluster 7.6.10 has been released (no replies)
Dear MySQL Users,
MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:
- In-Memory storage - Real-time performance (with optional
checkpointing to disk)
- Transparent Auto-Sharding - Read & write scalability
- Active-Active/Multi-Master geographic replication
- 99.999% High Availability with no single point of failure
and on-line maintenance
- NoSQL and SQL APIs (including C++, Java, http, Memcached
and JavaScript/Node.js)
MySQL Cluster 7.6.10 has been released and can be downloaded from
http://www.mysql.com/downloads/cluster/
where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.
MySQL Cluster 7.6 is also available from our repository for Linux
platforms, go here for details:
http://dev.mysql.com/downloads/repo/
The release notes are available from
http://dev.mysql.com/doc/relnotes/mysql-cluster/7.6/en/index.html
MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.
More details can be found at
http://www.mysql.com/products/cluster/
Enjoy !
Changes in MySQL NDB Cluster 7.6.10 (5.7.26-ndb-7.6.10) (2019-04-26, General Availability)
MySQL NDB Cluster 7.6.10 is a new release of NDB 7.6, based
on MySQL Server 5.7 and including features in version 7.6 of
the NDB storage engine, as well as fixing recently discovered
bugs in previous NDB Cluster releases.
Obtaining NDB Cluster 7.6. NDB Cluster 7.6 source code and
binaries can be obtained from
https://dev.mysql.com/downloads/cluster/.
For an overview of changes made in NDB Cluster 7.6, see What
is New in NDB Cluster 7.6
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-6.html).
This release also incorporates all bug fixes and changes made
in previous NDB Cluster releases, as well as all bug fixes
and feature changes which were added in mainline MySQL 5.7
through MySQL 5.7.26 (see Changes in MySQL 5.7.26 (2019-04-25, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-26.html)).
Bugs Fixed
* NDB Disk Data: The error message returned when validation
of MaxNoOfOpenFiles in relation to InitialNoOfOpenFiles
failed has been improved to make the nature of the
problem clearer to users. (Bug #28943749)
* NDB Disk Data: Repeated execution of ALTER TABLESPACE ...
ADD DATAFILE against the same tablespace caused data
nodes to hang and left them, after being killed manually,
unable to restart. (Bug #22605467)
* NDB Cluster APIs: NDB now identifies short-lived
transactions not needing the reduction of lock contention
provided by NdbBlob::close() and no longer invokes this
method in cases (such as when autocommit is enabled) in
which unlocking merely causes extra work and round trips
to be performed prior to committing or aborting the
transaction. (Bug #29305592)
References: See also: Bug #49190, Bug #11757181.
* NDB Cluster APIs: When the most recently failed operation
was released, the pointer to it held by NdbTransaction
became invalid and when accessed led to failure of the
NDB API application. (Bug #29275244)
* When a pushed join executing in the DBSPJ block had to
store correlation IDs during query execution, memory for
these was allocated for the lifetime of the entire query
execution, even though these specific correlation IDs are
required only when producing the most recent batch in the
result set. Subsequent batches require additional
correlation IDs to be stored and allocated; thus, if the
query took sufficiently long to complete, this led to
exhaustion of query memory (error 20008). Now in such
cases, memory is allocated only for the lifetime of the
current result batch, and is freed and made available for
re-use following completion of the batch. (Bug #29336777)
References: See also: Bug #26995027.
* API and data nodes running NDB 7.6 and later could not
use an existing parsed configuration from an earlier
release series due to being overly strict with regard to
having values defined for configuration parameters new to
the later release, which placed a restriction on possible
upgrade paths. Now NDB 7.6 and later are less strict
about having all new parameters specified explicitly in
the configuration which they are served, and use
hard-coded default values in such cases. (Bug #28993400)
* Added DUMP 406 (NdbfsDumpRequests) to provide NDB file
system information to global checkpoint and local
checkpoint stall reports in the node logs. (Bug
#28922609)
* A race condition between the DBACC and DBLQH kernel
blocks occurred when different operations in a
transaction on the same row were concurrently being
prepared and aborted. This could result in DBTUP
attempting to prepare an operation when a preceding
operation had been aborted, which was unexpected and
could thus lead to undefined behavior including potential
data node failures. To solve this issue, DBACC and DBLQH
now check that all dependencies are still valid before
attempting to prepare an operation.
Note
This fix also supersedes a previous one made for a
related issue which was originally reported as Bug
#28500861.
(Bug #28893633)
* The ndbinfo.cpustat table reported inaccurate information
regarding send threads. (Bug #28884157)
* Execution of an LCP_COMPLETE_REP signal from the master
while the LCP status was IDLE led to an assertion. (Bug
#28871889)
* Issuing a STOP command in the ndb_mgm client caused
ndbmtd processes which had recently been added to the
cluster to hang in Phase 4 during shutdown. (Bug
#28772867)
* In some cases, one and sometimes more data nodes
underwent an unplanned shutdown while running
ndb_restore. This occurred most often, but was not always
restircted to, when restoring to a cluster having a
different number of data nodes from the cluster on which
the original backup had been taken.
The root cause of this issue was exhaustion of the pool
of SafeCounter objects, used by the DBDICT kernel block
as part of executing schema transactions, and taken from
a per-block-instance pool shared with protocols used for
NDB event setup and subscription processing. The
concurrency of event setup and subscription processing is
such that the SafeCounter pool can be exhausted; event
and subscription processing can handle pool exhaustion,
but schema transaction processing could not, which could
result in the node shutdown experienced during
restoration.
This problem is solved by giving DBDICT schema
transactions an isolated pool of reserved SafeCounters
which cannot be exhausted by concurrent NDB event
activity. (Bug #28595915)
* After a commit failed due to an error, mysqld shut down
unexpectedly while trying to get the name of the table
involved. This was due to an issue in the internal
function ndbcluster_print_error(). (Bug #28435082)
* ndb_restore did not restore autoincrement values
correctly when one or more staging tables were in use. As
part of this fix, we also in such cases block applying of
the SYSTAB_0 backup log, whose content continued to be
applied directly based on the table ID, which could
ovewrite the autoincrement values stored in SYSTAB_0 for
unrelated tables. (Bug #27917769, Bug #27831990)
References: See also: Bug #27832033.
* ndb_restore employed a mechanism for restoring
autoincrement values which was not atomic, and thus could
yield incorrect autoincrement values being restored when
multiple instances of ndb_restore were used in parallel.
(Bug #27832033)
References: See also: Bug #27917769, Bug #27831990.
* Neither the MAX_EXECUTION_TIME optimizer hint nor the
max_execution_time system variable was respected for DDL
statements or queries against INFORMATION_SCHEMA tables
while an NDB global schema lock was in effect. (Bug
#27538139)
* An NDB table having both a foreign key on another NDB
table using ON DELETE CASCADE and one or more TEXT or
BLOB columns leaked memory. (Bug #27484882)
* When query memory was exhausted in the DBSPJ kernel block
while storing correlation IDs for deferred operations,
the query was aborted with error status 20000 Query
aborted due to out of query memory. (Bug #26995027)
References: See also: Bug #86537.
* MaxBufferedEpochs is used on data nodes to avoid
excessive buffering of row changes due to lagging NDB
event API subscribers; when epoch acjknowledgements from
one or more subscribers lag by this number of epochs, an
asynchronous disconnection is triggered, allowing the
data node to release the buffer space used for
subscriptions. Since this disconnection is asynchronous,
it may be the case that it has not completed before
additional new epochs are completed on the data node,
resulting in new epochs not being able to seize GCP
completion records, generating warnings such as those
shown here:
[ndbd] ERROR -- c_gcp_list.seize() failed...
...
[ndbd] WARNING -- ACK wo/ gcp record...
And leading to the following warning:
Disconnecting node %u because it has exceeded MaxBufferedEpochs
(100 > 100), epoch ....
This fix performs the following modifications:
+ Modifies the size of the GCP completion record pool
to ensure that there is always some extra headroom
to account for the asynchronous nature of the
disconnect processing previously described, thus
avoiding c_gcp_list seize failures.
+ Modifies the wording of the MaxBufferedEpochs
warning to avoid the contradictory phrase "100 >
100".
(Bug #20344149)
* When executing the redo log in debug mode it was possible
for a data node to fail when deallocating a row. (Bug
#93273, Bug #28955797)
↧
↧
MySQL Connector/ODBC 5.3.13 has been released (no replies)
Dear MySQL users, MySQL Connector/ODBC 5.3.13, a new version of the ODBC driver for the MySQL database management system, has been released. The available downloads include both a Unicode driver and an ANSI driver based on the same modern codebase. Please select the driver type you need based on the type of your application - Unicode or ANSI. Server-side prepared statements are enabled by default. It is suitable for use with any MySQL version from 5.6. This is the sixth release of the MySQL ODBC driver conforming to the ODBC 3.8 specification. It contains implementations of key 3.8 features, including self-identification as a ODBC 3.8 driver, streaming of output parameters (supported for binary types only), and support of the SQL_ATTR_RESET_CONNECTION connection attribute (for the Unicode driver only). The release is now available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/connector/odbc/5.3.html For information on installing, please see the documentation at http://dev.mysql.com/doc/connector-odbc/en/connector-odbc-installation.html Changes in MySQL Connector/ODBC 5.3.13 (2019-04-29, General Availability) Bugs Fixed * Connector/ODBC 5.3 is now built with MySQL client library 5.7.26, which includes OpenSSL 1.0.2R. Issues fixed in the new OpenSSL version are described at http://www.openssl.org/news/vulnerabilities.html. (Bug #29489006) * An exception was emitted when fetching contents of a BLOB/TEXT records after executing a statement as a server-side prepared statement with a bound parameter. The workaround is not using parameters or specifying NO_SSPS=1 in the connection string; this allows the driver to fetch the data. (Bug #29282638, Bug #29512548, Bug #28790708, Bug #93895, Bug #94545, Bug #92078) On Behalf of Oracle/MySQL Release Engineering Team, Hery Ramilison
↧
MySQL for Excel 1.3.8 has been released (no replies)
Dear MySQL users, The MySQL Windows Experience Team is proud to announce the release of MySQL for Excel version 1.3.8. This is a maintenance release for 1.3.x. It can be used for production environments. MySQL for Excel is an application plug-in enabling data analysts to very easily access and manipulate MySQL data within Microsoft Excel. It enables you to directly work with a MySQL database from within Microsoft Excel so you can easily do tasks such as: * Importing MySQL Data into Excel * Exporting Excel data directly into MySQL to a new or existing table * Editing MySQL data directly within Excel MySQL for Excel is installed using the MySQL Installer for Windows. The MySQL Installer comes in 2 versions - Full (400 MB) which includes a complete set of MySQL products with their binaries included in the download. - Web (18 MB - a network install) which will just pull the MySQL for Excel over the web and install it when run. You can download MySQL Installer from our official Downloads page at http://dev.mysql.com/downloads/installer/ The MySQL for Excel product can also be downloaded by using the product standalone installer found at this link http://dev.mysql.com/downloads/windows/excel/ Changes in MySQL for Excel 1.3.8 (2019-06-10, General Availability) * Functionality Added or Changed * Bugs Fixed Functionality Added or Changed * Previously, 1000 (first rows of a MySQL table) was the value limit for previewing a small amount of data in Excel. However, setting the value to 300 or greater generated an exception and prevented additional editing operations. The upper threshold now is 100, instead of 1000 (see Advanced Import Data Options, General Tab (https://dev.mysql.com/doc/mysql-for-excel/en/mysql-for-e xcel-import-options-advanced.html#mysql-for-excel-import- options-advanced-general)). (Bug #29745518) * A new global option, Tolerance for FLOAT and DOUBLE comparisons in WHERE clause, provides a way to edit data of these types that enables proper row-matching in the database when it is used together with optimistic updates (see Global Options, Edit Sessions Tab (https://dev.mysql.com/doc/mysql-for-excel/en/mysql-for-e xcel-config-options.html#mysql-for-excel-global-options-e dit-sessions)). (Bug #29179195, Bug #93824) * The Import Data operation adds digits to floating-point numbers. For example, instead of rendering a value such as 5.3 precisely from the database, the operation displays 5.0000019073486 after importing the data. This behavior affects FLOAT and DOUBLE data types, which adhere to the IEEE-754 standard and are stored as approximate values. A new option now provides a way to import floating-point numbers using the DECIMAL data type, which then stores and displays the exact value from the database (see Advanced Import Data Options, Formatting Tab (https://dev.mysql.com/doc/mysql-for-excel/en/mysql-for-e xcel-import-options-advanced.html#mysql-for-excel-import- advanced-format)). (Bug #26008777) * Support was added for encrypted connections in the form of SSL certificates and SSH tunneling, without the requirement of having intermediate proxy software to create the tunnel. Encrypted connections can be configured from the MySQL for Excel add-in directly or they can be configured with MySQL Workbench and then used to open a connection from the add-in. (Bug #18550080) * The Import Data operation for stored procedures now enables the selection of individual columns to be imported from each returned result set, which is similar to the way imported column data already works for table and view data. (Bug #16239029) Bugs Fixed * The Export and Append Data actions for a cell with data in a worksheet were transferred unexpectedly to a cell without data on a second worksheet when the active focus was shifted to the second worksheet. (Bug #29839647) * A lack of contrast between onscreen message data and the background obscured the connection information when some themes (such as Dark Gray) were set on the host. This fix extends the selected theme colors to the MySQL for Excel add-in for the following versions of Excel: 2007, 2010, 2013, 2016, 365, and 2019. (Bug #29826900) * When mappings were stored for Append Data operations, the add-in did not check for blank and duplicate stored mapping names. Now, validation ensures that all names are unique and that existing names are not overwritten without permission. (Bug #29826762) * Microsoft Excel prompted users to save workbooks that were unchanged. This fix alters the way metadata for connection information (used by Import and Edit Data operations) is created and stored, and ignores unrelated actions. (Bug #29625731) * When schema information was retrieved using a stored procedure, the operation was unable to find the mysql.proc system table. The operation now retrieves schema information from INFORMATION_SCHEMA tables. (Bug#29215137, Bug #93814) * With the option to create Excel relationships for imported tables enabled, an attempt to import a table (with related tables) generated an exception when the tables had circular references. This fix modifies the way relationships are created for Import Data operations for multiple tables, such that relationships among tables that could create a circular reference are not added to the Excel data model. (Bug #29050558) * The Edit Data operation returned an error message intermittently (value not suitable to be converted to a DateTime data type), even for tables without a DATETIME column. This fix updates the library used for internal connections to MySQL 8.0 server instances and the caching_sha2_password plugin. In addition, the updated library resolves an error in which fetched schema information for columns returns the rows in alphabetical order, instead of ordinal order. (Bug #29030866, Bug#93501) * Data imported to a worksheet could not be refreshed if the worksheet was renamed after the import operation. The add-in now inspects the connection information of imported tables to determine whether the associated worksheet name changed, and if so, it updates the connection metadata. Also, it removes the connection information for missing or deleted worksheets. (Bug#27441407, Bug #89387) * After editing, committing, and then refreshing the data from the database, subsequent commits were not recognized by the Edit Data operation. (Bug #27365464, Bug #87642) * An error was generated when an Edit Data operation involved changing the value of a date or time field. Now the value of each date or time field is wrapped with single quotes and the edits are saved to the database. (Bug #26301455, Bug #86723) * When an existing workbook was opened, a second (blank) workbook instance was also opened. (Bug #26245818, Bug#86633) * Some unsupported connection methods were shown as valid options to select. (Bug #26025950) * The Windows automatic scaling of visual elements did not work as expected when the operating system was configured to use a DPI value other than 100%. (Bug #23218058, Bug#81003) Quick links: MySQL for Excel documentation: http://dev.mysql.com/doc/en/mysql-for-excel.html. Inside MySQL blog (NEW blog home): http://insidemysql.com/ MySQL on Windows blog (OLD blog home): http://blogs.oracle.com/MySQLOnWindows. MySQL for Excel forum: http://forums.mysql.com/list.php?172. MySQL YouTube channel: http://www.youtube.com/user/MySQLChannel. Enjoy and thanks for the support! The MySQL on Windows team at Oracle.
↧
MySQL Community Server 8.0.17 has been released (part 1/3) (no replies)
[Due to size limitation, this announcement is split in three parts. This is part 1] Dear MySQL users, MySQL Server 8.0.17, a new version of the popular Open Source Database Management System, has been released. MySQL 8.0.17 is recommended for use on production systems. For an overview of what's new in MySQL 8.0, please see http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html For information on installing MySQL 8.0.17 on new servers, please see the MySQL installation documentation at http://dev.mysql.com/doc/refman/8.0/en/installing.html MySQL Server 8.0.17 is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/mysql/ MySQL Server 8.0.17 is also available from our repository for Linux platforms, go here for details: http://dev.mysql.com/downloads/repo/ Windows packages are available via the Installer for Windows: http://dev.mysql.com/downloads/installer/ along with .ZIP (no-install) packages for more advanced needs. 8.0.17 also comes with a web installer as an alternative to the full installer. The web installer doesn't come bundled with any actual products and instead relies on download-on-demand to fetch only the products you choose to install. This makes the initial download much smaller but increases install time as the individual products will need to be downloaded. We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc.: http://bugs.mysql.com/report.php The following link lists the changes in the MySQL 8.0 since the release of MySQL 8.0.16. It may also be viewed online at http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-17.html Enjoy! Changes in MySQL 8.0.17 (2019-07-22, General Availability) * Audit Log Notes * C API Notes * Character Set Support * Component Notes * Configuration Notes * Debugging Notes * Deprecation and Removal Notes * Installation Notes * Keyring Notes * Packaging Notes * Performance Schema Notes * Plugin Notes * X Plugin Notes * Functionality Added or Changed * Bugs Fixed Audit Log Notes * Encryption and decryption operations for encrypted MySQL Enterprise Audit log files use a password stored in the MySQL keyring. Previously, only a single password was stored. Generating a new password made the old password inaccessible, rendering MySQL Enterprise Audit unable to read log files encrypted with the old password. MySQL Enterprise Audit now archives old passwords to maintain a password history in the keyring, and includes in each encrypted log file name the ID of the password required to read the file. To enable expiration and cleanup of old archived passwords in the keyring, the new audit_log_password_history_keep_days system variable is available. See Audit Log Logging Configuration (https://dev.mysql.com/doc/refman/8.0/en/audit-log-logging-configuration.html). C API Notes * These C API changes were made: + HOSTNAME_LENGTH was changed from 60 to 255 and moved from include/mysql_com.h to include/my_hostname.h. + USER_HOST_BUFF_SIZE was moved from include/mysql_com.h to sql/auth/auth_common.h. (Bug #29590300) Character Set Support * The utf8mb4 character set has a new binary collation, utf8mb4_0900_bin, which differs from the existing utf8mb4_bin binary collation as follows: + For collating weights, utf8mb4_bin uses code points, possibly with leading zero bytes added, whereas utf8mb4_0900_bin uses the utf8mb4 encoding bytes. The sort order is the same for both collations, but sorting for utf8mb4_0900_bin is much faster. + The pad attribute for utf8mb4_bin is PAD SPACE, whereas for utf8mb4_0900_bin it is NO PAD. Consequently, operations involving utf8mb4_0900_bin do not add trailing spaces, and comparisons involving strings with trailing spaces may differ for the two collations. For more information, see Unicode Character Sets (https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html). Component Notes * A new mysql_current_thread_reader component service is available to enable server components to obtain a handle to the current thread. For example, the service enables components to access properties of the current session by passing its thread handle to other services. For information about this service, see the Component Subsystem section of the MySQL Server Doxygen documentation, available at https://dev.mysql.com/doc/index-other.html. Configuration Notes * The source files in the mysys_ssl directory have been moved to the mysys directory and the mysys_ssl library is no longer built. (Bug #29488066) * MySQL configuration now requires a minimum CMake version of 3.5.1. (Bug #29337090) * The maximum permitted length of host names throughout MySQL has been raised to 255 ASCII characters, up from the previous limit of 60 characters. This applies to, for example, host name-related columns in the data dictionary, mysql system schema, Performance Schema, INFORMATION_SCHEMA, and sys schema; the MASTER_HOST value for the CHANGE MASTER TO statement; the Host column in SHOW PROCESSLIST statement output; host names in account names (such as used in account-management statements and in DEFINER attributes); and host name-related command options and system variables. Caveats: + The increase in permitted host name length can affect tables with indexes on host name columns. For example, tables in the mysql system schema that index host names now have an explicit ROW_FORMAT attribute of DYNAMIC to accommodate longer index values. + Some file name-valued configuration settings might be constructed based on the server host name. The permitted values are constrained by the underlying operating system, which may not permit file names long enough to include 255-character host names. This affects the general_log_file, log_error, pid_file, relay_log, and slow_query_log_file system variables and corresponding options. If host name-based values are too long for the OS, explicit shorter values must be provided. + Although the server now supports 255-character host names, connections to the server established using the --ssl-mode=VERIFY_IDENTITY option are constrained by maximum host name length supported by OpenSSL. Host name matches pertain to two fields of SSL certificates, which have maximum lengths as follows: Common Name: maximum length 64; Subject Alternative Name: maximum length as per RFC#1034. Applications that expect host names to be a maximum of 60 characters should be adjusted to account for this change. (Bug #13548245, Bug #63814, Bug #27925782, Bug #90601, Bug #27955121, Bug #29584642, Bug #29602081, Bug #94907) Debugging Notes * The MySQL server is a multithreaded application that uses numerous internal locking primitives such as mutexes. To enable detection of lock-acquisition deadlocks and enforcement that runtime execution is free of them, MySQL now supports LOCK_ORDER tooling. This enables a lock-order dependency graph to be defined as part of server design, and server runtime checking to ensure that lock acquisition is acyclic and that execution paths comply with the graph. LOCK_ORDER support includes: + A lock_order_dependencies.txt file that defines the server lock-order dependency graph. + A WITH_LOCK_ORDER CMake option that configures whether MySQL is built with LOCK_ORDER tooling. + A set of system variables that configure LOCK_ORDER tool operation during server execution. + A --lock-order option for mysql-test-run.pl that controls whether to enable the LOCK_ORDER tool during test case execution. To use the LOCK_ORDER tool, you must build MySQL from source with tooling enabled. See The LOCK_ORDER Tool (https://dev.mysql.com/doc/refman/8.0/en/lock-order-tool.html). It is intended for debugging the server, not for production use. Deprecation and Removal Notes * FLOAT(M,D) and DOUBLE(M,D) syntax to specify the number of digits for columns of type FLOAT and DOUBLE (and any synonyms) is a nonstandard MySQL extension. This syntax is deprecated and support for it will be removed in a future MySQL version. (Bug #25328973, Bug #84363) * For string data types, the BINARY attribute is a nonstandard MySQL extension that is shorthand for specifying the binary (_bin) collation of the column character set (or of the table default character set if no column character set is specified). In MySQL 8.0, this nonstandard use of BINARY is ambiguous because the utf8mb4 character set has multiple _bin collations, so the BINARY attribute is deprecated and support for it will be removed in a future MySQL version. Applications should be adjusted to use an explicit _bin collation instead. The use of BINARY to specify a data type or character set remains unchanged. * The nonstandard C-style &&, ||, and ! operators that are synonyms for the standard SQL AND, OR, and NOT operators, respectively, are deprecated and support for them will be removed in a future MySQL version. Applications that use the nonstandard operators should be adjusted to use the standard operators. Note Use of || is deprecated unless the PIPES_AS_CONCAT SQL mode is enabled. In that case, || signifies the SQL-standard string concatenation operator). * The ZEROFILL attribute is deprecated for numeric data types, as is the display width attribute for integer data types. Support for ZEROFILL and display widths for integer data types will be removed in a future MySQL version. Consider using an alternative means of producing the effect of these attributes. For example, applications could use the LPAD() function to zero-pad numbers up to the desired width, or they could store the formatted numbers in CHAR columns. * The UNSIGNED attribute is deprecated for columns of type FLOAT, DOUBLE, and DECIMAL (and any synonyms) and will be removed in a future MySQL version. Consider using a simple CHECK constraint instead for such columns. * AUTO_INCREMENT support is deprecated for columns of type FLOAT and DOUBLE (and any synonyms) and will be removed in a future MySQL version. Consider removing the AUTO_INCREMENT attribute from such columns, or convert them to an integer type. * The SQL_CALC_FOUND_ROWS query modifier and accompanying FOUND_ROWS() function are now deprecated and will be removed in a future MySQL version. As a replacement, considering executing your query with LIMIT, and then a second query with COUNT(*) and without LIMIT to determine whether there are additional rows. For example, instead of these queries: SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name WHERE id > 100 LIMIT 10; SELECT FOUND_ROWS(); Use these queries instead: SELECT * FROM tbl_name WHERE id > 100 LIMIT 10; SELECT COUNT(*) WHERE id > 100; COUNT(*) is subject to certain optimizations. SQL_CALC_FOUND_ROWS causes some optimizations to be disabled. Installation Notes * An automatic upgrade at server startup can take some time to complete. For better status notification in systemd environments, the server now sends messages to the system notification socket when upgrades start and end. (Status can be monitored with server mysqld status.) (Bug #29493201) Keyring Notes * The keyring_aws plugin has been updated to use the latest AWS SDK and so that it works with OpenSSL 1.1. Packaging Notes * To reduce the download size and disk footprint of mysql-community-server Linux packages, debug binaries and plugins have been moved to separate packages for these platforms: + EL8, Fedora: The mysql-community-server package with debug binaries and associated plugins is now split into a mysql-community-server package without debug binaries or plugins and a mysql-community-server-debug package with debug binaries and plugins. + Debian: The mysql-community-server package with debug binaries and associated plugins is now split into a mysql-community-server package without debug binaries or plugins, a mysql-community-server-debug package with debug binaries, and a mysql-community-test-debug package with debug plugins. In all cases, the debug packages are dependent on the corresponding mysql-community-server package. (Bug #29769061, Bug #28647754, Bug #92415, Bug #29702765, Bug #95169, Bug #29681301) Performance Schema Notes * Performance Schema version checking at compile time was improved to prevent incompatibilities with the server version. (Bug #29550156) * Previously, the Performance Schema instrumentation for RWLOCK named priority read/write locks as rwlock (thus failing to distinguish plain from priority locks) and did not collect information about the kind of unlock operation performed. Priority read/write locks now are named prlock, so that events for them begin with wait/synch/prlock. Also, information about unlock operations is provided. (Bug #29270712) Plugin Notes * Not all plugins can operate properly if loaded "early" in the server startup sequence using the --early-plugin-load option (that is, before InnoDB is initialized). However, InnoDB requires keyring backend plugins to operate on encrypted tables. To enable plugins to indicate to the server whether they can be loaded early, a new PLUGIN_OPT_ALLOW_EARLY flag is available for use in the plugin descriptor. See Server Plugin Library and Plugin Descriptors (https://dev.mysql.com/doc/refman/8.0/en/plugin-data-structures.html#server-plugin-descriptors). Keyring plugins included in MySQL distributions now have the PLUGIN_OPT_ALLOW_EARLY flag enabled because InnoDB requires them, but the flag is not limited to keyring plugins. It can be set for other plugins that are able to initialize successfully early in the server startup sequence. This flag has no effect on whether a plugin can be loaded at server startup with the --plugin-load or --plugin-load-add option, or at runtime with the INSTALL PLUGIN statement. All plugins compiled using MySQL distributions prior to 8.0.17 do not have this flag set. When loading these into pre-8.0.17 servers this does not matter, but attempts to use --early-plugin-load to load plugin binaries compiled using pre-8.0.17 MySQL distributions into a 8.0.17 or higher server will fail. The plugins must be recompiled against MySQL 8.0.17 or higher. (Bug #29040456, Bug #93550) X Plugin Notes * The createIndex() method did not support the DOUBLE(M,D) syntax for specifying double-precision values due to a regression in MySQL 8.0.16. (Bug #29748841) * X Protocol's handling of messages with arguments encoded as octets was corrected to support non-scalar data such as an array of strings. (Bug #29721046) * When host name identity verification was active for SSL connections (--ssl-mode=VERIFY_IDENTITY), X Protocol did not check for matches to Subject Alternative Names (SANs) in the server Certificate Authority (CA) certificate. This could lead to connection requests being rejected unnecessarily because they used a valid host name that was specified as an SAN rather than as the certificate's Common Name value. (Bug #29691694) * When prepared statements were used with X Plugin, using IN or NOT IN in a modify or find operation produced invalid JSON, resulting in an error. (Bug #29259501) * On Windows, X Plugin logged some messages that were unnecessary or insufficiently informative. The messages have been removed or improved as appropriate. (Bug #27839153) * X Plugin's list of SQL functions was out of date, and has been updated to add new functions and remove functions that are no longer available. (Bug #26574971) Functionality Added or Changed * InnoDB; JSON: InnoDB now supports multi-valued indexes on JSON arrays. A multi-valued index is an index in which multiple index records can point to the same data record. This can be useful for indexing JSON documents such as {user:"Bob",zipcode:[94477,94536]} in which, if we wish to search all zip codes, it is necessary to have two index records for each zip code in the document. We can create such an index on the zipcode array using a CREATE INDEX statement such as this one: CREATE INDEX zips ON t1( (CAST(data->'$.zipcode' AS UNSIGNED ARRAY)) ) Effectively, this is a functional index using the CAST() function, which has been extended with the ARRAY keyword to enable casting of JSON arrays to SQL data type arrays. The path expression must be a valid JSON path, and must point to an array in the JSON document in order to be effective. All type specifiers supported by CAST() can be used except for BINARY. Such usage of the CAST() function is supported only by InnoDB, and only for creating multi-valued indexes on JSON arrays. As part of this work, MySQL adds a new function JSON_OVERLAPS() as well as a new MEMBER OF() operator for working with JSON documents, as described here: + JSON_OVERLAPS() compares two JSON documents. If they contain any key-value pairs or array elements in common, the function returns TRUE (1); otherwise it returns FALSE (0). If both values are scalars, the function performs a simple test for equality. If one argument is a JSON array and the other is a scalar, the scalar is treated as an array element. Thus, JSON_OVERLAPS() acts as a complement to JSON_CONTAINS(). + MEMBER OF() tests whether the first operand (a scalar or JSON document) is a member of the JSON array passed as the second operand, returning TRUE (1) if it is, and FALSE (0) if it is not. No type conversion of the operand is performed. The MySQL optimizer uses multi-valued indexes automatically for any suitable query---that is, a query using in its WHERE clause any of JSON_CONTAINS(), JSON_OVERLAPS(), or MEMBER OF() on an array within a JSON column. You can see whether such an index is actually used by checking the output of EXPLAIN for the given query. Multi-Valued Indexes (https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-multi-valued), provides more detailed information about multi-valued indexes, including examples. For more information about JSON_OVERLAPS() and MEMBER OF(), with examples of use, see Functions That Search JSON Values (https://dev.mysql.com/doc/refman/8.0/en/json-search-functions.html). * Microsoft Windows: A new warning message now reminds DBAs that connections made using the MySQL named pipe on Windows has limited the permissions a connector can request on the named pipe. Previously, the named_pipe_full_access_group system variable was set to a value that maps to the built-in Windows Everyone group (SID S-1-1-0) by default. However, this group is not ideal and should be replaced with a group that restricts its membership for connectors that are unable to request fewer permissions on the MySQL named pipe. The new warning is written to the error log at startup if the string value assigned to named_pipe_full_access_group is '*everyone*' (or the Windows System Language equivalent) and named pipes are enabled. In addition, the warning is written to the error log and raised to the client if the system variable is reset to the Everyone group at runtime. * X DevAPI: For Collection objects, the following methods have been deprecated and are scheduled to be removed in a future release: + Collection.find().where() + Collection.modify().where() + Collection.remove().where() Any Collection code relying on the .where() method should be updated and the expression in the .where() method should be provided directly in the appropriate .find(), .remove(), and .modify() method. * JSON: MySQL now supports JSON schema validation using two functions JSON_SCHEMA_VALID() and JSON_SCHEMA_VALIDATION_REPORT(), both of which validate a JSON document against a JSON schema conforming to Draft 4 of the JSON Schema specification. JSON_SCHEMA_VALID() returns true if the document validates against the schema and false if it does not. JSON_SCHEMA_VALIDATION_REPORT() returns a JSON document containing detailed information about the results of the validation. For both of these functions, the following statements apply: + required attributes are supported. + Regular expressions are supported (invalid expressions are silently ignored). + External resources in schemas and the $ref keyword are not supported. For more information, including examples, see JSON Schema Validation Functions (https://dev.mysql.com/doc/refman/8.0/en/json-validation-functions.html). * The time_zone session variable is now hintable using the SET_VAR optimizer hint. (Bug #29776464) * The minor version of the libmysqlclient.so C client library has been increased to 1 (21.0 to 21.1), to signal that new symbols have been added. This was done to correct an oversight in the MySQL 8.0.16 release. To address compatibility concerns, the version of all symbols is unchanged. This means the filename of the library is libmysqlclient.so.21.1.17, whereas all symbols inside the library are tagged as 21_0 (unchanged from the 8.0.16 release). (Bug #29584073, Bug #29642146) * Thanks to Josh Braden, Daniël van Eeden, Simon Mudd, and Zhou Mengkang, who contributed corrections to comments and messages in the MySQL source code. (Bug #29403708, Bug #94464, Bug #29428435, Bug #94527, Bug #29262200, Bug #94049, Bug #29468128, Bug #94625) * The mysql client program now sends os_user and os_sudouser connection attributes, when available, to indicate the name of the operating system user running the program and the value of the SUDO_USER environment variable, respectively. For general information about connection attributes, see Performance Schema Connection Attribute Tables (https://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html). Thanks to Daniël van Eeden for the contribution on which this feature was based. (Bug #29210935, Bug #93916) * Password hash values displayed in the IDENTIFIED WITH clause of output from SHOW CREATE USER may contain unprintable characters that have adverse effects on terminal displays and in other environments. Enabling the new print_identified_with_as_hex system variable causes SHOW CREATE USER to display such hash values as hexadecimal strings rather than as regular string literals. Hash values that do not contain unprintable characters still display as regular string literals, even with this variable enabled. For compatibility with this change, CREATE USER and ALTER USER now accept hash values specified either as regular string literals or as hexadecimal strings. (Bug #28053446, Bug #90947) * In MySQL 8.0, the lower_case_table_names variable can only be configured when the MySQL server is initialized. Because a MySQL server installation on Debian and Ubuntu performed using APT initializes the MySQL server for you, there was no opportunity to enable lower_case_table_names. To work around this issue, you can now use the debconf-set-selection utility to enable lower_case_table_names (set lower_case_table_names=1) prior to installing MySQL using APT. To enable lower_case_table_names prior to installing MySQL using APT, execute the following command: shell> sudo debconf-set-selections <<< "mysql-server mysql-server/lowe rcase-table-names select Enabled (Bug #27948395, Bug #90695) * The server now checks the SSL server certificate better at startup and writes a warning to the error log if it finds a problem. (Bug #25945005) * The umask for files created using SELECT ... INTO OUTFILE or SELECT ... INTO DUMPFILE was changed from 0666 to 0640. The LOAD_FILE() function no longer requires files to be world-readable, just readable by the server. (Bug #24513720) * The mysqldump option --set-gtid-purged controls whether or not a SET @@GLOBAL.gtid_purged statement is added to the mysqldump output. The statement updates the value of gtid_purged on a server where the dump file is reloaded, to add the GTID set from the source server's gtid_executed system variable. A new choice --set-gtid-purged=COMMENTED is now available. When this value is set, if GTIDs are enabled on the server you are backing up, SET @@GLOBAL.gtid_purged is added to the output (unless gtid_executed is empty), but it is commented out. This means that the value of gtid_executed is available in the output, but no action is taken automatically when the dump file is reloaded. With COMMENTED, you can control the use of the gtid_executed set manually or through automation. For example, you might prefer to do this if you are migrating data to another server that already has different active databases. Thanks to Facebook for this contribution. (Bug #94332, Bug #29357665) * MySQL now supports explicit casts to DOUBLE, FLOAT, and REAL using either of the functions CAST() or CONVERT(). For more information, see Cast Functions and Operators (https://dev.mysql.com/doc/refman/8.0/en/cast-functions.html). (Bug #30524, Bug #11747058) * InnoDB now supports redo log archiving. Backup utilities that copy redo log records may sometimes fail to keep pace with redo log generation while a backup operation is in progress, resulting in lost redo log records due to those records being overwritten. The redo log archiving feature addresses this issue by sequentially writing redo log records to an archive file. Backup utilities can copy redo log records from the archive file as necessary, thereby avoiding the potential loss of data. For more information, see Redo Log Archiving (https://dev.mysql.com/doc/refman/8.0/en/innodb-redo-log.html#innodb-redo-log-archiving). * To provide additional indexing options for JSON data, InnoDB now supports multi-value indexes. A multi-value index is a secondary index defined on a column that contains an array of values. * MySQL now provides a clone plugin that permits cloning InnoDB data locally or from a remote MySQL server instance. A local cloning operation stores cloned data on the same server or node where the MySQL instance runs. A remote cloning operation transfers cloned data over the network from a donor MySQL server instance to the recipient server or node where the cloning operation was initiated. The clone plugin supports replication. In addition to cloning data, a cloning operation extracts and transfers replication coordinates from the donor and applies them on the recipient, which enables using the clone plugin for provisioning Group Replication members and replication slaves. Using the clone plugin for provisioning is considerably faster and more efficient than replicating a large number of transactions. Group Replication members can also be configured to use the clone plugin as an alternative method of recovery, so that members automatically choose the most efficient way to retrieve group data from seed members. For more information, see The Clone Plugin (https://dev.mysql.com/doc/refman/8.0/en/clone-plugin.html), and Cloning for Distributed Recovery (https://dev.mysql.com/doc/refman/8.0/en/group-replication-cloning.html). * The compatibility policies that Group Replication implements for member versions in groups now consider the patch version of a member's MySQL Server release. Previously, only the major version was considered. Using the patch version means Group Replication can better maintain replication safety for mixed version groups during group reconfigurations and upgrade procedures. The compatibility policies are applied when a member joins the group, either for the first time or following its upgrade, when a donor is selected for state transfer, and when a primary member election takes place. Members running MySQL 8.0.16 or lower, or MySQL 5.7, only take into account the major version in these situations. For a primary member election, so that all members come to the same decision, members running releases from MySQL 8.0.17 adjust their policies to match members running lower releases if any are in the group. In a multi-primary mode group where members running multiple MySQL Server versions are online, for example during a rolling online upgrade procedure, Group Replication now automatically manages the read-write and read-only status of members running releases from MySQL 8.0.17. If a member leaves the group, the members running the version that is now the lowest are automatically set to read-write mode. When you change a mixed version group that was running in single-primary mode to run in multi-primary mode, using the group_replication_switch_to_multi_primary_mode() UDF, Group Replication automatically sets members to read-write or read-only mode depending on their MySQL server version. The improved compatibility policies influence the behavior of group members during an online upgrade procedure from one patch version to another, in the same ways as the behavior during upgrades from one major version to another was influenced previously. For a multi-primary mode group, the number of members in read-write mode is reduced during the upgrade procedure, but Group Replication now automatically manages their read-write status when the upgrade is complete. For a single-primary mode group, if you want the primary to remain as the primary, it must be upgraded last. * Group Replication can now use a remote cloning operation for state transfer to a joining member during distributed recovery. The remote cloning operation lets you add new members to the group without transferring the group's data to the server manually beforehand. To use this functionality, you must install the Clone plugin on the donor and joining member, grant the BACKUP_ADMIN permission to the replication user for distributed recovery, and set the new group_replication_clone_threshold system variable to an appropriate level. Group Replication automatically configures the required Clone plugin settings and manages the remote cloning operation. When cloning is complete and the joining member has restarted, the transactions that the group applied while the remote cloning operation was in progress are transferred to the joining member by replication from a donor's binary log, to complete distributed recovery. * Data that is held in the binary log transaction and statement caches during a transaction is in unencrypted format in the memory buffer that stores the cache. The data is written to a temporary file on disk if it exceeds the space available in the memory buffer. From MySQL 8.0.17, when binary log encryption is active on the server (binlog_encryption=ON), the temporary files used for the binary log cache are now encrypted using AES-CTR (AES Counter mode) for stream encryption. Because the temporary files are volatile and tied to a single process, they are encrypted using single-tier encryption, using a randomly generated file password and initialization vector that exist only in memory and are never stored on disk or in the keyring. After each transaction is committed, the binary log cache is reset: the memory buffer is cleared, any temporary file used to hold the binary log cache is truncated, and a new file password and initialization vector are randomly generated for use with the next transaction. This reset also takes place when the server is restarted after a normal shutdown or an unexpected halt. * An incomplete SQL predicate has the form WHERE value, in which value is a column name or constant expression and no comparison operator is used. MySQL now rewrites any predicate of this type internally as WHERE value != 0 during the contextualization phase, so that the query resolver, query optimizer, and query executor need work only with complete predicates. The principal visible effect of this change is that, for Boolean values, EXPLAIN output now shows true and false, rather than 1 and 0. * The optimizer now transforms a WHERE condition having NOT IN (subquery), NOT EXISTS (subquery), IN (subquery) IS NOT TRUE, or EXISTS (subquery) IS NOT TRUE internally into an antijoin, thus removing the subquery. This is similar to the existing IS NULL (Not exists) outer join optimization; see EXPLAIN Extra Information (https://dev.mysql.com/doc/refman/8.0/en/explain-output.html#explain-extra-information), for further information. In addition, the semijoin materialization can now be used for a WHERE condition having IN (subquery) IS TRUE, or EXISTS (subquery) IS TRUE, or when the IN condition belongs to a left join such as SELECT * FROM t1 LEFT JOIN t2 ON t2.x IN (SELECT * FROM t3). See Optimizing IN and EXISTS Subquery predicates with Semijoin Transformations (https://dev.mysql.com/doc/refman/8.0/en/semijoins.html). Also as a result of this work, MySQL is now able to simplify a condition of the form (x IS TRUE) IS FALSE as x IS NOT TRUE, which can be tested more quickly and optimized more easily than the condition as originally written. * InnoDB parallel read thread performance for large data sets was improved through better utilization of read threads, through a reduction in read thread I/O for prefetch activity that occurs during parallel scans, and through support for parallel scanning of partitions. The parallel read thread feature is controlled by the innodb_parallel_read_threads variable. The maximum setting is now 256, which is the total number of threads for all client connections. If the thread limit is reached, connections fall back to using a single thread. * mysqlbinlog now supports the --compress (or -C) option to enable compression in the client/server protocol. [To be continued]
↧
MySQL Community Server 8.0.17 has been released (part 2/3) (no replies)
[This is part 2 of the announcement]
Bugs Fixed
* NDB Cluster: Compile times for NDB Cluster using the
included compile_cluster build script have been improved
by removing options for software components not strictly
necessary for running MySQL Cluster. (Bug #29355872)
* NDB Cluster: Attempting to change an NDB table's column
properties (such as COLUMN_FORMAT) using ALTER TABLE
ALGORITHM=INPLACE was rejected, which is correct
behavior, but which raised a misleading error message.
(Bug #28929906)
* InnoDB: A failure occurred when attempting to kill a
process that was executing a row count. (Bug #29939617)
* InnoDB: Due to a regression introduced in MySQL 8.0.14,
in-place upgrade on a case sensitive file system from
MySQL 5.7 or a MySQL 8.0 release prior to MySQL 8.0.14 to
MySQL 8.0.16 failed for instances with partitioned tables
and lower_case_table_names=1. The failure was caused by a
case mismatch issue related to partitioned table file
names. The fix that introduced the regression was
reverted, which permits upgrades to MySQL 8.0.17 from
MySQL 5.7 or MySQL 8.0 releases prior to MySQL 8.0.14 to
function as normal. However, the regression is still
present in the MySQL 8.0.14, 8.0.15, and 8.0.16 releases.
In-place upgrade on a case sensitive file system from
MySQL 8.0.14, 8.0.15, or 8.0.16 to MySQL 8.0.17 fails
with the following error when starting the server after
upgrading binaries or packages to MySQL 8.0.17 if
partitioned tables are present and
lower_case_table_names=1:
Upgrading from server version version_number with
partitioned tables and lower_case_table_names == 1 on a case sensitive
file
system may cause issues, and is therefore prohibited. To upgrade anywa
y,
restart the new server version with the command line option 'upgrade=F
ORCE'.
When upgrade is completed, please execute 'RENAME TABLE part_table_nam
e
TO new_table_name; RENAME TABLE new_table_name
TO part_table_name;' for each of the partitioned tables.
Please see the documentation for further information.
If you encounter this error when upgrading to MySQL
8.0.17, perform the following workaround:
1. Restart the server with --upgrade=FORCE to force the
upgrade operation to proceed.
2. Identify partitioned table file names with lowercase
suffixes:
mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME
LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
3. For each file identified, rename the associated
table using a temporary name, then rename the table
back to its original name.
mysql> RENAME TABLE table_name TO temporary_table_name;
mysql> RENAME TABLE temporary_table_name TO table_name;
4. Verify that there are no partitioned table file
names with lowercase suffixes (an empty result set
should be returned).
mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME
LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
Empty set (0.00 sec)
5. Run ANALYZE TABLE on each renamed table to update
the optimizer statistics in the
mysql.innodb_index_stats and
mysql.innodb_table_stats tables.
Because of the regression still present in the MySQL
8.0.14, 8.0.15, and 8.0.16 releases, importing
partitioned tables from MySQL 8.0.14, 8.0.15, or 8.0.16
to MySQL 8.0.17 is not supported on case sensitive file
systems where lower_case_table_names=1. Attempting to do
so results in a "Tablespace is missing for table" error.
(Bug #29823032, Bug #29917793, Bug #95834)
References: This issue is a regression of: Bug #26925260.
* InnoDB: lock_sys mutex contention caused by lock-wait
functions (lock_wait_suspend_thread() and
lock_wait_table_release_slot()) was reduced. (Bug
#29814339)
* InnoDB: The fseg_n_reserved_pages_low() function, which
determines the number of pages reserved by a segment, did
not validate results read from the segment inode. (Bug
#29761998)
* InnoDB: Creation of the transaction rollback list
(hit_list) was decoupled from lock acquisition calls
(lock_rec_lock calls) to permit the use of different
latching schemes. (Bug #29753800)
* InnoDB: Disabling Performance Schema consumers caused an
ALTER TABLESPACE ... ENCRYPTION operation to assert. (Bug
#29646974, Bug #95005)
* InnoDB: Error messages were revised to remove references
to .frm files, which are not used in MySQL 8.0. (Bug
#29639655)
* InnoDB: It was possible for a background thread to check
the encryption status of an undo tablespace before the
undo tablespace was fully initialized and the encryption
flag set. (Bug #29600309)
* InnoDB: A table name parsing function call returned false
when parsing serialized dictionary information (SDI)
tables names, which are not formatted to include a
database name. The buffer that holds the database name
remained uninitialized, causing Valgrind errors. (Bug
#29550527)
* InnoDB: The space reserved in the mini-transaction (mtr)
log buffer for dynamic metadata logging was insufficient.
(Bug #29524260)
* InnoDB: Inaccuracies in the Variance-Aware Transaction
Scheduling (VATS) implementation raised a signed integer
overflow error in an UBSan build of MySQL. (Bug
#29508517, Bug #91959)
* InnoDB: Insufficient memory barriers in the rw-lock
implementation caused deadlocks on ARM.
Thanks to Yibo Cai from Arm Technology for the
contribution. (Bug #29508001, Bug #94699)
* InnoDB: The INFORMATION_SCHEMA.INNODB_TABLESPACES
ENCRYPTION column was not updated after enabling undo
tablespace encryption. (Bug #29492911, Bug #94665)
* InnoDB: A relocated table could not be accessed due to
incorrect parsing of a schema or table name that included
a forward slash character (/), which the server
incorrectly interpreted as a directory separator. (Bug
#29492113)
* InnoDB: Various fixes and revisions were applied to the
InnoDB memcached source code. (Bug #29485891)
* InnoDB: To enable global access, the value of
innodb_directories variable is now stored internally as a
global variable instead of a static variable. (Bug
#29471990)
* InnoDB: In debug builds, the thd_innodb_tmpdir() function
did not accept a NULL argument. (Bug #29471846)
* InnoDB: A subtraction operation in the file space
allocation code incorrectly stored the result as an
unsigned variable, which raised an assertion failure.
(Bug #29466680)
* InnoDB: After moving or deleting default undo tablespaces
and restarting the server with a new
innodb_undo_directory value, MySQL recreated the undo
tablespaces in the new location but failed to update the
undo directory path in the data dictionary. (Bug
#29461900)
* InnoDB: A previously freed LOB page was accessed while
rolling back a transaction during recovery. (Bug
#29440408)
* InnoDB: A request was issued during recovery to read
pages into the buffer pool when there were no pages to be
read. A check was added to avoid the unnecessary read
request. (Bug #29440208)
* InnoDB: A regression introduced in MySQL 8.0.14 caused a
"Invalid (old?) table or database name" error when
creating a partitioned table on a MySQL instance with
lower_case_table_names=1. The change that caused the
regression has been reverted. (Bug #29426720, Bug #94519)
References: This issue is a regression of: Bug #26925260.
* InnoDB: A FULLTEXT index table created in MySQL 5.6 in a
database with a hyphen in its name caused a startup
failure after upgrading from MySQL 5.7 to MySQL 8.0.
Tablespace file paths for FULLTEXT auxiliary tables were
not found in the data dictionary, and the hyphen in the
database name was not handled correctly in subsequently
generated file paths. (Bug #29411899, Bug #94431)
* InnoDB: There was potential for data loss to occur if the
redo log was not logically empty and comprised a single
block, and the server exited during recovery after an
insert buffer merge generated new redo records but before
the new records could be flushed to disk. (Bug #29411832,
Bug #94448)
* InnoDB: InnoDB returned an unknown generic error when
attempting to create a tablespace for which the path and
file name exceeded the MAX_PATH limit on Windows. InnoDB
now returns a more meaningful error. (Bug #29341634)
* InnoDB: An undo tablespace file was not found after being
moved to a different directory. (Bug #29328158)
* InnoDB: The server failed to start with an
innodb_buffer_pool_size=default setting. The default
value was not checked for compatibility with dependent
system variable settings. (Bug #29267814, Bug #94065)
* InnoDB: The CREATE TABLESPACE ... ADD DATAFILE clause no
longer permits circular directory references. For
example, the circular directory reference (/../) in the
following statement is not permitted:
CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd 'any_directory/../ts1.ibd';
An exception to this restriction exists on Linux, where a
circular directory reference is permitted if the
preceding directory is a symbolic link. For example, the
data file path in the example above is permitted if
any_directory is a symbolic link. (It is still permitted
for data file paths to begin with '../'.)
To avoid upgrade issues, remove any circular directory
references from tablespace data file paths before
upgrading to MySQL 8.0.17 or higher. To inspect
tablespace paths, query the
INFORMATION_SCHEMA.INNODB_DATAFILES table. (Bug
#29157265)
* InnoDB: Manually changing the system time while the MySQL
server was running caused page cleaner thread delays.
(Bug #29138644, Bug #93708)
* InnoDB: UPDATE statements did not always disable
semi-consistent reads properly when encountering errors,
which could lead to assertion errors in debug mode. (Bug
#29047894)
* InnoDB: When purging a deleted row, the logic that
governs lock inheritance did not correctly determine the
type of lock that should be inherited to satisfy
constraint checks by active transactions. (Bug #29004362)
* InnoDB: An unnecessary read lock was taken on implicitly
opened data dictionary tables when executing a prepared
statement in LOCK TABLES mode. (Bug #28875646)
* InnoDB: During log application, after an OPTIMIZE TABLE
operation, InnoDB did not populate virtual columns before
checking for virtual column index updates. (Bug
#28834208)
* InnoDB: An operation that copied data from the clustered
index was performed incorrectly, causing spatial indexes
to use spatial rows with stale pointers to the clustered
index. (Bug #28758961)
* InnoDB: An INSERT operation involving a generated virtual
BLOB column resulted a secondary index being updated with
an incorrect value. (Bug #28652826)
* InnoDB: Configuring innodb_data_file_path and
innodb_temp_data_file_path using SET PERSIST_ONLY =
default incorrectly set the variable values to NULL. (Bug
#28590014)
* InnoDB: A CREATE TABLE ... REPLACE SELECT operation
raised a lock_rec_get_rec_not_gap(lock) assertion
failure. The operation set a flag on the transaction
object indicating that a REPLACE operation was requested,
but did not clear the flag before updating dependent
views, causing a subsequent INSERT operation to be
interpreted as a REPLACE operation, leading to the wrong
row locks being taken. (Bug #28523025, Bug #92068)
* InnoDB: With super_read_only enabled, an attempted RENAME
TABLE operation on a temporary table raised an assertion
instead of returning an error. (Bug #28490368, Bug
#91975)
* InnoDB: Valgrind errors were reported due to
uninitialized bytes read during a virtual index prefix
search. (Bug #28184025)
* InnoDB: InnoDB initialization failed when attempting to
create an system tablespace greater than 2GB in size.
(Bug #27538464)
* InnoDB: A full-text cache lock taken when data is
synchronized was not released if the full-text cache size
exceeded the full-text cache size limit. (Bug #25289359)
* InnoDB: The INNODB_METRICS metadata_table_reference_count
counter reported a negative value. (Bug #20584149, Bug
#75966)
* InnoDB: Client sessions using different
auto_increment_increment values while performing
concurrent insert operations could cause a duplicate key
error. (Bug #15851528, Bug #67526)
References: Reverted patches: Bug #14049391, Bug #65225.
* Partitioning: For partitioned tables, an ALTER TABLE
statement could cause incorrect query results under these
conditions:
+ The statement swapped columns by renaming them,
either directly with RENAME COLUMN or by replacement
with DROP COLUMN/ADD COLUMN.
+ A swapped column was used in a partitioning
expression.
+ The alteration was performed as an in-place
operation that did not redistribute rows between
partitions.
Such column renames are now prohibited unless the same
ALTER TABLE statement satisfies one of these conditions:
+ The statement makes the table nonpartitioned.
+ The statement redefines the table partitioning or
partitioning expression (which causes a table
rebuild that redistributes rows). This enables
supporting existing scenarios in which partitioning
expressions are updated to follow column renaming.
+ Partitioning is specified using PARTITION BY KEY()
with an empty column list. This partitions using the
primary key, which tracks column renaming.
(Bug #29541665, Bug #94792)
* Partitioning: ALTER TABLE ... EXCHANGE PARTITION failed
with the error Non matching attribute 'ROW_FORMAT'
between partition and table when the partitioned table
had partitions using different row formats, even when the
partition to be exchanged used the same row format as the
non-partitioned table. (Bug #28687608)
* Replication: When message fragmentation is in use for
large Group Replication messages (which is available, and
the default, from MySQL 8.0.16), if a fragmented message
sent by the group member with the highest node identifier
in XCom was partially delivered, and one or more members
then left the group prior to the delivery of the
remaining message fragments, reassembly of the message
caused Group Replication to stop working. The loss of
members meant that the node identifier of the original
sender was no longer valid in the new view of the group.
To correct this issue, reassembly of fragmented messages
now uses the delivery information from the last fragment
that was delivered, which reflects the new situation
after the view change, rather than from the first
fragment that was delivered, which reflects the old
situation before the view change. (Bug #29716639)
* Replication: The error message that is issued for a
discrepancy between the number of group members and the
auto-increment interval incorrectly referred to the
group_replication_auto_increment_increment system
variable, instead of the auto_increment_increment system
variable. The value of auto_increment_increment is
changed to the value specified by
group_replication_auto_increment_increment when Group
Replication starts, but only if auto_increment_increment
and auto_increment_offset have their default values, and
from MySQL 8.0, only in multi-primary mode. The value of
auto_increment_increment was always the value that was
checked for the error message, and it has now been
corrected to give the accurate system variable name. (Bug
#29542425)
* Replication: Group Replication cannot be started
following a MySQL Server upgrade that uses the MINIMAL
option (--upgrade=MINIMAL), which does not upgrade system
tables on which the replication internals depend.
Previously, in this situation, the server was waiting
indefinitely for Group Replication to start. The
situation is now handled correctly by unblocking the
waiting thread and issuing the expected error
ER_GRP_RPL_START_GRP_RPL_FAILED. (Bug #29423358)
* Replication: In Group Replication's Group Communication
System (GCS), a change to the processing of suspicions by
a member that is leaving the group, which reduced the
execution time for some test cases, caused an issue in
the event that recovery failed, because it led to a
circular dependency between the recovery failure and the
view change notification. Now, if an error makes recovery
impossible, GCS takes the handling actions in an
appropriate sequence. The member leaves the group, the
view change is applied, and then the recovery thread is
terminated. (Bug #29417365, Bug #29628909)
* Replication: When events generated by one MySQL server
instance were written to the binary log of another
instance, the second server implicitly assumed that the
first server supported the same number of binary log
event types as itself. Where this was not the case, the
event header was handled incorrectly. The issue has now
been fixed. Thanks to Facebook for the contribution. (Bug
#29417234)
* Replication: In Group Replication, joining members could
wrongly identify themselves as incompatible with an
existing replication group even if there were members at
the same version already in the group, because they
checked against all other members, including the member
at the highest version. Joining members also included
their own version in the compatibility check. Now,
joining members only compare themselves with the existing
group member at the lowest version, and do not count
their own version. (Bug #29390946)
* Replication: If a LOCK INSTANCE FOR BACKUP statement was
used to acquire an instance-level backup lock, then a
STOP SLAVE statement was issued, a deadlock could be
created with the SQL thread waiting on the backup lock
and the STOP SLAVE statement waiting on the SQL thread to
complete its current action. To prevent this situation,
the STOP SLAVE process now tries to acquire the backup
lock before proceeding, and returns an error if the lock
cannot be acquired. (Bug #29386503, Bug #93649)
* Replication: From MySQL 8.0.13, if any replication
channel has open temporary tables, the binary logging
format cannot be changed using SET @@global.binlog_format
or SET @@persist.binlog_format. Previously, if this
operation was attempted after the new restriction was
implemented, the wrong error message was returned to the
client (referencing a running replication channel applier
as the issue, rather than an open temporary table). The
appropriate error message is now returned. (Bug
#29370024, Bug #94340)
* Replication: Binary log checksums were handled
incorrectly when de-serializing a format description
event. (Bug #29355110)
* Replication: With row-based replication in use, when the
replication applier thread unpacked a row change event,
index values for any functional indexes were calculated
for both the "before" image and the "after" image. In the
case of the "before" image, the values were not
necessary. This calculation has therefore been removed
for the before image in order to optimize row unpacking.
(Bug #29304076)
* Replication: When a MEMORY table is implicitly deleted on
a master following a server restart, the master writes a
DELETE statement to the binary log so that slaves also
empty the table. This generated event now includes a
comment in the binary log so that the reason for the
DELETE statement is easy to identify. Thanks to Daniël
van Eeden for the contribution. (Bug #29157796, Bug
#93771)
* Replication: If an invalid starting offset was provided
in a SHOW BINLOG EVENTS FROM statement, the invalid
offset was returned in place of the correct starting
position for the first returned event. (Bug #29039732,
Bug #93544)
* Replication: The Group Replication UDFs for configuring
an online group sometimes did not return an error if an
issue arose during main execution. The UDFs also now
check whether the Group Replication plugin is stopping
before they start to initialize. (Bug #28978767)
* Replication: Replication could stop with a "record not
found" error when the value INDEX_SCAN,HASH_SCAN (the
default in MySQL 8.0) was set for the
slave_rows_search_algorithms system variable, and an
update event contained two updates to the same row in a
table that did not have a unique key, meaning that the
hash scan was used. In this situation, the second update
was missed by the hash scan due to the row change. Now,
after updating a row, the hash scan operation searches
for the updated row in the hash map, and applies any
further update.
When the value TABLE_SCAN,HASH_SCAN is set for the
slave_rows_search_algorithms system variable, so that the
search cannot use an index, the "record not found" error
can occur in the above situation whether or not the table
has a unique key. Also, with this setting, when a hash
scan is used on a table that has a unique key, in the
case of an update event containing two row updates that
are order-dependent, the updates might be applied out of
order, causing replication to stop with a duplicate key
error. To avoid these issues, the documentation has been
updated to state that the value TABLE_SCAN,HASH_SCAN
should not be used. (Bug #28846386)
* Replication: When binary logging is enabled on a
replication slave, the combination of the
--replicate-same-server-id and --log-slave-updates
options on the slave can cause infinite loops in
replication if the server is part of a circular
replication topology. (In MySQL 8.0, binary logging is
enabled by default, and slave update logging is the
default when binary logging is enabled.) However, the use
of global transaction identifiers (GTIDs) prevents this
situation by skipping the execution of transactions that
have already been applied. The restriction on this
combination of options has therefore now been removed
when gtid_mode=ON is set. With any other GTID mode, the
server still does not start with this combination of
options. As a safeguard against creating the problem
situation after the server has started, you now cannot
change the GTID mode to anything other than ON on a
running server that has this combination of options set.
Thanks to Facebook for the contribution. (Bug #28782370,
Bug #92754)
* Replication: The group communication engine for Group
Replication (XCom, a Paxos variant) did not handle out of
memory errors in an appropriate way. If memory could not
be allocated to make a copy of the payload for a message,
an error was logged but the message was still sent, with
a null payload. The Group Communication System (GCS) on
the receiving member discarded the message as empty, and
the XCom instance on the receiving member accepted this
action and did not retry, resulting in the message
effectively being skipped. This caused the GTID set on
the receiving member to diverge from the group, leading
to replication errors. XCom now terminates gracefully if
it experiences an out of memory error, so that this
situation cannot occur. (Bug #28702320)
* Replication: In query log events in the binary log, the
thread ID used for the execution of DROP TABLE and DELETE
statements was identified incorrectly or not at all. On a
multi-threaded replication slave, where temporary tables
were involved (which require the correct thread ID as
they are session specific), this omission resulted in
errors when using mysqlbinlog to replay the binary log
for point-in-time recovery. The thread ID is now set
correctly. (Bug #28642318, Bug #92398)
* Replication: When a trigger invoked an INSERT or UPDATE
statement that set a column to its default value, and the
DEFAULT expression of that column was non-deterministic,
the expected warning was not raised when the trigger
fired under statement-based replication. In addition, if
the binary logging format was MIXED, the
non-deterministic statements were logged in the format
used for STATEMENT rather than that used for ROW.
The statement that causes the trigger to fire checks at
resolution time whether any of the triggered statements
are non-deterministic. At this time, the triggered
statements have been parsed, but not resolved, so the
only check that can be performed is whether the triggered
statements directly reference any non-deterministic
operators. When the non-deterministic operator is used by
a DEFAULT expression, the non-determinism is not visible
until the triggered statement has been resolved, which
happens when the trigger fires.
This is fixed by adding an extra check when determining
the logging format, where a statement is flagged as
unsafe if any of its substatements can write to a table
that has a column with a non-deterministic DEFAULT
expression. Since it is not yet known at this point
whether the DEFAULT expression will be used by the
substatement, this check flags the statement as unsafe
even if the substatement provides an explicit value for
the column with a non-deterministic DEFAULT expression.
(Bug #28297486)
* Replication: When a slave server logs master status and
connection information to a table
(master_info_repository=TABLE), which is the default in
MySQL 8.0, the mysql.slave_master_info table was not
being updated on shutdown if the server was in super read
only mode (super_read_only=ON). No error was written to
the error log at this time, but replication failed after
server startup because the master log file and master log
position information was out of date. The thread that
updates the master info log at shutdown is now excluded
from read-only checks like other replication threads are,
so it can update the table even if the server is in super
read only mode. Error handling for a slave that is
shutting down has also been improved so that any failure
to write to the slave status logs results in an error in
the error log. (Bug #27675107, Bug #89987)
* Replication: If a replication slave tried to connect to
the master using an incorrect user name, host, or port,
the original error message specifying the reason for the
connection failure was overwritten with a generic
message. The issue has now been corrected in the output
from the SHOW SLAVE STATUS statement and in the
Performance Schema table replication_connection_status.
(Bug #26580064)
* macOS: For macOS installations performed using DMG
packages, launchd operation was problematic:
+ Previously, SHUTDOWN caused a restart if MySQL was
configured to start at boot time via the preference
pane. This also affected the mysqladmin shutdown
command. Server shutdown initiated in these ways now
works correctly.
+ Previously, RESTART did not work. It now works
correctly.
+ Previously, unexpected server exits did not cause
automatic restart if the server was not configured
to start at boot time. Exits with a nonzero exit
status now cause a restart regardless of boot-time
startup configuration.
(Bug #29789857)
* JSON: MAX() and MIN() used on expressions returning JSON
data sometimes compared these values as strings rather
than JSON values, which caused unexpected results; this
was particularly evident when the JSON values were
numbers.
This was due to the fact that GROUP BY when using
temporary tables with indexes did not compare JSON values
correctly. (Bug #28947381)
* JSON: JSON_TABLE() returned the error Unknown database ''
when executed from a stored function.
The root cause of this issue was that, when merging
tables from a select that used JSON_TABLE(), MySQL
checked only for derived tables. This caused the result
table returned by JSON_TABLE() to be noted as a regular
table, so that when attempting to execute the query, the
server failed to open it. Now MySQL checks whether the
table to be added is not an internal table, that is, not
a derived table, a JSON_TABLE() result table, or a
reference to a recursive common table expression. (Bug
#92976, Bug #28851656)
* Some foreign key error messages could differ depending on
whether the user had the GRANT OPTION privilege. (Bug
#29868844)
* During upgrade operations, upgrades of the help tables
failed if autocommit was disabled. (Bug #29865428, Bug
#95620)
* Fetching dynamically allocated dictionary objects into a
vector during upgrade while operating with a small
table_open_cache size caused data dictionary tables to be
reopened, triggering a garbage collection mechanism that
incorrectly freed collected objects. Subsequent attempts
to access the freed objects caused a segmentation fault.
(Bug #29823053)
* For upgrades from MySQL 5.7 to 8.0, the upgrade process
did not close the innodb_*_stats_backup57.ibd files in
the mysql system schema before removing them, resulting
in errors for subsequent file system operations. (Bug
#29791350)
* mysqld --initialize would fail if the file system was
mounted at the data directory mount point and a
lost+found file or directory was present. The lost+found
file or directory is now ignored during data directory
initialization. (Bug #29780434)
* MySQL upgrades did not assign the AUDIT_ADMIN privilege
to accounts that had the SUPER privilege. (Bug #29770732)
* The REGEXP_REPLACE() function did not handle empty
strings correctly in all cases. (Bug #29763554)
* An overly strict assertion could be raised during sorting
of stored program local objects. (Bug #29759547, Bug
#95062)
* The group_replication_get_communication_protocol() UDF,
which is used to query the group's communication protocol
version, failed if any group members were in RECOVERING
state, which was an unnecessary restriction. The UDF can
now be used provided that the member where it runs is in
ONLINE state, and is in contact with a majority of the
group. (Bug #29754967)
* For some arguments to REPEAT(), maximum length
calculations were not always handled correctly. (Bug
#29739778)
* UPDATE statements for tables with CHECK constraints could
fail to enforce the constraints. (Bug #29706621, Bug
#95189)
* For installation from RPM or Debian packages, if the
mysql_upgrade_info file in the data directory is found to
exist but is owned by root, it is now changed to the same
owner as the data directory. The correct SELinux file
context is also set. (Bug #29704041)
* Installing from RPM packages could result in an error log
with incorrect permissions. (Bug #29702462)
* A mysql_upgrade_info file created by the mysql_upgrade
program during a previous upgrade could only be modified
the operating system user that executed the mysql_upgrade
program, causing an upgrade error. A warning is now
issued instead of an error, which permits the upgrade
operation to proceed. The mysql_upgrade_info file is
deprecated and will be removed in a future MySQL version.
(Bug #29702060, Bug #95165)
* A replication group member that was unable to contact a
majority of the group before the
group_replication_unreachable_majority_timeout setting
was reached, and then exhausted the number of auto-rejoin
attempts specified by the
group_replication_autorejoin_tries system variable
without successfully rejoining, was sometimes unable to
carry out the action specified by the
group_replication_exit_state_action system variable. The
member tries to carry out the action using the current
session, which sometimes failed. The member now ensures
that the session is initialized before using it to
connect to the server to carry out the exit state action.
(Bug #29698754)
* When performing a upgrade, server-side SQL statements
that update data dictionary tables used a non-default
collation, causing an upgrade failure. (Bug #29697670,
Bug #95144)
* Starting the server with --skip-grant-tables and invoking
ROLES_GRAPHML() could lead to a server exit. (Bug
#29681975)
* SELECT DISTINCT when using fixed-length keys did not
deduplicate records properly in all cases. (Bug
#29628699)
* Client programs that used asynchronous C API functions
could access freed memory after occurrence of a fatal
error such as connection failure or receipt of a
too-large packet. (Bug #29596244)
* For failed data directory initialization, the server
could produce a message indicating that the directory
could be removed, even if the server itself did not
create it. The message now indicates that only files in
the directory created by the server can be removed. (Bug
#29594082, Bug #94880)
* In MySQL 8.0, the keyring_encypted_file plugin could not
read a file created by a MySQL 5.7 keyring_encypted_file
plugin. (Bug #29588345)
* In builds with Undefined Behavior Sanitizer enabled,
runtime errors occurred in my_strtoll10_mb2() and
val_decimal(). (Bug #29585648, Bug #29594951)
* Some diagnostics produced by the server while checking
grant table structure at startup were written as errors
rather than warnings. (Bug #29558993)
* The comp_err utility could read uninitialized data. (Bug
#29550442)
* Enabling audit log encryption could cause a server exit.
(Bug #29549327)
* RPM package obsoletes were updated to enable successful
upgrades from MariaDB to MySQL on EL8. (Bug #29549127,
Bug #29623146, Bug #29623201, Bug #29659212)
* In a join of the form LEFT JOIN t ON column WHERE t.x=0
IS NOT TRUE, MySQL evaluated IS NOT TRUE as FALSE for a
NULL argument in a null-complemented row, and rejected
it. This caused an invalid conversion of the left join to
an inner join, so that there were missing rows in the
result. The same issue affected joins of the same form
but having IS NOT FALSE in the WHERE condition. (Bug
#29540230)
* If the read_only system variable was enabled, its value
improperly was applied against updates to the character
set and collation data dictionary tables. (Bug #29533590,
Bug #94769)
[To be continued]
↧
↧
MySQL Community Server 8.0.17 has been released (part 3/3) (no replies)
[This is part 3 (last) of the announcement ]
* The functions STATEMENT_DIGEST() and
STATEMENT_DIGEST_TEXT() used character_set_client while
parsing the function's argument instead of the character
set of the argument. (Bug #29526571)
* The server now tracks data dictionary upgrades to ensure
that INFORMATION_SCHEMA views are recreated when data
dictionary tables are changed. (Bug #29513265)
* Execution of STATEMENT_DIGEST() or
STATEMENT_DIGEST_TEXT() could have unintended side
effects on data in the
performance_schema.events_statements_summary_by_digest
table. (Bug #29512067)
* The implementation for CREATE TABLE did not provide the
table a clearly defined starting cursor when no seeks or
writes were performed. (Bug #29511318)
* When a table is const optimized, any predicate terms in
the join's ON condition should also be evaluated on the
tables marked as const to make sure that the row
qualifies for the ON condition.
The optimizer failed to mark a table as const when it was
handled as having an impossible ON condition, in which
case the resulting row from this table is a NULL extended
row.
This fix sets the const_table flag for the table and
marks the row as a NULL row. It also changes EXPLAIN
output for a table optimized as having an impossible ON
condition, where the resulting NULL values from this row
are now propagated into the rows column values, as with
other const rows. (Bug #29493830)
* A query containing an IN subquery could return
superfluous rows when optimizer_switch did not include
firstmatch=on. (Bug #29493026)
* RPM package detection of whether the operating system is
EL6 or EL7 failed on some systems. (Bug #29492896)
* SQL layer validation of keys stored in
storage-engine-private data fields in the data dictionary
was disabled to permit storage engines to add new keys as
required. Storage engines are now responsible for key
validation. (Bug #29491593, Bug #94667)
* Checks for NULL returned an incorrect result for some
expressions comparing rows. (Bug #29491083)
* When optimizing a table join which included ORDER BY and
LIMIT, the optimizer modified the select limit on the
first table by taking the fanout of the entire join into
consideration. The fanout was calculated using the
filter_effect for each table, which can be set to
COND_FILTER_STALE (-1) to indicate an unknown value. This
value was not actually checked for by the optimizer,
which could result in a negative fanout, leading to an
unexpected rows value of 0 in the EXPLAIN output for the
query.
Now COND_FILTER_STALE (filter_effect unknown) is
specifically checked for, and, if it is found, the fanout
is also assumed to be unknown, and the number of rows to
be selected from the first table is thus not modified by
the fanout for the entire join. (Bug #29487181, Bug
#29531472)
* An implicit assumption was made for the LEAST() and
GREATEST() functions that arguments to either of these
were all signed or all unsigned values. (Bug #29467577)
* Some arguments for the BIT_OR() function were not always
handled correctly. (Bug #29459549)
* For debug builds, mishandling of the user_attributes
column of the mysql.user system table could cause a
server exit. (Bug #29451897)
* MySQL Cluster-specific Debian debug packages had an
incorrect path to the debug symbols. (Bug #29446947)
* Compilation failure occurred when building with Protobuf
3.7.0. (Bug #29436791, Bug #94543)
* On Debian and Ubuntu, MySQL packages did not enable
mysql.service after upgrades from native MySQL packages.
(Bug #29435592)
* The server did not properly close shared-memory
connections when an error occurred, which could result in
unexpected server behavior. (Bug #29435426)
* The internal JOIN_CACHE::join_record() method attempted
to leave all tables on which it operated in the same
state with regard to the has_row and null_row flags by
saving the state upon entry and restoring the appropriate
flags when on completion.
The issue addressed here arose after these flags had been
restored, due to the fact that restore_last_record() was
also called to restore any records that had been
processed, which could lead to setting back a null_row
flag that had just been restored based on the saved
state. This is fixed by calling restore_last_record()
before the saved states are restored, rather than after,
as well as making sure that reset_null_row() is also
called if the saved state indicates that the null_row
flag was not set at the beginning. (Bug #29435133)
* Some ALTER TABLE statements using ADD COLUMN did not
perform as expected. (Bug #29428288)
References: This issue is a regression of: Bug #28333657.
* An incorrect error message was reported during upgrade
from MySQL 5.7 to MySQL 8.0 when a non-natively
partitioned table was encountered. The error message
referenced the -DWITH_PARTITION_STORAGE_ENGINE CMake
build option, which is not supported in MySQL 8.0. (Bug
#29426632, Bug #94518)
* MySQL Installer did not install OpenSSL DLL dependencies
if the Development component was not selected. (Bug
#29423421, Bug #94168)
* At startup, the server did not properly check the length
of user and host names in persisted variables. (Bug
#29420141)
* The parser could leak memory for certain
multiple-statement queries. (Bug #29419820)
* Installing MySQL on EL8 from RPM packages caused a
conflict with the installed MeCab library. (Bug
#29413115)
* On FreeBSD, stack traces dumped for fatal signals did not
work correctly. (Bug #29408039)
* With the derived_merge switch disabled in the value of
the optimizer_switch system variable, information
retrieved for base tables from INFORMATION_SCHEMA.TABLES
displayed inappropriate information in the TABLE_COMMENT
column. (Bug #29406053, Bug #94468)
* In certain cases, use of ORDER BY in a subselect did not
produce the expected result. (Bug #29402943)
* ROLLUP queries with wildcards (and probably also certain
other wildcard queries) could cause assertion errors.
(Bug #29396628)
* A condition inside an IF function having a constant
evaluating to TRUE was not always handled correctly. (Bug
#29394833)
* A code change in MySQL 8.0.13 related to full-text search
caused a segmentation fault. (Bug #29393105)
* mysqlpump did not check whether the argument to
--result-file was opened correctly and exited
unexpectedly if an error occurred. (Bug #29389828)
* In queries without joins, batch mode was not enabled
until after initialization was complete, so that OFFSET
rows were read outside of batch mode. This negated any
performance benefit to be had from batch mode. (Bug
#29373972)
* When renaming a functional index, the server did not
check for a possible duplicate index name. (Bug
#29360763)
* The system variable service did not check the input
buffer size for some operations. (Bug #29343505)
* For mysql system schema dumps, mysqlpump dumped certain
tables by row rather than as account-management
statements. (Bug #29343073)
* Creation of a functional index on a UNION subquery led to
an assertion in debug builds. (Bug #29342245)
* Non-numeric arguments to AVG() were not always handled
correctly. (Bug #29321764)
* Result sets with a very large number of columns could
cause client programs to use all available memory. Now
the client library allocates no more than
max_allowed_packet bytes for result set metadata,
returning an out-of-memory error if this limit is
exceeded. If this error occurs, it is fatal and the
client should disconnect. (Bug #29316814)
* A call to mysql_shutdown() could cause the client to exit
when the server and client were from different MySQL
series, due to return packet payload misinterpretation.
(Bug #29315393)
* Client programs could fail while reading result set
metadata if communicating with the server using the
pre-MySQL 4.1 protocol. (Bug #29304864)
* HANDLER statements did not always work correctly with
tables having generated columns. (Bug #29300049)
* Session-tracking information in the client/server
protocol could be mishandled. (Bug #29297652)
* Client programs that used the libmysqlclient C client
library could exit upon receipt of an OK packet
containing malformed session-tracking information. (Bug
#29297620)
* With the PAD_CHAR_TO_FULL_LENGTH SQL mode enabled,
password changes failed, with no warning or error
reported. (Bug #29287785)
* Initialization code of user-defined functions for the
keyring_aws plugin did not properly check whether the
plugin had been initialized. (Bug #29278153)
* Scalar subqueries were not always identified and handled
correctly when compared with aggregate or window
functions. (Bug #29276063)
* Ubuntu packages did not disable binary logging for
initialization scripts. (Bug #29263771)
* The internal collation map could become corrupted by use
of invalid collation names. (Bug #29258979)
* Single-table UPDATE and DELETE statements that used
indexed expressions could cause the server to exit when
executed as prepared statements. (Bug #29257254)
* The audit_log plugin did not log UNINSTALL PLUGIN
audit_log statements. (Bug #29248047)
* MySQL now uses open(O_TMPFILE) whenever applicable when
creating a temporary file that is immediately unlinked.
This is more efficient than previously and avoids the
small possibility of a race condition. Thanks to Daniel
Black for the contribution. (Bug #29215177, Bug #93937)
* audit_log filtering operations could leak memory. (Bug
#29201747)
* The GRANT OPTION privilege could be mishandled in some
cases. (Bug #29179334)
* Previously, LIKE comparisons could be incorrect if either
of the _ or % SQL wildcard characters was used as the
ESCAPE character. These characters can now be used. (Bug
#29175461, Bug #93811)
* The component_sys_variable service could fail to read
certain system variables, causing a server exit. (Bug
#29162657)
* Multiple-table UPDATE statements could search for
incorrect generated-column values when determining which
row to update. (Bug #29154379)
* If the server was started with Performance Schema
parameters that caused an out-of-memory condition,
startup failed. (Bug #29140212, Bug #93726)
* For consistency and compliance with standard SQL, the
ISNULL() function is now printed as IS NULL in warnings
generated by EXPLAIN statements. (Bug #29119455)
* Some supplemental Unicode characters could incorrectly be
flagged with a warning message as invalid. (Bug
#29110613, Bug #93626)
* For upgrades from MySQL 5.7 to 8.0, the root user was not
given all dynamic privileges. (Bug #29043233)
* When using subpartitioning, table serialized dictionary
information (SDI) was not stored in any tablespace file.
(Bug #29020745, Bug #93499)
* Privileges for dropping some Performance Schema tables
were checked incorrectly. (Bug #29010031)
* mysqldump failed to wrap SET NAMES utf8mb4 and SET
character_set_client = utf8mb4 statements within
version-specific comments, which could cause
compatibility problems. (Bug #29007506, Bug #93450)
* For a unique index created on one or more columns defined
as NULL, the optimizer failed to handle joins using that
index as eq_ref.
As part of this fix, late NULL filtering is now also
performed to avoid treating comparisons with NULL as
potential equality matches. (Bug #28965762, Bug
#29337233)
* For debug builds, an assertion could be raised by string
comparisons for which the expected and actual collation
differed. (Bug #28960901)
* The server did not handle correctly a subquery which,
prior to conversion to a semijoin, contained a merged
derived table or common table expression which in turn
had a WHERE clause with an outer reference against an
indexed column. (Bug #28955216)
* A query that employed a derived table which included an
ORDER BY was not always handled correctly. (Bug
#28942965)
* When clients were terminated for inactivity exceeding the
wait_timeout value, the message written to the error log
was unclear. Now ER_NET_WAIT_ERROR is written, which is
more specific about the cause of the problem. (Bug
#28940167, Bug #93240)
* Concurrent execution of FLUSH PRIVILEGES along with
CREATE USER or ALTER USER could cause the server to
stall. (Bug #28937018, Bug #93085)
* CASE statement comparisons that relied on index prefix
values could produce incorrect results. (Bug #28934315,
Bug #93215)
* When adjusting the query cost after sort elimination to
compensate for sorts that had not been considered in the
original cost estimate, and the estimates could sometimes
be too low, or even negative.
The sort cost is added to the total cost in
Optimize_table_order::consider_plan(), and subtracted
from the total cost in JOIN::optimize() if it is found
that sorting is not needed.
If consider_plan() finds that sorting is not needed, it
does not add the sort cost to the total cost, but still
records a sort cost in JOIN::sort_cost(), and this is set
to the sort cost of the candidate plan considered
previously. Later, JOIN::optimize() saw that the JOIN
object had an associated sort cost, and subtracted that
cost from the total cost, since it also sees that no sort
is needed. Since the sort cost came from a candidate plan
that was not the same as the chosen plan, the estimate
was incorrect.
The fix is to make consider_plan() set JOIN::sort_cost to
0 if no sort cost is added to the total cost, so that the
mistaken adjustment of the cost in JOIN::optimize() is
not performed. (Bug #28884359)
* Some GIS code failed to compile under Visual Studio 2017
15.5.6. (Bug #28861188)
References: This issue is a regression of: Bug #28842878.
* Stored generated column values and indexes on virtual
generated columns were not correctly updated after
columns on which these generated columns depended were
swapped using ALTER TABLE with RENAME COLUMN or CHANGE
COLUMN.
Renaming of base columns for generated columns, generated
defaults, and functional indexes is now prohibited unless
the same ALTER TABLE statement satisfies one of these
conditions:
+ The statement removes the generated column,
generated default, or functional index.
+ The statement updates the dependent expression in
question. This enables supporting existing scenarios
in which generation expressions are updated to
follow base column renaming.
Restrictions on dropping columns on which generated
columns, generated defaults, or functional indexes depend
were relaxed in a similar way. (Bug #28772251, Bug
#92727)
* Base columns were not excluded from index-only access by
a generated column. (Bug #28652733)
References: See also: Bug #29664369. This issue is a
regression of: Bug #23169112.
* SET PERSIST_ONLY did not properly handle the
version_tokens_session system variable. (Bug #28542569)
* For debug builds, improper error checking for CREATE
TABLE statements could cause an assertion to be raised.
(Bug #28490361, Bug #91976)
* MySQL 5.7 supported foreign keys on InnoDB tables with a
parent key for which part of the referenced columns were
hidden, but MySQL 8.0 did not. MySQL 8.0 now supports
this capability. (Bug #28480149, Bug #91952)
* INSERT ... ON DUPLICATE KEY UPDATE did not consider
privileges granted by active roles. (Bug #28395115)
* For unloaded components, component options specified at
startup with a --loose- prefix were not processed if the
component was later loaded at runtime. (Bug #28341329)
* Long passwords solicited interactively by client programs
could fail to be null-terminated. (Bug #28121400)
* When building MySQL, CMake begins the process of
downloading Boost by creating a zero-length tarball in
the destination directory, which is removed when the
download is complete. If the download was interrupted or
timed out, the presence of this file prevented CMake from
attempting to perform the download the time it was run.
Now the zero-length tarball, if present, is removed
before the download is started. (Bug #28089173)
* A thread pool group could be blocked when a thread
process tick time exceeded the maximum permitted value.
The tick time now uses a larger data type to permit
larger values. (Bug #28072609)
* Privileges were not checked correctly for ALTER USER ...
IDENTIFIED WITH ... BY. (Bug #27923149)
* MySQL does not support OpenSSL session tickets, but did
not set the SSL_OP_NO_TICKET flag to inform OpenSSL of
that. The flag is now set. (Bug #27655493)
* The audit_null plugin did not properly check for a null
event record. (Bug #27638290)
* UpdateXML() did not always free memory properly in
certain cases. (Bug #27312862)
* Empty values in the name column of the mysql.plugin
system table caused the server to exit during startup.
(Bug #27302459)
* The server did not properly check privileges for CACHE
INDEX statements. (Bug #26173827)
* With the thread_pool plugin enabled, the Performance
Schema status_by_thread table contained no data. (Bug
#25933891)
* The GRANT OPTION privilege was treated as related to
database operations. (Bug #25203933)
* REPAIR TABLE for ARCHIVE tables could result in a server
exit. (Bug #23304911)
* If an INSTALL PLUGIN statement contained invalid UTF-8
characters in the shared library name, it caused the
server to hang (or to raise an assertion in debug
builds). (Bug #14653594, Bug #23080148, Bug #27167197)
* Logging to the mysql.slow_log system table could fail
when values were to large for table columns. Now logging
proceeds on a best-effort basis, writing what information
can be provided. Otherwise, the row is discarded and a
message is written to the error log. (Bug #11748692, Bug
#37132)
* A query using WHERE date_column LIKE 'year_value' failed
with error 1525 Incorrect DATE value on Windows
platforms. (Bug #95780, Bug #29904751)
References: This issue is a regression of: Bug #29368521.
* A fix for a previous issue caused YEAR values to be
treated as unsigned, but this did not allow for possible
negative values arising during calculations involving
subtraction, which could lead to data truncation errors.
(Bug #95045, Bug #29668676)
References: This issue is a regression of: Bug #92209,
Bug #28562930.
* When working with derived tables with an aggregation
which had zero input rows, the results of the aggregate
functions were not properly copied into the temporary
table. This caused incorrect results in cases where the
derived table was evaluated multiple times, such as when
performing a lateral join. (Bug #94721, Bug #29514504)
* A window without a frame specification inheriting from a
window with an ORDER BY yielded an incorrect result. (Bug
#94251, Bug #29328529)
* The results returned by the functions REGEXP_REPLACE()
and REGEXP_SUBSTR() used UTF-16 rather than the character
set and collation of the expression searched for matches.
(Bug #94203, Bug #29308212)
* A UNION ALL query with SUM(constant) was processed very
slowly compared to the same query using SUM(column)
instead. (Bug #93922, Bug #29227464)
* JSON_OBJECTAGG() is non-deterministic in the presence of
duplicate keys unless the window has ordering on the key,
which is expected behavior, but a key-value pair that was
no longer in the window frame still appeared in the
result. (Bug #93822, Bug #29175262)
* LIMIT was applied before HAVING in queries with
subselects. (Bug #93214, Bug #28934388)
References: This issue is a regression of: Bug #25466100.
* A query involving GROUP BY on a TIMESTAMP column resulted
in a duplicate entry for key (ER_DUP_ENTRY) error. This
problem arose when TIMESTAMP values were inserted into a
table using a given setting for the time zone and these
values were later fetched after the time zone setting had
been changed, such that at least some of the inserted
TIMESTAMP values occurred during the hour that the time
changed from standard to daylight time (DST) in the new
time zone, during which time the same TIMESTAMP value can
exist twice. Now, when the server would otherwise return
the error DUPLICATE ENTRY FOR KEY 'group_key', if the
grouping involves a TIMESTAMP column, it instead raises
the error Grouping on temporal is non-deterministic for
time zones having DST. Please consider switching to UTC
for this query.
In addition, it is suggested to set
explicit_defaults_for_timestamp to ON as well as one or
more of MODE_NO_ZERO_IN_DATE, MODE_NO_ZERO_DATE, or
MODE_INVALID_DATES as part of the server SQL mode to help
avoid this issue. (Bug #90398, Bug #27970159)
On Behalf of Oracle/MySQL Release Engineering Team,
Balasubramanian Kandasamy
↧
MySQL Router 8.0.17 for MySQL Server 8.0 and 5.7 has been released (no replies)
Dear MySQL users, MySQL Router 8.0.17 is a new release for MySQL Router 8.0 series. MySQL Router 8.0 is highly recommended for use with MySQL Server 8.0 and 5.7. Please upgrade to MySQL Router 8.0.17. The MySQL Router is a new building block for high availability solutions based on MySQL InnoDB clusters. By taking advantage of the new Group Replication technology, and combined with the MySQL Shell, InnoDB clusters provide an integrated solution for high availability and scalability for InnoDB based MySQL databases, that does not require advanced MySQL expertise. The deployment of applications with high availability requirements is greatly simplified by MySQL Router. MySQL client connections are transparently routed to online members of a InnoDB cluster, with MySQL server outages and cluster reconfigurations being automatically handled by the Router. To download MySQL Router 8.0.17, see the "Generally Available (GA) Releases" tab at http://dev.mysql.com/downloads/router. Package binaries are available for several platforms and also as a source code download. Documentation for MySQL Router can be found at http://dev.mysql.com/doc/mysql-router/en/ Enjoy! Changes in MySQL Router 8.0.17 (2019-07-22) * Functionality Added or Changed * Bugs Fixed Functionality Added or Changed * Added the use_gr_notifications [metadata-cache] option to enable Group Replication notifications, which is disabled by default. It supports group_replication/membership/quorum_loss, group_replication/membership/view, group_replication/status/role_change, and group_replication/status/state_change. Optionally use the new --conf-use-gr-notifications bootstrap command-line to enable this option in the generated configuration file. * Added a REST API that follows the OpenAPI 2.0 specification and is implemented as a plugin; load the plugin using [rest_api] in the configuration file. It also requires the http_server plugin. Use the optional require_realm configuration option (string) to define the authentication realm. The base-path for all REST endpoints is "api" followed by a numeric API version that is defined as the release date, such as "/api/20190722/". The system follows camelCase naming rules and errors follow RFC 7807. The system exposes a swagger.json file as /api/ {apiVersion}/swagger.json. Bugs Fixed * Bootstrapping could misclassify a hostname as IPv6 and surround it with square brackets in the state (state.json) file; and this produced a "Configuration error: cluster-metadata-servers is incorrect" error. A workaround was to disable ipv6 support on the system. (Bug #29876948, Bug #95531) * Starting the http_server plugin against a port that was already bound would yield a confusing error, such as "Error: bind('0.0.0.0:10100) failed: The operation completed successfully." (Bug #29823472) * Improved the connection counter logic to prevent a potential unexpected halt before completing the shutdown process. (Bug #29820725) * Requesting the metadata-cache health immediately after start up could cause an expected exit by get_destinations() if metadata_cache's cache-api was not yet initialized. (Bug #29820155) * Bootstrapping would fail on hosts that defined multiple network interfaces. (Bug #29814629) * Optimized logging mechanism; system generated log messages independent of the log level. Now log messages are only prepared if configured to do so. (Bug #29798420) * Fixed potential blocking during shutdown by adding proper libmysqlclient deinitialisation where needed. This bug only affected DEBUG builds. (Bug #29635378) * harness/CMakeLists.txt was renamed to harness/src/CMakeLists.txt. (Bug #29629788) * The loaded plugin message level was changed from level "info" to "debug". (Bug #29616101) * The bootstrap "invalid URI" error message was improved. (Bug #29609170) * HTTPS connections with ECDHE ciphers to Router's http_server component failed if built against OpenSSL 1.0.1. (Bug #29609052) * The file generated by mysqlrouter_passwd was world-readable, and is now user-readable (Bug #29589127) * For the REST API, unsupported query parameters now return the 400 HTTP status code; and remain ignored. (Bug #29556935) * Log lines above 512 characters were truncated. (Bug #29540910) * For the REST API, OPTION, TRACE, and CONNECT requests now return the application/problem+json Content-Type and 405 HTTP status code. (Bug #29539557) * The HTTP server component now supports .jpg/.jpeg image files, and file extension matches are now case-insensitive. (Bug #29508595) * Added Visual Studio 2019 support. (Bug #29454252) * An unknown [http_auth_realm] backend yielded an unclear error. (Bug #29421759) * An uncaught exception was generated if a client socket was shutdown the client peer address was retrieved. (Bug #29382585) * Misleading "Potential changes detected in cluster" warnings were added to Router's log file. Node order differences no longer cause these errors. (Bug #29264764, Bug #94060) * Router would start if bootstrap_server_addresses was empty or not set. Now Router fails to start in this case if cluster-metadata-servers (a dynamic-config attribute) is also empty. (Bug #28352482) * The .ini configuration file locations are now detected and displayed in --help output. (Bug #28261802) * With Debian packages, the bootstrap process could fail when used with the --directory option. (Bug #27034449)
↧
MySQL Enterprise Backup 8.0.17 has been released (no replies)
Dear MySQL users,
MySQL Enterprise Backup 8.0.17, a new version of the online MySQL backup
tool, is now available for download from the My Oracle Support (MOS) website
as our latest GA release. This release will be available on eDelivery (OSDC)
after the next upload cycle. MySQL Enterprise Backup is a commercial
extension to the MySQL family of products.
MySQL Enterprise Backup 8.0.17 supports only the MySQL Server 8.0.17.
For earlier versions of MySQL 8.0, use the MySQL Enterprise Backup
version with the same version number as the server. For MySQL server
5.7, please use MySQL Enterprise Backup 4.1, and for MySQL Server 5.6
and 5.5, please use MySQL Enterprise Backup 3.12.
A brief summary of the changes in MySQL Enterprise Backup (MEB)
version 8.0.17 is given below.
Changes in MySQL Enterprise Backup 8.0.17 (2019-07-22, General
Availability)
* Functionality Added or Changed
* Bugs Fixed
Functionality Added or Changed
* Before the current release, when backing up a server that
used the keyring_okv
(https://dev.mysql.com/doc/refman/8.0/en/keyring-okv-plugin.html)
plugin for InnoDB table encryption, mysqlbackup
must not be run by a sudo user of its operating system.
This restriction has now been removed. (Bug #29020232)
* The --datadir option is no longer required for restoring
a TTS backup
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/restore-use-tts.html).
If the option is specified and
its value does not match with that of the target server,
the restore will be aborted. (Bug #28546760)
* The --incremental-base option now accepts a new value,
history:last_full_backup, which makes it easy to create a
differential backup
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/glossary.html#glos_differential_backup).
See the description of --incremental-base for details.
* To avoid mysqlbackup failing to catch up with the growing
redo log during a backup operation and missing redo log
data, mysqlbackup now utilizes redo log archiving
(https://dev.mysql.com/doc/refman/8.0/en/innodb-redo-log.html#innodb-redo-log-archiving),
a new feature available on MySQL Server 8.0.17. Redo log archiving can be
disabled using the new mysqlbackup option
--no-redo-log-archive. See Backing up Using Redo Log Archiving
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-redo-log-archiving.html)
for details.
* mysqlbackup now supports encrypted InnoDB redo logs
(https://dev.mysql.com/doc/refman/8.0/en/innodb-tablespace-encryption.html#innodb-tablespace-encryption-redo-log).
The encrypted redo tablespaces are handled the same way
as the encrypted tablespaces for InnoDB tables. See
Working with Encrypted InnoDB Tablespaces
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-encrypted-innodb.html)
for details.
Bugs Fixed
* A backup failed when the value of the server's system
variable innodb_undo_directory contained in itself the
file path for the server's data directory. It was due to
a mishandling of the file path prefix of the undo
tablespace directory by mysqlbackup, which has been
corrected by this fix. (Bug #29849566)
* Restore of an incremental backup failed if its base full
backup had been restored with the --skip-binlog option.
(Bug #29757701)
* If a relative path was used with the
backup_innodb_data_home_dir option when backing up a
server, the whole directory specified by the option was
being copied into the target server's data directory
during a restore of the backup. Not only was that not the
expected behavior of mysqlbackup, but it also made
subsequent backups of the server failed when the same
argument for backup_innodb_data_home_dir was used again.
(Bug #29613025)
* When the binary log on the server was more than one level
below the data directory on the directory tree,
mysqlbackup failed to copy the binary log into a backup.
This was due to an error on parsing the path of the
binary log directory, which has been corrected by this
fix. (Bug #29710251)
* During a backup operation, when a table or database name
contains a slash (/), mysqlbackup always treated the
corresponding tablespace as an external tablespace; if
that was not actually the case, restore for the backup
was going to fail. With this fix, mysqlbackup checks if
the tablespace is really external and then handles it
appropriately. (Bug #29472939)
* External undo tablespaces were missing after a restore of
a backup directory extracted from a backup image using
the image-to-backup-dir command. It was because of the
mishandling of the tracker file for external tablespaces
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-files-backed-up-summary.html#meb_file_tablespace-tracker)
by the image-to-backup-dir command, which has been
corrected by this fix. (Bug #29401027)
* While no upgrade path exists between MySQL Enterprise
Backup 4.1 and 8.0, an attempt to update the mysqlbackup
package from release 4.1.3 to 8.0.16 on Ubuntu failed
with the complaint that the update tried to overwrite the
installation directory for mysqlbackup. With this fix,
package conflict information has been added so that at
the same attempt, the old package is uninstalled (with
the user's consent) before the new package is installed.
(Bug #29314267)
* When using MySQL Enterprise Backup 8.0 to back up MySQL
Server 5.7, an error was thrown, and the error message
suggested a wrong version of MySQL Enterprise Backup to
be used for the Server. With this fix, the appropriate
version of MySQL Enterprise Backup is suggested. (Bug
#29195233)
* When backing up a server that used the keyring_okv
(https://dev.mysql.com/doc/refman/8.0/en/keyring-okv-plugin.html)
plugin for InnoDB table encryption, if the
--host, --user and --port options were not specified with
the mysqlbackup command via the command line or a
configuration file, the backup failed. It was because in
that case, mysqlbackup had no values for those options
that it could use to connect to the server for keyring
operations. With this fix, default values are now set, so
that mysqlbackup connects to the server on localhost as
root and on port 3306 for keyring operations when those
options are not specified. (Bug #29015923)
* A copy-back-and-apply-log operation for a compressed
backup created using the --backup_innodb_data_home_dir
option with a relative file path terminated with signal 6.
(Bug #28967141)
* mysqlbackup hung during a restore operation when the
backup contained more than a hundred InnoDB tablespaces.
(Bug #28884254, Bug #29674585)
* A restore operation for a compressed backup failed with
an unexpected end of file error when the backup was
created using --compress-method=zlib and the
innodb_page_size was smaller than 16KB. (Bug #28623215)
* A backup created on an EL7 platform containing InnoDB
tables encrypted with MySQL Enterprise Transparent Data
Encryption (TDE) could not be restored to a server on a
Solaris platform. It was because in this case, the source
and the target platforms of the backup used different
byte ordering formats, causing difficulties in loading
the encryption key from the backup. This fix prevents the
issue by adding detection and conversion utilities for
different system architectures. (Bug #28569367)
* Using the --uncompress option for restoring a backup not
created with the --compress option caused the operation
to fail with the error No such file or directory. With
this fix, the proper error is thrown in the situation.
(Bug #28334690)
* A backup failed with the error Log scan was only able to
reach... when there was a large amount of DML activities
occurring in parallel on the server that was being backed
up. (Bug #27555969)
* During the InnoDB buffer pool dump in a backup operation,
mysqlbackup sometimes reported failure for the dump while
it was actually still in progress. The fix prevents the
problem by improving the way mysqlbackup checks for the
status of the dump. (Bug #27185901)
↧