Tuesday, June 3, 2014

MySQL 5.6.19 (64-bit)

Summary of MySQL 5.6.19 (64-bit):

  • Requirements:

    Windows XP64 / Vista64 / Windows 7 64 / Windows 8 64

  • User Rating:

    Click to vote
  • Author / Product:

    Oracle / MySQL (64-bit)

  • Old Versions:

  • Filename:

    mysql-5.6.19-winx64.msi

  • MD5 Checksum:

    31a0de28d5fe9fa1f04f8dd8b4693250

MySQL is an open source RDBMS (Relational Database Management Systems), which supports requests written in various programming languages like C, C++, Java, Perl, and PHP. Due to its high speed and flexibility MySQL has become one of the most popular database systems used mainly for developing of Web applications of all shapes and sizes. After being present on the market since 1995, this extremely popular open-source database management system became used in countless of projects that today touch almost every internet users. Some of the most popular users of MySQL today are companies such as Facebook, Twitter, Wikipedia, Google, Flickr, YouTube, WordPress, JOomla, myBB, phpBB, and countless others. Under leadership of the Oracle Corporation, MySQL became absolute leader in adopting new technologies and tools for managing every single possible part of database projects, enabling companies from all around the world to create their own frontends that will control their own database project.

The official integrated environment of MySQL is MySQL Workbench, which c comes loaded with wide array of tools for graphical control of databases and SQL development projects. Even though 3rd party developers have created more than dozen popular MySQL frontends, Workbench is still considered being one of the most popular and most capable ones, serving as a concrete base from which all almost other frontends were made.

With incredible list of features, tools that can create databases that are used by millions of people, connected with cloud services and military-grade data protection and encryption, MySQL represents tool that singlehandedly enabled modern internet to expand into its modern state.

Top 10 Reasons to Use MySQL:

Scalability and Flexibility
The MySQL database server provides the ultimate in scalability, sporting the capacity to handle deeply embedded applications with a footprint of only 1MB to running massive data warehouses holding terabytes of information.

High Performance
A unique storage-engine architecture allows database professionals to configure the MySQL database server specifically for particular applications, with the end result being amazing performance results.

High Availability
Rock-solid reliability and constant availability are hallmarks of MySQL, with customers relying on MySQL to guarantee around-the-clock uptime.

Robust Transactional Support
MySQL offers one of the most powerful transactional database engines on the market.  Features include complete ACID (atomic, consistent, isolated, durable) transaction support, unlimited row-level locking and more.

Web and Data Warehouse Strengths
MySQL is the de-facto standard for high-traffic web sites because of its high-performance query engine, tremendously fast data insert capability, and strong support for specialized web functions like fast full text searches.

Strong Data Protection
Because guarding the data assets of corporations is the number one job of database professionals, MySQL offers exceptional security features that ensure absolute data protection.

Comprehensive Application Development
One of the reasons MySQL is the world's most popular open source database is that it provides comprehensive support for every application development need. Within the database, support can be found for stored procedures, triggers, functions, views, cursors, ANSI-standard SQL, and more.

Management Ease
MySQL offers exceptional quick-start capability with the average time from software download to installation completion being less than fifteen minutes.

Open Source Freedom and 24 x 7 Support
Many corporations are hesitant to fully commit to open source software because they believe they can't get the type of support or professional service safety nets they currently rely on with proprietary software to ensure the overall success of their key applications.

Lowest Total Cost of Ownership
By migrating current database-drive applications to MySQL, or using MySQL for new development projects, corporations are realizing cost savings that many times stretch into seven figures.



Tags: mysql, 32 bit version,

What's new in this version:

