Oracle Announces MySQL 5.6 Release Candidate

Hi Guys,
 
Finally MySQL 5.6 is here. With great features for DBA and Product.. Below is some of key features from Oracle Keynot.

Release Candidate Delivers a Wide Range of Innovations

MySQL 5.6 RC provides enhanced linear scalability, helping users to leverage modern hardware capabilities.

With this Release Candidate, users can experience simplified query development and execution, better transactional throughput and application availability, flexible NoSQL access, improved replication and enhanced instrumentation.

New features and benefits include:

ü  Better Query Execution Times and Diagnostics provided through an enhanced MySQL Optimizer that includes:

ü  Subquery Optimizations: simplify query development by optimizing subqueries prior to execution. New efficiencies in how result sets are selected, sorted and returned deliver substantial improvement in query execution times.

ü  The addition of Index Condition Pushdown (ICP) and Batch Key Access (BKA) can improve selected query throughput by up to 280x(1).

ü  Enhanced Optimizer Diagnostics: with EXPLAIN for INSERT, UPDATE, and DELETE operations. EXPLAIN plan output in JSON format delivers more precise optimizer metrics and better readability, and Optimizer Traces enables to track the optimizer decision-making process.

ü  Better Transactional Throughput and Application Availability with an improved InnoDB storage engine:

ü  Better Transactional and Read Only Throughput: InnoDB has been re-factored to minimize legacy threading, flushing, purge mutex contentions and bottlenecks, enabling better concurrency on heavily loaded OLTP systems, and resulting in significantly improved throughput for read only workloads(2).

ü  Enhanced Availability: Online DDL operations enable DBAs to add indexes and perform table alterations while the application remains available for updates.

ü  Full-Text Search with InnoDB: allows developers to build FULLTEXT indexes on InnoDB tables to represent text-based content and speed up application searches for words and phrases.

ü  Simple, Key Value Lookup: flexible NoSQL access to InnoDB provides simple, key-value lookup of InnoDB data via the familiar Memcached API. Users get the “best of both worlds,” combining key-value operations and complex SQL queries in the same database.

ü  Improved Scale-Out and High Availability: with new features in MySQL replication including:

ü  Self-Healing Replication Clusters: the addition of Global Transaction Identifiers and HA Utilities make it simple to automatically detect and recover from failures. Crash-Safe Replication enables the binary log and slaves to automatically recover correct positions in the replication stream in case of a crash, and resume replication without administrator intervention. Checksums maintain data integrity across the cluster by automatically detecting and alerting on errors.

ü  High Performance Replication Clusters: up to 5x faster replication through Multi-Threaded Slaves(3), Binlog Group Commit and Optimized Row-Based Replication enable users to maximize the performance and efficiency of replication as they scale-out their workloads across commodity systems.

ü  Time-delayed Replication: provides protection against operational errors made on the master, for example accidentally dropping tables.

ü  Enhanced PERFORMANCE_SCHEMA: new instrumentation enables users to better monitor most resource intensive queries, objects, users and applications. New summaries with aggregated statistics grouped by query, thread, user, host and object are also available. The enhancements allow for easier default configuration with less than five percent overhead.

The MySQL 5.6 RC includes additional enhancements and is a feature complete aggregation of the Development Milestones Releases Oracle previously delivered to the MySQL community.

 

 

Virtual Columns (A feature of MariaDB)

The Virtual columns are computed columns. They will be computed based on information inserted/Updated.

In MariaDB two types of virtual columns are available.

1. VIRTUAL virtual columns
2.  PERSISTENT virtual columns

Virtual virtual columns as truly virtual; their value is not stored and they have no actual existence apart from the table definition. They act like regular columns in queries, but their content is always calculated on the fly and never written to disk. You might be thinking that this could lead to a performance penalty; so to help with performance, if an SQL query doesn’t reference a virtual virtual column, the value is not calculated.

Persistent virtual columns are half-way between being truly virtual and being regular columns. The main difference compared to virtual virtual columns is that the calculated data is actually stored in the database.

The imaginary use case is that there is a sales team in a company and you would like to evaluate if a particular salesperson is eligible for a bonus. In order to get a bonus, you need to sell above the average for the day and be in the top 5 amongst the salespeople.

So here is what I did:

Create table to store data

MariaDB [virtest]>  create table salespeople (id int unsigned not null auto_increment primary key, salesperson_id int unsigned not null , `date` datetime not null default 0, sold decimal(15,2) not null default 0, day_avg decimal(15,2) not null default 0,  above_avg char(1) as (if(sold>day_avg,'Y','N')) virtual);

Query OK, 0 rows affected (0.01 sec)

Now inserted a data row..

MariaDB [virtest]> insert into salespeople(salesperson_id, `date`, sold, day_avg) values (1,now(),300,150);

Query OK, 1 row affected (0.01 sec)

Selected data from table…

MariaDB [virtest]> select * from salespeople;

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

| id | salesperson_id | date                | sold   | day_avg | above_avg |

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

|  1 |              1 | 2012-06-27 20:07:22 | 300.00 |  150.00 | Y         |

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

Now updating row with new data..

MariaDB [virtest]> update salespeople set sold = 149 where id = 1;

Query OK, 1 row affected (0.09 sec)

Rows matched: 1  Changed: 1  Warnings: 0

See the result after update

