MySQL

Dear MySQL users, MySQL Shell 8.0.19 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. ... [More] MySQL Shell 8.0 is highly recommended for use with MySQL Server 8.0 and 5.7. Please upgrade to MySQL Shell 8.0.19. 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.htmlThe 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.htmlFor 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.htmlFor 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.19, see the “General Availability (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.19 (2020-01-13, General Availability) InnoDB Cluster Added or Changed Functionality      * Incompatible Change: The AdminAPI now includes InnoDB        ReplicaSets, that enables you to administer asynchronous        replication set ups in a similar way to InnoDB cluster.        The addition of InnoDB ReplicaSet means that the InnoDB        cluster metadata schema has been upgraded to version 2.0.        Regardless of whether you plan to use InnoDB ReplicaSet        or not, to use MySQL Shell 8.0.19 and AdminAPI you must        upgrade the metadata of your clusters. Connect MySQL        Shell’s global session to your cluster and use the new        dba.upgradeMetadata() operation to upgrade the cluster’s        metadata to use the new metadata.        Warning        Without upgrading the metadata you cannot use MySQL Shell        8.0.19 to change the configuration of a cluster created        with earlier versions. You can only read the        configuration of the cluster, for example using        Cluster.status().        The dba.upgradeMetadata() operation upgrades any        automatically created MySQL Router users to have the        correct privileges. Manually created MySQL Router users        with a name not starting with mysql_router_ are not        automatically upgraded. This is an important step in        upgrading your cluster, only then can the MySQL Router        application be upgraded.        Warning        A cluster which is using the new metadata cannot be        administered by earlier MySQL Shell versions, for example        once you upgrade to version 8.0.19 you can no longer use        version 8.0.18 or earlier to administer the cluster.        To get information on which of the MySQL Router instances        registered with a cluster require the metadata upgrade,        issue        cluster.listRouters({‘onlyUpgradeRequired’:’true’}).      * AdminAPI now supports socket connections to be used for        cluster and replica set operations. (Bug #26265826)      * You can now get information about the MySQL Router        instances registered with a InnoDB cluster, and        unregister a Router from a cluster, for example when you        stop using it. The list of Routers registered with a        cluster contains information about whether the Router        instance is compatible with the version of MySQL on the        cluster instances, which guides you when upgrading a        cluster. Use the Cluster.listRouters() operation to show        a list of all Routers registered with the cluster. The        returned JSON object provides information such as the        hostname, ports, and if an upgrade is required. To filter        the list to only show Router instances that do not        support the latest metadata version use the        onlyUpgradeRequired option, for example by issuing        Cluster.listRouters({‘onlyUpgradeRequired’:’true’}). To        remove a registered Router from a cluster, use the        Cluster.removeRouterMetadata(router) operation.      * The AdminAPI includes support for InnoDB ReplicaSet, that        enables you to administer asynchronous replication sets        in a similar way to InnoDB cluster. InnoDB ReplicaSet        enables you to deploy an asynchronous replication set        consisting of a single primary and multiple secondaries        (traditionally referred to as the MySQL replication        master and slaves). You administer a ReplicaSet using        AdminAPI operations, for example to check the status of        the InnoDB ReplicaSet, and manually failover to a new        primary in the event of a failure. Similar to InnoDB        cluster, MySQL Router supports bootstrapping against        InnoDB ReplicaSet, which means you can automatically        configure MySQL Router to use your InnoDB ReplicaSet        without having to manually configure files. This makes        InnoDB ReplicaSet a quick and easy way to get MySQL        replication and MySQL Router up and running, making it        well suited to scaling out reads, development        environments, and applications that do not require the        high availability offered by InnoDB cluster. InnoDB Cluster Bugs Fixed      * The dba.configureLocalInstance() operation could fail        with a key not found (LogicError) error when executed on        a non-sandbox instance where it did not have access to        the my.cnf option file and the operation requested an        output configuration file to be specified. (Bug        #30657204)      * If a cluster had been deployed with MySQL Shell version        8.0.14 or earlier, the metadata contained an invalid port        number for X Protocol connections. The metadata upgrade        catches such ports and removes the invalid number. To        avoid problems with routing due to this incorrect port,        upgrade your cluster’s metadata. (Bug #30618264)      * When a replication slave was configured to read from an        InnoDB cluster primary, even with the appropriate        replication filtering to ignore the metadata replication        was failing when an instance was added to the cluster        using MySQL Clone as the recovery method. This was        because the recovery process was granting a privilege on        an account, which failed and broke replication. (Bug        #30609075)      * The Cluster.removeInstance() operation was issuing a        misleading error message when the instance was        unreachable, indicating that it did not belong to the        cluster when an alternative valid host or IP was used.        Now, the error indicates that the instance is        unreachable. (Bug #30580393)      * Although MySQL Shell version 8.0.18 added support for        IPv6 in WL#12758        (https://dev.mysql.com/worklog/task/?id=12758), using an        InnoDB cluster which consisted of MySQL Shell version        8.0.18 and MySQL Router 8.0.18 with IPv6 addresses was        not possible. With the release of version 8.0.19 of both        MySQL Shell and MySQL Router, be aware that:           + combining MySQL Shell version 8.0.18 with MySQL             Router 8.0.18 causes Router to fail, due to no IPv6             support. (BUG#30354273)           + combining MySQL Shell version 8.0.18 with Router             8.0.19 in a cluster which uses X Protocol             connections, results in AdminAPI storing mysqlX IPv6             values incorrectly in the metadata, causing Router             to fail. (BUG#30548843) However, combining MySQL             Shell version 8.0.18 with Router 8.0.19 in a cluster             which uses MySQL classic protocol connections, is             possible.        Therefore, to use InnoDB cluster with IPv6 addresses,        regardless of the protocol used, the recommended        deployment is MySQL Shell 8.0.19 and MySQL Router 8.0.19.        (Bug #30548843)        References: See also: Bug #30354273.      * When using automatic rejoin, if a target instance was        rejoining the cluster, operations such as        dba.rebootClusterFromCompleteOutage(), Cluster.status(),        and so on were failing. Now, clusters consider automatic        rejoin as an instance state instead of a check that        always aborts the operation. This ensures that        Cluster.status() is reported even for instances which are        rejoining the cluster, and that        dba.rebootClusterFromCompleteOutage() can detect        instances which are rejoining the cluster and override        the rejoin operation so that the cluster can be properly        rebooted. (Bug #30501590)      * SSL client certificate options for the clusterAdmin user        were not being copied when setting up connection options,        which made them fail when connecting. (Bug #30494198)      * When the automatically calculated localAddress is not        valid, for example when it exceeds the valid range, the        error message has now been improved. See Configuring        Ports        (https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-production-deployment.html#configuring-instance-ports).        (Bug #30405569)      * The AdminAPI ensures that all members of a cluster have        the same consistency level as configured at cluster        creation time. However, when high and non-default        consistency levels were chosen for the cluster, adding        instances to it resulted in an error 3796 which indicates        that group_replication_consistency cannot be used on the        target instance. This happened because the consistency        values of BEFORE, AFTER and BEFORE_AND_AFTER cannot be        used on instances that are RECOVERING and several        transactions happen while the instance is in the        RECOVERING phase. Other AdminAPI commands result in the        same error for the same scenario (high global consistency        levels) whenever at least one member of the cluster is        RECOVERING. For example, dba.getCluster(). The fix        ensures that all sessions used by the AdminAPI use the        consistency level of EVENTUAL when the cluster’s        consistency level is BEFORE, AFTER or BEFORE_AND_AFTER.        (Bug #30394258, Bug #30401048)      * Some privileges required for persisting configuration        changes on MySQL 8.0 servers were missing for the        clusterAdmin users created by AdminAPI. In particular, an        Access Denied error was being issued indicating the        SYSTEM_VARIABLES_ADMIN and PERSIST_RO_VARIABLES_ADMIN        privileges were required. Now these privileges are added        for the clusterAdmin user on MySQL 8.0 servers. (Bug        #30339460)      * When using MySQL Clone as the recovery method, trying to        add an instance that did not support RESTART to a cluster        caused MySQL Shell to stop unexpectedly. Now, in such a        situation a message explains that Cluster.rescan() must        be used to ensure the instance is added to the metadata.        (Bug #30281908)      * The autocommit and sql_mode system variables are session        settings, but they can be set globally to different        values. AdminAPI was failing if these variables had        non-default values in several different ways, for example        DML was failing, system variables could not be set and so        on. (Bug #30202883, Bug #30324461)      * Attempting to bootstrap MySQL Router against an InnoDB        cluster which had had the cluster administration user        modified or removed was failing. This was caused by the        privileges granted on the InnoDB cluster metadata table.        The recommended solution is to upgrade to metadata 2.0,        which changes the privileges on the metadata to ensure        this issue does not occur. (Bug #29868432)      * When you created a multi-primary cluster, the        group_replication_enforce_update_everywhere_checks system        variable was not being set automatically. However,        switching to multi-primary mode automatically enables        group_replication_enforce_update_everywhere_checks and        switching to single-primary disables it. Now, the        dba.createCluster() operation sets the        group_replication_enforce_update_everywhere_checks        variable as appropriate for single-primary or        multi-primary clusters. (Bug #29794779)      * In version 8.0.16, the autoRejoinTries option was added        to define the number of times an instance attempts to        rejoin the cluster after being expelled. The option is a        valid cluster setting, configurable through the AdminAPI        like many other options. However, the autoRejoinTries        option was not being listed by Cluster.options(). (Bug        #29654346)      * The InnoDB cluster metadata now supports host names up to        265 characters long, where 255 characters can be the host        part and the remaining characters can be the port number.        (Bug #29507913)      * dba.createCluster() could fail if the instance had been        started with innodb_default_row_format=COMPACT or        innodb_default_row_format=REDUNDANT. This was because no        ROW_FORMAT was specified on the InnoDB cluster metadata        tables, which caused them to use the one defined in        innodb_default_row_format. The metadata schema has been        updated to use ROW_FORMAT = DYNAMIC. (Bug #28531271)      * When an instance restarted, for example after a complete        outage, it could have super_read_only disabled. This        meant that instances which were not the primary could be        written to, resulting in the instances no longer being in        synchrony. This could result in        dba.rebootClusterFromCompleteOutage() failing with a        Conflicting transaction sets error. The fix ensures that        all instances have super_read_only=1 persisted while they        belong to the cluster, either through SET PERSIST_ONLY,        or through dba.configureLocalInstance() for instances        which do not support persisting. (Bug #97279, Bug        #30545872)      * The Cluster.status() operation could report an error        get_uint(24): field value out of the allowed range        because it was always expecting a positive value for some        fields that could in fact have negative values. For        example, this could happen when the clocks of different        instances were offset. (Bug #95191, Bug #29705983)      * If you changed the name of the clusterAdmin user once a        cluster had been created, you could encounter an error        such as The user specified as a definer does not exist.        This was because the clusterAdmin user was used as the        DEFINER of the views required by InnoDB cluster, and if        this user is renamed then the definer is in effect        missing. In version 8.0.19 the InnoDB cluster metadata        has been changed to avoid this problem, use        dba.upgradeMetadata() to upgrade the cluster. Clusters        deployed with 8.0.19 and later do not suffer from this        issue. (Bug #92128, Bug #28541069)      * It was not possible to create a multi-primary cluster due        to to cascading constraints on the InnoDB cluster        metadata tables. This has been fixed in version 8.0.19        and so to solve this issue upgrade your cluster using        dba.upgradeMetadata(). (Bug #91972, Bug #29137199) Functionality Added or Changed      * The JavaScript function require() has been improved in        MySQL Shell to support loading of local modules, in        addition to built-in modules and modules that are on        module search paths already known to MySQL Shell. If you        specify the module name or path prefixed with ./ or ../,        MySQL Shell now searches for the specified module in the        folder that contains the JavaScript file or module        currently being executed, or in interactive mode,        searches in the current working directory. If the module        is not found in that folder, MySQL Shell proceeds to        check the well-known module search paths specified by the        sys.path variable.      * MySQL Shell’s upgrade checker utility (the        util.checkForServerUpgrade() operation) includes the        following new and extended checks:           + The utility now flags all date, datetime, and             timestamp columns that have a default value of zero,             and states if the SQL mode (either global or for the             current session) allows the insertion of zero values             for these column types. By default, these are no             longer permitted in MySQL, and it is strongly             advised to replace zero values with valid ones, as             they might not work correctly in the future.           + The check for usage of removed functions now             includes the PASSWORD() function.           + The utility now checks for any orphaned tables which             are recognized by InnoDB, but the SQL layer thinks             they are handled by a different storage engine. This             situation can happen if manual updates are made in             the data directory. Orphaned tables can stall the             upgrade process if they are present.      * In MySQL Shell’s interactive mode, for JavaScript,        Python, or SQL, the \source command or its alias \. can        be used to execute code from a script file at a given        path. For compatibility with the mysql client, in SQL        mode only, you can now execute code from a script file        using the source command with no backslash and an        optional SQL delimiter. source can be used both in MySQL        Shell’s interactive mode for SQL, to execute a script        directly, and in a file of SQL code processed in batch        mode, to execute a further script from within the file.        In SQL mode only, you can also now use the \source        command’s alias \. (which does not use a SQL delimiter)        in a file of SQL code processed in batch mode. So with        MySQL Shell in SQL mode, you could now execute the script        in the /tmp/mydata.sql file from either interactive mode        or batch mode using any of these three commands:         source /tmp/mydata.sql;         source /tmp/mydata.sql         \. /tmp/mydata.sql        The command \source /tmp/mydata.sql is also valid, but in        interactive mode only. Bugs Fixed      * When searching for startup scripts in the platform’s        standard global configuration path (in the folder        %PROGRAMDATA%\MySQL\mysqlsh on Windows, or /etc/mysql/mysqlsh/ on Unix), MySQL Shell checked for the        incorrect script name shellrc, rather than the correct        name mysqlshrc. (Bug #30656548)      * On Windows, MySQL Shell passed UTF-8 encoded strings to        the NTFS file system, which stores file names in UTF-16        encoding. The mismatch caused files and folders to be        incorrectly named or located when non-ASCII characters        were used. MySQL Shell now converts all strings used in        operations on NTFS from UTF-8 to UTF-16, and converts        back to UTF-8 all strings received from Unicode function        versions of Windows API calls. (Bug #30538516)      * Some host names were not parsed correctly in the        connection data provided when running MySQL Shell’s        upgrade checker utility checkForServerUpgrade(). (Bug        #30536355)      * If the MySQL Server environment variable MYSQL_UNIX_PORT        (which specifies the default Unix socket file) was        updated by the same process that was then used to create        a MySQL Shell connection to a MySQL server using a socket        file, MySQL Shell cached and connected using the socket        file path that had previously been set, but reported that        a connection had been made using the updated socket file        path. The correct socket file used for the connection is        now displayed. (Bug #30533318)      * If a prompt theme file used to customize the MySQL Shell        prompt contained an ill-formed UTF-8 sequence, on startup        an error message was displayed in place of the prompt        text. MySQL Shell now validates the prompt theme file        before loading it, and if there is a problem, uses a        default prompt instead and issues an error message. (Bug        #30406283)      * If MySQL Shell was installed on Microsoft Windows at a        non-default location, and subsequently uninstalled, files        created after installation by the Python library used by        MySQL Shell were not removed. These files are now removed        when MySQL Shell is uninstalled from any location. (Bug        #30333801)      * Previously, most MySQL Shell options that expected an        integer value could be set with an empty value, in which        case the value 1 was applied. The exception was the        logLevel option, which required a value. The behavior has        now been standardized so all MySQL Shell options that        expect a non-string value must be specified with a value,        with the exception of options set on the command line.        The affected options are dba.gtidWaitTimeout, dba.logSql,        history.maxSize, and verbose. (Bug #30320839)      * When using MySQL Shell in interactive mode, using a        template literal in a multiple-line JavaScript statement        resulted in an error. The issue has now been fixed. (Bug        #30248651)      * In Python mode, when multiple statements were input to        MySQL Shell at the same time for execution in interactive        mode, only the first statement was executed correctly.        (Bug #30029568)      * The Debian control file for MySQL Shell has been        corrected to remove packaging errors that occurred when        certain variables were not defined. Thanks to Evgeniy        Patlan for the fix. (Bug #29802600, Bug #95158)      * In MySQL Shell’s parser for URI-like connection strings,        handling of path separators was previously platform        dependent. Unified parsing has now been introduced so        that Windows named pipes can be parsed correctly on Unix        platforms, and Unix socket files can be parsed correctly        on Windows platforms. (Bug #29456981)      * MySQL Shell now looks up host names by obtaining the        fully qualified domain name of the provided address and        using the absolute form of this name (with a trailing        dot). This method avoids potential issues caused by some        network configurations that resolve host names as        loopback addresses when they are actually addressable        externally. (Bug #27704559) On Behalf of Oracle/MySQL Release Engineering Team, Hery Ramilison [Less]

Dear MySQL users, MySQL Shell 8.0.19 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 ... [More] 8.0 and 5.7. Please upgrade to MySQL Shell 8.0.19. 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.19, see the "General Availability (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.19 (2020-01-13, General Availability) InnoDB Cluster Added or Changed Functionality * Incompatible Change: The AdminAPI now includes InnoDB ReplicaSets, that enables you to administer asynchronous replication set ups in a similar way to InnoDB cluster. The addition of InnoDB ReplicaSet means that the InnoDB cluster metadata schema has been upgraded to version 2.0. Regardless of whether you plan to use InnoDB ReplicaSet or not, to use MySQL Shell 8.0.19 and AdminAPI you must upgrade the metadata of your clusters. Connect MySQL Shell's global session to your cluster and use the new dba.upgradeMetadata() operation to upgrade the cluster's metadata to use the new metadata. Warning Without upgrading the metadata you cannot use MySQL Shell 8.0.19 to change the configuration of a cluster created with earlier versions. You can only read the configuration of the cluster, for example using Cluster.status(). The dba.upgradeMetadata() operation upgrades any automatically created MySQL Router users to have the correct privileges. Manually created MySQL Router users with a name not starting with mysql_router_ are not automatically upgraded. This is an important step in upgrading your cluster, only then can the MySQL Router application be upgraded. Warning A cluster which is using the new metadata cannot be administered by earlier MySQL Shell versions, for example once you upgrade to version 8.0.19 you can no longer use version 8.0.18 or earlier to administer the cluster. To get information on which of the MySQL Router instances registered with a cluster require the metadata upgrade, issue cluster.listRouters({'onlyUpgradeRequired':'true'}). * AdminAPI now supports socket connections to be used for cluster and replica set operations. (Bug #26265826) * You can now get information about the MySQL Router instances registered with a InnoDB cluster, and unregister a Router from a cluster, for example when you stop using it. The list of Routers registered with a cluster contains information about whether the Router instance is compatible with the version of MySQL on the cluster instances, which guides you when upgrading a cluster. Use the Cluster.listRouters() operation to show a list of all Routers registered with the cluster. The returned JSON object provides information such as the hostname, ports, and if an upgrade is required. To filter the list to only show Router instances that do not support the latest metadata version use the onlyUpgradeRequired option, for example by issuing Cluster.listRouters({'onlyUpgradeRequired':'true'}). To remove a registered Router from a cluster, use the Cluster.removeRouterMetadata(router) operation. * The AdminAPI includes support for InnoDB ReplicaSet, that enables you to administer asynchronous replication sets in a similar way to InnoDB cluster. InnoDB ReplicaSet enables you to deploy an asynchronous replication set consisting of a single primary and multiple secondaries (traditionally referred to as the MySQL replication master and slaves). You administer a ReplicaSet using AdminAPI operations, for example to check the status of the InnoDB ReplicaSet, and manually failover to a new primary in the event of a failure. Similar to InnoDB cluster, MySQL Router supports bootstrapping against InnoDB ReplicaSet, which means you can automatically configure MySQL Router to use your InnoDB ReplicaSet without having to manually configure files. This makes InnoDB ReplicaSet a quick and easy way to get MySQL replication and MySQL Router up and running, making it well suited to scaling out reads, development environments, and applications that do not require the high availability offered by InnoDB cluster. InnoDB Cluster Bugs Fixed * The dba.configureLocalInstance() operation could fail with a key not found (LogicError) error when executed on a non-sandbox instance where it did not have access to the my.cnf option file and the operation requested an output configuration file to be specified. (Bug #30657204) * If a cluster had been deployed with MySQL Shell version 8.0.14 or earlier, the metadata contained an invalid port number for X Protocol connections. The metadata upgrade catches such ports and removes the invalid number. To avoid problems with routing due to this incorrect port, upgrade your cluster's metadata. (Bug #30618264) * When a replication slave was configured to read from an InnoDB cluster primary, even with the appropriate replication filtering to ignore the metadata replication was failing when an instance was added to the cluster using MySQL Clone as the recovery method. This was because the recovery process was granting a privilege on an account, which failed and broke replication. (Bug #30609075) * The Cluster.removeInstance() operation was issuing a misleading error message when the instance was unreachable, indicating that it did not belong to the cluster when an alternative valid host or IP was used. Now, the error indicates that the instance is unreachable. (Bug #30580393) * Although MySQL Shell version 8.0.18 added support for IPv6 in WL#12758 (https://dev.mysql.com/worklog/task/?id=12758), using an InnoDB cluster which consisted of MySQL Shell version 8.0.18 and MySQL Router 8.0.18 with IPv6 addresses was not possible. With the release of version 8.0.19 of both MySQL Shell and MySQL Router, be aware that: + combining MySQL Shell version 8.0.18 with MySQL Router 8.0.18 causes Router to fail, due to no IPv6 support. (BUG#30354273) + combining MySQL Shell version 8.0.18 with Router 8.0.19 in a cluster which uses X Protocol connections, results in AdminAPI storing mysqlX IPv6 values incorrectly in the metadata, causing Router to fail. (BUG#30548843) However, combining MySQL Shell version 8.0.18 with Router 8.0.19 in a cluster which uses MySQL classic protocol connections, is possible. Therefore, to use InnoDB cluster with IPv6 addresses, regardless of the protocol used, the recommended deployment is MySQL Shell 8.0.19 and MySQL Router 8.0.19. (Bug #30548843) References: See also: Bug #30354273. * When using automatic rejoin, if a target instance was rejoining the cluster, operations such as dba.rebootClusterFromCompleteOutage(), Cluster.status(), and so on were failing. Now, clusters consider automatic rejoin as an instance state instead of a check that always aborts the operation. This ensures that Cluster.status() is reported even for instances which are rejoining the cluster, and that dba.rebootClusterFromCompleteOutage() can detect instances which are rejoining the cluster and override the rejoin operation so that the cluster can be properly rebooted. (Bug #30501590) * SSL client certificate options for the clusterAdmin user were not being copied when setting up connection options, which made them fail when connecting. (Bug #30494198) * When the automatically calculated localAddress is not valid, for example when it exceeds the valid range, the error message has now been improved. See Configuring Ports (https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-production-deployment.html#configuring-instance-ports). (Bug #30405569) * The AdminAPI ensures that all members of a cluster have the same consistency level as configured at cluster creation time. However, when high and non-default consistency levels were chosen for the cluster, adding instances to it resulted in an error 3796 which indicates that group_replication_consistency cannot be used on the target instance. This happened because the consistency values of BEFORE, AFTER and BEFORE_AND_AFTER cannot be used on instances that are RECOVERING and several transactions happen while the instance is in the RECOVERING phase. Other AdminAPI commands result in the same error for the same scenario (high global consistency levels) whenever at least one member of the cluster is RECOVERING. For example, dba.getCluster(). The fix ensures that all sessions used by the AdminAPI use the consistency level of EVENTUAL when the cluster's consistency level is BEFORE, AFTER or BEFORE_AND_AFTER. (Bug #30394258, Bug #30401048) * Some privileges required for persisting configuration changes on MySQL 8.0 servers were missing for the clusterAdmin users created by AdminAPI. In particular, an Access Denied error was being issued indicating the SYSTEM_VARIABLES_ADMIN and PERSIST_RO_VARIABLES_ADMIN privileges were required. Now these privileges are added for the clusterAdmin user on MySQL 8.0 servers. (Bug #30339460) * When using MySQL Clone as the recovery method, trying to add an instance that did not support RESTART to a cluster caused MySQL Shell to stop unexpectedly. Now, in such a situation a message explains that Cluster.rescan() must be used to ensure the instance is added to the metadata. (Bug #30281908) * The autocommit and sql_mode system variables are session settings, but they can be set globally to different values. AdminAPI was failing if these variables had non-default values in several different ways, for example DML was failing, system variables could not be set and so on. (Bug #30202883, Bug #30324461) * Attempting to bootstrap MySQL Router against an InnoDB cluster which had had the cluster administration user modified or removed was failing. This was caused by the privileges granted on the InnoDB cluster metadata table. The recommended solution is to upgrade to metadata 2.0, which changes the privileges on the metadata to ensure this issue does not occur. (Bug #29868432) * When you created a multi-primary cluster, the group_replication_enforce_update_everywhere_checks system variable was not being set automatically. However, switching to multi-primary mode automatically enables group_replication_enforce_update_everywhere_checks and switching to single-primary disables it. Now, the dba.createCluster() operation sets the group_replication_enforce_update_everywhere_checks variable as appropriate for single-primary or multi-primary clusters. (Bug #29794779) * In version 8.0.16, the autoRejoinTries option was added to define the number of times an instance attempts to rejoin the cluster after being expelled. The option is a valid cluster setting, configurable through the AdminAPI like many other options. However, the autoRejoinTries option was not being listed by Cluster.options(). (Bug #29654346) * The InnoDB cluster metadata now supports host names up to 265 characters long, where 255 characters can be the host part and the remaining characters can be the port number. (Bug #29507913) * dba.createCluster() could fail if the instance had been started with innodb_default_row_format=COMPACT or innodb_default_row_format=REDUNDANT. This was because no ROW_FORMAT was specified on the InnoDB cluster metadata tables, which caused them to use the one defined in innodb_default_row_format. The metadata schema has been updated to use ROW_FORMAT = DYNAMIC. (Bug #28531271) * When an instance restarted, for example after a complete outage, it could have super_read_only disabled. This meant that instances which were not the primary could be written to, resulting in the instances no longer being in synchrony. This could result in dba.rebootClusterFromCompleteOutage() failing with a Conflicting transaction sets error. The fix ensures that all instances have super_read_only=1 persisted while they belong to the cluster, either through SET PERSIST_ONLY, or through dba.configureLocalInstance() for instances which do not support persisting. (Bug #97279, Bug #30545872) * The Cluster.status() operation could report an error get_uint(24): field value out of the allowed range because it was always expecting a positive value for some fields that could in fact have negative values. For example, this could happen when the clocks of different instances were offset. (Bug #95191, Bug #29705983) * If you changed the name of the clusterAdmin user once a cluster had been created, you could encounter an error such as The user specified as a definer does not exist. This was because the clusterAdmin user was used as the DEFINER of the views required by InnoDB cluster, and if this user is renamed then the definer is in effect missing. In version 8.0.19 the InnoDB cluster metadata has been changed to avoid this problem, use dba.upgradeMetadata() to upgrade the cluster. Clusters deployed with 8.0.19 and later do not suffer from this issue. (Bug #92128, Bug #28541069) * It was not possible to create a multi-primary cluster due to to cascading constraints on the InnoDB cluster metadata tables. This has been fixed in version 8.0.19 and so to solve this issue upgrade your cluster using dba.upgradeMetadata(). (Bug #91972, Bug #29137199) Functionality Added or Changed * The JavaScript function require() has been improved in MySQL Shell to support loading of local modules, in addition to built-in modules and modules that are on module search paths already known to MySQL Shell. If you specify the module name or path prefixed with ./ or ../, MySQL Shell now searches for the specified module in the folder that contains the JavaScript file or module currently being executed, or in interactive mode, searches in the current working directory. If the module is not found in that folder, MySQL Shell proceeds to check the well-known module search paths specified by the sys.path variable. * MySQL Shell's upgrade checker utility (the util.checkForServerUpgrade() operation) includes the following new and extended checks: + The utility now flags all date, datetime, and timestamp columns that have a default value of zero, and states if the SQL mode (either global or for the current session) allows the insertion of zero values for these column types. By default, these are no longer permitted in MySQL, and it is strongly advised to replace zero values with valid ones, as they might not work correctly in the future. + The check for usage of removed functions now includes the PASSWORD() function. + The utility now checks for any orphaned tables which are recognized by InnoDB, but the SQL layer thinks they are handled by a different storage engine. This situation can happen if manual updates are made in the data directory. Orphaned tables can stall the upgrade process if they are present. * In MySQL Shell's interactive mode, for JavaScript, Python, or SQL, the \source command or its alias \. can be used to execute code from a script file at a given path. For compatibility with the mysql client, in SQL mode only, you can now execute code from a script file using the source command with no backslash and an optional SQL delimiter. source can be used both in MySQL Shell's interactive mode for SQL, to execute a script directly, and in a file of SQL code processed in batch mode, to execute a further script from within the file. In SQL mode only, you can also now use the \source command's alias \. (which does not use a SQL delimiter) in a file of SQL code processed in batch mode. So with MySQL Shell in SQL mode, you could now execute the script in the /tmp/mydata.sql file from either interactive mode or batch mode using any of these three commands: source /tmp/mydata.sql; source /tmp/mydata.sql \. /tmp/mydata.sql The command \source /tmp/mydata.sql is also valid, but in interactive mode only. Bugs Fixed * When searching for startup scripts in the platform's standard global configuration path (in the folder %PROGRAMDATA%\MySQL\mysqlsh on Windows, or /etc/mysql/mysqlsh/ on Unix), MySQL Shell checked for the incorrect script name shellrc, rather than the correct name mysqlshrc. (Bug #30656548) * On Windows, MySQL Shell passed UTF-8 encoded strings to the NTFS file system, which stores file names in UTF-16 encoding. The mismatch caused files and folders to be incorrectly named or located when non-ASCII characters were used. MySQL Shell now converts all strings used in operations on NTFS from UTF-8 to UTF-16, and converts back to UTF-8 all strings received from Unicode function versions of Windows API calls. (Bug #30538516) * Some host names were not parsed correctly in the connection data provided when running MySQL Shell's upgrade checker utility checkForServerUpgrade(). (Bug #30536355) * If the MySQL Server environment variable MYSQL_UNIX_PORT (which specifies the default Unix socket file) was updated by the same process that was then used to create a MySQL Shell connection to a MySQL server using a socket file, MySQL Shell cached and connected using the socket file path that had previously been set, but reported that a connection had been made using the updated socket file path. The correct socket file used for the connection is now displayed. (Bug #30533318) * If a prompt theme file used to customize the MySQL Shell prompt contained an ill-formed UTF-8 sequence, on startup an error message was displayed in place of the prompt text. MySQL Shell now validates the prompt theme file before loading it, and if there is a problem, uses a default prompt instead and issues an error message. (Bug #30406283) * If MySQL Shell was installed on Microsoft Windows at a non-default location, and subsequently uninstalled, files created after installation by the Python library used by MySQL Shell were not removed. These files are now removed when MySQL Shell is uninstalled from any location. (Bug #30333801) * Previously, most MySQL Shell options that expected an integer value could be set with an empty value, in which case the value 1 was applied. The exception was the logLevel option, which required a value. The behavior has now been standardized so all MySQL Shell options that expect a non-string value must be specified with a value, with the exception of options set on the command line. The affected options are dba.gtidWaitTimeout, dba.logSql, history.maxSize, and verbose. (Bug #30320839) * When using MySQL Shell in interactive mode, using a template literal in a multiple-line JavaScript statement resulted in an error. The issue has now been fixed. (Bug #30248651) * In Python mode, when multiple statements were input to MySQL Shell at the same time for execution in interactive mode, only the first statement was executed correctly. (Bug #30029568) * The Debian control file for MySQL Shell has been corrected to remove packaging errors that occurred when certain variables were not defined. Thanks to Evgeniy Patlan for the fix. (Bug #29802600, Bug #95158) * In MySQL Shell's parser for URI-like connection strings, handling of path separators was previously platform dependent. Unified parsing has now been introduced so that Windows named pipes can be parsed correctly on Unix platforms, and Unix socket files can be parsed correctly on Windows platforms. (Bug #29456981) * MySQL Shell now looks up host names by obtaining the fully qualified domain name of the provided address and using the absolute form of this name (with a trailing dot). This method avoids potential issues caused by some network configurations that resolve host names as loopback addresses when they are actually addressable externally. (Bug #27704559) On Behalf of Oracle/MySQL Release Engineering Team, Hery Ramilison [Less]

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 & ... [More] 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 8.0.19 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 8.0 is also available from our repository for Linux platforms, go here for details: https://dev.mysql.com/downloads/ 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.19 (2020-01-13, General Availability) MySQL NDB Cluster 8.0.19 is a new 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 (https://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.19 (see Changes in MySQL 8.0.19 (2020-01-13, General Availability) (https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-19.html)). Functionality Added or Changed * Important Change: The default value for the ndb_autoincrement_prefetch_sz server system variable has been increased to 512. (Bug #30316314) * Important Change: NDB now supports more than 2 replicas (up to a maximum of 4). Setting NoOfReplicas=3 or NoOfReplicas=4 is now fully covered in our internal testing and thus supported for use in production. (Bug #97479, Bug #97579, Bug #25261716, Bug #30501414, Bug #30528105) * Important Change: Added the TransactionMemory data node configuration parameter which simplifies configuration of data node memory allocation for transaction operations. This part of ongoing work on pooling of transactional and Local Data Manager (LDM) memory. This new parameter is intended to supersede several older transactional memory parameters which have been deprecated (and which are thus subject to removal in a future release of NDB Cluster). In particular, the following parameters are incompatible with TransactionMemory and cannot be set in the config.ini configuration file if this parameter has been set: + MaxNoOfConcurrentIndexOperations + MaxNoOfFiredTriggers + MaxNoOfLocalOperations + MaxNoOfLocalScans If you attempt to set any of these incompatible parameters concurrently with TransactionMemory, the cluster management server cannot start. For more information, see the description of the TransactionMemory parameter and Parameters incompatible with TransactionMemory (https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbd-definition.html#mysql-cluster-transactionmemory-incompatible). See also Data Node Memory Management (https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-data-node-memory-management.html), for information about how memory resources are allocated by NDB Cluster data nodes. (Bug #96995, Bug #30344471) * Important Change: The maximum or default values for several NDB Cluster data node configuration parameters have been changed in this release. These changes are listed here: + The maximum value for DataMemory is increased from 1 terabyte to 16 TB. + The maximum value for DiskPageBufferMemory is also increased from 1 TB to 16 TB. + The default value for StringMemory is decreased to 5 percent. Previously, this was 25 percent. + The default value for LcpScanProgressTimeout is increased from 60 seconds to 180 seconds. * Performance: Read from any replica, which greatly improves the performance of table reads at a very low cost to table write performance, is now enabled by default for all NDB tables. This means both that the default value for the ndb_read_backup system variable is now ON, and that the value of the NDB_TABLE comment option READ_BACKUP is 1 when creating a new NDB table. (Previously, the default values were OFF and 0, respectively.) For more information, see Setting NDB_TABLE Options (https://dev.mysql.com/doc/refman/8.0/en/create-table-ndb-table-comment-options.html), as well as the description of the ndb_read_backup system variable. * NDB Disk Data: The latency of checkpoints for Disk Data files has been reduced when using non-volatile memory devices such as solid-state drives (especially those using NVMe for data transfer), separate physical drives for Disk Data files, or both. As part of this work, two new data node configuration parameters, listed here, have been introduced: + MaxDiskDataLatency sets a maximum on allowed latency for disk access, aborting transactions exceeding this amount of time to complete + DiskDataUsingSameDisk makes it possible to take advantage of keeping Disk Data files on separate disks by increasing the rate at which Disk Data checkpoints can be made This release also adds three new tables to the ndbinfo database. These tables, listed here, can assist with performance monitoring of Disk Data checkpointing: + diskstat provides information about Disk Data tablespace reads, writes, and page requests during the previous 1 second + diskstats_1sec provides information similar to that given by the diskstat table, but does so for each of the last 20 seconds + pgman_time_track_stats table reports on the latency of disk operations affecting Disk Data tablespaces For additional information, see Disk Data latency parameters (https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbd-definition.html#mysql-cluster-ndbd-definition-disk-data-latency-parameters). * Added the ndb_metadata_sync server system variable, which simplifies knowing when metadata synchronization has completed successfully. Setting this variable to true triggers immediate synchronization of all changes between the NDB dictionary and the MySQL data dictionary without regard to any values set for ndb_metadata_check or ndb_metadata_check_interval. When synchronization has completed, its value is automatically reset to false. (Bug #30406657) * A stack trace is now written to the data node log on abnormal termination of a data node. * Automatic synchronization of metadata from the MySQL data dictionary to NDB now includes databases containing NDB tables. With this enhancement, if a table exists in NDB, and the table and the database it belongs to do not exist on a given SQL node, it is no longer necessary to create the database manually. Instead, the database, along with all NDB tables belonging to this database, should be created on the SQL node automatically. Bugs Fixed * Incompatible Change: ndb_restore no longer restores shared users and grants to the mysql.ndb_sql_metadata table by default. A new command-line option --include-stored-grants is added to override this behavior and enable restoring of shared user and grant data and metadata. As part of this fix, ndb_restore can now also correctly handle an ordered index on a system table. (Bug #30237657) References: See also: Bug #29534239, Bug #30459246. * Incompatible Change: The minimum value for the RedoOverCommitCounter data node configuration parameter has been increased from 0 to 1. The minimum value for the RedoOverCommitLimit data node configuration parameter has also been increased from 0 to 1. You should check the cluster global configuration file and make any necessary adjustments to values set for these parameters before upgrading. (Bug #29752703) * macOS: On MacOS, SQL nodes sometimes shut down unexpectedly during the binary log setup phase when starting the cluster. This occurred when there existed schemas whose names used uppercase letters and lower_case_table_names was set to 2. This caused acquisition of metadata locks to be attempted using keys having the incorrect lettercase, and, subsequently, these locks to fail. (Bug #30192373) * Microsoft Windows; NDB Disk Data: On Windows, restarting a data node other than the master when using Disk Data tables led to a failure in TSMAN. (Bug #97436, Bug #30484272) * Solaris: When debugging, ndbmtd consumed all available swap space on Solaris 11.4 SRU 12 and later. (Bug #30446577) * Solaris: The byte order used for numeric values stored in the mysql.ndb_sql_metadata table was incorrect on Solaris/Sparc. This could be seen when using ndb_select_all or ndb_restore --print. (Bug #30265016) * NDB Disk Data: After dropping a disk data table on one SQL node, trying to execute a query against INFORMATION_SCHEMA.FILES on a different SQL node stalled at Waiting for tablespace metadata lock. (Bug #30152258) References: See also: Bug #29871406. * NDB Disk Data: ALTER TABLESPACE ... ADD DATAFILE could sometimes hang while trying to acquire a metadata lock. (Bug #29871406) * The fix made in NDB 8.0.18 for an issue in which a transaction was committed prematurely aborted the transaction if the table definition had changed midway, but failed in testing to free memory allocated by getExtraMetadata(). Now this memory is properly freed before aborting the transaction. (Bug #30576983) References: This issue is a regression of: Bug #29911440. * Excessive allocation of attribute buffer when initializing data in DBTC led to preallocation of api connection records failing due to unexpectedly running out of memory. (Bug #30570264) * Improved error handling in the case where NDB attempted to update a local user having the NDB_STORED_USER privilege but which could not be found in the ndb_sql_metadata table. (Bug #30556487) * Failure of a transaction during execution of an ALTER TABLE ... ALGORITHM=COPY statement following the rename of the new table to the name of the original table but before dropping the original table caused mysqld to exit prematurely. (Bug #30548209) * Non-MSI builds on Windows using -DWITH_NDBCLUSTER did not succeed unless the WiX toolkit was installed. (Bug #30536837) * The allowed_values output from ndb_config --xml --configinfo for the Arbitration data node configuration parameter in NDB 8.0.18 was not consistent with that obtained in previous releases. (Bug #30529220) References: See also: Bug #30505003. * A faulty ndbrequire() introduced when implementing partial local checkpoints assumed that m_participatingLQH must be clear when receiving START_LCP_REQ, which is not necessarily true when a failure happens for the master after sending START_LCP_REQ and before handling any START_LCP_CONF signals. (Bug #30523457) * A local checkpoint sometimes hung when the master node failed while sending an LCP_COMPLETE_REP signal and it was sent to some nodes, but not all of them. (Bug #30520818) * Added the DUMP 9988 and DUMP 9989 commands. (Bug #30520103) * The management server did not handle all cases of NODE_FAILREP correctly. (Bug #30520066) * With SharedGlobalMemory set to 0, some resources did not meet required minimums. (Bug #30411835) * Execution of ndb_restore --rebuild-indexes together with the --rewrite-database and --exclude-missing-tables options did not create indexes for any tables in the target database. (Bug #30411122) * When writing the schema operation into the ndb_schema table failed, the states in the NDB_SCHEMA object were not cleared, which led to the SQL node shutting down when it tried to free the object. (Bug #30402362) References: See also: Bug #30371590. * If a transaction was aborted while getting a page from the disk page buffer and the disk system was overloaded, the transaction hung indefinitely. This could also cause restarts to hang and node failure handling to fail. (Bug #30397083, Bug #30360681) References: See also: Bug #30152258. * When synchronizing extent pages it was possible for the current local checkpoint (LCP) to stall indefinitely if a CONTINUEB signal for handling the LCP was still outstanding when receiving the FSWRITECONF signal for the last page written in the extent synchronization page. The LCP could also be restarted if another page was written from the data pages. It was also possible that this issue caused PREP_LCP pages to be written at times when they should not have been. (Bug #30397083) * Data node failures with the error Another node failed during system restart... occurred during a partial restart. (Bug #30368622) * Automatic synchronization could potentially trigger an increase in the number of locks being taken on a particular metadata object at a given time, such as when a synchronization attempt coincided with a DDL or DML statement involving the same metadata object; competing locks could lead to the NDB deadlock detection logic penalizing the user action rather than the background synchronization. We fix this by changing all exclusive metadata lock acquisition attempts during auto-synchronization so that they use a timeout of 0 (rather than the 10 seconds previously allowed), which avoids deadlock detection and gives priority to the user action. (Bug #30358470) * If a SYNC_EXTENT_PAGES_REQ signal was received by PGMAN while dropping a log file group as part of a partial local checkpoint, and thus dropping the page locked by this block for processing next, the LCP terminated due to trying to access the page after it had already been dropped. (Bug #30305315) * The wrong number of bytes was reported in the cluster log for a completed local checkpoint. (Bug #30274618) References: See also: Bug #29942998. * Added the new ndb_mgm client debugging commands DUMP 2356 and DUMP 2357. (Bug #30265415) * Executing ndb_drop_table using the --help option caused this program to terminate prematurely, and without producing any help output. (Bug #30259264) * A mysqld trying to connect to the cluster, and thus trying to acquire the global schema lock (GSL) during setup, ignored the setting for ndb_wait_setup and hung indefinitely when the GSL had already been acquired by another mysqld, such as when it was executing an ALTER TABLE statement. (Bug #30242141) * When a table containing self-referential foreign key (in other words, a foreign key referencing another column of the same table) was altered using the COPY algorithm, the foreign key definition was removed. (Bug #30233405) * In MySQL 8.0, names of foreign keys explicitly provided by user are generated automatically in the SQL layer and stored in the data dictionary. Such names are of the form [table_name]_ibfk_[#] which align with the names generated by the InnoDB storage engine in MySQL 5.7. NDB 8.0.18 introduced a change in behavior by NDB such that it also uses the generated names, but in some cases, such as when tables were renamed, NDB still generated and used its own format for such names internally rather than those generated by the SQL layer and stored in the data dictionary, which led to the following issues: + Discrepancies in SHOW CREATE TABLE output and the contents of I_S.REFENTIAL_CONSTRAINTS + Improper metadata locking for foreign keys + Confusing names for foreign keys in error messages Now NDB also renames the foreign keys in such cases, using the names provided by the MySQL server, to align fully with those used by InnoDB. (Bug #30210839) References: See also: Bug #96508, Bug #30171959. * When a table referenced by a foreign key was renamed, participating SQL nodes did not properly update the foreign key definitions for the referencing table in their data dictionaries during schema distribution. (Bug #30191068) * Data node handling of failures of other data nodes could sometimes not be synchronized properly, such that two or more data nodes could see different nodes as the master node. (Bug #30188414) * Some scan operations failed due to the presence of an old assert in DbtupBuffer.cpp that checked whether API nodes were using a version of the software previous to NDB 6.4. This was no longer necessary or correct, and has been removed. (Bug #30188411) * When executing a global schema lock (GSL), NDB used a single Ndb_table_guard object for successive retires when attempting to obtain a table object reference; it was not possible for this to succeed after failing on the first attempt, since Ndb_table_guard assumes that the underlying object pointer is determined once only---at initialisation---with the previously retrieved pointer being returned from a cached reference thereafter. This resulted in infinite waits to obtain the GSL, causing the binlog injector thread to hang so that mysqld considered all NDB tables to be read-only. To avoid this problem, NDB now uses a fresh instance of Ndb_table_guard for each such retry. (Bug #30120858) References: This issue is a regression of: Bug #30086352. * When upgrading an SQL node to NDB 8.0 from a previous release series, the .frm file whose contents are read and then installed in the data dictionary does not contain any information about foreign keys. This meant that foreign key information was not installed in the SQL node's data dictionary. This is fixed by using the foreign key information available in the NDB data dictionary to update the local MySQL data dictionary during table metadata upgrade. (Bug #30071043) * Restoring tables with the --disable-indexes option resulted in the wrong table definition being installed in the MySQL data dictionary. This is because the serialized dictionary information (SDI) packed into the NDB dictionary's table definition is used to create the table object; the SDI definition is updated only when the DDL change is done through the MySQL server. Installation of the wrong table definition meant that the table could not be opened until the indexes were re-created in the NDB dictionary again using --rebuild-indexes. This is fixed by extending auto-synchronization such that it compares the SDI to the NDB dictionary table information and fails in cases in which the column definitions do not match. Mismatches involving indexes only are treated as temporary errors, with the table in question being detected again during the next round of change detection. (Bug #30000202, Bug #30414514) * Restoring tables for which MAX_ROWS was used to alter partitioning from a backup made from NDB 7.4 to a cluster running NDB 7.6 did not work correctly. This is fixed by ensuring that the upgrade code handling PartitionBalance supplies a valid table specification to the NDB dictionary. (Bug #29955656) * The number of data bytes for the summary event written in the cluster log when a backup completed was truncated to 32 bits, so that there was a significant mismatch between the number of log records and the number of data records printed in the log for this event. (Bug #29942998) * mysqld sometimes aborted during a long ALTER TABLE operation that timed out. (Bug #29894768) References: See also: Bug #29192097. * When an SQL node connected to NDB, it did not know whether it had previously connected to that cluster, and thus could not determine whether its data dictionary information was merely out of date, or completely invalid. This issue is solved by implementing a unique schema version identifier (schema UUID) to the ndb_schema table in NDB as well as to the ndb_schema table object in the data dictionary. Now, whenever a mysqld connects to a cluster as an SQL node, it can compare the schema UUID stored in its data dictionary against that which is stored in the ndb_schema table, and so know whether it is connecting for the first time. If so, the SQL node removes any entries that may be in its data dictionary. (Bug #29894166) References: See also: Bug #27543602. * Improved log messages generated by table discovery and table metadata upgrades. (Bug #29894127) * Using 2 LDM threads on a 2-node cluster with 10 threads per node could result in a partition imbalance, such that one of the LDM threads on each node was the primary for zero fragments. Trying to restore a multi-threaded backup from this cluster failed because the datafile for one LDM contained only the 12-byte data file header, which ndb_restore was unable to read. The same problem could occur in other cases, such as when taking a backup immediately after adding an empty node online. It was found that this occurred when ODirect was enabled for an EOF backup data file write whose size was less than 512 bytes and the backup was in the STOPPING state. This normally occurs only for an aborted backup, but could also happen for a successful backup for which an LDM had no fragments. We fix the issue by introducing an additional check to ensure that writes are skipped only if the backup actually contains an error which should cause it to abort. (Bug #29892660) References: See also: Bug #30371389. * For NDB tables, ALTER TABLE ... ALTER INDEX did not work with ALGORITHM=INPLACE. (Bug #29700197) * ndb_restore failed in testing on 32-bit platforms. This issue is fixed by increasing the size of the thread stack used by this tool from 64 KB to 128 KB. (Bug #29699887) References: See also: Bug #30406046. * An unplanned shutdown of the cluster occurred due to an error in DBTUP while deleting rows from a table following an online upgrade. (Bug #29616383) * In some cases the SignalSender class, used as part of the implementation of ndb_mgmd and ndbinfo, buffered excessive numbers of unneeded SUB_GCP_COMPLETE_REP and API_REGCONF signals, leading to unnecessary consumption of memory. (Bug #29520353) References: See also: Bug #20075747, Bug #29474136. * The setting for the BackupLogBufferSize configuration parameter was not honored. (Bug #29415012) * When mysqld was run with the --upgrade=FORCE option, it reported the following issues: [Warning] Table 'mysql.ndb_apply_status' requires repair. [ERROR] Table 'mysql.ndb_apply_status' repair failed. This was because --upgrade=FORCE causes a bootstrap system thread to run CHECK TABLE FOR UPGRADE, but ha_ndbcluster::open() refused to open the table before schema synchronization had completed, which eventually led to the reported conditions. (Bug #29305977) References: See also: Bug #29205142. * When using explicit SHM connections, with ShmSize set to a value larger than the system's available shared memory, mysqld hung indefinitely on startup and produced no useful error messages. (Bug #28875553) * The maximum global checkpoint (GCP) commit lag and GCP save timeout are recalculated whenever a node shuts down, to take into account the change in number of data nodes. This could lead to the unintentional shutdown of a viable node when the threshold decreased below the previous value. (Bug #27664092) References: See also: Bug #26364729. * A transaction which inserts a child row may run concurrently with a transaction which deletes the parent row for that child. One of the transactions should be aborted in this case, lest an orphaned child row result. Before committing an insert on a child row, a read of the parent row is triggered to confirm that the parent exists. Similarly, before committing a delete on a parent row, a read or scan is performed to confirm that no child rows exist. When insert and delete transactions were run concurrently, their prepare and commit operations could interact in such a way that both transactions committed. This occurred because the triggered reads were performed using LM_CommittedRead locks (see NdbOperation::LockMode), which are not strong enough to prevent such error scenarios. This problem is fixed by using the stronger LM_SimpleRead lock mode for both triggered reads. The use of LM_SimpleRead rather than LM_CommittedRead locks ensures that at least one transaction aborts in every possible scenario involving transactions which concurrently insert into child rows and delete from parent rows. (Bug #22180583) * Concurrent SELECT and ALTER TABLE statements on the same SQL node could sometimes block one another while waiting for locks to be released. (Bug #17812505, Bug #30383887) * Failure handling in schema synchronization involves pushing warnings and errors to the binary logging thread. Schema synchronization is also retried in case of certain failures which could lead to an accumulation of warnings in the thread. Now such warnings and errors are cleared following each attempt at schema synchronization. (Bug #2991036) * An INCL_NODECONF signal from any local blocks should be ignored when a node has failed, except in order to reset c_nodeStartSlave.nodeId. (Bug #96550, Bug #30187779) * When returning Error 1022, NDB did not print the name of the affected table. (Bug #74218, Bug #19763093) References: See also: Bug #29700174. On Behalf of Oracle/MySQL Release Engineering Team, Hery Ramilison [Less]

The MySQL Development team is proud to announce version 8.0.19 of the MySQL Shell, with the following features: Admin API MySQL InnoDB ReplicaSet MySQL Router Management Functions Metadata Upgrade Router Management Functions Shell JavaScript ... [More] Plugins: require() function enhancements. Upgrade Checker Updates MySQL InnoDB ReplicaSet Similar to MySQL InnoDB Cluster (based on Group Replication), this release of the Shell introduces the MySQL InnoDB Replicaset which provides an easy to use management solution for MySQL Replication.… Facebook Twitter LinkedIn [Less]

Dear MySQL users, MySQL Connector/C++ 8.0.19 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 ... [More] 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.19, see the "General Availability (GA) Releases" tab at https://dev.mysql.com/downloads/connector/cpp/ ================================================== Changes in MySQL Connector/C++ 8.0.19 (2020-01-13, General Availability) * Error Handling * Legacy (JDBC API) Notes * Packaging Notes * X DevAPI Notes * Functionality Added or Changed * Bugs Fixed Error Handling * If an application tries to obtain a result set from a statement that does not produce one, an exception occurs. For applications that do not catch such exceptions, Connector/C++ now produces a more informative error message to indicate why the exception occurred. (Bug #28591814, Bug #92263) Legacy (JDBC API) Notes * For applications that use the legacy JDBC API (that is, not made using X DevAPI or X DevAPI for C), it is now possible when creating a new session to specify multiple hosts to be tried until a successful connection is established. A list of hosts can be given in the session creation options. The new OPT_MULTI_HOST option is disabled by default for backward compatibility, but if enabled in the ConnectionOptionsMap parameter passed to connect() calls, it permits other map parameters to specify multiple hosts. Examples: sql::ConnectOptionsMap opts; opts["hostName"]="host1,host2:13001,localhost:13000"; opts["schema"]="test"; opts["OPT_MULTI_HOST"] = true; opts["userName"]="user"; opts["password"]="password"; driver->connect(opts); sql::ConnectOptionsMap opts; opts["hostName"]="tcp://host1,host2:13001,localhost:13000/test"; opts["OPT_MULTI_HOST"] = true; opts["userName"]="user"; opts["password"]="password"; driver->connect(opts); sql::ConnectOptionsMap opts; opts["hostName"]="mysql://host1,host2:13001,localhost:13000/test"; opts["OPT_MULTI_HOST"] = true; opts["userName"]="user"; opts["password"]="password"; driver->connect(opts); Port values are host specific. If a host is specified without a port number, the default port is used. These rules apply: + If OPT_MULTI_HOST is disabled and multiple hosts are specified, an error occurs. + If OPT_MULTI_HOST is disabled and a single host that resolves to multiple hosts is specified, the first host is used for backward compatibility. + If OPT_MULTI_HOST is enabled and multiple hosts are specified, one of them is randomly chosen as the connection target. If the target fails, another host is randomly chosen from those that remain. If all targets fail, an error occurs. + The hostName parameter can accept a URI that contains a list of comma-separated hosts. The URI scheme can be mysql://, which works like tcp://. The URI scheme can also be omitted, so the parameter can be a list of comma-separated hosts. + The connect() syntax that takes URI, user, and password parameters does not permit multiple hosts because in that case OPT_MULTI_HOST is disabled. Packaging Notes * Connector/C++ now is compatible with MSVC 2019, while retaining compatibility with MSVC 2017: + Previously, Connector/C++ binary distributions were compatible with projects built using MSVC 2017 or 2015. Binary distributions now are compatible with projects built using MSVC 2019 (using either dynamic or static connector libraries) or MSVC 2017 (using dynamic connector libraries). Building using MSVC 2015 might work, but is not supported. + Previously, Connector/C++ source distributions could be built using MSVC 2017 or 2015. Source distributions now can be built using MSVC 2019 or 2017. Building using MSVC 2015 might work, but is not supported. + Previously, the MSI installer accepted the Visual C++ Redistributable for Visual Studio 2017 or 2015. The MSI installer now accepts the Visual C++ Redistributable for Visual Studio 2019 or 2017. X DevAPI Notes * For applications that use X DevAPI or X DevAPI for C, Connector/C++ now provides options that enable specifying the permitted TLS protocols and ciphersuites for TLS connection negotiation: + TLS protocols must be chosen from this list: TLSv1, TLSv1.1, TLSv1.2, TLSv1.3. (TLSv1.3 requires that both the server and Connector/C++ be compiled with OpenSSL 1.1.1 or higher.) + Ciphersuite values must be IANA ciphersuite names. TLS protocols and ciphersuites now may be specified in these contexts: + Connection strings permit tls-versions and tls-ciphersuites options. The tls-versions value is a list of one or more comma-separated TLS protocol versions. The tls-ciphersuites value is a list of one or more comma-separated ciphersuite names. Examples: ...?tls-versions=[TLSv1.3]&... ...?tls-versions=[TLSv1.2,TLSv1.3]&... ...?tls-ciphersuites=[ TLS_DHE_PSK_WITH_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256 ]&... + SessionSettings objects permit TLS_VERSIONS and TLS_CIPHERSUITES options. Each value is either a string containing one or more comma-separated items or a container with strings (that is, any type that can be iterated with a loop that yields string values). Example of single string values: Session s(..., TLS_VERSIONS, "TLSv1.2,TLSv1.3", TLS_CIPHERSUITES, "TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256" , ...); Example of string container values: std::list tls_versions = { "TLSv1.2", "TLSv1.3" }; std::list ciphers = { "TLS_DHE_PSK_WITH_AES_128_GCM_SHA256", "TLS_CHACHA20_POLY1305_SHA256" }; Session s(..., TLS_VERSIONS, tls_versions TLS_CIPHERSUITES, ciphers, ...); Session s(..., TLS_VERSIONS, std::vector{"TLSv1.2","TLSv1.3"}, TLS_CIPHERSUITES, std::vector{"TLS_DHE_PSK_WITH_AES_128_GCM_SHA256", "TLS_CHACHA20_POLY1305_SHA256"}, ...); + mysqlx_session_option_set() and friends permit MYSQLX_OPT_TLS_VERSIONS and MYSQLX_OPT_TLS_CIPHERSUITES session option constants, together with the corresponding OPT_TLS_VERSIONS() and OPT_TLS_CIPHERSUITES() macros. MYSQLX_OPT_TLS_VERSIONS and MYSQLX_OPT_TLS_CIPHERSUITES accept a string containing one or more comma-separated items. Examples: mysqlx_session_option_set(opts, ..., OPT_TLS_VERSIONS("TLSv1.2,TLSv1.3"), OPT_TLS_CIPHERSUITES( "TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256" ), ...) For more information about TLS protocols and ciphersuites in MySQL, see Encrypted Connection TLS Protocols and Ciphers ( https://dev.mysql.com/doc/refman/8.0/en/encrypted-connection-protocols-ciphers.html ). (Bug #28964583, Bug #93299) * For X DevAPI or X DevAPI for C, when creating a new connection (given by a connection string or other means), if the connection data contains several target hosts that have no explicit priority assigned, the behavior of the failover logic now is the same as if all those target hosts have the same priority. That is, the next candidate for making a connection is chosen randomly from the remaining available hosts. This is a change from previous behavior, where hosts with no explicit priority were assigned implicit decreasing priorities and tried in the same order as listed in the connection data. Functionality Added or Changed * Connector/C++ now supports the use of DNS SRV records to specify multiple hosts: + Session and session-pool creation accepts a URI scheme of mysqlx+srv:// that enables the DNS SRV feature in connect strings. Example: mysqlx+srv://example.com/db?options + For X DevAPI, mysqlx::Session objects permit a SessionOption::DNS_SRV entry to enable use of a DNS SRV record to specify available services. Example: mysqlx::Session sess( SessionOption::HOST, "example.com", SessionOption::DNS_SRV, true, SessionOption::USER, "user", SessionOption::PWD, "password"); Similarly, for X DevAPI for C, the mysqlx_session_option_set() function permits an OPT_DNS_SRV() option in the argument list. Example: mysqlx_session_option_set(opt, OPT_HOST("example.com"), OPT_DNS_SRV(true) OPT_USER("user"), OPT_PWD("password"), PARAM_END)); + For applications that use the legacy JDBC API (that is, not made using X DevAPI or X DevAPI for C), connection maps permit an OPT_DNS_SRV element. A map should specify the host for SRV lookup as a full lookup name and without a port. Example: sql::ConnectOptionsMap opts; opts["hostName"] = "_mysql._tcp.host1.example.com"; opts["OPT_DNS_SRV"] = true; opts["userName"] = "user"; opts["password"] = "password"; driver->connect(opts); In legacy applications, DNS SRV resolution cannot be enabled in URI connect strings because parameters are not supported in such strings. Bugs Fixed * Connector/C++ failed to compile using Clang on Linux. (Bug #30450484) * Connector/C++ set the transaction isolation level to REPEATABLE READ at connect time, regardless of the current server setting. (Bug #22038313, Bug #78852, Bug #30294415) On Behalf of MySQL Release Engineering Team, Surabhi Bhat [Less]

Dear MySQL users, MySQL Server 5.7.29, a new version of the popular Open Source Database Management System, has been released. MySQL 5.7.29 is recommended for use on production systems. For an overview of what's new in MySQL 5.7, please see ... [More] http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html For information on installing MySQL 5.7.29 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.29 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.29 is also available from our repository for Linux platforms, go here for details: http://dev.mysql.com/downloads/ 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.29 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.28. It may also be viewed online at http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-29.html Enjoy! ============================================================================== Changes in MySQL 5.7.29 (2020-01-13, General Availability) * Audit Log Notes * Bugs Fixed Audit Log Notes * ANALYZE TABLE statements now produce read audit events. (Bug #29625461) Bugs Fixed * InnoDB: os_file_get_parent_dir warnings were encountered when compiling MySQL with GCC 9.2.0. (Bug #30499288, Bug #97466) * InnoDB: An internal function (btr_push_update_extern_fields()) used to fetch newly added externally stored fields and update them during a pessimistic update or when going back to a previous version of a record was no longer required. Newly added externally stored fields are updated by a different function. Also, the method used to determine the number of externally stored fields was corrected. (Bug #30342846) * InnoDB: A comparison function found two records to be equal when attempting to merge non-leaf pages of a spatial index. The function was unable to handle this unexpected condition, which resulted in a long semaphore wait and an eventual assertion failure. (Bug #30287668) * InnoDB: Importing a tablespace from a location outside of the data directory raised an assertion failure. (Bug #30190227) * InnoDB: Importing a tablespace with a data directory definition that did not match the destination data directory returned an insufficiently descriptive schema mismatch error. (Bug #30190199) * InnoDB: Criteria used by the btr_cur_will_modify_tree() function, which detects whether a modifying record needs a modifying tree structure, was insufficient. (Bug #30113362) * InnoDB: An ALTER TABLE ... DISCARD TABLESPACE operation caused a hang condition. (Bug #29942556, Bug #30324703) * InnoDB: A code regression was addressed by prohibiting unnecessary implicit to explicit secondary index lock conversions for session temporary tables. (Bug #29718243) * InnoDB: A tablespace import operation raised an assertion when the cursor was positioned on a corrupted page while purging delete-marked records. Instead of asserting when encountering a corrupted page, the import operation is now terminated and an error is reported. (Bug #29454828, Bug #94541) * Replication: When a member is joining or rejoining a replication group, if Group Replication detects an error in the distributed recovery process (during which the joining member receives state transfer from an existing online member), it automatically switches over to a new donor, and retries the state transfer. The number of times the joining member retries before giving up is set by the group_replication_recovery_retry_count system variable. The Performance Schema table replication_applier_status_by_worker displays the error that caused the last retry. Previously, this error was only shown if the group member was configured with parallel replication applier threads (as set by the slave_parallel_workers system variable). If the group member was configured with a single applier thread, the error was cleared after each retry by an internal RESET SLAVE operation, so it could not be viewed. This was also the case for the output of the SHOW SLAVE STATUS command whether there were single or multiple applier threads. The RESET SLAVE operation is now no longer carried out after retrying distributed recovery, so the error that caused the last retry can always be viewed. (Bug #30517160, Bug #30517172) * Replication: A memory leak could occur when a failed replication group member tried to rejoin a minority group and was disallowed from doing so. (Bug #30162547, Bug #96471) * Replication: If a replication slave was set up using a CHANGE MASTER TO statement that did not specify the master log file name and master log position, then shut down before START SLAVE was issued, then restarted with the option --relay-log-recovery set, replication did not start. This happened because the receiver thread had not been started before relay log recovery was attempted, so no log rotation event was available in the relay log to provide the master log file name and master log position. In this situation, the slave now skips relay log recovery and logs a warning, then proceeds to start replication. (Bug #28996606, Bug #93397) * Replication: When GTIDs are enabled on a replication master and slave, and the slave connects to the master with the MASTER_AUTO_POSITION=1 option set, the master must send the slave all the transactions that the slave has not already received, committed, or both. If any of the transactions that should be sent by the master have been already purged from the master's binary log, the master sends the error ER_MASTER_HAS_PURGED_REQUIRED_GTIDS (1789) to the slave, and replication does not start. The message provided for the error ER_MASTER_HAS_PURGED_REQUIRED_GTIDS has been changed to provide advice on the correct action in this situation, which is for the slave to replicate the missing transactions from another source, or for the slave to be replaced by a new slave created from a more recent backup. The message advises that the master's binary log expiration period can be revised to avoid the situation in future. In addition, the master now identifies the GTIDs of the purged transactions and supplies them in its error log in the warning message ER_FOUND_MISSING_GTIDS (11809), so that you do not need to calculate the missing GTIDs manually. (Bug #26004541, Bug #29769293) * macOS: On macOS, configuring MySQL with -DWITH_SSL=system caused mysql_config output to incorrectly include internal CMake names for the static SSL libraries. (Bug #30541879, Bug #97632) * Docker packages were missing the LDAP authentication plugins. (Bug #30465247) * The original table name for a field in a derived table was not always displayed correctly. (Bug #30362898) References: See also: Bug #24611344. This issue is a regression of: Bug #22364401. * MySQL Installer was unable to uninstall MySQL 5.7 on Windows Server 2012. (Bug #30323924, Bug #96940) * With multiple sessions executing concurrent INSERT ... ON DUPLICATE KEY UPDATE statements into a table with an AUTO_INCREMENT column but not specifying the AUTO_INCREMENT value, inserts could fail with a unique index violation. (Bug #30194841, Bug #96578) * With lower_case_table_names=2, SHOW TABLES could fail to display tables with uppercase names. (Bug #29957361) * With keyring_encrypted_file_password set on the command line at server startup, the password value could be visible to system utilities. (Bug #29848634) * With a LOCK TABLES statement in effect, a metadata change for the locked table could cause Performance Schema or SHOW queries for session variables to hang in the opening_tables state. (Bug #29836204, Bug #92387) * A SELECT using a WHERE condition of the form A AND (B OR C [OR ...]) resulting in an impossible range led to an unplanned exit of the server. (Bug #29770705) * For JSON-format audit logging, the id field now may contain values larger than 65535. Previously, with heaving logging activity, more than 65536 queries per second could be executed, exceeding the 16 bits permitted for id values. (Bug #29661920) * An incomplete connection packet could cause clients not to properly initialize the authentication plugin name. (Bug #29630767) * Client programs that used the libmysqlclient C client library could exit upon receipt of an OK packet containing malformed session-tracking information. (Bug #29297620, Bug #29630735) * Under certain conditions, enabling the read_only or super_read_only system variable did not block concurrent DDL statements executed by users without the SUPER privilege. (Bug #28438114, Bug #91852) * mysqlpump exits rather than dumping databases that contain an invalid view, by design, but it also failed if an invalid view existed but was not in any of the databases to be dumped. (Bug #27096081) On Behalf of MySQL Release Engineering Team, Surabhi Bhat [Less]

Dear MySQL users, The MySQL developer tools team announces 8.0.19 as our General Availability (GA) for MySQL Workbench 8.0. For the full list of changes in this revision, visit https://dev.mysql.com/doc/relnotes/workbench/en/news-8-0.html For ... [More] discussion, join the MySQL Workbench Forums: http://forums.mysql.com/index.php?152 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/tools/workbench/ Enjoy! Changes in MySQL Workbench 8.0.19 (2020-01-13, General Availability) Functionality Added or Changed * Important Note: MySQL Workbench 8.0.19 is unable to open a new connection to MySQL Server from the home screen if the server is not started and you cannot start a server by using the Workbench Administration feature. Administrative and SQL editing tasks require an online server for the duration of this issue. Feature tasks that you performed with an offline server in previous releases now return an error message indicating that the server is unreachable. This issue is limited to MySQL Workbench 8.0.19. Thank you for your patience. Workaround: Start MySQL Server independently before opening the Administration and SQL Query tabs in MySQL Workbench. On Linux, you can replace the MySQL Connector/C++ 8.0.19 library with the 8.0.18 library. * A new context menu item now copies the headers and rows of queried data with tabs as separators, making it convenient to copy and paste query results into Excel. Thanks to Raj Rao for the patch. (Bug #30568824, Bug #97712) * The following MySQL server language features are now supported: value references in INSERT statements, new options (TLS version, cipher suite, compression, and privilege check) in CHANGE MASTER TO replication statements, random passwords in CREATE USER and ALTER USER statements, EXPLAIN ANALYZE, and binary collation names. * Context help for the keywords and functions in SQL queries now includes updated syntax and usage information. Bugs Fixed * When attempting to export MySQL 5.7 data using MySQL Workbench 8.0, the server returned an error indicating that INFORMATION_SCHEMA.COLUMN_STATISTICS was an unknown table. Consistent parameter use with mysqldump now skips the table as expected. (Bug #30515899, Bug #97520) * The SQL editor applied syntax-error highlighting to the EXPLAIN keyword in a valid statement prefixed with EXPLAIN ANALYZE, but the statement executed as expected. (Bug #30478023, Bug #97416) * A syntax error was generated for valid ANALYZE TABLE statements with either the UPDATE HISTOGRAM or DROP HISTOGRAM clause. (Bug #30449796, Bug #97281) * Storage engines not supported by MySQL were listed as possible engines that could be selected for tables. Unsupported storage engines now are removed from the suggestion list. (Bug #30338754, Bug #96968) * An existing stored connection could not be replaced with a new connection having the same name when the attempt was made from the Source Selection step of the MySQL Workbench Migration Wizard. (Bug #30269513) * On macOS, the Cancel and Export buttons in the Export Recordset context window (for SQL INSERT statements) were mostly hidden. (Bug #30244028, Bug #96689) * If the ls command produced an error message together with a list of files, no audit log for the error appeared in the Enterprise MySQL Audit Log Inspector. (Bug #30135391) * An original SQL Server record (for example, 1020.6) was copied inaccurately to the corresponding MySQL column (1020.0) when migrated using the DECIMAL data type. Similarly, data migrated using the NUMERIC type generated a type-conversion error. Now, both decimal and numeric values are stored as DECIMAL types to fix the resolution of the decimal value or to fix the type conversion. (Bug #30062094, Bug #96230, Bug #30263415, Bug #96744) * The uniqueidentifier data type in a SQL Server source table was interpreted during migration as type VARCHAR(64) UNIQUE in the MySQL target column, instead of a VARCHAR column to represent a GUID (UUID) that is not unique. (Bug #29355468, Bug #94066) * The relationship arrows within an EER diagram were not visible when the Dark Mode theme was enabled on a macOS host and the diagram was exported as a single page PDF file. This fix disables the theme in models to prevent conflicts with the colors assigned by the model editor. (Bug #29307893, Bug #94174) * An empty file list was shown when the audit_log_file value was set to any location other than the MySQL server data directory. (Bug #22673089) On Behalf of Oracle/MySQL Release Engineering Team, Nawaz Nazeer Ahamed [Less]

Dear MySQL users, The MySQL developer tools team announces 8.0.19 as our General Availability (GA) for MySQL Workbench 8.0. For the full list of changes in this revision ... [More] , visithttps://dev.mysql.com/doc/relnotes/workbench/en/news-8-0.html For discussion, join the MySQL Workbench Forums:http://forums.mysql.com/index.php?152 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/tools/workbench/ Enjoy! [Less]

Dear MySQL users, MySQL Connector/NET 8.0.19 is the latest General Availability release of the MySQL Connector/NET 8.0 series. This version supports .NET Core 3.0 and the X DevAPI, which enables application developers to write code that ... [More] 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.19, 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.19 (2020-01-13, General Availability) * Functionality Added or Changed * Bugs Fixed Functionality Added or Changed * Connector/NET supports TLS protocol versions TLSv1, TLSv1.1, TLSv1.2, and TLSv1.3. A new connection-string option, tlsversion, permits the restriction of a connection to a single version or to a list with any combination of the four supported TLS versions (see Options for Both Classic MySQL Protocol and X Protocol https://dev.mysql.com/doc/connector-net/en/connector-net-8-0-connection-options.html#connector-net-8-0-connection-options-classic-xprotocol.) Known issue: both .NET Core 3.0 (crossplatform) and .NET Framework 4.8 (windows only) added support for TLSv1.3. Be sure to confirm that the platform operating system running your application also supports TLSv1.3 before using it exclusively for connections. (Bug #30225427) * Support for DNS Service (SRV) records now provides an alternative to specifying individual hosts in the connection string. Instead, a single DNS domain can map to multiple targets (servers) using SRV address records. Each SRV record includes the host name, port, priority, and weight. For .NET applications using X Protocol, a new URI scheme of mysqlx+srv:// enables connections to share the query load when a single DNS domain is mapped to multiple servers. Similarly, the new dns-srv connection-string option also enables DNS SRV lookups for connections using either the classic MySQL protocol or X Protocol. The DNS SRV feature is disable by default. For usage information, see Options for Both Classic MySQL Protocol and X Protocol https://dev.mysql.com/doc/connector-net/en/connector-net-8-0-connection-options.html#connector-net-8-0-connection-options-classic-xprotocol. * When creating a new connection using classic MySQL protocol, multiple hosts can be tried until a successful connection is established. A list of hosts can be given in a connection string, with or without priorities. // Example with priority server=(address=192.10.1.52:3305,priority=60),(address=localhost:3306, priority=100); // Example without priority and with multiple ports host=10.10.10.10:3306,192.101.10.2:3305,localhost:3306;uid=test;passwo rd=xxxx; If the priority is not included, or if multiple hosts have the same priority, Connector/NET selects a host at random. The same random selection behavior also applies to connections made using X Protocol, which previously selected hosts sequentially when no priority was specified. Bugs Fixed * Clone connections did not process all connection settings as expected. (Bug #30502718) * Connector/NET files displayed an unlikely date after the NuGet package containing them was installed in a project. (Bug #30471336, Bug #97390) * The inclusion of the System.Resources.Extensions dependency was transient and now is removed from the MySql.Data NuGet package. (Bug #30421657, Bug #97218) On behalf of Oracle/MySQL Release Engineering Team, Tvarita Jain [Less]

A few days ago I wrote about how grossly outdated statistics returned through MySQL’s Information_Schema can be. In that post, Øystein Grøvlen suggested taking a look at mysql.innodb_table_stats and mysql.innodb_index_stats as a better source of ... [More] information. Let’s do just that! Let’s start with the good news. Unlike MySQL Data Dictionary Tables (mysql.table_stats, etc),  mysql.innodb_table_stats and mysql.innodb_index_stats can be queried by the user. They also contain a lot of interesting statistics. Before we get to that though, let’s examine where those tables come from in more detail. As the manual tells us, these tables are storing InnoDB Persistent Statistics, but only if those statistics are enabled. While in MySQL 8 the default is to use Persistent Statistics and update them automatically, the user has an option to disable persistent statistics by setting  innodb_stats_persistent=0 variable or disable automatic updates by setting innodb_stats_auto_recalc=0,  which means the data in these tables may be missing or maybe very stale. Furthermore, in their quest for ultimate flexibility, the MySQL Team allows you to enable/disable these options on a table by table basis using STATS_PERSISTENT, STATS_AUTO_RECALC, and STATS_SAMPLE_PAGES   CREATE TABLE clauses. This means information may be present for some tables but not others. So while this data is very valuable when it presents, you should not count on its being present or on its accuracy. OK, enough of that. Let’s take a look at what we have in those tables: mysql> select * from mysql.innodb_table_stats where database_name='tpcc' and table_name='orders1' \G *************************** 1. row *************************** database_name: tpcc table_name: orders1 last_update: 2020-01-04 23:59:27 n_rows: 380197 clustered_index_size: 1185 sum_of_other_index_sizes: 672 1 row in set (0.00 sec) The table information contains an estimated number of rows as well as clustered index size and size of all other indexes combined in pages. Multiply it by innodb_page_size  variable and you will get the size in bytes. Also, note the last_update column which specifies when stats were last updated. Very old last_update may mean two things – either the table is not getting many writes for stats update to be triggered, or automatic stats update for this table is disabled. Now let’s take a look at innodb_index_stats table: mysql> select * from mysql.innodb_index_stats where database_name='tpcc' and table_name='orders1'; +---------------+------------+-------------+---------------------+--------------+------------+-------------+-----------------------------------+ | database_name | table_name | index_name | last_update | stat_name | stat_value | sample_size | stat_description | +---------------+------------+-------------+---------------------+--------------+------------+-------------+-----------------------------------+ | tpcc | orders1 | PRIMARY | 2020-01-04 23:59:27 | n_diff_pfx01 | 9 | 11 | o_w_id | | tpcc | orders1 | PRIMARY | 2020-01-04 23:59:27 | n_diff_pfx02 | 101 | 20 | o_w_id,o_d_id | | tpcc | orders1 | PRIMARY | 2020-01-04 23:59:27 | n_diff_pfx03 | 380197 | 20 | o_w_id,o_d_id,o_id | | tpcc | orders1 | PRIMARY | 2020-01-04 23:59:27 | n_leaf_pages | 991 | NULL | Number of leaf pages in the index | | tpcc | orders1 | PRIMARY | 2020-01-04 23:59:27 | size | 1185 | NULL | Number of pages in the index | | tpcc | orders1 | idx_orders1 | 2020-01-04 23:59:27 | n_diff_pfx01 | 9 | 11 | o_w_id | | tpcc | orders1 | idx_orders1 | 2020-01-04 23:59:27 | n_diff_pfx02 | 101 | 20 | o_w_id,o_d_id | | tpcc | orders1 | idx_orders1 | 2020-01-04 23:59:27 | n_diff_pfx03 | 306329 | 20 | o_w_id,o_d_id,o_c_id | | tpcc | orders1 | idx_orders1 | 2020-01-04 23:59:27 | n_diff_pfx04 | 378338 | 20 | o_w_id,o_d_id,o_c_id,o_id | | tpcc | orders1 | idx_orders1 | 2020-01-04 23:59:27 | n_leaf_pages | 577 | NULL | Number of leaf pages in the index | | tpcc | orders1 | idx_orders1 | 2020-01-04 23:59:27 | size | 672 | NULL | Number of pages in the index | +---------------+------------+-------------+---------------------+--------------+------------+-------------+-----------------------------------+ 11 rows in set (0.00 sec) This table is designed to be extensible and able to hold many different statistics for the same index. We see several statistics here. First, there are n_diff_pfxXX statistics which show cardinality for different index prefixes – the specific columns which are part of that prefix are specified in stat_description  value. These are the same cardinality values you would see if you execute the  SHOW INDEX FROM tpcc.orders1 command. The other stats are n_leaf_pages and size which for each index specifies the full size (in pages) as well as the number of leaf pages. The difference between these two is the number of non-leaf pages the table has. In this example, the orders1 table has 95 non-leaf pages and 577 leaf pages, or 672 pages in total. This information can help you to identify how much space is needed in the InnoDB buffer pool if you want a particular index fully cached, or at least have non-leaf pages cached (which ensures index lookup will not take more than one IO operation). Summary mysql.innodb_table_stats and mysql.innodb_index_stats can be great sources of detailed information about your InnoDB tables and Indexes, and they are enabled and available by default in modern MySQL versions. Keep in mind, though, under certain configurations the information in these tables is unavailable or severely outdated. Also because the statistics are computed through sampling, they are not exact  – and can be grossly inaccurate in some conditions. [Less]