Functionality Added or Changed:
- The obsolete and unmaintained charset2html utility has been removed from MySQL distributions. (Bug #71897, Bug #18352347)
- The mysqlbug, mysql_waitpid, and mysql_zap utilities have been deprecated and will be removed in MySQL 5.7. Bugs Fixed:
- InnoDB: After upgrading from 5.6.10 to MySQL versions up to and including MySQL 5.6.18, InnoDB would attempt to rename obsolete full-text search auxiliary tables on server startup, resulting in an assertion failure. (Bug #18634201, Bug #72079)
- InnoDB: For each insert, memset would be called three times to allocate memory for system fields. To reduce CPU usage, the three memset calls are now combined into a single call. (Bug #17858679, Bug #71014)
- InnoDB: Enabling the InnoDB Table Monitor would result in a ib_table->stat_initialized assertion failure. (Bug #17039528, Bug #69641)
- InnoDB: Setting innodb_max_dirty_pages_pct=0 would leave 1% of dirty pages unflushed. Buffer pool flushing is initiated when the percentage of dirty pages is greater innodb_max_dirty_pages_pct. The internal variables that store the innodb_max_dirty_pages_pct value and the percentage of dirty pages (buf_get_modified_ratio_pct and srv_max_buf_pool_modified_pct) were defined as unsigned integer data types, which meant that a innodb_max_dirty_pages_pct value of 0 required a dirty pages percentage of 1 or greater to initiate buffer pool flushing.
- To address this problem, the buf_get_modified_ratio_pct and srv_max_buf_pool_modified_pct internal variables are redefined as double data types, which changes the range value for innodb_max_dirty_pages_pct and innodb_max_dirty_pages_pct_lwm from 0 .. 99 to 0 .. 99.99. Additionally, buffer pool flushing is now initiated when the percentage of dirty pages is “greater than or equal to” innodb_max_dirty_pages_pct. (Bug #13029450, Bug #62534)
- Replication: Log rotation events could cause group_relay_log_pos to be moved forward incorrectly within a group. This meant that, when the transaction was retried, or if the SQL thread was stopped in the middle of a transaction following one or more log rotations (such that the transaction or group spanned multiple relay log files), part or all of the group was silently skipped.
- This issue has been addressed by correcting a problem in the logic used to avoid touching the coordinates of the SQL thread when updating the log position as part of a relay log rotation whereby it was possible to update the SQL thread's coordinates when not using a multi-threaded slave, even in the middle of a group. (Bug #18482854)
- Replication: When running the server with --gtid-mode=ON, STOP SLAVE followed by START SLAVE resulted in a mismatch between the information provided by INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO and the Slave_open_temp_tables status variable: the INNODB_TEMP_TABLE_INFO table showed that no temporary tables existed, but Slave_open_temp_tables had a nonzero value. (Bug #18364070)
- References: See also Bug #18236612.
- Replication: In certain cases, the server mishandled triggers and stored procedures that tried to modify other tables when called by CREATE TABLE ... SELECT. This is now handled correctly as an error. (Bug #18137535)
- Replication: When used on a table employing a transactional storage engine, a failed TRUNCATE TABLE was still written to the binary log and thus replayed on the slave. This could lead to inconsistency when the master retained data that was removed on the slave.
- Now in such cases TRUNCATE TABLE is logged only when it executes successfully. (Bug #17942050, Bug #71070)
- Replication: The server did not always handle the auto.cnf file correctly in cases where this file's permissions were incorrect. (Bug #17786581, Bug #70891)
- Replication: When the binary log was rotated due to receipt of a SIGHUP signal, the new binary log did not contain the Previous_gtid_event required for subsequent processing of that binary log's GTID events. Now when SIGHUP is received, steps are taken to insure that the server writes the necessary Previous_gtid_event to the new log before writing any GTID events to the new log. (Bug #17026898) Replication: When gtid_mode=ON, and a transaction is filtered out on the slave, the GTID of the transaction is still logged on the slave as an “empty” transaction (consisting of a GTID followed immediately by BEGIN and then COMMIT). This is necessary to prevent the transaction from being retransmitted the next time the slave reconnects or is involved in a failover. The current fix addresses two issues relating to such “empty” transactions:
- No empty transaction was generated for CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE statements.
- If the slave used a database filter (--replicate-do-db or --replicate-ignore-db option), no empty transaction was generated.
- (Bug #71326, Bug #18095502, Bug #18145032)
- The server could fail to properly reprepare triggers that referred to another table after that table was truncated. (Bug #18596756)
- Certain INFORMATION_SCHEMA queries could cause a server exit. (Bug #18319790)
- For indexes on prefixes or character string columns, index corruption could occur for assignment of binary data to the column due to improper character counting. (Bug #18359924)
- Solaris-specific scripts were included in and installed by non-Solaris packages. (Bug #18305641)
- Concurrent execution of a FLUSH TABLE operation and a stored program that used a cursor could cause a server exit. (Bug #18158639)
- The cl

No comments:

Post a Comment