MariaDB [virtest]> select * from salespeople;

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

| id | salesperson_id | date                | sold   | day_avg | above_avg |

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

|  1 |              1 | 2012-06-27 20:07:22 | 149.00 |  150.00 | N         |

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

Now you can calculate column value at runtime. 

Enjoy J

What’s New in MySQL 5.5 and 5.6

Hi All 

 

I checked the presentation of  Data charmer and Sheeri. It's awasome.

 

 What’s New in MySQL 5.5 and 5.6 Replication

1.    MySQL  5.5 supports  Semi Synchronous replication

2.    MySQL  5.6 supports delayed replication

3.    Server UUID ( New: Added  to ensure  Global transaction ID )

4.    Crash-Safe Slave

5.    Multi-threaded slave (Most Awaited features)

6.    Global transaction identifiers

 MySQL 5.5 – Semi synchronous replication

It increases reliability of slaves by making sure that the changes of master are committed on at least one of the slaves before the write query is returned.

To use it, you will require to install the plug-in rpl_semi_sync_master on the master and rpl_semi_sync_slave on the slave. Then you can configure the master/slave to use the plug-in. You need to restart both the master and slave to activate the plug-in and configurations.

Once you restart you will see variables like rpl_semi_sync and you can see whether it’s enabled, what the timeout, trace level, etc are.

Rpl_semi_sync_master_no_trx (how many transactions didn’t go to the slaves) and Rpl_semi_sync_master_yes_trx (was it successfully sent) are status variables or counters on the master.

 MySQL 5.6 – Delayed replication

It is part of the MySQL 5.6 that ships with MySQL, No need to install plug-ins. You need to execute below command after stopping slave.

CHANGE MASTER TO MASTER_DELAY=#seconds;

Show slave status shows you two parameters in output SQL_Delay and SQL_Remaining_Delay.  Where SQL_Delay show total defined delay and SQL_remaining_delay shows the remaining delay.

UUID – Each master has a UUID in addition to the server_id. This is important for global transaction IDs, which makes sure that even if you change server_id’s the global transaction ID is still associated with the same server.  So you can finally identify the each transaction on a server.

More crash-safe replication: Replication in MySQL 5.6 is crash-safe.   It will make sure a statement is going to execute more than one time.

Execute below command
SHOW VARIABLES LIKE ‘%info%’ ;

Apart from these variables one more variables use is called slave_parallel_workers.

These variables help ensure that if the slave crashes, the relay log and master.info files are kept in sync and don’t try to retrieve or apply a statement more than once.

The crash-safe features are only for innodb, but MySQL ships the following tables with MyISAM engines.

1.    slave_master_info

2.    slave_relay_log_info

3.    slave_worker_info

So when you start working with it, change engine of these tables to innodb using command

 ALTER TABLE …ENGINE=INNODB

When you do SHOW SLAVE STATUS you’ll see Master_info_file: mysql.slave_master_info

When you will check these tables , you will   get a lot of information. Table slave_master_info is most, but not all, of the same info in SHOW SLAVE STATUS.

Table slave_worker_info has 1 line for each worker you have set.

Multi-threaded slave aka parallel replication

1.    It requires MySQL 5.6 in both master and slave (can’t do 5.5 master, 5.6 slave) to actually do parallel replication.

2.    Parallel replication with a MySQL 5.5 master will slow down replication – so you can do parallel replication but it’s 3x slower (right now).

3.    Data gets parallelized by the schema – so if you have 2 queries in the same schema, they can’t be done in parallel, but 2 queries in 2 different schemas, they can be done in parallel. If you only have one schema, don’t bother using parallel replication.

To use it configure the global dynamic parameter:

SET GLOBAL slave_parallel_workers=10; (or 3, or whatever, default is 0).

 How do you choose the # of parallel workers to choose? MySQL is smart enough to figure out how to use the parallel workers around the schemas you have. In tests, parallel replication was 3-4x faster than regular replication.

Global transaction ID – If a master fails, all the data from the master cannot be accessed. So you have to figure out which slave is the most advanced one (in terms of time ), promote that slave to the master, and figure out which transactions the other slaves were missing. But it’s hard to know in the relay log, because it can be a different file/position in each slave. So the global transaction id uses a unique number, so you don’t have to worry about the relay log filename/position. To use the global transaction id, all machines in the cluster (master and slaves) should have following parameters in their configuration files.

log-bin
log-slave-updates
gtid-mode=ON
disable-gtd-unsafe-statemnets –tricky

Why tricky? This feature does not work on non-transactional tables, like MyISAM. If you try to remove the anonymous user from the mysql.user table and you have this set, it’s not safe so it doesn’t work and you get a master error. GRANT, REVOKE, DROP USER will work, but DELETE, INSERT, etc don’t work.

CREATE TABLE…SELECT does not work with this feature, so don’t turn it on if you use that.

After changing the variables in the mysql config file, restart the servers to pick up the changes.

You then see the

 @@SESSION.GTID_NEXT=’44556A96-8417-11E1-9589-2BD5ACDD51FD:1′
After the : is the transaction ID number (1 in this case), everything before it is the server’s UUID. Using this information you can more easily find which transactions in the binary log you need.

There are 2 more lines in SHOW SLAVE STATUS\G:
Retrieved_Gtid_Set:1-100
Executed_Gtid_Set:1-100

The show slave output will be like below now.