subject:"IF"

MySQL Enterprise Backup 8.0.16, a new version of the online MySQL backup
tool, is now available for download from the My Oracle Support (MOS) website
as our latest GA release. This release will be available on eDelivery (OSDC)
after the next upload cycle. MySQL Enterprise Backup is a commercial
extension to the MySQL family of products.

MySQL Enterprise Backup 8.0.16 supports only the MySQL Server 8.0.16.
For earlier versions of MySQL 8.0, use the MySQL Enterprise Backup
version with the same version number as the server. For MySQL server
5.7, please use MySQL Enterprise Backup 4.1, and for MySQL Server 5.6
and 5.5, please use MySQL Enterprise Backup 3.12.

A brief summary of the changes in MySQL Enterprise Backup (MEB)
version 8.0.16 is given below.

Changes in MySQL Enterprise Backup 8.0.16 (2019-04-25, GA)

* Functionality Added or Changed

* Bugs Fixed

Functionality Added or Changed

* mysqlbackup now supports encrypted InnoDB undo logs
(http://dev.mysql.com/doc/refman/8.0/en/innodb-tablespace-encryption.html#innodb-tablespace-encryption-undo-log).
The encrypted undo tablespaces are handled the same way
as the encrypted tablespaces for InnoDB tables. See
Working with Encrypted InnoDB Tablespaces
(http://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-encrypted-innodb.html)
for details.

* Near the end of the backup process, instead of locking
the whole server instance for a brief period of time,
mysqlbackup now applies these locks consecutively:

1. A backup lock
(http://dev.mysql.com/doc/refman/8.0/en/lock-instance-for-backup.html)
on the server instance, which
blocks DDLs (except those on user-created temporary
tables), but not DMLs on InnoDB tables.

2. A FLUSH TABLES tbl_name [, tbl_name] ... WITH READ
LOCK
(http://dev.mysql.com/doc/refman/8.0/en/flush.html#flush-tables-with-read-lock-with-list)
operation on all non-InnoDB tables, for copying the
relevant ones among them into the backup. This step is
skipped if no user-created non-InnoDB tables exist.

3. A brief blocking of logging activities on the
server, for collecting logging-related information.
See The Backup Process
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-backup-process)
for details. The removal of the lock
on the whole server instance reduces disruption to the
database service by the backup operation.
Important
The change requires that the BACKUP_ADMIN
(http://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_backup-admin)
and SELECT
(http://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_select)
privileges on all tables be granted
to the user by which mysqlbackup connects to the server
(the BACKUP_ADMIN
(http://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_backup-admin)
privilege is automatically granted to users with the RELOAD
(http://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_reload)
privilege when an in-place upgrade to MySQL Server 8.0 from an
earlier version is performed).

* mysqlbackup now supports dynamic changes to undo
tablespaces
(http://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html)
on the server being backed up. During a
restore, the default undo tablespaces, as well as any
non-default undo tablespaces resided in the backed-up
server's data directory, are restored to the location
pointed to by the mysqlbackup option
--innodb_undo_directory. Non-default, external undo
tablespaces are restored to the locations they were found
on the backed-up server. See undo log files
(http://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-files-backed-up-summary.html#meb_file_undo-log-files)
for details.

* In addition to the requirement that the target data
directory for a restore specified by the --datadir option
must be non-existent or empty, mysqlbackup now enforces
the same rule for the --innodb_data_home_dir,
--innodb_log_group_home_dir, and --innodb_undo_directory
options (the --force option cannot be used to override
the requirement on the three options).

Bugs Fixed

* Zip packages of mysqlbackup contained duplicate files,
which have now been removed. (Bug #29497272, Bug #94683)

* mysqlbackup might quit unexpectedly if it lost its
connection to the server at the middle of a backup
operation. With this fix, mysqlbackup exits gracefully in
the situation after throwing the appropriate errors. (Bug
#29376006)

* Restore of an incremental backup failed if, on the
server, some binary log files had been purged in between
the times the incremental backup and

MySQL Router 8.0.16 for MySQL Server 8.0 and 5.7 has been released

Dear MySQL users,

MySQL Router 8.0.16 is a new release for MySQL Router 8.0 series.

MySQL Router 8.0 is highly recommended for use with MySQL Server 8.0 and 5.7.
Please upgrade to MySQL Router 8.0.16.

The MySQL Router is a new building block for high availability solutions
based on MySQL InnoDB clusters.

By taking advantage of the new Group Replication technology, and
combined with the MySQL Shell, InnoDB clusters provide an integrated
solution for high availability and scalability for InnoDB based MySQL
databases, that does not require advanced MySQL expertise.

The deployment of applications with high availability requirements is
greatly simplified by MySQL Router. MySQL client connections are
transparently routed to online members of a InnoDB cluster, with MySQL
server outages and cluster reconfigurations being automatically handled
by the Router.

To download MySQL Router 8.0.16, see the "Generally Available (GA)
Releases" tab at http://dev.mysql.com/downloads/router. Package
binaries are available for several platforms and also as a source code
download.

Documentation for MySQL Router can be found at
http://dev.mysql.com/doc/mysql-router/en/

Enjoy!

Changes in MySQL Router 8.0.16 (2019-04-25, General Availability)

 * Functionality Added or Changed

 * Bugs Fixed

Functionality Added or Changed


 * Before, bootstrapping would generate Read-Write (PRIMARY)
   and Read-Only (SECONDARY) configuration routing sections
   for multi-master mode, but only Read-Write sections for
   single-master mode. Now, both Read-Write and Read-Only
   sections are always generated.

 * Bootstrapping now sets new routing_strategy values in the
   generated configuration file. Read-Write (PRIMARY)
   sections set routing_strategy to first-available; and
   Read-Only (SECONDARY) sections set it to
   round-robin-with-fallback. Previously, they were both set
   to round-robin.
   The default behavior (for example, if routing_strategy is
   not defined in mysqlrouter.conf) did not change and is
   still round-robin.

 * Added ability to integrate external log-rotation
   applications by reopening the file-based logfile on
   SIGHUP. On Linux, this allows integrating the system-wide
   logrotate utility.

 * On Windows, added the ability to report events to the
   Windows Application Events log.

 * Added a new sinks configuration file option to define one
   or more logger sinks. For example, all level=debug
   messages can be sent to a file while only level=error are
   sent to an eventlog.
   The supported sinks are: consolelog, filelog, eventlog on
   Windows, and syslog on Unix-based systems.

 * An HTTP interface was added based on libevent's HTTP
   library. It's configured using a new [http_server]
   configuration section that contains the following
   options:

  + port: The TCP port listening for HTTP requests; it
defaults to 8011.

  + bind_address: IPv4 address bound to the port; it
defaults to 0.0.0.0.

  + static_folder: Base directory for static file
requests; it's empty by default. An empty value
means no static files are served.

  + require_realm: Name of the [http_auth_realm]
instance.

  + ssl: The value 1 enables SSL, and 0 disables it. TLS
clients supporting TLSv1.2 or later are required.

  + ssl_cert: File name of the certificate and its chain
certifications in PEM format; required if ssl=1.

  + ssl_key: File name of the key in PEM format;
required if ssl=1.

  + ssl_cipher: The cipher-spec (see openssl's 'ciphers'
list). Defaults to a comma-separated list of all
approved ciphers. Unknown ciphers are silently
ignored. Fails if list of ciphers is empty and
ssl=1.

  + ssl_dh_param: Read the DH parameter from this file
in PEM format. Uses the dh-param from RFC 5114 by
default if ssl=1.

 * A mysqlrouter_passwd tool was added to manage password's
   for the HTTP server component.
   Two new HTTP configuration sections were added;
   [http_auth_backend] and [http_auth_realm]. Both are
   optional, and multiple definitions are allowed. There
   options are:
   [http_auth_backend]

  + backend: Name of the backend implementation; it
defaults to file.

  + filename: Name of the backend storage file, relative
to the data_folder directory.
   [http_auth_realm]

  + backend: Name of the [http_auth_backend] section.

  + method: The HTTP authentication method; defaults to
basic.

  + require: Requires that the user validates with the
authentication backend; defaults to valid-user,
which enables this check.

MySQL Community Server 8.0.16 has been released [part 2]

[This is part 2 of the announcement]

Bugs Fixed, continued

 * InnoDB: Write-ahead did not work as expected due to an
   incorrectly initialized variable.
   Thanks to Yuhui Wang for the contribution. (Bug
   #29028838, Bug #93442)

 * InnoDB: The base column information for a generated
   column was not stored. (Bug #29021730)

 * InnoDB: An implicit lock check on secondary indexes
   needlessly compared columns using collation rules. (Bug
   #29010725)

 * InnoDB: Assertion code related to the innodb_flush_method
   O_DIRECT_NO_FSYNC setting was no longer valid due to a
   recent modification to that setting. Assertion code was
   revised. (Bug #29007731)
   References: See also: Bug #27309336.

 * InnoDB: When starting the server with undo log encryption
   enabled, the master key for newly created undo
   tablespaces was generated without a server UUID. Undo
   tablespaces should use the DefaultMasterKey if the server
   UUID is not yet generated. (Bug #29006275)

 * InnoDB: Data dictionary code did not check for a returned
   data dictionary object, which could potentially cause the
   server to exit due to a null pointer access. (Bug
   #28977444, Bug #93362)

 * InnoDB: An undo tablespace file was left behind by a
   failed CREATE UNDO TABLESPACE operation. (Bug #28966457)

 * InnoDB: A CREATE UNDO TABLESPACE statement failed on
   Windows due to an invalid character in the file name. The
   failure resulted in a hang condition due to a missing
   OS_FILE_ON_ERROR_NO_EXIT attribute in the call that
   creates the undo tablespace file. (Bug #28955676)

 * InnoDB: Modifying the value of the
   innodb_undo_log_encrypt variable was not a blocking
   operation, which could lead to the modification being
   reverted by a background thread after the operation
   appeared to have been completed successfully. (Bug
   #28952870)

 * InnoDB: An invalid debug assertion was removed from the
   temptable::Handler::primary_key_is_clustered function.
   (Bug #28949332)

 * InnoDB: An ALTER TABLE ... EXCHANGE PARTITION operation
   did not properly update column table_id values in the
   data dictionary. (Bug #28927005)

 * InnoDB: Memory leaks discovered in the innochecksum
   utility were removed. (Bug #28917614, Bug #93164)

 * InnoDB: A DDL operation that followed a failed attempt to
   create an index on a virtual column resulted in an
   assertion failure. (Bug #28825718)

 * InnoDB: A performance regression was observed for partial
   update operations on compressed BLOBs less than or equal
   to 128KB in size. (Bug #28784301)

 * InnoDB: Running aggregated queries raised Valgrind
   warnings. (Bug #28711717)

 * InnoDB: A CHECK TABLE operation raised an assertion
   failure. A pointer to a local call stack variable was not
   set back to null before a function exit. (Bug #28525110)

 * InnoDB: DDL log functions were modified to handle
   ER_TOO_MANY_CONCURRENT_TRXS errors. (Bug #28523127, Bug
   #92071)

 * InnoDB: The purge thread failed to free LOB data pages.
   (Bug #28510599)

 * InnoDB: Some DDL log table transactions were not rolled
   back prior to DDL log recovery. (Bug #28494969)

 * InnoDB: A function invoked during SHOW CREATE TRIGGER
   processing that retrieves the table name did not perform
   the expected lowercase conversion. (Bug #28351038)

 * InnoDB: The INFORMATION_SCHEMA.INNODB_FOREIGN TYPE column
   reported incorrect values. (Bug #28315651, Bug #91577)

 * InnoDB: A Linux AIO handler function failed to check if
   completed I/O events succeeded. Thanks to Wei Zhao for
   the contribution. (Bug #27850600, Bug #90402)

 * InnoDB: An assertion failure was raised in a check that
   determines if a transaction holds an implicit lock on a
   secondary index. A transaction that does not change the
   columns of a secondary index that includes virtual
   columns could be incorrectly determined to hold an
   implicit lock. (Bug #27491839)

 * InnoDB: A function called by a CREATE TABLE thread
   attempted to access a table object after it was freed by
   a background thread.
   Thanks to Yan Huang for the patch. (Bug #27373959, Bug
   #89126)

 * InnoDB: Two sessions concurrently executing an INSERT ...
   ON DUPLICATE KEY UPDATE operation generated a deadlock.
   During partial rollback of a tuple, another session could
   update it. The fix for this bug reverts fixes for Bug
   #11758237, Bug #17604730, and Bug #20040791. (Bug
   #25966845)

 * InnoDB: When the method used to access a joined table was
   const, InnoDB attempted to unlock the matching row
   multiple times. (Bug #20939184)

 * InnoDB: The INDEX_LENGTH value in

MySQL Community Server 8.0.16 has been released [part 1]

[Due to size limitation, this announcement is split in two. This is part 1] 

Dear MySQL users,

MySQL Server 8.0.16, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.16 is
recommended for use on production systems.

For an overview of what's new in MySQL 8.0, please see

http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html

For information on installing MySQL 8.0.16 on new servers, please see
the MySQL installation documentation at

  http://dev.mysql.com/doc/refman/8.0/en/installing.html

MySQL Server 8.0.16 is available in source and binary form for a number of
platforms from our download pages at

  http://dev.mysql.com/downloads/mysql/

MySQL Server 8.0.16 is also available from our repository for Linux
platforms, go here for details:

  http://dev.mysql.com/downloads/repo/

Windows packages are available via the Installer for Windows:

  http://dev.mysql.com/downloads/installer/

along with .ZIP (no-install) packages for more advanced needs. 

8.0.16 also comes with a web installer as an alternative to the full
installer.

The web installer doesn't come bundled with any actual products
and instead relies on download-on-demand to fetch only the
products you choose to install. This makes the initial download
much smaller but increases install time as the individual products
will need to be downloaded.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc.:

  http://bugs.mysql.com/report.php

The following link lists the changes in the MySQL 8.0 since
the release of MySQL 8.0.15. It may also be viewed
online at

  http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-16.html

Enjoy!

==
Changes in MySQL 8.0.16 (2019-04-25, General Availability)


 * Account Management Notes

 * C API Notes

 * Character Set Support

 * Compilation Notes

 * Configuration Notes

 * Deprecation and Removal Notes

 * Installation Notes

 * Packaging Notes

 * Parser Notes

 * Performance Schema Notes

 * Plugin Notes

 * Security Notes

 * Spatial Data Support

 * SQL Syntax Notes

 * Test Suite Notes

 * X Plugin Notes

 * Functionality Added or Changed

 * Bugs Fixed

Account Management Notes


 * Previously, users who had the DROP ROLE privilege could
   use the DROP ROLE statement to drop locked or unlocked
   accounts. Now, users who have the DROP ROLE privilege can
   use DROP ROLE only to drop accounts that are locked
   (unlocked accounts are presumably user accounts used to
   log in to the server and not just as roles). Users who
   have the CREATE USER privilege can use DROP ROLE to drop
   accounts that are locked or unlocked. (Bug #28953158, Bug
   #93263)

 * Several changes have been made to MySQL
   account-management capabilities:

  + MySQL now incorporates the concept of user account
categories, with system and regular users
distinguished according to whether they have the new
SYSTEM_USER privilege:
   o System users are users who possess the
 SYSTEM_USER privilege. A system user can
 perform operations on both system and regular
 accounts.
   o Regular users are ordinary users who do not
 possess the SYSTEM_USER privilege. A regular
 user can perform operations on regular
 accounts, but not system accounts.
If a user has the appropriate privileges to perform
a given operation on regular accounts, SYSTEM_USER
enables the user to also perform the operation on
system accounts. SYSTEM_USER does not imply any
other privilege, so the ability to perform a given
account operation remains predicated on possession
of any other required privileges. For example, if a
user can grant the SELECT and UPDATE privileges to
regular accounts, then with SYSTEM_USER the user can
also grant SELECT and UPDATE to system accounts.
The distinction between system and regular accounts
enables better control over certain account
administration issues by protecting accounts that
have the SYSTEM_USER privilege from accounts that do
not have the privilege. For example, the CREATE USER
privilege enables not only creation of new accounts,
but modification and removal of existing accounts.
Without the system user concept, a user who has the
CREATE USER privilege can modify or drop any
existing account, including the root account. The
concept of system user enables restricting
modifications to the root account (itself a system
account)

Re: How do I determine if versions of phpMyAdmin before 4.8.5 is SQL Injectable using sqlmap?

2019-04-17 Thread shawn l.green


Hello,

On 4/17/2019 10:29 AM, Turritopsis Dohrnii Teo En Ming wrote:

Subject/Topic: How do I determine if versions of phpMyAdmin before 4.8.5 is SQL 
Injectable using sqlmap?

Good evening from Singapore,

Our customer (company name is Confidential/not disclosed) reported that their 
MySQL database has been found missing or was deleted a few times.


While it is bad form to explain how to break into anyone's software 
(including our own), there are places you can look to get a better idea 
about what might have happened:


1 - the database may have been removed by a DROP DATABASE command.

General Query Log - this will show you which session issued the command 
and the command itself.


Audit log (only for commercial releases) - same thing

Binary Log - Should have a record of the command executing. But, 
depending on which account was used or if Binary Log filtering is in 
place, it may not. This presumes that the Binary Log is even enabled on 
this system.  Many people mistakenly believe it is only for Replication 
when its other primary use is for point-in-time recovery. If your 
customer has a recent backup and all of the Binary Log files created 
since that backup, they could return the system to the point it was at 
just before that database went missing, skip that DROP command, then 
continue rolling forward the changes to the other tables to return to a 
"current" state of their data.


2 - The database was "dropped" by either changing privileges to the 
folder or by removing it from disk or some other file-level or 
system-level operation. Either of those would cause errors to start 
appearing in the MySQL Error Log because a resource that mysqld thinks 
should exist is no longer available.   While the Error Log can't tell 
you which operation made those files "no longer available" it will have 
a fingerprint that such an action happened outside of mysqld.



Have you determined which method was used to make that database/schema 
disappear?


A normal DROP command (which could happen through an SQL injection 
attack) would not leave messages in the Error Log about "unable to 
access ..." or something similar. The server (mysqld) would know that 
the database was gone (because it removed it) and it wouldn't be trying 
to find it or the tables within it for your clients to use it.





... snip ...
No matter how many commands I try, sqlmap always report that phpMyAdmin 4.8.4 
is *NOT* SQL injectable. Perhaps I was using the wrong sqlmap commands all the 
time? The following is one of the many sqlmap commands I have used.

$ python sqlmap.py -u "https://www.EXAMPLE.com/phymyadmin/index.php?id=1; --level=1 
--dbms=mysql --sql-query="drop database"



Privately asking phpMyAdmin may be a better source of information about 
how to hack their system to do things it was not intended to do. This 
list is not about phpMyAdmin and it is very public.  They may also have 
a way of showing you some kind of trace or log that serves as a 
fingerprint for that happening.



--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Integrated Cloud Applications & Platform Services
Office: Blountville, TN

Become certified in MySQL! Visit https://www.mysql.com/certification/ 
for details.


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

How do I determine if versions of phpMyAdmin before 4.8.5 is SQL Injectable using sqlmap?

2019-04-17 Thread Turritopsis Dohrnii Teo En Ming

Subject/Topic: How do I determine if versions of phpMyAdmin before 4.8.5 is SQL 
Injectable using sqlmap?

Good evening from Singapore,

Our customer (company name is Confidential/not disclosed) reported that their 
MySQL database has been found missing or was deleted a few times. They are 
using Ubuntu 16.04 LTS Linux server with Apache2 Web Server, MySQL and PHP 
(LAMP).

We responded to these security incidents by changing the passwords of the 
regular user, root user, and MySQL database user root. We have also examined 
/var/log/auth.log and think that the hacker could not have come in through ssh 
or sftp over ssh. From /var/log/mysql/error.log, we can ascertain that the 
MySQL database has been deleted at certain timings. We have also found nothing 
abnormal after examining /var/log/apache2/access.log.

Even though we have secured the Ubuntu Linux server by changing passwords, the 
hacker was still able to delete our customer's MySQL database again and again. 
I have already proposed to install ModSecurity Open Source Web Application 
Firewall (WAF) to defend against web application attacks but my boss has told 
me to put that on hold at the moment. In fact, I have already deployed 
ModSecurity 2.9.0 on a Ubuntu 16.04 LTS *Testing* server and found that it 
actively detects and logs Nessus and sqlmap vulnerability scans in blocking 
mode.

Since we did not find any evidence that the hacker had breached our customer's 
Ubuntu 16.04 LTS production server through ssh or Teamviewer, we suspect that 
the hacker could have achieved it by SQL injection. I took the initiative of 
downloading and installing Nessus Professional 8.3.1 Trial version for Windows 
64-bit. The vulnerability scan report generated by Nessus Web Application Tests 
shows that our customer is using a version of phpMyAdmin prior to 4.8.5 which 
could be vulnerable to SQL injection using the designer feature.

Further research shows that I can use sqlmap to determine if phpMyAdmin is SQL 
injectable. I already have a Testing Ubuntu 16.04 LTS Linux server with a 
Testing MySQL database and a Testing phpMyAdmin 4.8.4. I have purposely 
installed phpMyAdmin 4.8.4 because this version was reported to be vulnerable 
to SQL injection using the designer feature, and our customer is using a 
vulnerable version, according to CVE-2019-6798 ( 
https://nvd.nist.gov/vuln/detail/CVE-2019-6798 ). Then I proceeded to download 
and execute sqlmap on our Ubuntu Linux desktop against our Testing server.

No matter how many commands I try, sqlmap always report that phpMyAdmin 4.8.4 
is *NOT* SQL injectable. Perhaps I was using the wrong sqlmap commands all the 
time? The following is one of the many sqlmap commands I have used.

$ python sqlmap.py -u "https://www.EXAMPLE.com/phymyadmin/index.php?id=1; 
--level=1 --dbms=mysql --sql-query="drop database"

Replace database by database name.

May I know what is the correct sqlmap command that I should use to determine 
that my Testing phpMyAdmin 4.8.4 is SQL injectable? I would like to know if I 
can successfully drop/delete the Testing database on our Testing server. If I 
can successfully drop/delete the Testing MySQL database using sqlmap, I would 
be able to conclude that the hacker must have carried out SQL injection to 
drop/delete the customer's database. I have already turned off the Testing 
ModSecurity Web Application Firewall on our Testing server to allow sqlmap to 
go through.

Please point me to any good tutorial on SQL injection using sqlmap. Maybe I do 
not understand SQL injection well enough. Our customer is also using a 
customised in-house inventory management system that relies on PHP application 
and MySQL database.

Would open source Snort Intrusion Detection System (IDS) and Intrusion 
Prevention System (IPS) be able to detect and block SQL injection as well?

Please advise.

Thank you very much.

-BEGIN EMAIL SIGNATURE-

The Gospel for all Targeted Individuals (TIs):

[The New York Times] Microwave Weapons Are Prime Suspect in Ills of
U.S. Embassy Workers

Link: 
https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html



Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic
Qualifications as at 14 Feb 2019

[1] https://tdtemcerts.wordpress.com/

[2] https://tdtemcerts.blogspot.sg/

[3] https://www.scribd.com/user/270125049/Teo-En-Ming

-END EMAIL SIGNATURE-


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

[ANN] Mroonga 9.01 - Fast fulltext search for all languages on MySQL

2019-03-28 Thread Kentaro Hayashi

Hi,

Mroonga 9.01 has been released!

Mroonga is a MySQL storage engine that supports fast fulltext search
and geolocation search.  It is CJK ready. It uses Groonga as a storage
and fulltext search engine.

Document:
   http://mroonga.org/docs/

How to install: Install Guide
   http://mroonga.org/docs/install.html

How to upgrade: Upgrade Guide
   http://mroonga.org/docs/upgrade.html

Blog:
   http://mroonga.org/en/blog/2019/03/29/mroonga-9.01.html

Changes:
   http://mroonga.org/docs/news.html#release-9.01

Here are some topics in this release.

  * Improved support for more table and comment parameter about 
tokenizer/normalizer/indexes.
* See above blog entry about details.
  * Added support for latest MariaDB/Percona Server.
* Percona Server 5.7.25-28.
* MariaDB 10.3.13.
* MariaDB 10.2.23.
  * Added support for building bundled MariaDB package on AppVeyor.

Let's search by Mroonga!


Regards,

-- 
Kentaro Hayashi 

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: Replication and user privileges

2019-02-26 Thread Jim

On 2/26/2019 1:57 PM, Jim wrote:

On 2/26/2019 9:44 AM, shawn l.green wrote:

Hello Jim,

On 2/25/2019 7:29 PM, Jim wrote:

On 2/25/2019 5:46 PM, shawn l.green wrote:

Hello Jim,

On 2/25/2019 5:04 PM, Jim wrote:
I have a question about mysql replication. I believe I understand
most

of it, but have a question about user privileges.

I understand on the master, the replication user must have the
Repl_slave_priv privilege as described here:
https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-slave

My question is about what replication-related users and privileges
must

exist on the slave.

So, for example, if an insert on the master that is to be
replicated is

performed by user 'abc' with proper insert permissions on the master,
does that same 'abc' user with same insert permissions need to
exist on

the slave as well?

In other words, what user is performing the replication operation
on the

slave? I don't see any indication of users referenced in the bin logs
that I have examined on the master. Are user and privileges regarding
replicated queries irrelevant on the slave and that is handled all
internally via the replication thread with no regard to user
privileges?

Thank you.
Jim

Your final supposition is correct. All privileges were checked and
verified on the master when the original command was executed. The
Replication system on the slave is going to repeat that change as well
as possible given the state of its copy of the data without regards to
"who originally performed this change" on the upstream master.

We do not store credentials in the Binary Log because they are not
important to either of the purposes of the Binary Log

* point-in-time recovery
or
* Replication (which is very much like an automated, continuous
point-in-time recovery)

===

That replication account you mentioned, on the master, is required to
give a slave (and you could have several) enough rights to read the
Binary Log and not much else. This allows you to create an account
that can login from a remote location with the "least privileges"
necessary to do its job. This minimizes your data's exposure should
that account become compromised.

Many other accounts could also have the REPL_SLAVE_PRIV privilege and
any of those could be used by a slave to do the same job. However
losing control over one of those more privileged accounts could pose a
higher risk to your data.

Thanks, Shawn. Your response confirms what I had assumed was happening.

So bottom line... what I plan to do is strip the various
insert/update/delete privileges from appropriate db users on my slaves.
I had placed them there originally because I thought they would be
needed for the replicated queries, but not true based on your response.

I only want the various mysql users used by my code to have select
privs
on the slaves so that if somehow a slave was mistakenly written to
via a
bug in my code, that write would fail and I would receive the error.
The
slaves should only be used for selects and should never experience a
write.

That would make sense based on our discussion, correct?

Thanks again.
Jim

As masters and slaves can exchange "positions" or "roles" (it depends
on how you like to mentally visualize the relationship) within a
replication graph in a failover situation, adding time to
re-establish actual permissions using GRANT commands to reset user
accounts to their old privileges may not be time you want to spend.

A cleaner, simpler solution is to set the --super-read-only flag in
the server:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only

That way, you get the behavior you want (no writes to a read-only
slave) without forcing differences to the content of your privileges
tables within different nodes of your Replication setup. Each node
will remain a transactionally consistent copy of all the others
(within the temporal limits of replication being an asynchronous
process).

Yours,

Thanks, Shawn.

super-read-only looks perfect for what I want. I can keep my slaves
with all the potential users needed to take over as master without
risking unwanted writes.

Given how you read:
"If the |read_only|

system variable is enabled, the server permits client updates only
from users who have the |SUPER|

privilege. If the |super_read_only|

system variable is also enabled, the server prohibits client updates
even from users who have |SUPER|
."
One somewhat gets the impression that in order to enable
super_read_only, one must also enable read_only.

However, based on:

Re: Replication and user privileges

2019-02-26 Thread Jim

On 2/26/2019 9:44 AM, shawn l.green wrote:

Hello Jim,

On 2/25/2019 7:29 PM, Jim wrote:

On 2/25/2019 5:46 PM, shawn l.green wrote:

Hello Jim,

On 2/25/2019 5:04 PM, Jim wrote:

I have a question about mysql replication. I believe I understand most
of it, but have a question about user privileges.

I understand on the master, the replication user must have the
Repl_slave_priv privilege as described here:
https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-slave

My question is about what replication-related users and privileges
must

exist on the slave.

So, for example, if an insert on the master that is to be
replicated is

performed by user 'abc' with proper insert permissions on the master,
does that same 'abc' user with same insert permissions need to
exist on

the slave as well?

In other words, what user is performing the replication operation
on the

Thank you.
Jim

We do not store credentials in the Binary Log because they are not
important to either of the purposes of the Binary Log

* point-in-time recovery
or
* Replication (which is very much like an automated, continuous
point-in-time recovery)

===

Thanks, Shawn. Your response confirms what I had assumed was happening.

I only want the various mysql users used by my code to have select privs
on the slaves so that if somehow a slave was mistakenly written to via a
bug in my code, that write would fail and I would receive the error. The
slaves should only be used for selects and should never experience a
write.

That would make sense based on our discussion, correct?

Thanks again.
Jim

As masters and slaves can exchange "positions" or "roles" (it depends
on how you like to mentally visualize the relationship) within a
replication graph in a failover situation, adding time to re-establish
actual permissions using GRANT commands to reset user accounts to
their old privileges may not be time you want to spend.

A cleaner, simpler solution is to set the --super-read-only flag in
the server:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only

Yours,

Thanks, Shawn.

super-read-only looks perfect for what I want. I can keep my slaves with
all the potential users needed to take over as master without risking
unwanted writes.

Given how you read:
"If the |read_only|

system variable is enabled, the server permits client updates only from
users who have the |SUPER|

privilege. If the |super_read_only|

However, based on:

Re: Replication and user privileges

2019-02-26 Thread shawn l.green

Hello Jim,

On 2/25/2019 7:29 PM, Jim wrote:

On 2/25/2019 5:46 PM, shawn l.green wrote:

Hello Jim,

On 2/25/2019 5:04 PM, Jim wrote:

I have a question about mysql replication. I believe I understand most
of it, but have a question about user privileges.

I understand on the master, the replication user must have the
Repl_slave_priv privilege as described here:
https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-slave

My question is about what replication-related users and privileges must
exist on the slave.

So, for example, if an insert on the master that is to be replicated is
performed by user 'abc' with proper insert permissions on the master,
does that same 'abc' user with same insert permissions need to exist on
the slave as well?

In other words, what user is performing the replication operation on the
slave? I don't see any indication of users referenced in the bin logs
that I have examined on the master. Are user and privileges regarding
replicated queries irrelevant on the slave and that is handled all
internally via the replication thread with no regard to user privileges?

Thank you.
Jim

We do not store credentials in the Binary Log because they are not
important to either of the purposes of the Binary Log

* point-in-time recovery
or
* Replication (which is very much like an automated, continuous
point-in-time recovery)

===

Thanks, Shawn. Your response confirms what I had assumed was happening.

I only want the various mysql users used by my code to have select privs
on the slaves so that if somehow a slave was mistakenly written to via a
bug in my code, that write would fail and I would receive the error. The
slaves should only be used for selects and should never experience a write.

That would make sense based on our discussion, correct?

Thanks again.
Jim

As masters and slaves can exchange "positions" or "roles" (it depends on
how you like to mentally visualize the relationship) within a
replication graph in a failover situation, adding time to re-establish
actual permissions using GRANT commands to reset user accounts to their
old privileges may not be time you want to spend.

A cleaner, simpler solution is to set the --super-read-only flag in the
server:

https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only

That way, you get the behavior you want (no writes to a read-only slave)
without forcing differences to the content of your privileges tables
within different nodes of your Replication setup. Each node will remain
a transactionally consistent copy of all the others (within the temporal
limits of replication being an asynchronous process).

Yours,

--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Integrated Cloud Applications & Platform Services
Office: Blountville, TN

Become certified in MySQL! Visit https://www.mysql.com/certification/
for details.

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

ANN: Upscene releases Database Workbench 5.6.0

2019-02-26 Thread Martijn Tonies (Upscene Productions)

Upscene Productions is proud to announce the availability of
the next version of the popular multi-DBMS development tool:

“ Database Workbench 5.6.0 "

This new release brings you the Command Line Data Pump & Favorites feature (Pro 
Edition) and a few important bugfixes. 

Version 5.5 brought you support for the latest versions of supported database 
systems, that includes PostgreSQL 11, InterBase 2017 and MySQL 8.

Database Workbench 5 comes in multiple editions with different pricing models, 
there's always a version that suits you!

Here's the full list of changes
http://www.upscene.com/go/?go=tracker=5.6.0=12
and for version 5.5.0
http://www.upscene.com/go/?go=tracker=5.5.0=12

For more information, see What's new in Database Workbench 5?
( http://www.upscene.com/database_workbench/whatsnew )


Database Workbench supports MySQL, MariaDB, Firebird, Oracle, MS SQL Server,
SQL Anywhere, NexusDB, PostgreSQL and InterBase, comes in multiple editions and 
is licensed based on selectable modules.

It includes tools for database design, database maintenance, testing, data 
transfer,
data import & export, database migration, database compare and numerous other 
tools.


About Database Workbench
Database Workbench is a database developer tool, over 12 years in the making and
is being used by thousands of developers across the globe who have come to rely 
on it
every day. From database design, implementation, to testing and debugging, it 
will aid you 
in your daily database work.

About Upscene Productions
Based in The Netherlands, Europe, this small but dedicated company has been 
providing
database developers with useful tools for over 14 years. Slowly expanding the 
product portfolio
and gaining recognition amongst InterBase and Firebird database developers, 
they now offer
tools for a whole range of database systems, including Oracle and Microsoft SQL 
Server.

Re: Replication and user privileges

2019-02-25 Thread Jim


On 2/25/2019 5:46 PM, shawn l.green wrote:

Hello Jim,

On 2/25/2019 5:04 PM, Jim wrote:

I have a question about mysql replication. I believe I understand most
of it, but have a question about user privileges.

I understand on the master, the replication user must have the
Repl_slave_priv privilege as described here:
https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-slave 




My question is about what replication-related users and privileges must
exist on the slave.

So, for example, if an insert on the master that is to be replicated is
performed by user 'abc' with proper insert permissions on the master,
does that same 'abc' user with same insert permissions need to exist on
the slave as well?

In other words, what user is performing the replication operation on the
slave? I don't see any indication of users referenced in the bin logs
that I have examined on the master. Are user and privileges regarding
replicated queries irrelevant on the slave and that is handled all
internally via the replication thread with no regard to user privileges?

Thank you.
Jim



Your final supposition is correct. All privileges were checked and 
verified on the master when the original command was executed. The 
Replication system on the slave is going to repeat that change as well 
as possible given the state of its copy of the data without regards to 
"who originally performed this change" on the upstream master.


We do not store credentials in the Binary Log because they are not 
important to either of the purposes of the Binary Log


* point-in-time recovery
or
* Replication (which is very much like an automated, continuous 
point-in-time recovery)


===

That replication account you mentioned, on the master, is required to 
give a slave (and you could have several) enough rights to read the 
Binary Log and not much else. This allows you to create an account 
that can login from a remote location with the "least privileges" 
necessary to do its job. This minimizes your data's exposure should 
that account become compromised.


Many other accounts could also have the REPL_SLAVE_PRIV privilege and 
any of those could be used by a slave to do the same job. However 
losing control over one of those more privileged accounts could pose a 
higher risk to your data.





Thanks, Shawn. Your response confirms what I had assumed was happening.

So bottom line... what I plan to do is strip the various 
insert/update/delete privileges from appropriate db users on my slaves.
I had placed them there originally because I thought they would be 
needed for the replicated queries, but not true based on your response.


I only want the various mysql users used by my code to have select privs 
on the slaves so that if somehow a slave was mistakenly written to via a 
bug in my code, that write would fail and I would receive the error. The 
slaves should only be used for selects and should never experience a write.


That would make sense based on our discussion, correct?

Thanks again.
Jim

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: Replication and user privileges

2019-02-25 Thread shawn l.green


Hello Jim,

On 2/25/2019 5:04 PM, Jim wrote:

I have a question about mysql replication. I believe I understand most
of it, but have a question about user privileges.

I understand on the master, the replication user must have the
Repl_slave_priv privilege as described here:
https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-slave


My question is about what replication-related users and privileges must
exist on the slave.

So, for example, if an insert on the master that is to be replicated is
performed by user 'abc' with proper insert permissions on the master,
does that same 'abc' user with same insert permissions need to exist on
the slave as well?

In other words, what user is performing the replication operation on the
slave? I don't see any indication of users referenced in the bin logs
that I have examined on the master. Are user and privileges regarding
replicated queries irrelevant on the slave and that is handled all
internally via the replication thread with no regard to user privileges?

Thank you.
Jim



Your final supposition is correct. All privileges were checked and 
verified on the master when the original command was executed. The 
Replication system on the slave is going to repeat that change as well 
as possible given the state of its copy of the data without regards to 
"who originally performed this change" on the upstream master.


We do not store credentials in the Binary Log because they are not 
important to either of the purposes of the Binary Log


* point-in-time recovery
or
* Replication (which is very much like an automated, continuous 
point-in-time recovery)


===

That replication account you mentioned, on the master, is required to 
give a slave (and you could have several) enough rights to read the 
Binary Log and not much else. This allows you to create an account that 
can login from a remote location with the "least privileges" necessary 
to do its job. This minimizes your data's exposure should that account 
become compromised.


Many other accounts could also have the REPL_SLAVE_PRIV privilege and 
any of those could be used by a slave to do the same job. However losing 
control over one of those more privileged accounts could pose a higher 
risk to your data.



--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Integrated Cloud Applications & Platform Services
Office: Blountville, TN

Become certified in MySQL! Visit https://www.mysql.com/certification/ 
for details.


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Replication and user privileges

2019-02-25 Thread Jim

I have a question about mysql replication. I believe I understand most 
of it, but have a question about user privileges.


I understand on the master, the replication user must have the 
Repl_slave_priv privilege as described here:

https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-slave

My question is about what replication-related users and privileges must 
exist on the slave.


So, for example, if an insert on the master that is to be replicated is 
performed by user 'abc' with proper insert permissions on the master, 
does that same 'abc' user with same insert permissions need to exist on 
the slave as well?


In other words, what user is performing the replication operation on the 
slave? I don't see any indication of users referenced in the bin logs 
that I have examined on the master. Are user and privileges regarding 
replicated queries irrelevant on the slave and that is handled all 
internally via the replication thread with no regard to user privileges?


Thank you.
Jim

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Enterprise Backup 3.12.4 has been released

2019-02-15 Thread Surabhi Bhat


Dear MySQL users,

MySQL Enterprise Backup v3.12.4, a new version of the online MySQL backup
tool, is now available for download from the My Oracle Support (MOS) website
as our latest GA release. This release will be available on eDelivery (OSDC)
after the next upload cycle. MySQL Enterprise Backup is a commercial
extension to the MySQL family of products.

A brief summary of the changes in MySQL Enterprise Backup (MEB)
version 3.12.4 is given below.

Changes in MySQL Enterprise Backup 3.12.4 (2019-02-15)

 * Functionality Added or Changed

 * Bugs Fixed

Functionality Added or Changed


 * Information on the executed GTIDs is now includfed in the
   mysqlbackup output and the backup log when the backed-up
   server has GTIDs enabled. (Bug #25978803)

 * A backup became corrupted if, during the backup process,
   a DDL operation that took advantage of MySQL server's
   online DDL feature
   (http://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.html)
   occurred. This was because mysqlbackup did not
   support the server feature---and it still does not. This
   fix avoids the error by having mysqlbackup turn the
   server's system variable old_alter_table to "1" at the
   beginning of a backup if it is "0," so that any DDL
   operations that take place during the backup are handled
   with the old table copy method. mysqlbackup then turns
   the variable back to "0" near the end of the backup
   operation.
   Important
   Notice that in cases where mysqlbackup quits unexpectedly
   and does not turn old_alter_table back to its original
   value, the user will have to turn the value back to "0"
   manually on the server, in order to return the server to
   its original configuration. This should be performed if
   the statement "Server system variable 'old_alter_table'
   was set to '0'. Setting it to '1'" appears in the early
   output of mysqlbackup, but the statement "Setting server
   system variable 'old_alter_table' back to '0'" does not
   appear before mysqlbackup quits.
   (Bug #25217215)

 * A new option, --skip-final-rescan, makes mysqlbackup skip
   the final rescan for InnoDB tables that are modified by
   DDL operations after the database has been locked near
   the end of a backup operation. This potentially shortens
   the duration for the lock and reduces the backup's impact
   on the server's normal operation. See the description for
   --skip-final-rescan for details. (Bug #21094221)

 * The output by mysqlbackup, which goes to the stderr
   stream and the message log, has now been improved to
   include the timestamps and thread IDs for all steps taken
   by mysqlbackup, in order to provide more information for
   debugging purposes. (Bug #20142619)

 * When there were no tables matching the regular expression
   specified with the --include-tables option during a
   backup operation, mysqlbackup still created a backup,
   which contained an empty folder for each database on the
   server. mysqlbackup now throws an error when
   --include-tables selects no tables to be backed up. (Bug
   #18114353)

 * During the final stage of a backup when MySQL Enterprise
   Backup tried to temporarily put the database into a
   read-only state using the FLUSH TABLES WITH READ LOCK
   statement in order to copy non-InnoDB files, if a long
   query was running on the server at the same time, the
   FLUSH TABLES WITH READ LOCK statement could be taking too
   long to finish, holding up further queries and eventually
   bringing down the server.
   A new mysqlbackup option --lock-wait-timeout can now be
   used to specify the timeout in seconds for the FLUSH
   TABLES WITH READ LOCK statement. If the timeout is
   exceeded, the statement is failed and the lock on the
   tables is released, so that queries held up by the lock
   can then be executed. mysqlbackup then retries the
   statement and continues with the backup. Default value
   for --lock-wait-timeout is 60 [seconds]. (Bug #14339483)

 * In order to minimize the impact of a hot backup on the
   MySQL server, the copying of the buffer pool dump files
   and some of the metadata files is now performed before
   the final phase of the backup in which the server
   instance is locked. This shortens the duration for the
   lock and reduces the backup's impact on the server's
   normal operation.
   Also, to minimize the resource used on a backup, the
   copying of the buffer pool dump files is no longer
   performed for partial and offline backups, for which the
   buffer pool dump is usually not very useful.

Bugs Fixed


 * While MySQL Server interprets the system variable setting
   --innodb_checksum_algorithm=0 to mean

Re: mysql V 8.0.12 and mysqdump

2019-02-14 Thread Walter Harms




> Halaasz Saandor  hat am 9. Februar 2019 um 10:01 geschrieben:
> 
> 
> 2019/02/08 10:32 ... Walter Harms:
> > Hello list,
> > i run into an unexpected problem with mysqldump:
> > 
> > mysqldump --version
> > mysqldump  Ver 8.0.12 for Linux on x86_64 (MySQL Community Server - GPL)
> > 
> > 
> > when i try it results in:
> > mysqldump: Error: 'Lost connection to MySQL server during query' when trying
> > to
> > dump tablespaces
> > mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': MySQL
> > server has gone away (2006)
> 
> I regulary hav this problem with the command-line client (mysql.exe) and 
> when I asked R H gave this answer (and with the command-line client it 
> is much less imporant):
> 
>  Forwarded Message 


I found a solution with this (to set for mysqld in my.cnf):
wait_timeout = 31536000

It sets the time out very high and mysqldump can now complet the query.

personaly i would say this is not a propper solution as it does not solve
the problem of an sql statement taking 15min to complet.

re,
 wh

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: mysql V 8.0.12 and mysqdump

2019-02-09 Thread Walter Harms




> Halaasz Saandor  hat am 9. Februar 2019 um 10:01 geschrieben:
> 
> 
> 2019/02/08 10:32 ... Walter Harms:
> > Hello list,
> > i run into an unexpected problem with mysqldump:
> > 
> > mysqldump --version
> > mysqldump  Ver 8.0.12 for Linux on x86_64 (MySQL Community Server - GPL)
> > 
> > 
> > when i try it results in:
> > mysqldump: Error: 'Lost connection to MySQL server during query' when trying
> > to
> > dump tablespaces
> > mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': MySQL
> > server has gone away (2006)
> 
> I regulary hav this problem with the command-line client (mysql.exe) and 
> when I asked R H gave this answer (and with the command-line client it 
> is much less imporant):
> 
>  Forwarded Message 
> Subject: Re: ERROR 2013 (HY000): Lost connection to MySQL server during 
> query
> Date: Mon, 06 Jan 2014 17:07:45 +0100
> From: Reindl Harald 
> 
> 
> Am 06.01.2014 15:36, schrieb h...@tbbs.net:
>  > Now that I installed 5.6.14 on our Vista machine, when using "mysql" 
> I often see that error-message, which under 5.5.8 I never saw. What is 
> going on?
> 
> what about look in the servers logfiles
> most likely "max_allowed_packet" laughable low
> 

I do not thing so,
it is onvoius that the sql statement i postet is rediciusly slow, causing
mysqldump to terminate the connection. What anoys me most is the fact that
the result is empty. So i could remove it from the code, but i have no idea
about the consequences.

NTL i will try max_allowed_packet and see what will happen.

re,
 wh

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: mysql V 8.0.12 and mysqdump

2019-02-09 Thread Halaasz Saandor


2019/02/08 10:32 ... Walter Harms:

Hello list,
i run into an unexpected problem with mysqldump:

mysqldump --version
mysqldump  Ver 8.0.12 for Linux on x86_64 (MySQL Community Server - GPL)


when i try it results in:
mysqldump: Error: 'Lost connection to MySQL server during query' when trying to
dump tablespaces
mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': MySQL
server has gone away (2006)


I regulary hav this problem with the command-line client (mysql.exe) and 
when I asked R H gave this answer (and with the command-line client it 
is much less imporant):


 Forwarded Message 
Subject: Re: ERROR 2013 (HY000): Lost connection to MySQL server during 
query

Date: Mon, 06 Jan 2014 17:07:45 +0100
From: Reindl Harald 


Am 06.01.2014 15:36, schrieb h...@tbbs.net:
> Now that I installed 5.6.14 on our Vista machine, when using "mysql" 
I often see that error-message, which under 5.5.8 I never saw. What is 
going on?


what about look in the servers logfiles
most likely "max_allowed_packet" laughable low

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

[ANN] Mroonga 9.00 - Fast fulltext search for all languages on MySQL

2019-02-08 Thread Horimoto Yasuhiro

Hi,

Mroonga 9.00 has been released!

Mroonga is a MySQL storage engine that supports fast fulltext search
and geolocation search.  It is CJK ready. It uses Groonga as a storage
and fulltext search engine.

Document:
   http://mroonga.org/docs/

How to install: Install Guide
   http://mroonga.org/docs/install.html

How to upgrade: Upgrade Guide
   http://mroonga.org/docs/upgrade.html

Blog:
   http://mroonga.org/en/blog/2019/02/09/mroonga-9.00.html

Changes:
   http://mroonga.org/docs/news.html#release-9.00

Here are some topics in this release.

  * Added support for MariaDB 10.3.12.
  * Added support for MariaDB 10.2.21.
  * Added support for Percona Server 5.7.24-27.
  * Added support for Percona Server 5.6.43 rel84.3.
  * Added support for MySQL 5.7.25.
  * Added support for MySQL 5.6.43.

In Groonga 9.0.0, TokenPattern, TokenTable tokenizer and remove_blank
for NormalizerNFKC100 is supported.

If you upgrade to Groonga 9.0.0, you can use them from Mroonga 9.00!

* See http://groonga.org/docs/news.html#release-9-0-0-2019-02-09

Regards,

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

mysql V 8.0.12 and mysqdump

2019-02-08 Thread Walter Harms

Hello list,
i run into an unexpected problem with mysqldump:

mysqldump --version
mysqldump  Ver 8.0.12 for Linux on x86_64 (MySQL Community Server - GPL)


when i try it results in:
mysqldump: Error: 'Lost connection to MySQL server during query' when trying to
dump tablespaces
mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': MySQL
server has gone away (2006)


I seems it get stuck in this query:

 explain SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE,
ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE
_TYPE = 'UNDO LOG' AND FILE_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IS NOT NULL
AND LOGFILE_GROUP_NAME IN (SELECT DISTINCT LOGFILE_GROUP
_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' AND
TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATIO
N_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA IN ('kpc'))) GROUP BY LOGFILE_GROUP_NAME,
FILE_NAME, ENGINE, TOTAL_EXTENTS, INITIAL_SIZE ORDER BY
 LOGFILE_GROUP_NAME;
++-+-+++-+-+-+--
+---+--+---+
| id | select_type | table   | partitions | type   | possible_keys   |
key | key_len | ref  
| rows  | filtered | Extra
|
++-+-+++-+-+-+--
+---+--+---+
|  1 | SIMPLE  | cat | NULL   | index  | PRIMARY |
name| 194 | NULL 
| 1 |   100.00 | Using index; Using temporary; Using filesort; Start
temporary |
|  1 | SIMPLE  | sch | NULL   | eq_ref | PRIMARY,catalog_id  |
catalog_id  | 202 | mysql.cat.id,const   
| 1 |   100.00 | Using index
  |
|  1 | SIMPLE  | tbl | NULL   | ref| schema_id   |
schema_id   | 8   | mysql.sch.id 
|78 |   100.00 | Using where
  |
|  1 | SIMPLE  | part| NULL   | ref| table_id,table_id_2 |
table_id| 8   | mysql.tbl.id 
|   597 |10.00 | Using where
  |
|  1 | SIMPLE  | part_ts | NULL   | eq_ref | PRIMARY |
PRIMARY | 8   | mysql.part.tablespace_id 
| 1 |   100.00 | NULL
 |
|  1 | SIMPLE  | ts  | NULL   | ALL| PRIMARY |
NULL| NULL| NULL 
| 12605 |   100.00 | Using join buffer (Block Nested Loop)
|
|  1 | SIMPLE  | tsf | NULL   | ref| tablespace_id   |
tablespace_id   | 8   | mysql.ts.id  
| 1 |   100.00 | Using where
  |
|  1 | SIMPLE  | sub_part| NULL   | ref| parent_partition_id |
parent_partition_id | 9   | mysql.part.id
| 13152 |   100.00 | NULL
 |
|  1 | SIMPLE  | sub_part_ts | NULL   | eq_ref | PRIMARY |
PRIMARY | 8   | mysql.sub_part.tablespace
_id | 1 |   100.00 | Using where
  |
|  1 | SIMPLE  | ts  | NULL   | eq_ref | PRIMARY,name|
name| 779 | func 
| 1 |   100.00 | Using where
  |
|  1 | SIMPLE  | tsf | NULL   | ref| tablespace_id   |
tablespace_id   | 8   | mysql.ts.id  
| 1 |   100.00 | Using where; End temporary
   |
++-+-+++-+-+-+--
+---+--+---+

The probelm seems to happen only when i dump the whole database, single tables
are ok.

re,
 wh

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Enterprise Backup 8.0.15 has been released

2019-02-01 Thread Bjorn Munch

Dear MySQL users,

MySQL Enterprise Backup 8.0.15, a new version of the online MySQL backup
tool, is now available for download from the My Oracle Support (MOS) website
as our latest GA release. This release will be available on eDelivery (OSDC)
after the next upload cycle. MySQL Enterprise Backup is a commercial
extension to the MySQL family of products.

MySQL Enterprise Backup 8.0.15 supports only the MySQL Server 8.0.15.
For earlier versions of MySQL 8.0, use the MySQL Enterprise Backup
version with the same version number as the server. For MySQL server
5.7, please use MySQL Enterprise Backup 4.1 and for MySQL Server 5.6
and 5.5, please use MySQL Enterprise Backup 3.12.

A brief summary of the changes in MySQL Enterprise Backup (MEB)
version 8.0.15 is given below.

Enjoy!

--

Changes in MySQL Enterprise Backup 8.0.15 (2019-02-01)

   This release contains no functional changes and is published
   to align version number with the MySQL Server 8.0.15 release.

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Router 8.0.15 for MySQL Server 8.0 and 5.7 has been released

2019-02-01 Thread Bjorn Munch

Dear MySQL users,

MySQL Router 8.0.15 is a new release for MySQL Router 8.0 series.

MySQL Router 8.0 is highly recommended for use with MySQL Server 8.0 and 5.7.
Please upgrade to MySQL Router 8.0.15.

The MySQL Router is a new building block for high availability solutions
based on MySQL InnoDB clusters.

By taking advantage of the new Group Replication technology, and
combined with the MySQL Shell, InnoDB clusters provide an integrated
solution for high availability and scalability for InnoDB based MySQL
databases, that does not require advanced MySQL expertise.

The deployment of applications with high availability requirements is
greatly simplified by MySQL Router. MySQL client connections are
transparently routed to online members of a InnoDB cluster, with MySQL
server outages and cluster reconfigurations being automatically handled
by the Router.

To download MySQL Router 8.0.15, see the "Generally Available (GA)
Releases" tab at http://dev.mysql.com/downloads/router. Package
binaries are available for several platforms and also as a source code
download.

Documentation for MySQL Router can be found at
http://dev.mysql.com/doc/mysql-router/en/

Enjoy!

-
Changes in MySQL Router 8.0.15 (2019-02-01)

   This release contains no functional changes and is published
   to align version number with the MySQL Server 8.0.15 release.

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Connector/Node.js 8.0.15 has been released

2019-02-01 Thread Hery Ramilison


Dear MySQL users,

MySQL Connector/Node.js is a new Node.js driver for use with the X
DevAPI. This release, v8.0.15, is a maintenance release of the
MySQL Connector/Node.js 8.0 series.

The X DevAPI enables application developers to write code that combines
the strengths of the relational and document models using a modern,
NoSQL-like syntax that does not assume previous experience writing
traditional SQL.

MySQL Connector/Node.js can be downloaded through npm (see
https://www.npmjs.com/package/@mysql/xdevapi for details) or from
https://dev.mysql.com/downloads/connector/nodejs/.

To learn more about how to write applications using the X DevAPI, see
http://dev.mysql.com/doc/x-devapi-userguide/en/. For more information
about how the X DevAPI is implemented in MySQL Connector/Node.js, and
its usage, see http://dev.mysql.com/doc/dev/connector-nodejs/.

Please note that the X DevAPI requires at least MySQL Server version
8.0 or higher with the X Plugin enabled. For general documentation
about how to get started using MySQL as a document store, see
http://dev.mysql.com/doc/refman/8.0/en/document-store.html.

Changes in MySQL Connector/Node.js 8.0.15 (2019-02-01, General Availability)

   This release contains no functional changes and is published
   to align version number with the MySQL Server 8.0.15 release.

On Behalf of Oracle/MySQL Release Engineering Team,
Hery Ramilison

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Connector/J 8.0.15 has been released

2019-02-01 Thread Gipson Pulla

Dear MySQL users,

MySQL Connector/J Version 8.0.15 is the GA release of the 8.0
branch of MySQL Connector/J. It is suitable for use with MySQL Server
versions 8.0, 5.7, 5.6, and 5.5. It supports the Java Database
Connectivity (JDBC) 4.2 API, and implements the X DevAPI.

This release includes the following new features and changes, also
described in more detail on

https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-15.html

As always, we recommend that you check the "CHANGES" file in the
download archive to be aware of changes in behavior that might affect
your application.

To download MySQL Connector/J 8.0.15 GA, see the "Generally Available
(GA) Releases" tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.15 (2019-02-01, General Availability)

Functionality Added or Changed


 * Default value of the connection property
   allowLoadLocalInfile has been changed to false.
   Applications that use the LOAD DATA LOCAL INFILE
   (http://dev.mysql.com/doc/refman/8.0/en/load-data.html)
   statement on MySQL Server needs to set this property to
   true explicitly. (Bug #29261254)

Enjoy and thanks for the support!

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Workbench 8.0.15 has been released

2019-02-01 Thread Prashant Tekriwal


Dear MySQL users,

The MySQL developer tools team announces 8.0.15 as our general available 
(GA) for

MySQL Workbench 8.0.

For the full list of changes in this revision, visit
http://dev.mysql.com/doc/relnotes/workbench/en/changes-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!


Changes in MySQL Workbench 8.0.15 (2019-02-01, General
Availability)

   This release contains no functional changes and is published
   to align version number with the MySQL Server 8.0.15 release.


On Behalf of Oracle/MySQL Release Engineering Team,
Prashant Tekriwal



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Connector/NET 8.0.15 has been released

2019-02-01 Thread Surabhi Bhat


Dear MySQL users,

MySQL Connector/NET 8.0.15 is the third version to support
Entity Framework Core 2.1 and the fifth general availability release
of MySQL Connector/NET to add support for the new X DevAPI, which
enables application developers to write code that combines the
strengths of the relational and document models using a modern,
NoSQL-like syntax that does not assume previous experience writing 
traditional SQL.


To learn more about how to write applications using the X DevAPI, see
http://dev.mysql.com/doc/x-devapi-userguide/en/index.html. For more
information about how the X DevAPI is implemented in Connector/NET, see
http://dev.mysql.com/doc/dev/connector-net. NuGet packages provide 
functionality at a project level. To get the

full set of features available in Connector/NET such as availability
in the GAC, integration with Visual Studio's Entity Framework Designer
and integration with MySQL for Visual Studio, installation through
the MySQL Installer or the stand-alone MSI is required.

Please note that the X DevAPI requires at least MySQL Server version
8.0 or higher with the X Plugin enabled. For general documentation
about how to get started using MySQL as a document store, see
http://dev.mysql.com/doc/refman/8.0/en/document-store.html.

To download MySQL Connector/NET 8.0.15, 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.15 (2019-02-01)

Bugs Fixed

 * The client library has been modified to initialize the
   MySqlBulkLoader class with the local-infile capability
   disabled by default (see Using the BulkLoader Class
   
(http://dev.mysql.com/doc/connector-net/en/connector-net-programming-bulk-loader.html)).
   (Bug #29259767)


On Behalf of MySQL Release Engineering Team,
Surabhi Bhat

MySQL Shell 8.0.15 for MySQL Server 8.0 and 5.7 has been released

2019-02-01 Thread Balasubramanian Kandasamy



Dear MySQL users,

MySQL Shell 8.0.15 is a maintenance release of MySQL Shell 8.0 Series
(a component of the MySQL Server). The MySQL Shell is provided under
Oracle's dual-license.

MySQL Shell 8.0 is highly recommended for use with MySQL Server 8.0
and 5.7. Please upgrade to MySQL Shell 8.0.15.

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.15, see
the "Generally Available (GA) Releases" tab at

  http://dev.mysql.com/downloads/shell/

We welcome and appreciate your feedback and bug reports, see

  http://bugs.mysql.com/

Enjoy and thanks for the support!

Changes in MySQL Shell 8.0.15 (2019-02-01)

   This release contains no functional changes and is published
   to align version number with the MySQL Server 8.0.15 release.


On Behalf of Oracle/MySQL Release Engineering Team,
Balasubramanian Kandasamy

MySQL Community Server 8.0.15 has been released

2019-02-01 Thread Bjorn Munch

Dear MySQL users,

MySQL Server 8.0.15, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.15 is
recommended for use on production systems.

For an overview of what's new in MySQL 8.0, please see

http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html

For information on installing MySQL 8.0.15 on new servers, please see
the MySQL installation documentation at

  http://dev.mysql.com/doc/refman/8.0/en/installing.html

MySQL Server 8.0.15 is available in source and binary form for a number of
platforms from our download pages at

  http://dev.mysql.com/downloads/mysql/

MySQL Server 8.0.15 is also available from our repository for Linux
platforms, go here for details:

  http://dev.mysql.com/downloads/repo/

Windows packages are available via the Installer for Windows:

  http://dev.mysql.com/downloads/installer/

[At the time of this announcement, the 8.0.15 Installer has not yet
 been uploaded but it will arrive within a few days]

along with .ZIP (no-install) packages for more advanced needs. 

8.0.15 also comes with a web installer as an alternative to the full
installer.

The web installer doesn't come bundled with any actual products
and instead relies on download-on-demand to fetch only the
products you choose to install. This makes the initial download
much smaller but increases install time as the individual products
will need to be downloaded.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc.:

  http://bugs.mysql.com/report.php

The following link lists the changes in the MySQL 8.0 since
the release of MySQL 8.0.14. It may also be viewed
online at

  http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-15.html

Enjoy!


==
Changes in MySQL 8.0.15 (2019-02-01, General Availability)

Bugs Fixed


 * Group Replication was unable to function in the 8.0.14
   release of MySQL Server if IPv6 support was disabled at
   the operating system level, even if the replication group
   did not use any IPv6 addresses. The issue is fixed by
   this release of MySQL Server, 8.0.15. (Bug #29249542, Bug
   #94004)


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Connector/ODBC 5.3.12 has been released

2019-01-27 Thread Balasubramanian Kandasamy


Dear MySQL users,

MySQL Connector/ODBC 5.3.12, a new version of the ODBC driver for the
MySQL database management system, has been released.

The available downloads include both a Unicode driver and an ANSI
driver based on the same modern codebase. Please select the driver
type you need based on the type of your application - Unicode or ANSI.
Server-side prepared statements are enabled by default. It is suitable
for use with any MySQL version from 5.5.

This is the sixth release of the MySQL ODBC driver conforming to the
ODBC 3.8 specification. It contains implementations of key 3.8
features, including self-identification as a ODBC 3.8 driver,
streaming of output parameters (supported for binary types only), and
support of the SQL_ATTR_RESET_CONNECTION connection attribute (for the
Unicode driver only).

The release is now available in source and binary form for a number of
platforms from our download pages at

http://dev.mysql.com/downloads/connector/odbc/5.3.html

For information on installing, please see the documentation at

http://dev.mysql.com/doc/connector-odbc/en/connector-odbc-installation.html


Changes in MySQL Connector/ODBC 5.3.12 (2019-01-28, General Availability)

Functionality Added or Changed


 * A new ENABLE_LOCAL_INFILE connection option was added to
   the connection string, DSN, and GUI. Disabled by default,
   set ENABLE_LOCAL_INFILE=1 to enable LOAD DATA operations.
   This toggles the MYSQL_OPT_LOCAL_INFILE mysql_options()
   option.
   The connection string overrides the DSN value if both are
   set.

Bugs Fixed


 * Dynamic linking (-DCLIENT_STATIC_LINKING:BOOL=false) was
   not functioning, and updating to the most recent MySQL
   Server 5.7 headers restored this functionality. (Bug
   #28609434, Bug #92319, Bug #91841)

 * Calling SQLBulkOperations with no_ssps set to 0 and
   cursortype set to SQL_CURSOR_DYNAMIC would cause an
   unexpected halt when using the generic Linux binaries.
   (Bug #28289320)


On Behalf of Oracle/MySQL Release Engineering Team,
Balasubramanian Kandasamy

MySQL Cluster 7.6.9 has been released

2019-01-22 Thread Lars Tangvald


Dear MySQL Users,

MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:

  - In-Memory storage - Real-time performance (with optional
    checkpointing to disk)
  - Transparent Auto-Sharding - Read & write scalability
  - Active-Active/Multi-Master geographic replication

  - 99.999% High Availability with no single point of failure
    and on-line maintenance
  - NoSQL and SQL APIs (including C++, Java, http, Memcached
    and JavaScript/Node.js)

MySQL Cluster 7.6.9 has been released and can be downloaded from

  http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

MySQL Cluster 7.6 is also available from our repository for Linux
platforms, go here for details:

  http://dev.mysql.com/downloads/repo/

The release notes are available from

  http://dev.mysql.com/doc/relnotes/mysql-cluster/7.6/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.

More details can be found at

  http://www.mysql.com/products/cluster/

Enjoy !


==
Changes in MySQL NDB Cluster 7.6.9 (5.7.25-ndb-7.6.9) (2019-01-22, 
General Availability)


   MySQL NDB Cluster 7.6.9 is a new release of NDB 7.6, based on
   MySQL Server 5.7 and including features in version 7.6 of the
   NDB storage engine, as well as fixing recently discovered
   bugs in previous NDB Cluster releases.

   Obtaining NDB Cluster 7.6.  NDB Cluster 7.6 source code and
   binaries can be obtained from
   https://dev.mysql.com/downloads/cluster/.

   For an overview of changes made in NDB Cluster 7.6, see What
   is New in NDB Cluster 7.6
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-6.html).

   This release also incorporates all bug fixes and changes made
   in previous NDB Cluster releases, as well as all bug fixes
   and feature changes which were added in mainline MySQL 5.7
   through MySQL 5.7.25 (see Changes in MySQL 5.7.25
   (2019-01-21, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-25.html)).

Bugs Fixed


 * Important Change: When restoring to a cluster using data
   node IDs different from those in the original cluster,
   ndb_restore tried to open files corresponding to node ID
   0. To keep this from happening, the --nodeid and
   --backupid options---neither of which has a default
   value---are both now explicitly required when invoking
   ndb_restore. (Bug #28813708)

 * Packaging; MySQL NDB ClusterJ: libndbclient was missing
   from builds on some platforms. (Bug #28997603)

 * NDB Replication: A DROP DATABASE operation involving
   certain very large tables could lead to an unplanned
   shutdown of the cluster. (Bug #28855062)

 * NDB Replication: When writes on the master---done in such
   a way that multiple changes affecting BLOB column values
   belonging to the same primary key were part of the same
   epoch---were replicated to the slave, Error 1022 occurred
   due to constraint violations in the NDB$BLOB_id_part
   table. (Bug #28746560)

 * NDB Cluster APIs: When the NDB kernel's SUMA block sends
   a TE_ALTER event, it does not keep track of when all
   fragments of the event are sent. When NDB receives the
   event, it buffers the fragments, and processes the event
   when all fragments have arrived. An issue could possibly
   arise for very large table definitions, when the time
   between transmission and reception could span multiple
   epochs; during this time, SUMA could send a
   SUB_GCP_COMPLETE_REP signal to indicate that it has sent
   all data for an epoch, even though in this case that is
   not entirely true since there may be fragments of a
   TE_ALTER event still waiting on the data node to be sent.
   Reception of the SUB_GCP_COMPLETE_REP leads to closing
   the buffers for that epoch. Thus, when TE_ALTER finally
   arrives, NDB assumes that it is a duplicate from an
   earlier epoch, and silently discards it.
   We fix the problem by making sure that the SUMA kernel
   block never sends a SUB_GCP_COMPLETE_REP for any epoch in
   which there are unsent fragments for a SUB_TABLE_DATA
   signal.
   This issue could have an impact on NDB API applications
   making use of TE_ALTER events. (SQL nodes do not make any
   use of TE_ALTER events and so they and applications using
   them were not affected.) (Bug #28836474)

 * Where a data node was restarted after a configuration
   change whose result was a decrease in the sum of
   MaxNoOfTables, MaxNoOfOrderedIndexes, and
   MaxNoOfUniqueHashIndexes, it sometimes failed with a
   misleading

MySQL Cluster 7.5.13 has been released

2019-01-22 Thread Prashant Tekriwal


Dear MySQL Users,

MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:

  - In-Memory storage - Real-time performance (with optional
    checkpointing to disk)
  - Transparent Auto-Sharding - Read & write scalability
  - Active-Active/Multi-Master geographic replication

  - 99.999% High Availability with no single point of failure
    and on-line maintenance
  - NoSQL and SQL APIs (including C++, Java, http, Memcached
    and JavaScript/Node.js)

MySQL Cluster 7.5.13 has been released and can be downloaded from

  http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

The release notes are available from

http://dev.mysql.com/doc/relnotes/mysql-cluster/7.5/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime, and agility.

More details can be found at

  http://www.mysql.com/products/cluster/

Enjoy !

==
Changes in MySQL NDB Cluster 7.5.13 (5.7.25-ndb-7.5.13) (
2019-01-22, General Availability)

   MySQL NDB Cluster 7.5.13 is a new release of MySQL NDB
   Cluster 7.5, based on MySQL Server 5.7 and including features
   in version 7.5 of the NDB
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
   storage engine, as well as fixing recently discovered bugs in
   previous NDB Cluster releases.

   Obtaining MySQL NDB Cluster 7.5.  MySQL NDB Cluster 7.5
   source code and binaries can be obtained from
   https://dev.mysql.com/downloads/cluster/.

   For an overview of changes made in MySQL NDB Cluster 7.5, see
   What is New in NDB Cluster 7.5
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-5.html).

   This release also incorporates all bug fixes and changes made
   in previous NDB Cluster releases, as well as all bug fixes
   and feature changes which were added in mainline MySQL 5.7
   through MySQL 5.7.25 (see Changes in MySQL 5.7.25
   (2019-01-21, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-25.html)).

Bugs Fixed

 * Important Change: When restoring to a cluster using data
   node IDs different from those in the original cluster,
   ndb_restore tried to open files corresponding to node ID
   0. To keep this from happening, the --nodeid
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-pro 

grams-ndb-restore.html#option_ndb_restore_nodeid 
) 
and

   --backupid
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-pro 

grams-ndb-restore.html#option_ndb_restore_backupid 
)

   options---neither of which has a default value---are both
   now explicitly required when invoking ndb_restore. (Bug
   #28813708)

 * Packaging; MySQL NDB ClusterJ: libndbclient was missing
   from builds on some platforms. (Bug #28997603)

 * NDB Replication: When writes on the master---done in such
   a way that multiple changes affecting BLOB
   (http://dev.mysql.com/doc/refman/5.7/en/blob.html) column
   values belonging to the same primary key were part of the
   same epoch---were replicated to the slave, Error 1022
   occurred due to constraint violations in the
   NDB$BLOB_id_part table. (Bug #28746560)

 * When only the management server but no data nodes were
   started, RESTART ALL timed out and eventually failed.
   This was because, as part of a restart, ndb_mgmd starts a
   timer, sends a STOP_REQ signal to all the data nodes, and
   waits for all of them to reach node state SL_CMVMI. The
   issue arose becaue no STOP_REQ signals were ever sent,
   and thus no data nodes reached SL_CMVMI. This meant that
   the timer always expired, causing the restart to fail.
   (Bug #28728485, Bug #28698831)
   References: See also: Bug #11757421.

 * Running ANALYZE TABLE
 (http://dev.mysql.com/doc/refman/5.7/en/analyze-table.html)
   on an NDB table with an index having longer than the
   supported maximum length caused data nodes to fail. (Bug
   #28714864)

 * It was possible in certain cases for nodes to hang during
   an initial restart. (Bug #28698831)
   References: See also: Bug #27622643.

 * The output of ndb_config --configinfo
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-pro

MySQL Cluster 7.5.13 has been released

2019-01-22 Thread Prashant Tekriwal


Dear MySQL Users,

MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:

  - In-Memory storage - Real-time performance (with optional
    checkpointing to disk)
  - Transparent Auto-Sharding - Read & write scalability
  - Active-Active/Multi-Master geographic replication

  - 99.999% High Availability with no single point of failure
    and on-line maintenance
  - NoSQL and SQL APIs (including C++, Java, http, Memcached
    and JavaScript/Node.js)

MySQL Cluster 7.5.13 has been released and can be downloaded from

  http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

The release notes are available from

http://dev.mysql.com/doc/relnotes/mysql-cluster/7.5/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime, and agility.

More details can be found at

  http://www.mysql.com/products/cluster/

Enjoy !

==
Changes in MySQL NDB Cluster 7.5.13 (5.7.25-ndb-7.5.13) (
2019-01-22, General Availability)

   MySQL NDB Cluster 7.5.13 is a new release of MySQL NDB
   Cluster 7.5, based on MySQL Server 5.7 and including features
   in version 7.5 of the NDB
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
   storage engine, as well as fixing recently discovered bugs in
   previous NDB Cluster releases.

   Obtaining MySQL NDB Cluster 7.5.  MySQL NDB Cluster 7.5
   source code and binaries can be obtained from
   https://dev.mysql.com/downloads/cluster/.

   For an overview of changes made in MySQL NDB Cluster 7.5, see
   What is New in NDB Cluster 7.5
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is
   -new-7-5.html).

   This release also incorporates all bug fixes and changes made
   in previous NDB Cluster releases, as well as all bug fixes
   and feature changes which were added in mainline MySQL 5.7
   through MySQL 5.7.25 (see Changes in MySQL 5.7.25
   (2019-01-21, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-25.html)).

Bugs Fixed

 * Important Change: When restoring to a cluster using data
   node IDs different from those in the original cluster,
   ndb_restore tried to open files corresponding to node ID
   0. To keep this from happening, the --nodeid
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-pro
   grams-ndb-restore.html#option_ndb_restore_nodeid) and
   --backupid
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-pro
   grams-ndb-restore.html#option_ndb_restore_backupid)
   options---neither of which has a default value---are both
   now explicitly required when invoking ndb_restore. (Bug
   #28813708)

 * Packaging; MySQL NDB ClusterJ: libndbclient was missing
   from builds on some platforms. (Bug #28997603)

 * NDB Replication: When writes on the master---done in such
   a way that multiple changes affecting BLOB
   (http://dev.mysql.com/doc/refman/5.7/en/blob.html) column
   values belonging to the same primary key were part of the
   same epoch---were replicated to the slave, Error 1022
   occurred due to constraint violations in the
   NDB$BLOB_id_part table. (Bug #28746560)

 * When only the management server but no data nodes were
   started, RESTART ALL timed out and eventually failed.
   This was because, as part of a restart, ndb_mgmd starts a
   timer, sends a STOP_REQ signal to all the data nodes, and
   waits for all of them to reach node state SL_CMVMI. The
   issue arose becaue no STOP_REQ signals were ever sent,
   and thus no data nodes reached SL_CMVMI. This meant that
   the timer always expired, causing the restart to fail.
   (Bug #28728485, Bug #28698831)
   References: See also: Bug #11757421.

 * Running ANALYZE TABLE
 (http://dev.mysql.com/doc/refman/5.7/en/analyze-table.html)
   on an NDB table with an index having longer than the
   supported maximum length caused data nodes to fail. (Bug
   #28714864)

 * It was possible in certain cases for nodes to hang during
   an initial restart. (Bug #28698831)
   References: See also: Bug #27622643.

 * The output of ndb_config --configinfo
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-pro
   grams-ndb-config.html#option_ndb_config_configinfo) --xml
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-pro
   grams-ndb-config.html#option_ndb_config_xml) --query-all
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-pro
   grams-ndb-config.html#option_ndb_config_query-all) now
   shows that configuration changes for the ThreadConfig
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndb

MySQL Connector/C++ 8.0.14 has been released

2019-01-21 Thread Kent Boortz



Dear MySQL users,

MySQL Connector/C++ 8.0.14 is a new release version of the MySQL
Connector/C++ 8.0 series.

Connector/C++ 8.0 can be used to access MySQL implementing Document
Store or in a traditional way, using SQL queries. It allows writing
both C++ and plain C applications using X DevAPI and X DevAPI for C.
It also supports the legacy API of Connector/C++ 1.1 based on JDBC4.

To learn more about how to write applications using X DevAPI, see
"X DevAPI User Guide" at

  https://dev.mysql.com/doc/x-devapi-userguide/en/

See also "X DevAPI Reference" at

  https://dev.mysql.com/doc/dev/connector-cpp/devapi_ref.html

and "X DevAPI for C Reference" at

  https://dev.mysql.com/doc/dev/connector-cpp/xapi_ref.html

For generic information on using Connector/C++ 8.0, see

  https://dev.mysql.com/doc/dev/connector-cpp/

For general documentation about how to get started using MySQL
as a document store, see

  http://dev.mysql.com/doc/refman/8.0/en/document-store.html

To download MySQL Connector/C++ 8.0.14, see the "Generally Available (GA)
Releases" tab at

  https://dev.mysql.com/downloads/connector/cpp/

==

Changes in MySQL Connector/C++ 8.0.14 (2019-01-21)

 * Configuration Notes

 * Packaging Notes

 * X DevAPI Notes

Configuration Notes

 * These CMake options have been added to enable more
   fine-grained specification of installation directories.
   All are relative to CMAKE_INSTALL_PREFIX:

  + CMAKE_INSTALL_LIBDIR: Library installation
directory.

  + CMAKE_INSTALL_INCLUDEDIR: Header file installation
directory.

  + CMAKE_INSTALL_DOCDIR: Documentation installation
directory.

   (Bug #28045358)

Packaging Notes

 * Previously, MySQL Connector/C++ binary distributions
   included a BUILDINFO.txt file that contained information
   about the build environment used to produce the
   distribution. Binary distributions now include a file
   named INFO_BIN that provides similar information, and an
   INFO_SRC file that provides information about the product
   version and the source repository from which the
   distribution was produced. Source distributions include
   the INFO_SRC file only.

 * MySQL Connector/C++ now is compatible with MSVC 2017,
   while retaining compatibility with MSVC 2015:

  + Previously, Connector/C++ binary distributions were
compatible with projects built using MSVC 2015.
Binary distributions now are compatible with
projects built using MSVC 2017 or 2015. DLLs have a
-vs14 suffix in their names to reflect that they are
compatible with MSVC 2015, but can also be used in
MSVC 2017 projects.

  + Previously, Connector/C++ source distributions could
be built using MSVC 2015. Source distributions now
can be built using MSVC 2017 or 2015.

  + Previously, the MSI installer accepted the Visual
C++ Redistributable for Visual Studio 2015. The MSI
installer now accepts the Visual C++ Redistributable
for Visual Studio 2017 or 2015.

 * Installers for Connector/C++ are now available as Debian
   packages. See Installing Connector/C++ from a Binary Distribution
   
(http://dev.mysql.com/doc/connector-cpp/8.0/en/connector-cpp-installation-binary.html).

X DevAPI Notes

 * Connector/C++ now provides collection counting methods
   for applications that use X DevAPI for C:

  + mysqlx_collection_count(): The number of documents
in a collection without filtering.

  mysqlx_collection_t *c1 = mysqlx_get_collection(schema, "c1", 1);
  ulong64_t documents;
  mysqlx_collection_count(c1, );

  + mysqlx_table_count(): The number of rows in a table
without filtering.

  mysqlx_table_t *t1 = mysqlx_get_table(schema, "t1", 1);
  ulong64_t rows;
  mysqlx_table_count(t1, );

  + mysqlx_get_count(): The number of remaining cached
rows held at the moment. After a row is consumed by
a fetch function, the number of cached rows
decreases.

  mysqlx_stmt_t *stmt = mysqlx_sql_new(session, query, 
strlen(query));
  mysqlx_result_t *res = mysqlx_execute(stmt);

  ulong64_t row_count;
  mysqlx_get_count(res, _count);

mysqlx_get_count() is similar in all respects to
mysqlx_store_result() except that the behavior
differs after fetching rows when reaching zero
number of rows in the cache:

   o mysqlx_get_count() returns zero through the
 parameter and finishes with RESULT_OK.

   o mysqlx_store_result() does not return anything
 through the parameter (which

MySQL Shell 8.0.14 for MySQL Server 8.0 and 5.7 has been released

2019-01-21 Thread Kent Boortz



Dear MySQL users,

MySQL Shell 8.0.14 is a maintenance release of MySQL Shell 8.0 Series
(a component of the MySQL Server). The MySQL Shell is provided under
Oracle's dual-license.

MySQL Shell 8.0 is highly recommended for use with MySQL Server 8.0
and 5.7. Please upgrade to MySQL Shell 8.0.14.

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.14, see
the "Generally Available (GA) Releases" tab at

  http://dev.mysql.com/downloads/shell/

We welcome and appreciate your feedback and bug reports, see

  http://bugs.mysql.com/

Enjoy and thanks for the support!

==

Changes in MySQL Shell 8.0.14 (2019-01-21)

 * Functionality Added or Changed

 * Bugs Fixed

Functionality Added or Changed

 * When started from the command line, MySQL Shell prints
   information about the product, information about the
   session (such as the default schema and connection ID),
   warning messages, and any errors that are returned during
   startup and connection. You can now suppress printing of
   information that you do not need by using the
   --quiet-start[=1|2] mysqlsh command-line option. With a
   value of 1 (the default when the option is specified),
   information about the MySQL Shell product is not printed,
   but session information, warnings, and errors are
   printed. With a value of 2, only errors are printed.
   As part of this work, the printed information was tidied
   up so that the information about the MySQL Shell product
   is printed before the information about the session.
   Also, the handling of error printing was normalized to
   send diagnostic data to stderr, and errors to stdout.
   (Bug #28833718, Bug #28855291)

 * MySQL Shell connections using classic MySQL protocol now
   support compression for information sent between the
   client and the server. You can specify compression when
   you start MySQL Shell and connect using command line
   options, or in a URI string or a key-value pair when you
   create a session using other interfaces. You can also use
   the MySQL Shell configuration option defaultCompress to
   enable compression for every global session.
   For MySQL Shell connections that use Unix socket files,
   the --socket command line option can now be specified
   with no argument to connect using the default Unix socket
   file for the protocol. (Bug #28730149)

 * The Cluster.status() operation has been extended to
   enable you to display information about the underlying
   Group Replication group used by the cluster. Now you can
   retrieve information from all members of a cluster
   without having to connect to each member individually.
   To see information about the groupName and memberId; and
   general statistics about the number of transactions
   checked, proposed, and rejected by members issue:

 Cluster.status(extended:true)

   To see information about recovery and regular transaction
   I/O,

MySQL Community Server 5.7.25 has been released

2019-01-21 Thread Surabhi Bhat


Dear MySQL users,

MySQL Server 5.7.25, a new version of the popular Open Source Database
Management System, has been released. MySQL 5.7.25 is recommended for
use on production systems.

For an overview of what's new in MySQL 5.7, please see

http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html

For information on installing MySQL 5.7.25 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.25 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.25 is also available from our repository for Linux
platforms, go here for details:

http://dev.mysql.com/downloads/repo/

Windows packages are available via the Installer for Windows or .ZIP
(no-install) packages for more advanced needs. The point and click
configuration wizards and all MySQL products are available in the
unified Installer for Windows:

http://dev.mysql.com/downloads/installer/

5.7.25 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.24. It may also be viewed online at

http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-25.html

Enjoy!

Changes in MySQL 5.7.25 (2019-01-21, General Availability)


 * Deprecation and Removal Notes

 * Pluggable Authentication

 * Security Notes

 * Functionality Added or Changed

 * Bugs Fixed

Deprecation and Removal Notes


 * The resolveip and resolve_stack_dump utilities are now
   deprecated and will be removed in MySQL 8.0. nslookup, host, or
   dig can be used instead of resolveip. Stack traces from official
   MySQL builds are always symbolized, so there is no need to use
   resolve_stack_dump.

Pluggable Authentication


 * If the LDAP port number is configured as 636 or 3269, the
   plugin now uses LDAPS (LDAP over SSL) instead of LDAP.  The port
   number is settable using the authentication_ldap_sasl_server_port
   or authentication_ldap_simple_server_port system variable.
   (LDAPS differs from startTLS.) (Bug #28743563)

 * Previously, for LDAP authentication with proxying, LDAP
   authentication plugins used the first group name returned by the
   LDAP server as the MySQL proxy user account name.  The
   authentication string for a MySQL account now can specify a list
   of groups to match, in preference order, and can optionally map
   the matching group name to a specified MySQL proxy user name. See
   LDAP Pluggable Authentication
   
(http://dev.mysql.com/doc/refman/5.7/en/ldap-pluggable-authentication.html). 



Security Notes


 * The linked OpenSSL library for the MySQL Commercial
   Server has been updated to version 1.0.2q. Issues fixed in the
   new OpenSSL version are described at
http://www.openssl.org/news/vulnerabilities.html. This change
   does not affect the Oracle-produced MySQL Community build of
   MySQL Server, which uses the yaSSL library instead. (Bug
   #28988091)

Functionality Added or Changed


 * Microsoft Windows: The access control granted to clients
   on the named pipe created by the MySQL server now is set to the
   minimum necessary for successful communication on Windows. Newer
   MySQL client software can open named pipe connections without any
   additional configuration. If older client software cannot be
   upgraded immediately, the new named_pipe_full_access_group server
   system variable can be used to give a Windows group the necessary
   permissions to open a named pipe connection. Membership in the
   full-access group should be restricted and temporary.

Bugs Fixed


 * InnoDB: A dangling pointer caused a memory leak. (Bug
   #28693568)

 * InnoDB: An ON DELETE CASCADE operation on table with a
   foreign key constraint and an indexed virtual column caused the
   server to exit. (Bug #28470805)

 * InnoDB: An incorrectly written DML log involving a
   virtual column value raised an assertion. (Bug #28448853)

 * InnoDB: Using the O_DIRECT_NO_FSYNC innodb_flush_method
   setting could cause the system to hang due to file system
   metadata becoming unsynchronized. To prevent this issue from
   occurring in O_DIRECT_NO_FSYNC mode, InnoDB now calls fsync()
   after creating a new file, after increasing file size, and after
   closing a file. The fsync() system call is

MySQL Workbench 8.0.14 has been released

2019-01-21 Thread daniel . horecki


Dear MySQL users,

The MySQL developer tools team announces 8.0.14 as our general available (GA) 
for
MySQL Workbench 8.0.

For the full list of changes in this revision, visit
http://dev.mysql.com/doc/relnotes/workbench/en/changes-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 
ofplatforms from our download pages at:


http://dev.mysql.com/downloads/tools/workbench/


Enjoy!


Changes in MySQL Workbench 8.0.14 (2019-01-21, General
Availability)


 * Functionality Added or Changed

 * Bugs Fixed

Functionality Added or Changed


 * The following new functions were added to the Workbench
   GRT module:

  + activateDiagram()
Opens the selected EER diagram for use with the
exportPNG, exportSVG, exportPS, and exportPDF
functions.

  + exportDiagramToPng(, )
Performs a PNG export of an EER diagram to the path
provided without activating it.
   (Bug #28853802, Bug #92985)

 * MySQL Workbench now supports macOS 10.14 Mojave,
   including full compatibility with the Dark Mode color
   scheme. (Bug #28831956, Bug #92902)

 * The Adv. Find tab operation that searched an open EER
   diagram by database objects only was removed.
   (Bug #28740047)

 * All editions of MySQL Workbench and the bundled libraries
   were upgraded to use OpenSSL 1.0.2q. (Bug #28695759)

 * Keyboard access was added to the home screen tab to
   enable navigation using the Tab and Enter keys. In
   addition, the screen view now scrolls to display a
   selected item if the item was off-screen when highlighted
   with the Tab key.
   On Windows and Linux hosts, the Application key and
   Ctrl+F10 now open a menu of commands (context menu)
   related to the selection.

 * Two redundant features were removed from all platforms:

  + The connection information pop-up sheet on the home
screen tab
Instead, open Manage Connections from the Database
menu (or Edit Connection from the context menu of
each connection) to view connection details.

  + The merge icon (two arrows pointing at each other)
located in the Navigation area of the side panel
Content from the Administration and Schemas tabs
were merged or split when this icon was toggled.
Now, the administration section links and schema
tree appear in separate tabs only.

Bugs Fixed


 * Valid decimal data within a Microsoft SQL Server table
   generated an error when used with the MySQL Workbench
   Migration Wizard. (Bug #28962023, Bug #93293)

 * The InnoDB status shown within the Administration -
   Dashboard tab displayed the wrong usage percent.
   (Bug #28919419)

 * A conflicting dependency was removed that prevented the
   mysql-connector-c++-devel package installation when MySQL
   Workbench was installed first. (Bug #28915929,
   Bug #93172)

 * The on-screen process of editing a stored procedure did
   not prompt to save the changes. (Bug #28880743,
   Bug #93068)

 * A new table added to an existing model caused MySQL
   Workbench to stop working. (Bug #28879925, Bug #93067)

 * The alter-table operation when applied to partitioned
   tables on Windows caused MySQL Workbench to stop working.
   (Bug #28856542, Bug #92990)

 * Characters from Cyrillic character sets when included in
   the path to SSH key files caused valid connection
   attempts to fail without producing a clear error message.
   These characters now are permitted within the path.
   (Bug #28814329, Bug #92847)

 * Connections made to a remote MySQL server over SSH did
   not recover properly after the network was interrupted
   temporarily. (Bug #28806660, Bug #90884)

 * New accounts created to use standard authentication were
   instead created to require strong password encryption
   when the default_authentication_plugin server system
   variable was configured with the caching_sha2_password
   value. (Bug #28777856, Bug #92740)

 * The default user name, newuser, was not accepted when it
   was used to create a new account. (Bug #28776902,
   Bug #92738)

 * The operation to migrate a Microsoft SQL Server schema
   produced an error when it encountered problematic tables
   during the reverse-engineering step. (Bug #28747888,
   Bug #92659)

 * A table editor tab that was opened by clicking the table
   icon from within the sidebar (Schemas tab) displayed the
   correct SELECT * FROM query and results, but the query
   text did not line up along the left margin as expected.
   (Bug #28730407)

 * Context-menu actions (New Tab, Save Tab,

MySQL Connector/NET 8.0.14 has been released

2019-01-21 Thread Surabhi Bhat


Dear MySQL users,

MySQL Connector/NET 8.0.14 is the second version to support
Entity Framework Core 2.1 and the fourth general availability release
of MySQL Connector/NET to add support for the new XDevAPI, which
enables application developers to write code that combines the
strengths of the relational and document models using a modern,
NoSQL-like syntax that does not assume previous experience writing 
traditional SQL.


To learn more about how to write applications using the XDevAPI, see
http://dev.mysql.com/doc/x-devapi-userguide/en/index.html. For more
information about how the XDevAPI 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 XDevAPI 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.14, 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.14 (2019-01-21)

*Functionality Added or Changed*

 * The internal method called by the
   MySqlX.XDevAPI.Relational.Table.Count,
   MySqlX.XDevAPI.Collection.Count, and
   MySqlX.XDevAPI.Collection.Count methods were moved to
   a standardized location within the library.

 * The auth connection option (along with aliases
   authentication and authentication mode) was removed from
   the MySqlBaseConnectionStringBuilder class. This option
   now is available for X Protocol connections only.

 * The following obsolete (deprecated) members of
   Connector/NET 8.0 API classes were removed:

  + Collection.Remove(Object) method

  + Collection.Remove(DbDoc) method

  + FindStatement.Limit(Int64, Int64) method

  + MySqlParameterCollection.Add(String, Object) method

  + TableSelectStatement.Limit(Int64, Int64) method

  + BaseResult.WarningCount property

  + MySqlBaseConnectionStringBuilder.Auth property

  + Result.RecordsAffected property

  + SqlResult.AutoIncrementValue property

  + SqlResult.RecordsAffected property

On Behalf of MySQL Release Engineering Team,
Surabhi Bhat

MySQL Connector/J 8.0.14 has been released

2019-01-21 Thread daniel . horecki


Dear MySQL users,

MySQL Connector/J Version 8.0.14 is the GA release of the 8.0
branch of MySQL Connector/J. It is suitable for use with MySQL Server
versions 8.0, 5.7, 5.6, and 5.5. It supports the Java Database
Connectivity (JDBC) 4.2 API, and implements the X DevAPI.

This release includes the following new features and changes, also
described in more detail on

https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-14.html

As always, we recommend that you check the "CHANGES" file in the
download archive to be aware of changes in behavior that might affect
your application.

To download MySQL Connector/J 8.0.14 GA, see the "Generally Available
(GA) Releases" tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.14 (2019-01-21, General
Availability)

 * Functionality Added or Changed

 * Bugs Fixed

Functionality Added or Changed


 * Important Change: For MySQL Server 8.0.14 and later,
   5.7.25 and later, 5.6.43 and later, and 5.5.63 and later,
   minimal permissions on named pipes are granted to clients
   that use them to connect to the server. Connector/J,
   however, can only use named pipes when granted full
   access on them. As a workaround, the MySQL Server that
   Connector/J wants to connect to must be started with the
   system variable named_pipe_full_access_group; see the
   description for the system variable for more details.
   (Bug #28971500)

 * X DevAPI: getDefaultSchema() now returns null when no
   default schema has been set for the Session.

 * Connector/J now has a new property for building from
   source, com.mysql.cj.build.verbose, which controls the
   verbosity of the build process' output. Its default value
   is false, which makes the output considerably shorter
   comparing with earlier versions of Connector/J.
   (Bug #28970166)

 * The method ResultSet.getBoolean() now returns FALSE when
   the designated column is of data type CHAR or VARCHAR and
   contains an "N" or "n". This makes Connector/J 8.0
   behaves like Connector/J 5.1 when it comes to converting
   strings to booleans. (Bug #28706219, Bug #92574)

 * Connector/J is now capable of reading and, if needed,
   ignoring any initial notice packets sent by X Plugin
   before an X Protocol connection is established.

Bugs Fixed


 * X DevAPI: Connector/J returned a NullPointerException
   when an application tried to establish an XProtocol
   connection using a Windows named pipe, which is not
   supported. With this fix, an XProtoclException is
   returned instead.
   This fix also makes sure that instead of a
   NullPointerException, a proper exception is thrown when
   an application tries to establish a Classic MySQL
   Protocol connection with a named pipe, but the named pipe
   is not specified at connection or it cannot be found on
   the specified path. (Bug #28606708)

 * X DevAPI: Adding an empty document with executeAsync()
   resulted in an ERROR 5013 (Missing row data for Insert).
   With this fix, no error or warning is returned in the
   case. (Bug #23045642)

 * Collection.count() returned a wrong error message when
   the collection did not exist. (Bug #28924137)

 * The source code of Connector/J contains non-ASCII
   characters, which might cause encoding issues during
   compilation if the system did not also use a UTF-8
   locale. With this fix, the build script now handles
   non-ASCII characters well regardless of the system
   locale. (Bug #28894344)

 * A memory leak occurred if Connector/J was loaded via the
   bootstrap class path instead of the main application
   classpath. It was because
   AbandonedConnectionCleanupThread failed to initialize its
   internal thread in that case, so that references for
   closed connections were not cleaned up, and their number
   kept growing. This fix repairs the clean up process for
   closed connections and also makes the process thread
   safe. (Bug #28747636, Bug #92508)

 * clearInputStream() returned a NullPointerException when
   the mysqlSocket, mysqlInput, or mysqlOutput object it
   tried to retrieve was null. With this fix, an IOExcpetion
   is thrown instead in the situation. Thanks to Henning
   Schmiedehausen for contributing to the fix.
   (Bug #28731795, Bug #92625)

 * Updating a result set returned by a server-side prepared
   statement with SELECT ... FOR UPDATE
   (http://dev.mysql.com/doc/refman/8.0/en/select.html)
   resulted in an SQLException. (Bug #28692243, Bug #92536)

 * When the connection property zeroDateTimeBehavior was set
   to CONVERT_TO_NULL, Connector/J converted a TIME
   (http://dev.mysql.com/doc/refman/8.0/en/time.html) type
   value of 00:00:00 to null. With this fix,

MySQL Connector/ODBC 8.0.14 has been released

2019-01-21 Thread Hery Ramilison


Dear MySQL users,

MySQL Connector/ODBC 8.0.14 is a new version in the MySQL Connector/ODBC 
8.0 series,

the ODBC driver for the MySQL Server.

The available downloads include both a Unicode driver and an ANSI driver 
based on the
same modern codebase. Please select the driver type you need based on 
the type of your
application - Unicode or ANSI. Server-side prepared statements are 
enabled by default.

It is suitable for use with any MySQL server version from 5.5.

This release of the MySQL ODBC driver is conforming to the ODBC 3.8 
specification.
It contains implementations of key 3.8 features, including 
self-identification
as a ODBC 3.8 driver, streaming of output parameters (supported for 
binary types
only), and support of the SQL_ATTR_RESET_CONNECTION connection attribute 
(for the

Unicode driver only).

The release is now available in source and binary form for a number of 
platforms

from our download pages at

https://dev.mysql.com/downloads/connector/odbc/

For information on installing, please see the documentation at

https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-installation.html

Changes in MySQL Connector/ODBC 8.0.14 (2019-01-21, General Availability)

Functionality Added or Changed

 * A new ENABLE_LOCAL_INFILE connection option was added to
   the connection string, DSN, and GUI. Disabled by default,
   set ENABLE_LOCAL_INFILE=1 to enable LOAD DATA operations.
   This toggles the MYSQL_OPT_LOCAL_INFILE mysql_options()
   option.
   The connection string overrides the DSN value if both are
   set.

 * MySQL Connector/ODBC is now compatible with MSVC 2017,
   while retaining compatibility with MSVC 2015:

  + Previously, Connector/ODBC binary distributions were
compatible with projects built using MSVC 2015.
Binary distributions now are compatible with
projects built using MSVC 2017 or 2015.

  + Previously, Connector/ODBC source distributions
could be built using MSVC 2015. Source distributions
now can be built using MSVC 2017 or 2015.

  + Previously, the MSI installer accepted the Visual
C++ Redistributable for Visual Studio 2015. The MSI
installer now accepts the Visual C++ Redistributable
for Visual Studio 2017 or 2015.

 * Two informative text files were added: INFO_BIN contains
   information about the build environment used to produce
   the distribution, and INFO_SRC provides information about
   the product version and the source repository from which
   the distribution was produced. Source distributions
   include the INFO_SRC file only.

On Behalf of Oracle/MySQL Release Engineering Team,
Hery Ramilison

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Enterprise Backup 8.0.14 has been released

MySQL Enterprise Backup 8.0.14, a new version of the online MySQL backup
tool, is now available for download from the My Oracle Support (MOS) website
as our latest GA release. This release will be available on eDelivery (OSDC)
after the next upload cycle. MySQL Enterprise Backup is a commercial
extension to the MySQL family of products.

MySQL Enterprise Backup 8.0.14 supports only the MySQL Server 8.0.14.
For earlier versions of MySQL 8.0, use the MySQL Enterprise Backup
version with the same version number as the server. For MySQL server
5.7, please use MySQL Enterprise Backup 4.1 and for MySQL Server 5.6
and 5.5, please use MySQL Enterprise Backup 3.12.

A brief summary of the changes in MySQL Enterprise Backup (MEB)
version 8.0.14 is given below.

Changes in MySQL Enterprise Backup 8.0.14 (2019-01-21, General Availability)

* Functionality Added or Changed

* Bugs Fixed

Functionality Added or Changed

* mysqlbackup now supports encrypted binary and relay log.
See Working with Encrypted Binary and Relay Logs
(http://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/advanced.encrypted-binlog-relaylog.html)
for details.

* mysqlbackup now supports the --ssl-fips-mode option,
which controls whether mysqlbackup operates in FIPS mode.
See FIPS Support
(http://dev.mysql.com/doc/refman/8.0/en/fips-mode.html)
for details.

Bugs Fixed

* An apply-incremental-backup operation failed with an
error (RDR1 ERROR: Unable to remove relaylog files from
full backup) when the incremental backup was created with
the --compress option. (Bug #28366241)

* mysqlbackup quit unexpectedly during an
apply-incremental-backup operation if the backed up
server had been started using relative paths for
--datadir and --log-bin. (Bug #28334521)

* Attempts to restore a backup of a MySQL 5.7 Server to a
MySQL 8.0 Server resulted in a strange error message
(Server_version is not obtained). With this fix,
mysqlbackup now indicates that the operation is not
supported. For related information, see Restoring a
Backup with a Database Upgrade or Downgrade
(http://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/restore-upgrade.html).
(Bug #27952379)

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Router 8.0.14 for MySQL Server 8.0 and 5.7 has been released

Dear MySQL users,

MySQL Router 8.0.14 is a new release for MySQL Router 8.0 series.

MySQL Router 8.0 is highly recommended for use with MySQL Server 8.0 and 5.7.
Please upgrade to MySQL Router 8.0.14.

The MySQL Router is a new building block for high availability solutions
based on MySQL InnoDB clusters.

By taking advantage of the new Group Replication technology, and
combined with the MySQL Shell, InnoDB clusters provide an integrated
solution for high availability and scalability for InnoDB based MySQL
databases, that does not require advanced MySQL expertise.

The deployment of applications with high availability requirements is
greatly simplified by MySQL Router. MySQL client connections are
transparently routed to online members of a InnoDB cluster, with MySQL
server outages and cluster reconfigurations being automatically handled
by the Router.

To download MySQL Router 8.0.14, see the "Generally Available (GA)
Releases" tab at http://dev.mysql.com/downloads/router. Package
binaries are available for several platforms and also as a source code
download.

Documentation for MySQL Router can be found at
http://dev.mysql.com/doc/mysql-router/en/

Enjoy!

Changes in MySQL Router 8.0.14 (Not yet released)


 * Functionality Added or Changed

 * Bugs Fixed

Functionality Added or Changed


 * A new dynamic configuration bootstrap feature was added
   that tracks the current MySQL InnoDB cluster Metadata
   servers. This replaces the existing
   bootstrap_server_addresses option with the new
   dynamic_config option in mysqlrouter.conf.
   MySQL Router now tracks and stores active MySQL InnoDB
   cluster Metadata server addresses and loads them if
   Router is restarted. Previously, metadata server
   information was defined during Router's initial bootstrap
   operation and stored statically as
   bootstrap_server_addresses in the configuration file.
   This new dynamic_config option is generated by
   --bootstrap and is defined under mysqlrouter.conf's
   [DEFAULT] section. Its value points to a generated JSON
   file named state.json that's initialized with InnoDB
   cluster Metadata server addresses and the group
   replication ID; and additional information is added and
   updated while Router is running.
   The bootstrap process no longer defines
   bootstrap_server_addresses because dynamic_config
   replaces its functionality; and these two options cannot
   be set at the same time. For backwards compatibility, if
   only bootstrap_server_addresses is set then it functions
   as it did in previous Router versions and this new
   dynamic configuration functionality is not used. (Bug
   #28082857, Bug #91029)

 * MySQL Router now persistently tracks the metadata server
   addresses rather than only using the static list defined
   in the configuration file using the destinations option.

Bugs Fixed


 * The --version output was aligned with MySQL Server's
   layout. (Bug #28899194)

 * Linking Router against libmsyqlclient that was built with
   DBUG enabled led to slow Router shutdown procedures. (Bug
   #28656618)

 * Fixed a thread shutdown race condition. (Bug #28610484)

 * Sending mysqlrouter a SIGTERM would take at least 100ms
   to shut down. Now a concurrent plugin shutdown queue was
   added to speed up the shutdown process. (Bug #28570122)

 * A metadata-cache API method was added to check the
   initialization status. Routing plugins use this during
   initialization to safely register the callbacks after
   metadata-cache is initialized. (Bug #28569717)

 * Installing MySQL Server with Router from source or
   building a tarball with "make package" would create a top
   level "data/" directory as part of the "Router"
   component. Due to possible collisions with MySQL Server,
   "data/" was changed to "var/lib/mysqlrouter". (Bug
   #28537733)

 * The connection error counter that blocks clients after
   max_connect_errors connection errors did not reset after
   a successful connection. (Bug #27995042, Bug #90809)

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Connector/Node.js 8.0.14 has been released

2019-01-21 Thread Hery Ramilison


Dear MySQL users,

MySQL Connector/Node.js is a new Node.js driver for use with the X
DevAPI. This release, v8.0.14, is a maintenance release of the
MySQL Connector/Node.js 8.0 series.

The X DevAPI enables application developers to write code that combines
the strengths of the relational and document models using a modern,
NoSQL-like syntax that does not assume previous experience writing
traditional SQL.

MySQL Connector/Node.js can be downloaded through npm (see
https://www.npmjs.com/package/@mysql/xdevapi for details) or from
https://dev.mysql.com/downloads/connector/nodejs/.

To learn more about how to write applications using the X DevAPI, see
http://dev.mysql.com/doc/x-devapi-userguide/en/. For more information
about how the X DevAPI is implemented in MySQL Connector/Node.js, and
its usage, see http://dev.mysql.com/doc/dev/connector-nodejs/.

Please note that the X DevAPI requires at least MySQL Server version
8.0 or higher with the X Plugin enabled. For general documentation
about how to get started using MySQL as a document store, see
http://dev.mysql.com/doc/refman/8.0/en/document-store.html.

Changes in MySQL Connector/Node.js 8.0.14 (2019-01-21, General Availability)

Functionality Added or Changed


 * Removed deprecation notices from the count() methods.

 * Setting the default schema via the connection now sets
   the default schema on the server; meaning, subsequent
   queries executed using session.sql() do not need to
   specify the schema.

Bugs Fixed


 * Setting the default schema with the connection URI using
   a schema name that contained special characters (that
   would need to be percent-encoded) would result in the
   percent-encoded name being used instead of the original
   one (e.g. "%25%26%5E*%5E_" instead of "%&^*^_"). (Bug
   #28990682)

 * An error is once again thrown if sslOption's 'ca' is
   different than the certificate authority used to sign the
   server certificate, or if the server certificate has been
   revoked. (Bug #28977649)

 * Attempting to use false-like values such as 0, false,
   null, and undefined would emit errors when updating or
   inserting documents in a collection or rows in a table.
   Additionally, now boolean values become numeric values
   (true=1, false=0) while null and undefined are converted
   to MySQL's NULL type. (Bug #28970727, Bug #93315)

 * Collection.existsInDatabase() always returned true if any
   other collection existed in the database. (Bug #28745240)

 * Configuring a default schema from the connection string
   would create the schema if it did not exist. Now, an
   "Unknown database" error is thrown instead.

 * An unexpected notice could result in an unexpected halt
   of the client.

On Behalf of Oracle/MySQL Release Engineering Team,
Hery Ramilison

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Community Server 8.0.14 has been released (part 2/2)

[This is part 2 of the announcement]

Bugs Fixed


 * Important Change: Importing a dump from a MySQL 5.7
   server to a server running MySQL 8.0 often failed with
   ER_WRONG_VALUE_FOR_VAR when an SQL mode not supported by
   the 8.0 server was used. This could happen frequently due
   to the fact that NO_AUTO_CREATE_USER is enabled by
   default in MySQL 5.7 but not supported in MySQL 8.0.
   The behavior of the server in such circumstances now
   depends on the setting of the pseudo_slave_mode system
   variable. If this is false, the server rejects the mode
   setting with ER_UNSUPPORTED_SQL_MODE. If
   pseudo_slave_mode is true, the server ignores the
   unsupported mode and gives a warning. Note that
   mysqlbinlog sets pseudo_slave_mode to true prior to
   executing any SQL. (Bug #90337, Bug #27828236)

 * InnoDB: MySQL would not start on Solaris X86. The static
   thread-local 'tables' variable in the TempTable storage
   engine was not properly initialized. (Bug #28987365)

 * InnoDB: Latching logic used during deadlock detection was
   simplified. (Bug #28904966)

 * InnoDB: An invalid record offset for an old version of a
   clustered index record raised a debug assertion. (Bug
   #28825617)
   References: This issue is a regression of: Bug #25540277.

 * InnoDB: The minimum DML delay imposed when the length of
   the history list exceeds innodb_max_purge_lag was
   decreased from 5000 microseconds to 5 microseconds. (Bug
   #28813453)

 * InnoDB: An incorrect lock order caused a deadlock when
   one thread attempted to drop a table while another
   created an encrypted tablespace. (Bug #28774259)

 * InnoDB: ALTER TABLESPACE failed to ignore unsupported
   tablespace attributes. (Bug #28656611)

 * InnoDB: Implicit to explicit lock conversion logic was
   simplified and optimized. (Bug #28637472)

 * InnoDB: A fragment page allocation failure raised an
   assertion. (Bug #28615893)

 * InnoDB: Incorrectly placed debug points caused flushed
   LOB pages to be considered corrupt. (Bug #28607368)

 * InnoDB: The TempTable storage engine incorrectly created
   temporary files in the system temporary directory instead
   of the directory defined by the tmpdir variable. (Bug
   #28598943)

 * InnoDB: Attempting to drop a table with a name similar to
   that of a full-text search auxiliary table caused an
   assertion failure. (Bug #28577083)

 * InnoDB: A function called by an UPDATE query did not
   account for virtual columns. (Bug #28560650)

 * InnoDB: An incorrect key was defined for the buffer pool
   zip hash mutex. (Bug #28556539)

 * InnoDB: Deadlock handling for background transactions
   that involve the mysql.innodb_table_stats and
   mysql.innodb_index_stats tables was modified. The tables
   were incorrectly included in an assertion that is
   triggered when internal tables are included in a deadlock
   cycle. (Bug #28523042, Bug #92069)

 * InnoDB: Setting innodb_spin_wait_delay to a high value
   caused an assertion failure when attempting to shut down
   the server. To prevent this failure from occurring, the
   innodb_spin_wait_delay maximum value was reduced to 1000.
   (Bug #28489407, Bug #91973)

 * InnoDB: An ON DELETE CASCADE operation on table with a
   foreign key constraint and an indexed virtual column
   caused the server to exit. (Bug #28470805)

 * InnoDB: An incorrectly written DML log involving a
   virtual column value raised an assertion. (Bug #28448853)

 * InnoDB: A RENAME TABLE operation failed when run on a
   table created outside of the MySQL data directory using
   the DATA DIRECTORY clause. (Bug #28341514)

 * InnoDB: ALTER TABLE ... EXCHANGE PARTITION permitted
   partitions with different virtual column definitions to
   be exchanged, which resulted in an assertion when InnoDB
   later attempted to read from a nonexistent virtual
   column. (Bug #28235668)

 * InnoDB: A counter was added for redo log write and flush
   requests that occur during transaction commit. The
   counter is used by the log writer thread to compute the
   average time between consecutive requests. When the
   average time is greater than 100 microseconds, log writer
   threads do not use spin delay and instead wait on request
   events with a 10 microsecond timeout limit.
   A log writer thread implementation issue that could cause
   a hang was also fixed. (Bug #28062382, Bug #28444247, Bug
   #28616442, Bug #90890)

 * InnoDB: An assertion was raised when attempting to add
   rollback segments to newly added undo tablespace that was
   not fully initialized. (Bug #27914054)

 * InnoDB: Foreign key constraints were ignored after a

MySQL Community Server 8.0.14 has been released (part 1/2)

[Due to size limitation, this announcement is split in two. This is part 1]

Dear MySQL users,

MySQL Server 8.0.14, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.14 is
recommended for use on production systems.

For an overview of what's new in MySQL 8.0, please see

http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html

For information on installing MySQL 8.0.14 on new servers, please see
the MySQL installation documentation at

  http://dev.mysql.com/doc/refman/8.0/en/installing.html

MySQL Server 8.0.14 is available in source and binary form for a number of
platforms from our download pages at

  http://dev.mysql.com/downloads/mysql/

MySQL Server 8.0.14 is also available from our repository for Linux
platforms, go here for details:

  http://dev.mysql.com/downloads/repo/

Windows packages are available via the Installer for Windows:

  http://dev.mysql.com/downloads/installer/

along with .ZIP (no-install) packages for more advanced needs. 

8.0.14 also comes with a web installer as an alternative to the full
installer.

The web installer doesn't come bundled with any actual products
and instead relies on download-on-demand to fetch only the
products you choose to install. This makes the initial download
much smaller but increases install time as the individual products
will need to be downloaded.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc.:

  http://bugs.mysql.com/report.php

The following link lists the changes in the MySQL 8.0 since
the release of MySQL 8.0.13. It may also be viewed
online at

  http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-14.html

Enjoy!

==
Changes in MySQL 8.0.14 (2019-01-21, General Availability)


 * Account Management Notes

 * Audit Log Notes

 * Compilation Notes

 * Component Notes

 * Configuration Notes

 * Deprecation and Removal Notes

 * Function Notes

 * Logging Notes

 * Optimizer Notes

 * Packaging Notes

 * Performance Schema Notes

 * Pluggable Authentication

 * Security Notes

 * Spatial Data Support

 * SQL Syntax Notes

 * Thread Pool Notes

 * X Plugin Notes

 * Functionality Added or Changed

 * Bugs Fixed

Account Management Notes


 * Previously, each MySQL user account was permitted to have
   a single password. MySQL now permits an account to have
   dual passwords, designated as primary and secondary
   passwords. This capability enables phased password
   changes to be performed seamlessly in complex
   multiple-server systems, without downtime. To support
   dual-password capability, the ALTER USER and SET PASSWORD
   statements now have a RETAIN CURRENT PASSWORD clause that
   saves the current password as the secondary password when
   you assign an account a new primary password. ALTER USER
   also has a DISCARD OLD PASSWORD clause to discard a
   secondary password that is no longer needed. See Password
   Management
   (http://dev.mysql.com/doc/refman/8.0/en/password-management.html).
   Important
   The implementation of dual-password capability involves a
   change to the structure of the mysql.user system table.
   If you upgrade to this MySQL release from an earlier
   version, you must run mysql_upgrade (and restart the
   server) to incorporate this system database change. Until
   this is done, password changes are not possible.

Audit Log Notes


 * The audit API now enables applications to add their own
   message events to the audit log using the new
   audit_api_message_emit component, which includes an
   audit_api_message_emit_udf() user-defined function. See
   The Audit Message Component
   (http://dev.mysql.com/doc/refman/8.0/en/audit-api-message-emit.html).

Compilation Notes


 * The minimum version of the Boost library for server
   builds is now 1.68.0. (Bug #28478497)

Component Notes


 * A new host_application_signal component service is
   available to enable server components to deliver signals
   to the host application. For example, the service enables
   replication components to send a shutdown signal to the
   server.

Configuration Notes


 * The content of the .gitignore file has been cleaned up.
   Much of this file was inherited from its .bzrignore
   predecessor and was not relevant. One implication of this
   cleanup is that in-source builds are disallowed. (Bug
   #28341794, Bug #91626)

 * MySQL Server now permits a TCP/IP port to be configured
   specifically for administrative connections. This
   provides an alternative to the single administrative
   connection that is permitted on the network interfaces
   used for ordinary connections even when max_connections

MySQL Community Server 5.6.43 has been released

2019-01-21 Thread Gipson Pulla

Dear MySQL users,

MySQL Server 5.6.43, a new version of the popular Open Source
Database Management System, has been released. MySQL 5.6.43 is
recommended for use on production systems.

For an overview of what's new in MySQL 5.6, please see

http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html

 Starting with 5.6.11, Microsoft Windows packages for MySQL 5.6
 are available both as a "full" installer and as a "web" installer.
 The full installer is significantly larger and comes bundled with
 the latest software releases available. This bundle makes it easy
 to download and configure a full server and development suite.

 The web installer doesn't come bundled with any actual products
 and instead relies on download-on-demand to fetch only the
 products you choose to install. This makes the initial download
 much smaller but increases install time as the individual products
 will need to be downloaded.

For information on installing MySQL 5.6.43 on new servers or upgrading
to MySQL 5.6.43 from previous MySQL releases, please see

  http://dev.mysql.com/doc/refman/5.6/en/installing.html

MySQL Server 5.6.43, is available in source and binary form for a number of
platforms from our download pages at

  http://dev.mysql.com/downloads/mysql


We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc:

  http://bugs.mysql.com/report.php

The following link lists the changes in the MySQL 5.6 since
the release of MySQL 5.6.42. It may also be viewed
online at

  http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-43.html

Enjoy!

Changes in MySQL 5.6.43 (2019-01-21, General Availability)


Security Notes


 * The linked OpenSSL library for the MySQL Commercial
   Server has been updated to version 1.0.2q. Issues fixed
   in the new OpenSSL version are described at
   http://www.openssl.org/news/vulnerabilities.html.
   This change does not affect the Oracle-produced MySQL
   Community build of MySQL Server, which uses the yaSSL
   library instead. (Bug #28988091)

Functionality Added or Changed


 * Microsoft Windows: The access control granted to clients
   on the named pipe created by the MySQL server now is set
   to the minimum necessary for successful communication on
   Windows. Newer MySQL client software can open named pipe
   connections without any additional configuration. If
   older client software cannot be upgraded immediately, the
   new named_pipe_full_access_group server system variable
   can be used to give a Windows group the necessary
   permissions to open a named pipe connection. Membership
   in the full-access group should be restricted and
   temporary.

Bugs Fixed


 * Replication: A patch to correct the handling of quotes
   for identifiers in ROLLBACK TO SAVEPOINT statements in
   the binary log was not correctly applied to subsequent
   MySQL versions. (Bug #28569645)

 * Replication: In some circumstances, the CHANGE MASTER TO
   statement could not be used on a replication slave if the
   master info log had been changed from a table
   (master_info_repository=TABLE) into a file
   (master_info_repository=FILE). (Bug #28529558)

 * Replication: The value returned by a SHOW SLAVE STATUS
   statement for the total combined size of all existing
   relay log files (Relay_Log_Space) could become much
   larger than the actual disk space used by the relay log
   files. The I/O thread did not lock the variable while it
   updated the value, so the SQL thread could automatically
   delete a relay log file and write a reduced value before
   the I/O thread finished updating the value. The I/O
   thread then wrote its original size calculation, ignoring
   the SQL thread's update and so adding back the space for
   the deleted file. The Relay_Log_Space value is now locked
   during updates to prevent concurrent updates and ensure
   an accurate calculation. (Bug #26997096, Bug #87832)

 * Replication: If the relay log index file was temporarily
   locked for viewing by a backup process for a replication
   slave, and MySQL Server also attempted to access the file
   at that time for rename or delete operations, the backup
   completed with warnings, but MySQL Server experienced an
   unexpected halt. MySQL Server now retries the file access
   operation a number of times in case this or a similar
   scenario is the explanation and the file becomes
   available again before long. (Bug #25839610)

 * The server permitted creation of databases with the same
   name as redo log files, which could result in unexpected
   server behavior. Such names are no longer permitted as
   database names. (Bug #28867993)

 * Comparing log file names as strings using the memcmp()
   function resulted in uninitialized memory

ANN: Database Workbench 5.5.0 released and free Lite Edition for MySQL

2019-01-15 Thread Martijn Tonies (Upscene Productions)

Upscene releases Database Workbench 5.5.0

Upscene Productions is proud to announce the availability of
the next version of the popular multi-DBMS development tool:

" Database Workbench 5.5.0 "

This new release brings you support for the latest versions of supported 
database systems, that includes PostgreSQL 11, InterBase 2017 and MySQL 8.

There's also a new release of the free Lite Edition for MySQL: version 5.4.6 
has been made available today.

Database Workbench 5 comes in multiple editions with different pricing models, 
there's always a version that suits you!

Here's the full list of changes
http://www.upscene.com/go/?go=tracker=5.5.0=12
and for version 5.4.x
http://www.upscene.com/go/?go=tracker=5.4.x=12

For more information, see What's new in Database Workbench 5?
( http://www.upscene.com/database_workbench/whatsnew )


Database Workbench supports MySQL, MariaDB, Firebird, Oracle, MS SQL Server,
SQL Anywhere, NexusDB, PostgreSQL and InterBase, comes in multiple editions and 
is licensed based on selectable modules.

It includes tools for database design, database maintenance, testing, data 
transfer,
data import & export, database migration, database compare and numerous other 
tools.


About Database Workbench
Database Workbench is a database developer tool, over 12 years in the making and
is being used by thousands of developers across the globe who have come to rely 
on it
every day. From database design, implementation, to testing and debugging, it 
will aid you 
in your daily database work.

About Upscene Productions
Based in The Netherlands, Europe, this small but dedicated company has been 
providing
database developers with useful tools for over 14 years. Slowly expanding the 
product portfolio
and gaining recognition amongst InterBase and Firebird database developers, 
they now offer
tools for a whole range of database systems, including Oracle and Microsoft SQL 
Server.

Full text search not matching 2 letter word

2019-01-08 Thread Andrew Wood

Im trying to run a full text query on a two letter keyword 'K7'. I have 
set ft_min_word_len=2 and restarted the server and if I view the system 
vars in Mysql Workbench it shows it is set correctly.


I have then dropped and re-created the index on the descrip column. It 
is an InnoDB table so I cannot do repair table.


Im running the following query which I expect to match the following 
record but it doesnt. Full text searches for other words match OK.


select * from asset where type ='DOCUMENTS' and (match(descrip) against 
('K7' in boolean mode)) ;



+-++--+---+---+--+-+
| id  | type               | descrip           | subtype | 
intendeduse  | location    | assetfileid |

+-++-++---+--+-+
| 153 | DOCUMENTS | Telephone Kiosk No. 7 K7 Interior promo photo from 
field trial.  | PHOTO   | DISPLAY | STORAGE  
| 152 |

+-++--++--+--+-+


Any ideas why this is not working?

Thanks

Andrew



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Cluster Manager 1.4.7 has been released

2018-12-14 Thread Surabhi Bhat


Dear MySQL Users,

MySQL Cluster Manager 1.4.7 can be downloaded from
the My Oracle Support (MOS) website. It will also be available
on Oracle Software Delivery Cloud at http://edelivery.oracle.com 
with

the next monthly update

MySQL Cluster Manager is an optional component of the MySQL Cluster Carrier
Grade Edition, providing a command-line interface that automates common
management tasks, including the following online operations:
 - Configuring and starting MySQL Cluster
 - Upgrades
 - Adding and removing cluster nodes
 - Adding and removing site hosts
 - Configuration changes
 - Backup and restore

MySQL Cluster Manager is a commercial extension to the MySQL family of 
products.

More details can be found at http://www.mysql.com/products/cluster/mcm/.

A brief summary of changes in MySQL Cluster Manager version 1.4.7 is 
listed below:


Changes in MySQL Cluster Manager 1.4.7  (2018-12-14)

 * Functionality Added or Changed

 * Bugs Fixed

*Functionality Added or Changed*


 * Agent: Performance has been improved for the add package
   command by removing unnecessary queries from its
   execution process. (Bug #28950231)

 * Agent: The initialization script for mcmd now cleans up
   the temporary files it creates under the tmp directory while
   starting new mcmd processes. (Bug #28924059)

 * Agent: The list hosts command now returns, in addition to
   Available and Unavailable, two more possible statuses for
   the agent of a host:

  + Recovery: The agent is in the process of recovering
itself

  + Unresponsive: The agent rejected an attempt to
connect
   (Bug #28438155)

 * Agent: The option --core-file
   
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-program-options-common.html#option_ndb_common_core-file),
   when used at the command line to start a node in a wild
   cluster, now causes the import cluster and update process
   commands to give a warning (that the option "may be
   removed on next restart of the process"), instead of
   causing the commands to fail. See Creating and
   Configuring the Target Cluster
   
(http://dev.mysql.com/doc/mysql-cluster-manager/1.4/en/mcm-using-import-cluster-create-configure.html)
   for details. (Bug #28177366)

 * Agent: The import cluster and update process commands now
   support a new --remove-angel option, which kills any
   angel processes for the data nodes to be imported or
   updated and also updates the data nodes' PID files. See
   descriptions for the two commands for details. (Bug
   #28116279)

 * Agent: The backup cluster command finishes faster now, as
   some unnecessary wait time has been eliminated from the
   backup process. (Bug #27986443)

 * Agent: A new option for mcmd, --initial, allows an agent
   that has fallen into an inconsistent state to recover its
   configuration from other agents. See the description for
   --initial for details. (Bug #20892397)

 * Agent: The set, get, and reset commands now support the
   following command-line-only attributes, which can only be
   configured at the command line when outside MySQL Cluster
   Manager:

  + For ndb_mgmd: --core-file, --log-name, --verbose

  + For ndbd and ndbmtd: --core-file, -- --verbose

 * Agent: The internal mechanism for agent recovery
   
(http://dev.mysql.com/doc/mysql-cluster-manager/1.4/en/mcm-using-restore-agent.html)
   has been improved, making it more robust and less error-prone.

 * Client: To reduce the size of the mcmd log, node events
   are no longer dumped into the log during a cluster
   restart. (Bug #28843656)

 * Client: The message for ERROR 5200 ("Restore cannot be
   performed ...") has been expanded to include the reason
   for the restore's failure. (Bug #25075284)

 * Client: The message for ERROR 5017 has been expanded to
   include the reason for an action being invalid for a
   process or cluster. (Bug #22777846)

*Bugs Fixed*


 * Agent: During a rolling restart for a cluster (which
   takes place, for example, after a cluster
   reconfiguration), the node group IDs for some data nodes
   might become some invalid numbers transiently, and that
   might cause mcmd to throw an internal error (Error 1003).
   With this fix, such transient changes of node group IDs
   are ignored by mcmd, and no error is thrown. (Bug
   #28949173)

 * Agent: An update process command on a mysqld node failed
   with a timeout if the node was in the status of stopping.
   It was because mcmd did not retry stopping the node, and
   this fix makes it do so in the situation. (Bug #28913525)

 * Agent: After a cluster reconfiguration failed, the
   restart of an mcmd agent that had lost contact with other
   agents

Re: undiscribe

2018-12-02 Thread Reindl Harald

WTF

look at the "List-Unsubscribe:" header in every list message and say
thanks to fools using DMARC enabled domains on mailing-lists resulting
in list footers are removd everywhere

no mailing list unsubsribe on planet earth works that way spam every
subscriber, you got a welcome message as you subscribed with
instructions too, keep such informations for later usage

Am 02.12.18 um 15:43 schrieb 高强:
> |
> undiscribe

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

undiscribe

2018-12-02 Thread 高强

|
undiscribe



--

Eric Gao
Keep on going never give up.
Blog:
http://gaoqiangdba.blog.163.com/

http://gaoqiang.blog.chinaunix.net/












|
|
|   |   |
|

Re: [ANN] Mroonga 8.09 - Fast fulltext search for all languages on MySQL

2018-11-28 Thread Horimoto Yasuhiro

Hi,

Sorry, There was wrong release information in Mroonga 8.09.
The MySQL 8 is not supported.  That is still being handled.

On 2018/11/29 14:12, Horimoto Yasuhiro wrote:
> Hi,
> 
> Mroonga 8.09 has been released!
> 
> Mroonga is a MySQL storage engine that supports fast fulltext search
> and geolocation search.  It is CJK ready. It uses Groonga as a storage
> and fulltext search engine.
> 
> Document:
>http://mroonga.org/docs/
> 
> How to install: Install Guide
>http://mroonga.org/docs/install.html
> 
> How to upgrade: Upgrade Guide
>http://mroonga.org/docs/upgrade.html
> 
> Blog:
>http://mroonga.org/en/blog/2018/11/29/mroonga-8.09.html
> 
> Changes:
>http://mroonga.org/docs/news.html#release-8.09
> 
> Here are some topics in this release.
> 
>   * Supported Ubuntu 18.10 (Cosmic Cuttlefish).
>   * Supported MariaDB 10.3.10.
>   * Supported MariaDB 10.2.19
>   * Supported MariaDB 10.1.37
>   * Supported Percona Server 5.7.23-25.
>   * Supported MariaDB 10.3.11.
>   * Supported MySQL 5.6.42.
>   * Supported MySQL 5.7.24.
>   * Supported MySQL 8.
> 
> Regards,
> 

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

[ANN] Mroonga 8.09 - Fast fulltext search for all languages on MySQL

2018-11-28 Thread Horimoto Yasuhiro

Hi,

Mroonga 8.09 has been released!

Mroonga is a MySQL storage engine that supports fast fulltext search
and geolocation search.  It is CJK ready. It uses Groonga as a storage
and fulltext search engine.

Document:
   http://mroonga.org/docs/

How to install: Install Guide
   http://mroonga.org/docs/install.html

How to upgrade: Upgrade Guide
   http://mroonga.org/docs/upgrade.html

Blog:
   http://mroonga.org/en/blog/2018/11/29/mroonga-8.09.html

Changes:
   http://mroonga.org/docs/news.html#release-8.09

Here are some topics in this release.

  * Supported Ubuntu 18.10 (Cosmic Cuttlefish).
  * Supported MariaDB 10.3.10.
  * Supported MariaDB 10.2.19
  * Supported MariaDB 10.1.37
  * Supported Percona Server 5.7.23-25.
  * Supported MariaDB 10.3.11.
  * Supported MySQL 5.6.42.
  * Supported MySQL 5.7.24.
  * Supported MySQL 8.

Regards,

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: Estimate mysqldump size

2018-11-28 Thread Olivier

Ronan McGlue  writes:

> Hi Olivier,
>
> On 28/11/2018 8:00 pm, Olivier wrote:
>> Hello,
>>
>> Is there a way that gives an estimate of the size of a mysqldump such a
>> way that it would always be larger than the real size?
>>
>> So far, I have found:
>>
>> mysql -s -u root -e "SELECT SUM(data_length) Data_BB FROM
>>information_schema.tables WHERE table_schema NOT IN
>>('information_schema','performance_schema','mysql');
>>
>> but the result may be smaller than the real size.
>
> In the above example, you also need to account for index_length, eg
>
> mysql>  select round(SUM(data_length+index_length)/POWER(1024,2),1) 
> Total_MB,round(SUM(data_length)/POWER(1024,2),1) 
> data_MB,round(SUM(index_length)/POWER(1024,2),1) index_MB  FROM 
> information_schema.tables where TABLE_SCHEMA not in ( 
> "information_schema", "performance_schema", "mysql") ;
> +--+-+--+
> | Total_MB | data_MB | index_MB |
> +--+-+--+
> |   4546.0 |  4093.7 |    452.2 |
> +--+-+--+
> 1 row in set (0.00 sec)

Thanks.

> However, this doesn't 100% map to OS file size ( if using innodb file 
> per table ) and will likely never be 100% accurate to what the OS 
> reports, due to fragmentation etc.
>
>>
>> I am writting a program that takes the result of mysqldump and pipe it
>> in a tar file.
>
> A typical global mysqldump ( ie taken with -A ) will be a single file.  
> Why are you then wanting to pipe this to a tar archive?

The tar file will be part of Amanda backup. On a full backup, it should
have the mysqldump and on incremental backups it should have the binary
logs.

Having everything in a tar file makes it very consistent and easy to
deal with in case of catastrophic failure (like everything is lost
except the tape, the backup can still be extracted by hand on a live
CD/single user system as it is all tar).

Amanda will also take care of the compression.

> Its also common for mysqldump to be compressed via a pipe due to the 
> nature of the output file created ( eg text files compress *very* well ) 
> , to then be sent across the network , eg via ssh
>
> mysqldump -u.. -p -A | gzip > schema.sql.gz
>
>
> Aside from your stated goal of piping to tar, if we can step back a 
> level briefly - what are you trying to achieve here?

A plugin for Amanda. I think a commercial solution exist, I don't need
anything very fancy, so I am trying to come up with my own solution.

Best regards,

Olivier

>
>> Tar file format has the size in the header, before the
>> data and if the size of the dump is bigger than the size declared in the
>> header, tar does not like that (if the size of the dump is smaller than
>> the actual size, it can be padded with spaces).
>>
>> So, the estimate must be larger than the actual dump, how to acheive
>> that?
>
> It wont be anything other than an estimate , however it should still be 
> reasonably close if you arent doing a *lot* of dml on it.
>
> You could artificially inflate the expected size by ,eg multiplying by 
> 1.1x or 1.2x , however there will always be an edge case table which 
> will be greater still..
>
>
> Regards
>
> Ronan McGlue
>
> MySQL Support
>
>
>
>>
>> Thanks in advance,
>>
>> Olivier
>>
>>
>

-- 

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: Estimate mysqldump size

2018-11-28 Thread Olivier

Ronan McGlue  writes:

> Hi Olivier,
>
> On 28/11/2018 8:00 pm, Olivier wrote:
>> Hello,
>>
>> Is there a way that gives an estimate of the size of a mysqldump such a
>> way that it would always be larger than the real size?
>>
>> So far, I have found:
>>
>> mysql -s -u root -e "SELECT SUM(data_length) Data_BB FROM
>>information_schema.tables WHERE table_schema NOT IN
>>('information_schema','performance_schema','mysql');
>>
>> but the result may be smaller than the real size.
>
> In the above example, you also need to account for index_length, eg

But I thought I had read that indexes are not saved by a myslqdump, but
recreated on a restore?

Thanks in advance,

Olivier

>
> mysql>  select round(SUM(data_length+index_length)/POWER(1024,2),1) 
> Total_MB,round(SUM(data_length)/POWER(1024,2),1) 
> data_MB,round(SUM(index_length)/POWER(1024,2),1) index_MB  FROM 
> information_schema.tables where TABLE_SCHEMA not in ( 
> "information_schema", "performance_schema", "mysql") ;
> +--+-+--+
> | Total_MB | data_MB | index_MB |
> +--+-+--+
> |   4546.0 |  4093.7 |    452.2 |
> +--+-+--+
> 1 row in set (0.00 sec)
>
> However, this doesn't 100% map to OS file size ( if using innodb file 
> per table ) and will likely never be 100% accurate to what the OS 
> reports, due to fragmentation etc.
>
>>
>> I am writting a program that takes the result of mysqldump and pipe it
>> in a tar file.
>
> A typical global mysqldump ( ie taken with -A ) will be a single file.  
> Why are you then wanting to pipe this to a tar archive?
>
> Its also common for mysqldump to be compressed via a pipe due to the 
> nature of the output file created ( eg text files compress *very* well ) 
> , to then be sent across the network , eg via ssh
>
> mysqldump -u.. -p -A | gzip > schema.sql.gz
>
>
> Aside from your stated goal of piping to tar, if we can step back a 
> level briefly - what are you trying to achieve here?
>
>> Tar file format has the size in the header, before the
>> data and if the size of the dump is bigger than the size declared in the
>> header, tar does not like that (if the size of the dump is smaller than
>> the actual size, it can be padded with spaces).
>>
>> So, the estimate must be larger than the actual dump, how to acheive
>> that?
>
> It wont be anything other than an estimate , however it should still be 
> reasonably close if you arent doing a *lot* of dml on it.
>
> You could artificially inflate the expected size by ,eg multiplying by 
> 1.1x or 1.2x , however there will always be an edge case table which 
> will be greater still..
>
>
> Regards
>
> Ronan McGlue
>
> MySQL Support
>
>
>
>>
>> Thanks in advance,
>>
>> Olivier
>>
>>
>

-- 

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: Estimate mysqldump size

2018-11-28 Thread Reindl Harald




Am 28.11.18 um 10:00 schrieb Olivier:
> Is there a way that gives an estimate of the size of a mysqldump such a
> way that it would always be larger than the real size?
keep in mind that a dump has tons of sql statements not existing that
way in the data

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: Estimate mysqldump size

2018-11-28 Thread Ronan McGlue


Hi Olivier,

On 28/11/2018 8:00 pm, Olivier wrote:

Hello,

Is there a way that gives an estimate of the size of a mysqldump such a
way that it would always be larger than the real size?

So far, I have found:

mysql -s -u root -e "SELECT SUM(data_length) Data_BB FROM
   information_schema.tables WHERE table_schema NOT IN
   ('information_schema','performance_schema','mysql');

but the result may be smaller than the real size.


In the above example, you also need to account for index_length, eg

mysql>  select round(SUM(data_length+index_length)/POWER(1024,2),1) 
Total_MB,round(SUM(data_length)/POWER(1024,2),1) 
data_MB,round(SUM(index_length)/POWER(1024,2),1) index_MB  FROM 
information_schema.tables where TABLE_SCHEMA not in ( 
"information_schema", "performance_schema", "mysql") ;

+--+-+--+
| Total_MB | data_MB | index_MB |
+--+-+--+
|   4546.0 |  4093.7 |    452.2 |
+--+-+--+
1 row in set (0.00 sec)

However, this doesn't 100% map to OS file size ( if using innodb file 
per table ) and will likely never be 100% accurate to what the OS 
reports, due to fragmentation etc.




I am writting a program that takes the result of mysqldump and pipe it
in a tar file.


A typical global mysqldump ( ie taken with -A ) will be a single file.  
Why are you then wanting to pipe this to a tar archive?


Its also common for mysqldump to be compressed via a pipe due to the 
nature of the output file created ( eg text files compress *very* well ) 
, to then be sent across the network , eg via ssh


mysqldump -u.. -p -A | gzip > schema.sql.gz


Aside from your stated goal of piping to tar, if we can step back a 
level briefly - what are you trying to achieve here?



Tar file format has the size in the header, before the
data and if the size of the dump is bigger than the size declared in the
header, tar does not like that (if the size of the dump is smaller than
the actual size, it can be padded with spaces).

So, the estimate must be larger than the actual dump, how to acheive
that?


It wont be anything other than an estimate , however it should still be 
reasonably close if you arent doing a *lot* of dml on it.


You could artificially inflate the expected size by ,eg multiplying by 
1.1x or 1.2x , however there will always be an edge case table which 
will be greater still..



Regards

Ronan McGlue

MySQL Support





Thanks in advance,

Olivier




--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Estimate mysqldump size

2018-11-28 Thread Olivier

Hello,

Is there a way that gives an estimate of the size of a mysqldump such a
way that it would always be larger than the real size?

So far, I have found:

   mysql -s -u root -e "SELECT SUM(data_length) Data_BB FROM
  information_schema.tables WHERE table_schema NOT IN
  ('information_schema','performance_schema','mysql');

but the result may be smaller than the real size.

I am writting a program that takes the result of mysqldump and pipe it
in a tar file. Tar file format has the size in the header, before the
data and if the size of the dump is bigger than the size declared in the
header, tar does not like that (if the size of the dump is smaller than
the actual size, it can be padded with spaces).

So, the estimate must be larger than the actual dump, how to acheive
that?

Thanks in advance,

Olivier


-- 

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Encryption-at-rest capability

2018-11-14 Thread Venkata Nagothi

Hi MySQL Community,

Greetings !

I have a query regarding encryption-at-rest feature in MySQL Community Edition -

What i understand is that Encryption-at-rest is supported from MySQL-5.7.11 
community edition and only on file-per-table basis which means encryption at 
table-level can be implemented - is that correct ?

Also, if you can help us understand the security compliance requirements (like 
PCI-DSS etc.) this encryption can satisfy, that would be great. Thanks in 
advance !

Please confirm !
Regards,
Ven

Re: Connections from mysql8.0 to mysql5.1 - bad handshake

2018-11-01 Thread shawn l.green


Hi Jim,

On 10/31/2018 7:12 PM, Halaasz Saandor wrote:

2018/10/31 15:15 ... Jim:

Given the following bug report, what I am trying to do does not sound
hopeful:
https://bugs.mysql.com/bug.php?id=90994


...


Any thoughts or do I need to accept that what I'm attempting just
isn't going to work?


 From the same bug report, id=90994:

[24 Oct 20:17] Brad Jackson

Version 8.0.13 was released on 10/22 and the change list says:

"Support for MySQL 5.5 by MySQL Workbench 8.0 was removed. If you still
need to use MySQL Workbench on a MySQL 5.5 server, you can use MySQL
Workbench 6.3"

I guess we're all stuck on the old version until we upgrade our servers.



Halaasz is on the right track.

As a client (which is what a replication slave really is), MySQL 8.0 
doesn't know how to login to a 5.1 server. Those old handshakes have 
been retired.


We only maintain connection compatibility with the "previous version" 
which, relative to 8.0, is 5.7 . Older versions may work, but it isn't 
guaranteed.


You could, potentially, set up replication chain like this
5.1 -> (is a master of) 5.5 -> 5.6 -> 5.7 -> 8.0

But then you would need to worry if your table definitions (we have 
deprecated and removed some data types since 5.1 was the "current 
version") are even legal in 8.0.  Other language features, like command 
syntaxes, also evolve over time.


There's a lot of deprecation history you will need to worry about. 
Something that is legal to replicate from 5.1 -> 5.5 may no longer be 
legal between 5.5 and 5.6 because 5.5 may have been the last version for 
which that feature was supported.  You may be better off with a 
lift-and-shift upgrade to try to establish a copy of your non-system 
tables and other objects (like stored procedures or views) in an empty 
initialized 8.0 server.  Then you can use a set of 8.0 CREATE USER and 
GRANT commands (you can't use naked GRANT commands to create accounts 
any longer. That feature was deprecated and removed in earlier versions) 
to populate your 8.0 server with user accounts.


Once you reach that stage, you are ready to start testing copies of your 
applications against 8.0 to see what else will need to be updated (such 
as the library you use to connect to MySQL).  Moving from 5.1 to 8.0 is 
a big shift, you potentially have a lot of work ahead of you.



Yours,

--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Integrated Cloud Applications & Platform Services
Office: Blountville, TN

Become certified in MySQL! Visit https://www.mysql.com/certification/ 
for details.


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: Connections from mysql8.0 to mysql5.1 - bad handshake

2018-10-31 Thread Halaasz Saandor


2018/10/31 15:15 ... Jim:
Given the following bug report, what I am trying to do does not sound 
hopeful:

https://bugs.mysql.com/bug.php?id=90994


...


Any thoughts or do I need to accept that what I'm attempting just isn't 
going to work?


From the same bug report, id=90994:

[24 Oct 20:17] Brad Jackson

Version 8.0.13 was released on 10/22 and the change list says:

"Support for MySQL 5.5 by MySQL Workbench 8.0 was removed. If you still 
need to use MySQL Workbench on a MySQL 5.5 server, you can use MySQL 
Workbench 6.3"


I guess we're all stuck on the old version until we upgrade our servers.

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Connections from mysql8.0 to mysql5.1 - bad handshake

2018-10-31 Thread Jim

I'm trying to configure replication of a mysql5.1 database master server 
to a mysql8.0 database server.

But the replication connection will not succeed.

I don't believe the issue is directly related to replication, because 
any connection attempt from mysql8.0 to mysql5.1 fails as follows.

As run from the mysql8.0 server:
$ mysql -h db5.1server.mydomain.com -u my_user -p
Enter password:
ERROR 1043 (08S01): Bad handshake

Given the following bug report, what I am trying to do does not sound 
hopeful:

https://bugs.mysql.com/bug.php?id=90994

I'm in the middle of a transition from centos6 to centos7. mysql5.1 is 
the standard mysql distribution in centos6. With centos7, I decided to 
skip mariadb and use the mysql8.0 distribution. My upgrade path would be 
much safer if I could get replication working as stated above.


Any thoughts or do I need to accept that what I'm attempting just isn't 
going to work?


Thanks,
Jim

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

In MySQL 8, how do you distinguish between Roles and Users in table mysql.user?

2018-10-30 Thread Martijn Tonies (Upscene Productions)

Hi there,

In MySQL 8, how can you figure out if an entry in the mysql.user table is a 
role or a user?

With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Database Workbench - developer tool for Oracle, MS SQL Server, PostgreSQL,
SQL Anywhere, MySQL, InterBase, NexusDB and Firebird.

Re: High cpu usage

2018-10-26 Thread shawn l.green


Hello Machiel,

(I am guessing you can only process top-posts?)

When you stop only the IO thread, you may leave the last event recorded 
to the Relay Log incomplete.


When it gets to that part of the Relay Log, the SQL thread may only be 
part-way through a transaction. It will keep that transaction alive 
waiting for the IO thread to finish downloading the rest of the event 
from the master's copy of the binary log. That partially-complete 
transaction is most likely blocking the ability of your other commands 
to operate more efficiently for several reasons:

 * MVCC
 * InnoDB history length
 * Incomplete transactions to secondary indexes forcing those commands 
to scan the table instead of using the index (related to MVCC)



We made the SQL thread wait so that intermittent networks (a real thing 
years ago) would not "break" replication. We would wait for connectivity 
to resume so that replication could continue.


A safer plan is to stop both threads at the same time. Just use the 
basic STOP SLAVE command instead of the more specific STOP SLAVE IO_THREAD.


Yours,
--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Integrated Cloud Applications & Platform Services
Office: Blountville, TN

Become certified in MySQL! Visit https://www.mysql.com/certification/ 
for details.




On 10/26/2018 2:09 AM, Machiel Richards wrote:

Hi Shawn


Thank you for the response.


 In order to pause the slave , the stop the sql_io_thread, and to unpause 
they simply start the thread.


  I have run "show engine innodb status" yes and the threads show 90% as 
sleeping and then a few selects , all from the same table as it does a lot of 
authentications for dial outs.


 I will have a look at the results from SELECT * FROM 
information_schema.INNODB_TRX; during the day as we get this issue regularly 
and will provide feedback.



Regards





(earlier thread below... )




From: shawn l.green 
Sent: Thursday, 25 October 2018 9:54:10 PM
To: mysql@lists.mysql.com
Subject: Re: High cpu usage

Hello Machiel,

On 10/25/2018 6:09 AM, Machiel Richards wrote:

Good day all


 Hoping this mail finds you well.


 I am hoping someone can perhaps give us some guidance here as we now seem 
to be stuck on a problem and have not been able to find a solution after more 
than a month.


 We are running an opensips server on Centos 6.5 , using mysql 5.7.13 which 
was installed via Tarball file.


 The server is setup as a slave and master and receives updates from 
opensips config nodes as well as registrations from workers.


 Replication is paused during the day and forward replication (master) is 
disabled at the moment.


 However , we are getting an issue every day on mysql side in terms of 
mysql pushing up server load.



  During the day the server is running fine with a load avg not going above 
1.5 during peak times.


  However in the evening , replication is unpaused, and completes 
processing and catchup within about 15 minutes and is paused again about 30 
minutes after the unpause.



Give or take 45 minutes to an hour after the replication is paused 
again, mysql starts to cause high cpu usage with no apparent processes running 
as can be seen on full processlist (maybe one or two selects which completes 
fairly quickly)


 The higher load, causes queries to slow down however and opensips to 
start timing out on db connections, causing clients to resubmit.


   The resubmits , then obviously causes even more load spiking the mysql 
load to increase as well as the server load and eventually opensips kills 
itself.



  I have looked at the disks, iowaits, memory usage, all is fine.


  We do not see any strange queries or stick queries, no deadlocks, etc... 
only the increase in selects after mysql starts to push up the cpu load.



  We have added all indexes we can find, but even this has made no 
difference at all.


   Currently we are at a loss so I am hoping someone else can assist in 
explaining how else we can find out why mysql is eating up the cpu ...



 The same behaviour can also be seen the moment any new feature is added to 
the server that requires mysql processing to be done, so this does not seem to 
be specifically related to replication, however it does seem like the current 
load from replication causes mysql to act up.


the server is currently running on SSD (recently replaced) , and 8Gb of 
memory with 1 x quadcore CPU.



  should any more info be required, please feel free to ask.




When you say pause replication, what command are you executing on the
slave?

Which end of the system is experiencing the high CPU usage: the master
or the slave?

Have you checked these resources to see what the InnoDB main or
background threads are doing when your CPU starts to spike? (you could
be in a massive rollback)

SHOW ENGINE INNODB STATUS
SELECT

Re: High cpu usage

2018-10-26 Thread Machiel Richards

Hi Shawn


   Thank you for the response.


In order to pause the slave , the stop the sql_io_thread, and to unpause 
they simply start the thread.


 I have run "show engine innodb status" yes and the threads show 90% as 
sleeping and then a few selects , all from the same table as it does a lot of 
authentications for dial outs.


I will have a look at the results from SELECT * FROM 
information_schema.INNODB_TRX; during the day as we get this issue regularly 
and will provide feedback.



Regards



From: shawn l.green 
Sent: Thursday, 25 October 2018 9:54:10 PM
To: mysql@lists.mysql.com
Subject: Re: High cpu usage

Hello Machiel,

On 10/25/2018 6:09 AM, Machiel Richards wrote:
> Good day all
>
>
> Hoping this mail finds you well.
>
>
> I am hoping someone can perhaps give us some guidance here as we now seem 
> to be stuck on a problem and have not been able to find a solution after more 
> than a month.
>
>
> We are running an opensips server on Centos 6.5 , using mysql 5.7.13 
> which was installed via Tarball file.
>
>
> The server is setup as a slave and master and receives updates from 
> opensips config nodes as well as registrations from workers.
>
>
> Replication is paused during the day and forward replication (master) is 
> disabled at the moment.
>
>
> However , we are getting an issue every day on mysql side in terms of 
> mysql pushing up server load.
>
>
>
>  During the day the server is running fine with a load avg not going 
> above 1.5 during peak times.
>
>
>  However in the evening , replication is unpaused, and completes 
> processing and catchup within about 15 minutes and is paused again about 30 
> minutes after the unpause.
>
>
>
>Give or take 45 minutes to an hour after the replication is paused 
> again, mysql starts to cause high cpu usage with no apparent processes 
> running as can be seen on full processlist (maybe one or two selects which 
> completes fairly quickly)
>
>
> The higher load, causes queries to slow down however and opensips to 
> start timing out on db connections, causing clients to resubmit.
>
>
>   The resubmits , then obviously causes even more load spiking the mysql 
> load to increase as well as the server load and eventually opensips kills 
> itself.
>
>
>
>  I have looked at the disks, iowaits, memory usage, all is fine.
>
>
>  We do not see any strange queries or stick queries, no deadlocks, etc... 
> only the increase in selects after mysql starts to push up the cpu load.
>
>
>
>  We have added all indexes we can find, but even this has made no 
> difference at all.
>
>
>   Currently we are at a loss so I am hoping someone else can assist in 
> explaining how else we can find out why mysql is eating up the cpu ...
>
>
>
> The same behaviour can also be seen the moment any new feature is added 
> to the server that requires mysql processing to be done, so this does not 
> seem to be specifically related to replication, however it does seem like the 
> current load from replication causes mysql to act up.
>
>
>the server is currently running on SSD (recently replaced) , and 8Gb of 
> memory with 1 x quadcore CPU.
>
>
>
>  should any more info be required, please feel free to ask.
>
>

When you say pause replication, what command are you executing on the
slave?

Which end of the system is experiencing the high CPU usage: the master
or the slave?

Have you checked these resources to see what the InnoDB main or
background threads are doing when your CPU starts to spike? (you could
be in a massive rollback)

SHOW ENGINE INNODB STATUS
SELECT * FROM information_schema.INNODB_TRX;

Yours,
--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc.

Become certified in MySQL! Visit https://www.mysql.com/certification/
for details.


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: High cpu usage

2018-10-25 Thread shawn l.green


Hello Machiel,

On 10/25/2018 6:09 AM, Machiel Richards wrote:

Good day all


Hoping this mail finds you well.


I am hoping someone can perhaps give us some guidance here as we now seem 
to be stuck on a problem and have not been able to find a solution after more 
than a month.


We are running an opensips server on Centos 6.5 , using mysql 5.7.13 which 
was installed via Tarball file.


The server is setup as a slave and master and receives updates from 
opensips config nodes as well as registrations from workers.


Replication is paused during the day and forward replication (master) is 
disabled at the moment.


However , we are getting an issue every day on mysql side in terms of mysql 
pushing up server load.



 During the day the server is running fine with a load avg not going above 
1.5 during peak times.


 However in the evening , replication is unpaused, and completes processing 
and catchup within about 15 minutes and is paused again about 30 minutes after 
the unpause.



   Give or take 45 minutes to an hour after the replication is paused 
again, mysql starts to cause high cpu usage with no apparent processes running 
as can be seen on full processlist (maybe one or two selects which completes 
fairly quickly)


The higher load, causes queries to slow down however and opensips to 
start timing out on db connections, causing clients to resubmit.


  The resubmits , then obviously causes even more load spiking the mysql 
load to increase as well as the server load and eventually opensips kills 
itself.



 I have looked at the disks, iowaits, memory usage, all is fine.


 We do not see any strange queries or stick queries, no deadlocks, etc... 
only the increase in selects after mysql starts to push up the cpu load.



 We have added all indexes we can find, but even this has made no 
difference at all.


  Currently we are at a loss so I am hoping someone else can assist in 
explaining how else we can find out why mysql is eating up the cpu ...



The same behaviour can also be seen the moment any new feature is added to 
the server that requires mysql processing to be done, so this does not seem to 
be specifically related to replication, however it does seem like the current 
load from replication causes mysql to act up.


   the server is currently running on SSD (recently replaced) , and 8Gb of 
memory with 1 x quadcore CPU.



 should any more info be required, please feel free to ask.




When you say pause replication, what command are you executing on the 
slave?


Which end of the system is experiencing the high CPU usage: the master 
or the slave?


Have you checked these resources to see what the InnoDB main or 
background threads are doing when your CPU starts to spike? (you could 
be in a massive rollback)


SHOW ENGINE INNODB STATUS
SELECT * FROM information_schema.INNODB_TRX;

Yours,
--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc.

Become certified in MySQL! Visit https://www.mysql.com/certification/ 
for details.



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

High cpu usage

2018-10-25 Thread Machiel Richards

Good day all


   Hoping this mail finds you well.


   I am hoping someone can perhaps give us some guidance here as we now seem to 
be stuck on a problem and have not been able to find a solution after more than 
a month.


   We are running an opensips server on Centos 6.5 , using mysql 5.7.13 which 
was installed via Tarball file.


   The server is setup as a slave and master and receives updates from opensips 
config nodes as well as registrations from workers.


   Replication is paused during the day and forward replication (master) is 
disabled at the moment.


   However , we are getting an issue every day on mysql side in terms of mysql 
pushing up server load.



During the day the server is running fine with a load avg not going above 
1.5 during peak times.


However in the evening , replication is unpaused, and completes processing 
and catchup within about 15 minutes and is paused again about 30 minutes after 
the unpause.



  Give or take 45 minutes to an hour after the replication is paused again, 
mysql starts to cause high cpu usage with no apparent processes running as can 
be seen on full processlist (maybe one or two selects which completes fairly 
quickly)


   The higher load, causes queries to slow down however and opensips to 
start timing out on db connections, causing clients to resubmit.


 The resubmits , then obviously causes even more load spiking the mysql 
load to increase as well as the server load and eventually opensips kills 
itself.



I have looked at the disks, iowaits, memory usage, all is fine.


We do not see any strange queries or stick queries, no deadlocks, etc... 
only the increase in selects after mysql starts to push up the cpu load.



We have added all indexes we can find, but even this has made no difference 
at all.


 Currently we are at a loss so I am hoping someone else can assist in 
explaining how else we can find out why mysql is eating up the cpu ...



   The same behaviour can also be seen the moment any new feature is added to 
the server that requires mysql processing to be done, so this does not seem to 
be specifically related to replication, however it does seem like the current 
load from replication causes mysql to act up.


  the server is currently running on SSD (recently replaced) , and 8Gb of 
memory with 1 x quadcore CPU.



should any more info be required, please feel free to ask.

MySQL Cluster 7.6.8 has been released

2018-10-23 Thread Lars Tangvald


Dear MySQL Users,

MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:

  - In-Memory storage - Real-time performance (with optional
    checkpointing to disk)
  - Transparent Auto-Sharding - Read & write scalability
  - Active-Active/Multi-Master geographic replication

  - 99.999% High Availability with no single point of failure
    and on-line maintenance
  - NoSQL and SQL APIs (including C++, Java, http, Memcached
    and JavaScript/Node.js)

MySQL Cluster 7.6.8, has been released and can be downloaded from

  http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

MySQL Cluster 7.6 is also available from our repository for Linux
platforms, go here for details:

  http://dev.mysql.com/downloads/repo/

The release notes are available from

http://dev.mysql.com/doc/relnotes/mysql-cluster/7.6/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.

More details can be found at

  http://www.mysql.com/products/cluster/

Enjoy !


Changes in MySQL NDB Cluster 7.6.8 (5.7.24-ndb-7.6.8) (2018-10-23, 
General Availability)


   MySQL NDB Cluster 7.6.8 is a new release of NDB 7.6, based on
   MySQL Server 5.7 and including features in version 7.6 of the
   NDB storage engine, as well as fixing recently discovered
   bugs in previous NDB Cluster releases.

   Obtaining NDB Cluster 7.6.  NDB Cluster 7.6 source code and
   binaries can be obtained from
   https://dev.mysql.com/downloads/cluster/.

   For an overview of changes made in NDB Cluster 7.6, see What
   is New in NDB Cluster 7.6
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-6.html).

   This release also incorporates all bug fixes and changes made
   in previous NDB Cluster releases, as well as all bug fixes
   and feature changes which were added in mainline MySQL 5.7
   through MySQL 5.7.24 (see Changes in MySQL 5.7.24 (2018-10-22, 
General Availability)

(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-24.html)).


Functionality Added or Changed


 * Performance: This release introduces a number of
   significant improvements in the performance of scans;
   these are listed here:

  + Row checksums help detect hardware issues, but do so
    at the expense of performance. NDB now offers the
    possibility of disabling these by setting the new
    ndb_row_checksum server system variable to 0; doing
    this means that row checksums are not used for new
    or altered tables. This can have a significant
    impact (5 to 10 percent, in some cases) on
    performance for all types of queries. This variable
    is set to 1 by default, to provide compatibility
    with the previous behavior.

  + A query consisting of a scan can execute for a
    longer time in the LDM threads when the queue is not
    busy.

  + Previously, columns were read before checking a
    pushed condition; now checking of a pushed condition
    is done before reading any columns.

  + Performance of pushed joins should see significant
    improvement when using range scans as part of join
    execution.

Bugs Fixed


 * Packaging: Expected NDB header files were in the devel
   RPM package instead of libndbclient-devel. (Bug #84580,
   Bug #26448330)

 * NDB Disk Data: While restoring a local checkpoint, it is
   possible to insert a row that already exists in the
   database; this is expected behavior which is handled by
   deleting the existing row first, then inserting the new
   copy of that row. In some cases involving data on disk,
   NDB failed to delete the existing row. (Bug #91627, Bug
   #28341843)

 * NDB Client Programs: Removed a memory leak in
   NdbImportUtil::RangeList that was revealed in ASAN
   builds. (Bug #91479, Bug #28264144)

 * MySQL NDB ClusterJ: When a table containing a BLOB or a
   TEXT field was being queried with ClusterJ for a record
   that did not exist, an exception ("The method is not
   valid in current blob state") was thrown. (Bug #28536926)

 * MySQL NDB ClusterJ: A NullPointerException was thrown
   when a full table scan was performed with ClusterJ on
   tables containing either a BLOB or a TEXT field. It was
   because the proper object initializations were omitted,
   and they have now been added by this fix. (Bug #28199372,
   Bug #91242)

 * When copying deleted rows from a live node to a node just
   starting, it is possible for one or more of these rows to
   have a global checkpoint index equal to zero. If this
   happened at the same time that a full local checkpoint

MySQL Cluster 8.0.13-dmr has been released

2018-10-23 Thread Balasubramanian Kandasamy




Dear MySQL Users,

MySQL Cluster is the distributed database combining massive
scalability and high availability. It provides in-memory
real-time access with transactional consistency across
partitioned and distributed datasets. It is designed for
mission critical applications.

MySQL Cluster has replication between clusters across multiple
geographical sites built-in. A shared nothing architecture with
data locality awareness make it the perfect choice for running
on commodity hardware and in globally distributed cloud
infrastructure.


This storage engine provides:

  - In-Memory storage - Real-time performance (with optional
    checkpointing to disk)
  - Transparent Auto-Sharding - Read & write scalability
  - Active-Active/Multi-Master geographic replication
  - Transactional consistency across partitioned and distributed datasets
  - Parallel cross partition queries such as joins

  - 99.% 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.13-dmr, has been released and can be downloaded from

  http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

The release notes are available from

http://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.

More details can be found at

  http://www.mysql.com/products/cluster/

Enjoy !

Changes in MySQL NDB Cluster 8.0.13 (2018-10-23, Development Milestone)

   MySQL NDB Cluster 8.0.13 is a new development release of NDB
   8.0, based on MySQL Server 8.0 and including features in
   version 8.0 of the NDB storage engine, as well as fixing
   recently discovered bugs in previous NDB Cluster releases.

   Obtaining NDB Cluster 8.0.  NDB Cluster 8.0 source code and
   binaries can be obtained from
   https://dev.mysql.com/downloads/cluster/.

   For an overview of changes made in NDB Cluster 8.0, see
   What is New in NDB Cluster 8.0

(http://dev.mysql.com/doc/refman/8.0/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.13 (see Changes in MySQL 8.0.13 (2018-10-22)
(http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html)).

 * Functionality Added or Changed

 * Bugs Fixed

Functionality Added or Changed


 * Important Change; NDB Disk Data: The following changes
   are made in the display of information about Disk Data
   files in the INFORMATION_SCHEMA.FILES table:

  + Tablespaces and log file groups are no longer
    represented in the FILES table. (These constructs
    are not actually files.)

  + Each data file is now represented by a single row in
    the FILES table. Each undo log file is also now
    represented in this table by one row only.
    (Previously, a row was displayed for each copy of
    each of these files on each data node.)

  + For rows corresponding to data files or undo log
    files, node ID and undo log buffer information is no
    longer displayed in the EXTRA column of the FILES
    table.

 * Important Change; NDB Client Programs: Removed the
   deprecated --ndb option for perror. Use ndb_perror to
   obtain error message information from NDB error codes
   instead. (Bug #81705, Bug #23523957)
   References: See also: Bug #81704, Bug #23523926.

 * Important Change: Beginning with this release, MySQL NDB
   Cluster is being developed in parallel with the standard
   MySQL 8.0 server under a new unified release model with
   the following features:

  + NDB 8.0 is developed in, built from, and released
    with the MySQL 8.0 source code tree.

  + The numbering scheme for NDB Cluster 8.0 releases
    follows the scheme for MySQL 8.0, starting with the
    current MySQL release (8.0.13).

  + Building the source with NDB support appends
    -cluster to the version string returned by mysql -V,
    as shown here:
    shell≫ mysql -V
    mysql  Ver 8.0.13-cluster for Linux on x86_64 (Source 
distribution)


    NDB binaries continue to display both the MySQL
    Server version and the NDB engine version, like
    this:
    shell> ndb_mgm -V
    MySQL distrib mysql-8.0.13 ndb-8.0.13-dmr, for Linux (x86_64)

    In MySQL Cluster NDB 8.0, these two version numbers
    are always the same.
   To build the MySQL 8.0.13 (or later) source with NDB

MySQL Cluster 7.5.12 has been released

2018-10-23 Thread Prashant Tekriwal


Dear MySQL Users,

MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:

  - In-Memory storage - Real-time performance (with optional
    checkpointing to disk)
  - Transparent Auto-Sharding - Read & write scalability
  - Active-Active/Multi-Master geographic replication

  - 99.999% High Availability with no single point of failure
    and on-line maintenance
  - NoSQL and SQL APIs (including C++, Java, http, Memcached
    and JavaScript/Node.js)

MySQL Cluster 7.5.12, has been released and can be downloaded from

  http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

The release notes are available from

http://dev.mysql.com/doc/relnotes/mysql-cluster/7.5/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.

More details can be found at

  http://www.mysql.com/products/cluster/

Enjoy !

==
Changes in MySQL NDB Cluster 7.5.12 (5.7.24-ndb-7.5.12) (2018-10-23,
General Availability)

   MySQL NDB Cluster 7.5.12 is a new release of MySQL NDB
   Cluster 7.5, based on MySQL Server 5.7 and including features
   in version 7.5 of the NDB
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
   storage engine, as well as fixing recently discovered bugs in
   previous NDB Cluster releases.

   Obtaining MySQL NDB Cluster 7.5.  MySQL NDB Cluster 7.5
   source code and binaries can be obtained from
   https://dev.mysql.com/downloads/cluster/.

   For an overview of changes made in MySQL NDB Cluster 7.5, see
   What is New in NDB Cluster 7.5
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-5.html).

   This release also incorporates all bug fixes and changes made
   in previous NDB Cluster releases, as well as all bug fixes
   and feature changes which were added in mainline MySQL 5.7
   through MySQL 5.7.24 (see Changes in MySQL 5.7.24 (2018-10-22,
   General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-24.html)).

Bugs Fixed


 * Packaging: Expected NDB header files were in the devel
   RPM package instead of libndbclient-devel. (Bug #84580,
   Bug #26448330)

 * MySQL NDB ClusterJ: When a table containing a BLOB
   (http://dev.mysql.com/doc/refman/5.7/en/blob.html) or a
   TEXT (http://dev.mysql.com/doc/refman/5.7/en/blob.html)
   field was being queried with ClusterJ for a record that
   did not exist, an exception ("The method is not valid in
   current blob state") was thrown. (Bug #28536926)

 * MySQL NDB ClusterJ: A NullPointerException was thrown
   when a full table scan was performed with ClusterJ on
   tables containing either a BLOB or a TEXT field. It was
   because the proper object initializations were omitted,
   and they have now been added by this fix. (Bug #28199372,
   Bug #91242)

 * When the SUMA kernel block receives a SUB_STOP_REQ
   signal, it executes the signal then replies with
   SUB_STOP_CONF. (After this response is relayed back to
   the API, the API is open to send more SUB_STOP_REQ
   signals.) After sending the SUB_STOP_CONF, SUMA drops the
   subscription if no subscribers are present, which
   involves sending multiple DROP_TRIG_IMPL_REQ messages to
   DBTUP. LocalProxy can handle up to 21 of these requests
   in parallel; any more than this are queued in the Short
   Time Queue. When execution of a DROP_TRIG_IMPL_REQ was
   delayed, there was a chance for the queue to become
   overloaded, leading to a data node shutdown with Error in
   short time queue.
   This issue is fixed by delaying the execution of the
   SUB_STOP_REQ signal if DBTUP is already handling
   DROP_TRIG_IMPL_REQ signals at full capacity, rather than
   queueing up the DROP_TRIG_IMPL_REQ signals.
   (Bug#26574003)

 * Having a large number of deferred triggers could
   sometimes lead to job buffer exhaustion. This could occur
   due to the fact that a single trigger can execute many
   operations---for example, a foreign key parent trigger
   may perform operations on multiple matching child table
   rows---and that a row operation on a base table can
   execute multiple triggers. In such cases, row operations
   are executed in batches. When execution of many triggers
   was deferred---meaning that all deferred triggers are
   executed at pre-commit---the resulting concurrent
   execution of a great many trigger operations could cause
   the data node job buffer or send buffer to be exhausted,
   leading to failure of the node.
   This issue is fixed by limiting the number of concurrent
   trigger operations as well as

ANN: Upscene releases Database Workbench 5.4.6

2018-10-23 Thread Martijn Tonies (Upscene Productions)

Upscene releases Database Workbench 5.4.6

Upscene Productions is proud to announce the availability of
the next version of the popular multi-DBMS development tool:

“ Database Workbench 5.4.6 "

This is a bugfix release, previous releases included support for MariaDB 10.1 
and 10.2, MySQL 5.7 and Azure, a custom report writer, a renewed stored routine 
debugger with full support for Firebird 3 Stored Functions and Packages and 
several other features.

Database Workbench 5 comes in multiple editions with different pricing models, 
there's always a version that suits you!

Here's the full list of changes
http://www.upscene.com/go/?go=tracker=5.4.x=12

For more information, see What's new in Database Workbench 5?
( http://www.upscene.com/database_workbench/whatsnew )


Database Workbench supports MySQL, MariaDB, Firebird, Oracle, MS SQL Server,
SQL Anywhere, NexusDB, PostgreSQL and InterBase, comes in multiple editions and 
is licensed based on selectable modules.

It includes tools for database design, database maintenance, testing, data 
transfer,
data import & export, database migration, database compare and numerous other 
tools.


About Database Workbench
Database Workbench is a database developer tool, over 12 years in the making and
is being used by thousands of developers across the globe who have come to rely 
on it
every day. From database design, implementation, to testing and debugging, it 
will aid you 
in your daily database work.

About Upscene Productions
Based in The Netherlands, Europe, this small but dedicated company has been 
providing
database developers with useful tools for over 14 years. Slowly expanding the 
product portfolio
and gaining recognition amongst InterBase and Firebird database developers, 
they now offer
tools for a whole range of database systems, including Oracle and Microsoft SQL 
Server.

MySQL Connector/NET 8.0.13 has been released

2018-10-22 Thread Surabhi Bhat


Dear MySQL users,

MySQL Connector/NET 8.0.13 is the first version to support
Entity Framework Core 2.1 and the third general availability release
of MySQL Connector/NET to add support for the new X DevAPI,which
enables application developers to write code that combines the
strengths of the relational and document models using a modern,
NoSQL-like syntax that does not assume previous experience writing 
traditional SQL.


To learn more about how to write applications using the X DevAPI, see
http://dev.mysql.com/doc/x-devapi-userguide/en/index.html. For more
information about how the X DevAPI is implemented in Connector/NET, see
http://dev.mysql.com/doc/dev/connector-net.

NuGet packages provide functionality at a project level. To get the
full set of features available in Connector/NET such as availability
in the GAC, integration with Visual Studio's Entity Framework Designer
and integration with MySQL for Visual Studio, installation through
the MySQL Installer or the stand-alone MSI is required.

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.13, 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.13 (2018-10-22, General Availability)

 * Important Changes

 * Functionality Added or Changed

 * Bugs Fixed

*Important Changes*


 * The default value for the SslMode connection option now
   differs based on the protocol used to make the
   connection. The Preferred mode has been reintroduced in
   this release (see Options for Both Classic MySQL Protocol
   and X Protocol
   (http://dev.mysql.com/doc/connector-net/en/connector-net- 
8-0-connection-options.html#connector-net-8-0-connection- 
options-classic-xprotocol 
).
   To summarize the defaultSslmode values in the Connector/NET 8.0 
(and 7.0) releaseseries:


   Connector/NET 8.0.13: Preferred mode is the default for
   classic MySQL protocol connections only. Required mode is
   the default for X Protocol connections only (Preferred
   mode is not available for use with X Protocol).

   Connector/NET 8.0.8 to 8.0.12: Preferred mode is not
   supported for any connections. Required mode is the
   default for both classic MySQL protocol and X Protocol
   connections.

   Connector/NET 7.0.0 to 7.0.7: Preferred mode is the
   default for both classic MySQL protocol and X Protocol
   connections. (Bug #28687769)


*Functionality Added or Changed*

 * Document Store: An incremental improvement was made to
   the performance of session creation with a connection
   string. (Bug #28343655)

 * Support for EF Core 2.1 was added to Connector/NET 8.0.13
   and support for EF Core 2.0 was discontinued in the same
   connector version. Other versions of Connector/NET
   continue to support EF Core 2.0 (see Entity Framework
   Core Support
   (http://dev.mysql.com/doc/connector-net/en/connector-net- 
entityframework-core.html 
).


 * The ConnectionTimeout connection option and property were
   reimplemented as the Connect-Timeout option (and the
   ConnectTimeout property) for X Protocol operations. Some
   aspects of the timeout behavior were changed (see Options
   for X Protocol Only
   (http://dev.mysql.com/doc/connector-net/en/connector-net- 
8-0-connection-options.html#connector-net-8-0-connection- 
options-xprotocol 
).

   The new ConnectTimeout property was added to the
   MySqlX.XDevAPI.MySqlXConnectionStringBuilder class and
   the existing ConnectionTimeout property was removed.

   No modifications were made to the existing implementation
   of the ConnectionTimeout option (or property) for classic
   MySQL operations.

 *

MySQL Community Server 5.5.62 has been released

2018-10-22 Thread Hery Ramilison


Dear MySQL users,

MySQL Server 5.5.62 is a new version of the 5.5 production release of
the world's most popular open source database. MySQL 5.5.62 is
recommended for use on production systems.

MySQL 5.5 includes several high-impact enhancements to improve the
performance and scalability of the MySQL Database, taking advantage of
the latest multi-CPU and multi-core hardware and operating systems. In
addition, with release 5.5, InnoDB is now the default storage engine for
the MySQL Database, delivering ACID transactions, referential integrity
and crash recovery by default.

MySQL 5.5 also provides a number of additional enhancements including:

  - Significantly improved performance on Windows, with various Windows
specific features and improvements
  - Higher availability, with new semi-synchronous replication and
Replication Heartbeat
  - Improved usability, with Improved index and table partitioning,
SIGNAL/RESIGNAL support and enhanced diagnostics, including a new
Performance Schema monitoring capability.

For a more complete look at what's new in MySQL 5.5, please see the
following resources:

Documentation:

  http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html

If you are running a MySQL production level system, we would like to
direct your attention to MySQL Enterprise Edition, which includes the
most comprehensive set of MySQL production, backup, monitoring,
modeling, development, and administration tools so businesses can
achieve the highest levels of MySQL performance, security and uptime.

  http://mysql.com/products/enterprise/

For information on installing MySQL 5.5.62 on new servers, please see
the MySQL installation documentation at

  http://dev.mysql.com/doc/refman/5.5/en/installing.html

For upgrading from previous MySQL releases, please see the important
upgrade considerations at:

  http://dev.mysql.com/doc/refman/5.5/en/upgrading.html

MySQL Database 5.5.62 is available in source and binary form for a
number of platforms from our download pages at:

  http://dev.mysql.com/downloads/mysql/

The following link lists the changes in the MySQL source code since the
previous released version of MySQL 5.5. It may also be viewed online at:

  http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-62.html

This is the last update to be published for MySQL Server 5.5. To
continue receiving updates for this product, you will need to upgrade to
at least version 5.6.

Enjoy!

Changes in MySQL 5.5.62 (2018-10-22, General availability)

Functionality Added or Changed

 * Previously, file I/O performed in the I/O cache in the
   mysys library was not instrumented, affecting in
   particular file I/O statistics reported by the
   Performance Schema about the binary log index file. Now,
   this I/O is instrumented and Performance Schema
   statistics are accurate. Thanks to Yura Sorokin for the
   contribution. (Bug #27788907, Bug #90264)

 * The zlib library version bundled with MySQL was raised
   from version 1.2.3 to version 1.2.11. MySQL implements
   compression with the help of the zlib library.
   The zlib compressBound() function in zlib 1.2.11 returns
   a slightly higher estimate of the buffer size required to
   compress a given length of bytes than it did in zlib
   version 1.2.3. The compressBound() function is called by
   InnoDB functions that determine the maximum row size
   permitted when creating compressed InnoDB tables or
   inserting rows into compressed InnoDB tables. As a
   result, CREATE TABLE ... ROW_FORMAT=COMPRESSED or INSERT
   operations with row sizes very close to the maximum row
   size that were successful in earlier releases could now
   fail.


Bugs Fixed

 * MySQL Server and test RPM packages were missing
   perl-Data-Dumper as a dependency. (Bug #28144933, Bug
   #72926)

 * For the mysql client, the -b short option was associated
   with two long options, --no-beep and --binary-as-hex. The
   -b option now is associated only with --no-beep. (Bug
   #28093271)

 * During server startup/shutdown, PID files could be
   mishandled. (Bug #27919254)

 * For MEMORY tables, memory overflow errors could occur.
   (Bug #27799513)

 * When converting from a BLOB (or TEXT) type to a smaller
   BLOB (or TEXT) type, no warning or error was reported
   informing about the truncation or data loss. Now an
   appropriate error is issued in strict SQL mode and a
   warning in nonstrict SQL mode. (Bug #27788685, Bug
   #90266)

 * ALTER TABLE ... REORGANIZE PARTITION ... could result in
   incorrect behavior if any partition other than the last
   was missing the VALUES LESS THAN part of the syntax. (Bug
   #26791931)

On Behalf of the MySQL/Oracle Release Engineering Team,
Hery Ramilison

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:

MySQL Workbench 8.0.13 has been released

2018-10-22 Thread daniel . horecki


Dear MySQL users,

The MySQL developer tools team announces 8.0.13 as our general available (GA) 
for
MySQL Workbench 8.0.

For the full list of changes in this revision, visit
http://dev.mysql.com/doc/relnotes/workbench/en/changes-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 
ofplatforms from our download pages at:


http://dev.mysql.com/downloads/tools/workbench/


Enjoy!


Changes in MySQL Workbench 8.0.13 (2018-10-22, General Availability)

 * Server Support

 * Functionality Added or Changed

 * Bugs Fixed

Server Support


 * Support for MySQL 5.5 by MySQL Workbench 8.0 was removed.
   If you still need to use MySQL Workbench on a MySQL 5.5
   server, you can use MySQL Workbench 6.3, which is
   available from MySQL Product Archives (see
   https://downloads.mysql.com/archives/workbench/).

Functionality Added or Changed


 * MySQL Workbench on macOS 10.14 Mojave was tested with
   positive results. The new Dark Mode feature is not yet
   compatible with all screens and should not be enabled for
   this release.

Bugs Fixed


 * With valid geometry points inserted, the option to open
   the points in a browser failed on macOS hosts because the
   URL was improperly formed. (Bug #28587193, Bug #92266)

 * An apostrophe character (') within a table comment
   generated a parsing error when an attempt was made to
   alter the table. (Bug #28552873, Bug #92191)

 * Insufficient privilege was granted during the attempt to
   create a new MySQL Enterprise Backup user account.
   Although valid prerequisite backup information was
   provided, the validation script returned the following
   error message: Access denied for backup account.
   (Bug #28536272, Bug #92115)

 * When remote management with SSH was enabled, attempting
   to insert the required passwords in the Options file
   produced an error message. After the error was closed,
   the Administration tab became unresponsive and MySQL
   Workbench did not shut down properly. (Bug #28519087,
   Bug #92061)

 * An error with the following message was generated when
   the export operation was executed on tables from an
   earlier server version: Unknown table 'COLUMN_STATISTICS'
   in information_schema (1109).
   Because the version of mysqldump used with the operation
   can differ from that of the target server, some features
   may not be exported as expected when the versions are
   mismatched. A warning message now provides a description
   of the condition, along with instructions to resolve the
   version mismatch, or the option to continue anyway.
   (Bug #28471433, Bug #91640)

 * On Windows hosts, the history of scheduled MySQL
   Enterprise Backup jobs was not persisted in the dashboard
   between MySQL Workbench sessions. This fix eliminates the
   issue; however, the existing mysqlwbmeb.vbs file must be
   removed before scheduling new backup jobs.
   (Bug #28430457)

 * The default target version of MySQL to use with MySQL
   Workbench models was set to MySQL 5.6.30 and did not
   increment automatically. With this fix, the value now
   defaults to the latest version. The default target
   version can also be set manually (see Preferences:
   Modeling: MySQL
   (http://dev.mysql.com/doc/workbench/en/wb-preferences-mod
   eling.html#wb-preferences-modeling-mysql)).
   (Bug #28397515, Bug #91782)

 * Executing queries over an period of time caused the
   existing result grid in each query tab to be hidden when
   the grid was previously visible and prevented the results
   grid in new tabs from showing. (Bug #28361489,
   Bug #91265)

 * After copying a query into a second query editor,
   auto-completion did not display the related column names.
   Instead, when auto-completion was engaged, MySQL
   Workbench stopped working. (Bug #28312867, Bug #91559)

 * The operation to compare schemas did not appear in the
   menu after a valid model was opened on Linux hosts.
   (Bug #28249454)

 * The filter arrows that select objects for forward or
   reverse engineering within wizards generated an error
   instead of moving the objects as expected.
   (Bug #26435349, Bug #26922638, Bug #87980, Bug #25921645,
   Bug #86013, Bug #25852505, Bug #85837, Bug #25741519,
   Bug #85522)

 * Schema privileges in the Administration - Users and
   Privileges tab (Object Rights, DDL Rights, and Other
   Rights) were not visible with all screen resolutions.
   (Bug #25584920, Bug #85079)

 * The color used to highlight a selected item in the schema
   tree view did not provide enough contrast from the
   background

MySQL Community Server 5.6.42 has been released

2018-10-22 Thread Surabhi Bhat


Dear MySQL users,

MySQL Server 5.6.42, a new version of the popular Open Source Database
Management System, has been released. MySQL 5.6.42 is recommended for
use on production systems.

   This release also incorporates all bug fixes and changes made in
   previous NDB Cluster releases, as well as all bug fixes and feature
   changes which were added in mainline MySQL 5.5 through MySQL 5.5.62
   (see Changes in MySQL 5.5.62 (Not yet released, General availability)
   (http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-62.html)).
   For an overview of what's new in MySQL 5.6, please see

http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html

 Starting with 5.6.11, Microsoft Windows packages for MySQL 5.6 are
 available both as a "full" installer and as a "web" installer.  The
 full installer is significantly larger and comes bundled with the
 latest software releases available. This bundle makes it easy to
 download and configure a full server and development suite.

 The web installer doesn't come bundled with any actual products and
 instead relies on download-on-demand to fetch only the products you
 choose to install. This makes the initial download much smaller but
 increases install time as the individual products will need to be
 downloaded.

For information on installing MySQL 5.6.42 on new servers or upgrading
to MySQL 5.6.42 from previous MySQL releases, please see

http://dev.mysql.com/doc/refman/5.6/en/installing.html

MySQL Server is available in source and binary form for a number of
platforms from our download pages at

http://dev.mysql.com/downloads/

Not all mirror sites may be up to date at this point in time, so if you
can't find this version on some mirror, please try again later or choose
another download site.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc:

https://wikis.oracle.com/display/mysql/Contributing

The following link lists the changes in the MySQL 5.6 since the release
of MySQL 5.6.41. It may also be viewed online at

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-42.html

Enjoy!

Changes in MySQL 5.6.42 (2018-10-22, General Availability)


 * Functionality Added or Changed

 * Bugs Fixed

Functionality Added or Changed


 * Previously, file I/O performed in the I/O cache in the
   mysys library was not instrumented, affecting in particular file
   I/O statistics reported by the Performance Schema about the
   binary log index file. Now, this I/O is instrumented and
   Performance Schema statistics are accurate. Thanks to Yura
   Sorokin for the contribution. (Bug #27788907, Bug #90264)

 * The zlib library version bundled with MySQL was raised
   from version 1.2.3 to version 1.2.11. MySQL implements
   compression with the help of the zlib library.  The zlib
   compressBound() function in zlib 1.2.11 returns a slightly higher
   estimate of the buffer size required to compress a given length
   of bytes than it did in zlib version 1.2.3. The compressBound()
   function is called by InnoDB functions that determine the maximum
   row size permitted when creating compressed InnoDB tables or
   inserting rows into compressed InnoDB tables. As a result, CREATE
   TABLE ... ROW_FORMAT=COMPRESSED or INSERT operations with row
   sizes very close to the maximum row size that were successful in
   earlier releases could now fail.  If you have compressed InnoDB
   tables with large rows, it is recommended that you test
   compressed table CREATE TABLE statements on a MySQL 8.0.3 test
   instance prior to upgrading.

Bugs Fixed


 * InnoDB: An ALTER TABLE operation that added a primary key
   produced a segmentation fault. (Bug #28395278) References: This
   issue is a regression of: Bug #27753193.

 * InnoDB: An assertion was raised during an OPTIMIZE TABLE
   operation. (Bug #27753193)

 * InnoDB: A foreign key constraint name was duplicated
   during a rename table operation, causing a failure during later
   query execution. (Bug #27545888)

 * InnoDB: The location of the Innodb Merge Temp File that
   reported by the wait/io/file/innodb/innodb_temp_file Performance
   Schema instrument was incorrect. (Bug #21339079, Bug #77519)

 * Replication: When FLUSH statements for specific log types
   (such as FLUSH SLOW LOGS) resulted in an error, the statements
   were still written to the binary log. This stopped replication
   because the error had occurred on the master, but did not occur
   on the slave. MySQL Server now checks on the outcome of these
   FLUSH statements, and if an error occurred, the statement is not
   written to the binary log. (Bug #24786290, Bug #83232)

 * Microsoft Windows: On Windows, uninstallation of the
   MySQL Server MSI package through MySQL Installer produced a
   spurious popup

Benetl, a free ETL tool for MySQL, out in version 4.9

2018-10-22 Thread Benoît Carpentier


Dear all,

Benetl, a free ETL tool for MySQL, is out in version 4.9.

This new version is providing some code optimizations, tests coverage 
improvement.


This version supports Java 1.8 and providesone bug correction (dist 
function now returns result as double type).

You should really update.

Benetl is freely dowloadable at:https://www.benetl.net

You can learn more about ETL tools at: 
http://en.wikipedia.org/wiki/Extract,_transform,_load


Thanks for your interest.

Regards,

--
Benoît Carpentier
https://www.benetl.net
Founder of Benetl and Java project manager

MySQL Connector/Node.js 8.0.13 has been released

2018-10-22 Thread Hery Ramilison


Dear MySQL users,

MySQL Connector/Node.js is a new Node.js driver for use with the X
DevAPI. This release, v8.0.13, is a maintenance release of the
MySQL Connector/Node.js 8.0 series.

The X DevAPI enables application developers to write code that combines
the strengths of the relational and document models using a modern,
NoSQL-like syntax that does not assume previous experience writing
traditional SQL.

MySQL Connector/Node.js can be downloaded through npm (see
https://www.npmjs.com/package/@mysql/xdevapi for details) or from
https://dev.mysql.com/downloads/connector/nodejs/.

To learn more about how to write applications using the X DevAPI, see
http://dev.mysql.com/doc/x-devapi-userguide/en/. For more information
about how the X DevAPI is implemented in MySQL Connector/Node.js, and
its usage, see http://dev.mysql.com/doc/dev/connector-nodejs/.

Please note that the X DevAPI requires at least MySQL Server version
8.0 or higher with the X Plugin enabled. For general documentation
about how to get started using MySQL as a document store, see
http://dev.mysql.com/doc/refman/8.0/en/document-store.html.

Changes in MySQL Connector/Node.js 8.0.13 (2018-10-22, General availability)

Functionality Added or Changed

 * To go with the existing asynchronous
   mysqlx.getSession(conn_str) method, a new synchronous
   mysqlx.getClient(conn_str, options) method was added that
   creates a connection pool handler that provides an
   asynchronous getSession() method to create and retrieve
   connections from the pool. The collection pooling options
   are:

  + enabled: enables or disables connection pooling;
boolean and defaults to true.

  + maxSize: maximum number of connections available in
the pool; positive integer and defaults to 25.

  + maxIdleTime: maximum number of milliseconds a
connection can be idle in the queue before being
closed; integer >= 0 and defaults to 0 (infinite).

  + queueTimeout: maximum number of milliseconds a
request will wait for a connection to become
available; integer >= 0 and defaults to 0
(infinite).
This is different than connectTimeout that's used
for non-pooling. In a pooling scenario, there might
already be connections in the pool and queueTimeout
controls how long to wait for a connection in the
pool.
   Example usage:
   var mysqlx = require('@mysql/xdevapi')
   var client = mysqlx.getClient(
 { user: 'root', host: 'localhost', port: 33060 },
 { pooling: { enabled: true, maxIdleTime: 5000, maxSize: 25, 
queueTimeout: 2 } }

   );

   client.getSession()
 .then(session => {
   console.log(session.inspect())
   return session.close() // the connection becomes idle in the 
client pool

 })
 .then(() => {
   return client.getSession()
 })
 .then(session => {
   console.log(session.inspect())
   return client.close() // closes all connections and destroys 
the pool

 })

   Closing a session attached to the pool makes the
   connection available in the pool for subsequent
   getSession() calls, while closing (destroying) the pool
   effectively closes all server connections.

 * Added a connection timeout query parameter. This defines
   the length of time (milliseconds) the client waits for a
   MySQL server to become available in the given network
   addresses. It was added to both the mysqlx.getSession()
   (non-pooling sessions) and mysqlx.getClient() (pooling
   sessions) interfaces. This option defaults to 1 (10
   seconds). The value 0 disables the timeout so the client
   will wait until the underlying socket (platform
   dependent) times out.
   Similar to other option formatting rules, this option
   defined as connection-timeout (kebab-case) for URI
   definitions and connectionTimeout (camelCase) for plain
   JavaScript configuration objects.
   Example usage:
   const mysqlx = require('@mysql/xdevapi');
   var client = mysqlx.getClient('root@localhost?connect-timeout=5000')
   client.getSession()
   .catch(err => {
   console.log(err.message) // "Connection attempt to the 
server was aborted. Timeout of 5000 ms was exceeded."

   })

   // Or

   const mysqlx = require('@mysql/xdevapi');
   var client = 
mysqlx.getClient('mysqlx://root:passwd@[localhost:33060, 
127.0.0.1:33060]?connect-timeout=5000')

   client.getSession()
   .catch(err => {
   // connection could not be established after 10 seconds 
(5 seconds for each server)
   console.log(err.message); // All server connection 
attempts we re aborted. Timeout of 5000 ms was exceeded for each 
selected server.

   });

MySQL Community Server 5.7.24 has been released

2018-10-22 Thread Gipson Pulla

Dear MySQL users,

MySQL Server 5.7.24, a new version of the popular Open Source
Database Management System, has been released. MySQL 5.7.24 is
recommended for use on production systems.

For an overview of what's new in MySQL 5.7, please see

  http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html

For information on installing MySQL 5.7.24 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.24 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.24 is also available from our repository for Linux
platforms, go here for details:

  http://dev.mysql.com/downloads/repo/

Windows packages are available via the Installer for Windows or .ZIP
(no-install) packages for more advanced needs. The point and click
configuration wizards and all MySQL products are available in the
unified Installer for Windows:

  http://dev.mysql.com/downloads/installer/

5.7.24 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.23. It may also be viewed
online at

  http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-24.html

Enjoy!

Changes in MySQL 5.7.24 (2018-10-22, General Availability)

Deprecation and Removal Notes


 * InnoDB; Partitioning: Support for placing table
   partitions in shared tablespaces is deprecated and will
   be removed in a future version of MySQL. Shared
   tablespaces include the system tablespace and general
   tablespaces. For information about identifying partitions
   in shared tablespaces and moving them to file-per-table
   tablespaces, see Preparing Your Installation for Upgrade
http://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html

 * InnoDB: Support for TABLESPACE = innodb_file_per_table
   and TABLESPACE = innodb_temporary clauses with CREATE
   TEMPORARY TABLE is deprecated and will be removed in a
   future MySQL version.

Packaging Notes


 * Binary packages that include curl rather than linking to
   the system curl library now use curl 7.60.0 rather than
   7.45.0. (Bug #28043702)

Security Notes


 * Microsoft Windows: On Windows, MySQL Enterprise Edition
   distributions now bundle the Cyrus SASL library files
   libsasl.dll and saslSCRAM.dll so that the LDAP
   authentication plugins can use the SCRAM-SHA-1
   authentication method.

 * MySQL Enterprise Edition now provides data masking and
   de-identification capabilities, implemented as a plugin
   library containing a plugin and a set of user-defined
   functions. Data masking hides sensitive information by
   replacing real values with substitutes. MySQL Enterprise
   Data Masking and De-Identification functions enable
   masking existing data using several methods such as
   obfuscation (removing identifying characteristics),
   generation of formatted random data, and data replacement
   or substitution. For example:
mysql> SET @ssn = gen_rnd_ssn();
mysql> SET @masked_ssn1 = mask_ssn(@ssn);
mysql> SET @masked_ssn2 = mask_outer(mask_inner (@ssn,4,5,'A'), 3,0,'B');
mysql> SELECT @ssn, @masked_ssn1, @masked_ssn2;
+-+--+--+
| @ssn| @masked_ssn1 | @masked_ssn2 |
+-+--+--+
| 980-31-2838 | XXX-XX-2838  | BBB-AA-2838  |
+-+--+--+

   For more information, see MySQL Enterprise Data Masking
   and De-Identification
http://dev.mysql.com/doc/refman/8.0/en/data-masking.html

Functionality Added or Changed


 * Previously, file I/O performed in the I/O cache in the
   mysys library was not instrumented, affecting in
   particular file I/O statistics reported by the
   Performance Schema about the binary log index file. Now,
   this I/O is instrumented and Performance Schema
   statistics are accurate. Thanks to Yura Sorokin for the
   contribution. (Bug #27788907, Bug #90264)

 * The zlib library version bundled with MySQL was raised
   from version 1.2.3 to version 1.2.11. MySQL implements
   compression with the help of the zlib library.
   The zlib compressBound() function in zlib 1.2.11 returns
   a slightly higher estimate of the buffer size required to
   compress a given length of bytes than it did in zlib
   version 1.2.3. The compressBound()

MySQL Connector/ODBC 8.0.13 has been released

2018-10-22 Thread Kent Boortz



Dear MySQL users,

MySQL Connector/ODBC 8.0.13 is a new version in the MySQL
Connector/ODBC 8.0 series, the ODBC driver for the MySQL Server.

The available downloads include both a Unicode driver and an ANSI
driver based on the same modern codebase. Please select the driver
type you need based on the type of your application - Unicode or ANSI.
Server-side prepared statements are enabled by default. It is suitable
for use with any MySQL server version from 5.5.

This release of the MySQL ODBC driver is conforming to the ODBC 3.8
specification. It contains implementations of key 3.8 features,
including self-identification as a ODBC 3.8 driver, streaming of
output parameters (supported for binary types only), and support of
the SQL_ATTR_RESET_CONNECTION connection attribute (for the Unicode
driver only).

The release is now available in source and binary form for a number of
platforms from our download pages at

  https://dev.mysql.com/downloads/connector/odbc/

For information on installing, please see the documentation at

  https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-installation.html

Changes in MySQL Connector/ODBC 8.0.13 (2018-10-22, General Availability)

   Functionality Added or Changed

 * Added dynamic libmysql linking support via the
   -DMYSQLCLIENT_STATIC_LINKING:BOOL=TRUE|FALSE option;
   defaults to FALSE to enable dynamic linking.

   Bugs Fixed

 * Fixed column metadata handling with Microsoft Access.
   (Bug #28670725, Bug #91856)

 * The following obsolete options were removed: NO_SCHEMA
   (use NO_CATALOG instead), DISABLE_SSL_DEFAULT (use
   SSLMODE instead), and SSL_ENFORCE (use SSLMODE instead).
   (Bug #28407520)

 * The ODBC Driver returned 0 for the
   SQL_MAX_SCHEMA_NAME_LEN attribute, and now returns 64 as
   the maximum length for a MySQL schema name.
   (Bug #28385722)

 * Because the MySQL ODBC driver ignored the SQL_RD_OFF
   value for the SQL_ATTR_RETRIEVE_DATA attribute, it
   incorrectly kept writing into the data buffers. This led
   to write access violation errors when data was written
   into the buffer when the user application explicitly
   requested not to write there. (Bug #28098219, Bug #91060)

On Behalf of Oracle/MySQL Release Engineering Team,
Kent Boortz

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Router 8.0.13 for MySQL Server 8.0 and 5.7 has been released

Dear MySQL users,

MySQL Router 8.0.13 is a new release for MySQL Router 8.0 series.

MySQL Router 8.0 is highly recommended for use with MySQL Server 8.0 and 5.7.
Please upgrade to MySQL Router 8.0.13.

The MySQL Router is a new building block for high availability solutions
based on MySQL InnoDB clusters.

By taking advantage of the new Group Replication technology, and
combined with the MySQL Shell, InnoDB clusters provide an integrated
solution for high availability and scalability for InnoDB based MySQL
databases, that does not require advanced MySQL expertise.

The deployment of applications with high availability requirements is
greatly simplified by MySQL Router. MySQL client connections are
transparently routed to online members of a InnoDB cluster, with MySQL
server outages and cluster reconfigurations being automatically handled
by the Router.

To download MySQL Router 8.0.13, see the "Generally Available (GA)
Releases" tab at http://dev.mysql.com/downloads/router. Package
binaries are available for several platforms and also as a source code
download.

Documentation for MySQL Router can be found at
http://dev.mysql.com/doc/mysql-router/en/

Enjoy!

--

Changes in MySQL Router 8.0.13 (2018-10-22)


 * Functionality Added or Changed

 * Bugs Fixed

Functionality Added or Changed


 * To align package names with MySQL Server, the community
   package name prefix changed from "mysql-router-" to
   "mysql-router-community-". This change also allows
   upgrading from MySQL Router 2.1 to 8.0. Additionally, a
   "mysql-router" meta package was added that redirects
   "mysql-router" to "mysql-router-community".

Bugs Fixed


 * For SLES 12, MySQL binary distributions are now built
   using GCC 7. The lowest supported GCC version on this
   platform is now 5.3 (previously 4.8.5).
   Installing MySQL Router 8.0.13 or higher RPM packages on
   SLES 12 platforms requires that the GCC Devel repo is
   enabled, for example:
shell> cd /etc/zypp/repos.d/
shell> wget 
https://download.opensuse.org/repositories/devel:/gcc/SLE-12/devel:gcc.repo
...
shell> zypper install ./mysql-router-community-8.0.*rpm

   (Bug #28685857)
   References: See also: Bug #92147.

 * The log level was changed from INFO to DEBUG for the
   InnoDB cluster Metadata server and replicaset
   connections. Because MySQL Router's ttl configuration
   option defaults to 0.1, these each generate 10 log
   entries per second. (Bug #28424243)

 * Running MySQL Router against an invalid InnoDB cluster
   would report internal SQL errors, such as "Unknown
   database 'mysql_innodb_cluster_metadata'", rather than
   user-friendly information that the cluster is not set up
   as a metadata server. The generated error now clarifies
   the reason and points to related documentation. (Bug
   #28292073)

 * The --version output was aligned across all binaries to
   include license related text. (Bug #28262453)

 * On Windows, starting Router after uninstalling the Router
   service would cause Router to hang as it assumed the
   service was still enabled. (Bug #28261217)

 * Passing in --directory to an unwritable empty directory
   would yield a generic error. (Bug #28228800)

 * The error code ER_CON_COUNT_ERROR is now used instead of
   HY000 ("unknown") when the maximum number of allowed
   connections is exceeded. (Bug #28183810)

 * The metadata version
   (mysql_innodb_cluster_metadata.schema_version)
   compatibility check is now checked at runtime, when
   before it only happened during the bootstrap process.
   (Bug #28147601)

 * Bootstraping with --user set to the same user running the
   bootstrap operation would halt with a "setegid failed"
   error. (Bug #27698052)

 * An error related to running out of available threads was
   only logged once until Router was restarted. (Bug
   #27577694)

 * MySQL Router is now included in MySQL Server's source and
   monolithic binary packages. The MySQL Router standalone
   packages continue to exist, as before.

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Enterprise Backup 8.0.13 has been released

Dear MySQL users,
 
MySQL Enterprise Backup 8.0.13, a new version of the online MySQL backup
tool, is now available for download from the My Oracle Support (MOS) website
as our latest GA release. This release will be available on eDelivery (OSDC)
after the next upload cycle. MySQL Enterprise Backup is a commercial
extension to the MySQL family of products.
 
MySQL Enterprise Backup 8.0.13 only supports MySQL Server 8.0.13. For
earlier versions of MySQL 8.0, use the MySQL Enterprise Backup version
with the same version number as the server.  For MySQL server 5.7,
please use MySQL Enterprise Backup 4.1 and for MySQL Server 5.6 and
5.5, please use MySQL Enterprise Backup 3.12.
 
A brief summary of the changes in MySQL Enterprise Backup (MEB)
version 8.0.13 is given below.



Changes in MySQL Enterprise Backup 8.0.13 (2018-10-22)


 * Functionality Added or Changed

 * Bugs Fixed

Functionality Added or Changed


 * mysqlbackup now supports backup compression (the use of
   the --compress and --uncompress options) for incremental
   backups (except for incremental backups created with the
   --incremental-with-redo-log-only option).

 * mysqlbackup now supports transparent page compression for
   InnoDB tables. The support is enabled by setting the
   mysqlbackup option --compress-method=punch-hole; see
   description for the option for details.

Bugs Fixed


 * mysqlbackup hung when a backup operation failed due to a
   full disk. With this fix, mysqlbackup quits gracefully in
   the situation by throwing an error. (Bug #28399821)

 * A mysqlbackup operation on an image stored on an
   OpenStack cloud storage service sometimes failed with a
   segmentation fault or a bad URL error. It was because of
   a race condition caused by an uninitiated variable, which
   has been eliminated by this fix. (Bug #28189239, Bug
   #28183729)

 * Backups for databases with encrypted InnoDB tables failed
   when the --compress option was used. (Bug #28177466)

 * A mysqlbackup operation on an image stored on an
   OpenStack cloud storage service failed with a 401
   Unauthorized error when the operation took a long time
   and the authentication token for the cloud access
   expired. With this fix, a separate thread in mysqlbackup
   requests a new token from the OpenStack cloud service in
   that situation, so that the operation can continue. (Bug
   #27893174)

 * When an incremental backup was restored without using the
   --log-bin option, the binary log was not restored to its
   original location on the backed up server, but to the
   location specified by --log-bin earlier during the
   restore of the base backup. The same occurred for relay
   logs of incremental backups for slaves when the
   --relay-log option was not used. (Bug #27545745)

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

MySQL Community Server 8.0.13 has been released (part 2/2)

[This is part 2 of the announcement]

Bugs Fixed


 * Important Note: The libevent library included with the
   MySQL Server was upgraded to version 2.1.8. (Bug
   #28207237)

 * InnoDB; Partitioning: Removed old InnoDB handler and
   partitioning code that referenced .frm files, and thus no
   longer had any purpose. (Bug #27995316)

 * InnoDB: An assertion was raised during a DROP TABLE
   operation. A thread that was accessing the table through
   the memcached API released metadata locks before
   releasing the table. (Bug #28531148)

 * InnoDB: The being_modified bit in a LOB reference was set
   but the bit modification was not logged, causing an
   assertion failure. (Bug #28443837)

 * InnoDB: Window functions returned incorrect results when
   the optimizer used the InnoDB storage engine for internal
   temporary tables. (Bug #28430650)

 * InnoDB: Adjusting the server time to an earlier time
   caused periodic redo flushes to be missed. (Bug
   #28430358, Bug #90670)

 * InnoDB: An ALTER TABLE operation that added a primary key
   produced a segmentation fault. (Bug #28395278)
   References: This issue is a regression of: Bug #27753193.

 * InnoDB: A conditional check was removed by removing the
   ReadView::complete() function and splitting its work
   among other functions. This change helps optimize
   performance on ARM 64-bit. (Bug #28385211, Bug #91759)

 * InnoDB: Leftover thread_mutex code was removed from
   InnoDB source code files. (Bug #28363673, Bug #91678)

 * InnoDB: Type changes were implemented to eliminate
   warnings that occurred when compiling InnoDB with
   Microsoft Visual Studio 2017. (Bug #28338720)

 * InnoDB: An invalid assertion was raised when a B-tree
   flag used to mark shared index locks was used to mark a
   shared-exclusive index lock. (Bug #28317172)

 * InnoDB: The sharp checkpoint mechanism no longer forces
   preflushing of dirty pages when requesting a checkpoint
   for the currently available LSN.
   The log checkpointer thread now takes the concurrency
   margin (the per thread margin for free space in the log)
   into account when determining if the next checkpoint
   write is required and whether to wake up page cleaners to
   force a sync-flush of dirty pages. Page cleaner threads
   take the concurrency margin into account when determining
   whether to flush dirty pages and how many pages to flush.
   (Bug #28297462)

 * InnoDB: A misplaced debug crash point caused a
   transaction timeout resulting in test failures. (Bug
   #28295814)

 * InnoDB: InnoDB error message format was modified to
   remove duplicate text. (Bug #28289789)

 * InnoDB: Unnecessary cycles of freeing and allocating
   memory caused JSON performance degradation on Windows.
   (Bug #28278737)

 * InnoDB: To avoid checking hardware support each time a
   hardware-optimized checksum is computed, asserts were
   converted to debug-only asserts. (Bug #28267334, Bug
   #91485)

 * InnoDB: A patch that combined Variance-Aware Transaction
   Scheduling (VATS) with functionality that releases read
   locks caused gap locks to be removed without granting
   locks to waiting transactions, resulting in transaction
   timeouts. (Bug #28261530)
   References: This issue is a regression of: Bug #28261530.

 * InnoDB: The log_checkpointer thread failed to write new
   checkpoints in a timely manner when the amount of redo
   was small. (Bug #28220222)

 * InnoDB: The server exited during an in-place upgrade from
   MySQL 5.7 to MySQL 8.0 due to an attempted eviction of a
   foreign-key-related table from the cache. At the end of
   the upgrade process, tables with FULLTEXT indexes were
   marked as ready for eviction without checking for foreign
   key relationships. (Bug #28212734, Bug #91325)

 * InnoDB: The format of the following Performance Schema
   and INFORMATION_SCHEMA table columns was modified:

  + data_locks.ENGINE_LOCK_ID

  + data_lock_waits.REQUESTING_ENGINE_LOCK_ID

  + data_lock_waits.BLOCKING_ENGINE_LOCK_ID

  + INNODB_TRX.TRX_REQUESTED_LOCK_ID
   The previous format was trx_id:table_id for table locks
   and trx_id:space_id:page_no:heap_no for record locks. The
   new format is trx_immutable_id:table_id:lock_immutable_id
   for table locks and
   trx_immutable_id:space_id:page_no:heap_no:lock_immutable_
   id for record locks.
   lock_immutable_id and trx_immutable_id are 64-bit values
   that do not change during the lifetime of a lock or
   transaction, respectively, and are unique among other
   instance object IDs. (Bug #28176910)

 * InnoDB: The list of permitted lock mode descriptors used
   by the

MySQL Connector/C++ 8.0.13 has been released

2018-10-22 Thread Balasubramanian Kandasamy




Dear MySQL users,

MySQL Connector/C++ 8.0.13 is a new release version of the MySQL
Connector/C++ 8.0 series.

Connector/C++ 8.0 can be used to access MySQL implementing Document
Store or in a traditional way, using SQL queries. It allows writing
both C++ and plain C applications using X DevAPI and X DevAPI for C.
It also supports the legacy API of Connector/C++ 1.1 based on JDBC4.

To learn more about how to write applications using X DevAPI, see "X
DevAPI User Guide"

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.13, see the "Generally Available (GA)
Releases" tab at

https://dev.mysql.com/downloads/connector/cpp/


Changes in MySQL Connector/C++ 8.0.13 (2018-10-22, General Availability)

 * Character Set Support

 * Packaging Notes

 * X DevAPI Notes

 * Functionality Added or Changed

 * Bugs Fixed

Character Set Support


 * For connections to the server made using the legacy JDBC
   API (that is, not made using X DevAPI or X DevAPI for C),
   the default connection character set is now utf8mb4
   rather than utf8. Connections to the server made using X
   DevAPI or X DevAPI for C continue to use the connection
   character set determined by the server. (Bug #28204677)

Packaging Notes


 * Connector/C++ 32-bit MSI packages are now available for
   Windows. These 32-bit builds enable use of the legacy
   JDBC connector.

 * Connector/C++ compressed tar file packages are now
   available for Solaris.
   It is also possible to build Connector/C++ from source on
   Solaris. For platform-specific build notes, see Building
   Connector/C++ Applications: Platform-Specific Considerations
(http://dev.mysql.com/doc/connector-cpp/8.0/en/connector-cpp-apps-platform-considerations.html).


X DevAPI Notes


 * Connector/C++ now provides connection pooling for
   applications using X Protocol. This capability is based
   on client objects, a new type of X DevAPI object. A
   client can be used to create sessions, which take
   connections from a pool managed by that client. For a
   complete description, see Connecting to a Single MySQL
   Server Using Connection Pooling
(http://dev.mysql.com/doc/x-devapi-userguide/en/connecting-connection-pool.html).
   X DevAPI example:
   using namespace mysqlx;

   Client cli("user:password@host_name/db_name", 
ClientOption::POOL_MAX_SIZE, 7);

   Session sess = cli.getSession();

   // use sess as before

   cli.close();  // close session sess

   X DevAPI for C example:
   char error_buf[255];
   int  error_code;

   mysqlx_client_t *cli
   = mysqlx_get_client_from_url(
   "user:password@host_name/db_name", "{ \"maxSize\": 7 }", 
error_buf, _code);

   mysqlx_session_t *sess = mysqlx_get_session_from_client(cli);

   // use sess as before

   mysqlx_close_client(cli);  // close session sess


 * For X DevAPI, a new connect-timeout option can be
   specified in connection strings or URIs to indicate a
   connection timeout in milliseconds. The
   SessionSettings::Options object supports a new
   CONNECT_TIMEOUT option.
   For X DevAPI for C, the mysqlx_opt_type_t constant is
   MYSQLX_OPT_CONNECT_TIMEOUT together with the
   OPT_CONNECT_TIMEOUT() macro.
   If no timeout option is specified, the default is 1
   (10 seconds). A value of 0 disables the timeout. The
   following examples set the connection timeout to 10
   milliseconds:
   X DevAPI examples:
   Session sess("user@host/db?connect-timoeut=10");

   Session sess(..., SessionOption::CONNECT_TIMEOUT, 10, ...);

   Session sess(
   ...,
   SessionOption::CONNECT_TIMEOUT, std::chrono::milliseconds(10),
   ...
   );

   X DevAPI for C example:
   mysqlx_session_options_t *opt = mysqlx_session_options_new();
   mysqlx_session_option_set(opt, ..., OPT_CONNECT_TIMEOUT(10), ...);

Functionality Added or Changed


 * JSON: Connector/C++ now uses RapidJSON for improved
   performance of operations that involve parsing JSON
   strings. There are no user-visible API changes for X
   DevAPI or X DevAPI for C.

Bugs Fixed


 * On SLES 15, Connector/C++ installation failed if
   libmysqlcppcon7 was already installed. (Bug #28658120)

 * Applications that were statically linked to the legacy
   JDBC connector could encounter a read access violation at
   exit time

MySQL Community Server 8.0.13 has been released (part 1/2)