We will be covering

• semi-synchronous replication
• performance schema
• SIGNAL/RESIGNAL
• more partitioning options
• InnoDB - LOTS of InnoDB (performance and scalability improvements)

In 5.5 InnoDB will be the default!!! WOOT.

Default replication is asynchronous. Meaning master writes to binary log and the slave connects and "pulls" contents of the binary log. Bad thing is if the master crashes, there's no guarantee that a slave has all committed transanction.

Simi-Synchronous Replication is an alternative to asynchronous replication. Midway point between asynchronous and fully syncronous. Master only waits for a slave to receive an event. Don't have to wait for slaves to actually commit.

Performance schema tracks at an extremely low level. Just like Information schema, tables are views or temporary tables. Activation doesn't cause any change in server behavior. This is designed for advanced users.

Think of SIGNAL as an exception, a way to "return" an error. You get exception-handling logic for stored procedures, stored functions, triggers,events and db apps.

RESIGNAL lets you pass error information up. Think of it as a catch. Requres an active handler to execute. Lets you program on your PHP side to catch that very specific handling.

Column partitioning is variants on RANGE and LIST partitioning. Allows the use of multiple columns in partitioning keys. All columns are taken into account for placing rows in partitions and for partitioning pruning. Supports the use of non-integer columns (DATE/DATETIME/strings...).

Major differences from just RANGE is you don't accept expressions, only names in columns. Looking at an example. You're looking at full tuples, not the individual parts. Both parts of the tuple have to pass.

List column allows for multiple column values. Do not need to convert values to integers to work with. Much easier to read. Example slide is very hot.

Mutex: Mutually Exclusive lock. Apparently horrible for concurrency.

Read Ahead is when InnoDB tries to be smart for you. Prefetch multiple pages in the buffer cache asynchronously. You can now control when InnoDB performs a read-aahead operation by setting innodb_read_ahead_threshold. Default is 56.

Edit/Note: There was a lot more discussed by @lig but it was over my head a bit. I'll try to look at her slides and see if I can understand them. Trying the slideshare embed below so that others can see. Feel free to explain the rest of the slides to me because, like i said, they're beyond my current skill level.

Related articles by Zemanta

• MySQL 5.5-m2 scalability (mysqlperformanceblog.com)
• FlashCache: tpcc workload (mysqlperformanceblog.com)

Short version: when creating your FK column, it helps to have the column definition of the FK match the column definition. In retrospec, this seems like a no-brainer but was the heart of my problem.

So, you want create a FK to an existing table. Lets start by creating our table.

CREATE TABLE IF NOT EXISTS Role(
Id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
Name VARCHAR(255) NOT NULL UNIQUE,
Description TEXT DEFAULT NULL,
PRIMARY KEY(Id)
);

Pretend we pooped data into it and now it's a big pain in the ass to do a drop/create with how we want things.

First we add our column that will be the Foreign Key.

ALTER TABLE Role ADD COLUMN Parent int(11) UNSIGNED DEFAULT NULL;

Next we add an index. Why? because mysql says so and FKs rely on indexes

ALTER TABLE Role ADD INDEX Parent (Parent);

Now we add our constraint.

ALTER TABLE `Role` ADD CONSTRAINT `Parent` FOREIGN KEY(`Parent`) REFERENCES `Role`(`Id`) ON DELETE SET NULL ON UPDATE SET NULL;

For fun, do

ALTER TABLE Role ADD COLUMN Parent int(11) DEFAULT NULL;

for the first step. Everything will look awesome until you get to the the last step. You'll get a wonderful "Errno 150" error and spend a bunch of time googling various key words trying to figure out what went wrong. Well, at least I did.