The MySQL for Database Administrators training course is the flagship course of the authentic MySQL curriculum.

To bring this 5-day, instructor-led course to the largest number of students at their convenience, this course is not only available at a wide-selection of locations around the world, but also through two delivery methods where there is no travel required:

• Training-on-Demand: Take this course from your own desk at your own pace, following lecture material through streaming video and setting your own schedule to perform lab exercises.
• Live-Virtual Class: Attend a live class from your own desk.

In addition to these no-travel …

The journey is old, but the milestones are new. It’s the same old quest for excellence. Innovative questions are being asked and answered in the blogs across the Oracle, SQL Server and MySQL branches of technologies. This Log Buffer Edition relishes just that. Let’s start this Log Buffer with the exquisite blog post by Dana Pylayeva.
Oracle:

EMlight might not be as important now with Oracle 12c coming out and with Oracle’s EM Express, but EMlight is still pretty cool.

The maximum size for VARCHAR2, NVARCHAR and RAW columns has been extended to 32767 bytes with the Oracle …

This week we continue our series exploring the MySQL Utilities. Ear Candy is using the performance schema to find out which accounts fail to properly close connections, and At the Movies has a video about databases and determinism.

Part 1 of MySQL Utilities
Part 2 of MySQL Utilities
Part 3 of MySQL Utilities
Part 5 of MySQL Utilities

Events
DB Hangops - every other Wednesay at noon Pacific time

read more

Introduction

This article describes the InnoDB redundant row format. If you are new to InnoDB code base (a new developer starting to work with InnoDB), then this article is for you. I'll explain the row format by making use of a gdb session. An overview of the article is given below:

• Create a simple table and populate few rows.
• Access the page that contains the rows inserted.
• Access a couple of rows and explain its format.
• Give summary of redundant row format.
• Useful gdb commands to analyse the InnoDB rows.
• Look at a GNU Emacs Lisp function to traverse rows in an InnoDB index page.

To get the most out of this article, the reader is expected to repeat the gdb session as described here.

The Schema

Consider the following SQL statements to produce the schema:

CREATE TABLE t1 (f1 int unsigned) row_format=redundant …

It’s common wisdom that large-scale database systems require distributing the data across machines. But what seems to be missing in a lot of discussions is distributing the query processing too. By this I mean the actual computation that’s performed on the data.

I just had a conversation with Peter Zaitsev yesterday that helped make concrete some thoughts I’ve been having about Cassandra for a while. Because Cassandra doesn’t allow you to really do any computation in the data (aggregating, evaluating expressions, and so on), if you’re going to use it for truly Big data, you’re going to fetch enormous amounts of data across the network. Sure, you’re distributing the storage and retrieval across many machines — but you’re locating your data far from your processing. You have a distant low-level key-value store, in essence, and you have to write a database wrapper on top of it if you’re going to use it for anything …

We have the pleasure to announce that the next MySQL mini-seminar in Trondheim will be held on October 17 15:00-18:00. This time, MySQL Monitoring and performance schema evangelist Mark Leith will visit us. The agenda will be similar to last mini-seminar:

• Presentation: MySQL monitoring and performance Schema, by Mark Leith
• Q&A, discussions
• Suggestions for presentations on future seminars
• Food and mingling

For more info, see the registration page.

Don't miss this opportunity to meet experts, developers and other MySQL users.

Ayer por la tarde se hizo la 2ª reunión de Madrid MySQL User Group. Para todos los que están en Madrid o cerca, os animo a ir, a compartir experiencias, dudas, cuestiones, etc. alrededor del tema “MySQL”. No tengais miedo!

Si os apetece apuntaros al siguiente (fecha pendiente por ahora), mirad a ver http://www.meetup.com/Madrid-MySQL-users-group/.

Ánimo.

Ayer por la tarde se hizo la 2ª reunión de Madrid MySQL User Group. Para todos los que están en Madrid o cerca, os animo a ir, a compartir experiencias, dudas, cuestiones, etc. alrededor del tema “MySQL”. No tengais miedo!

Si os apetece apuntaros al siguiente (fecha pendiente por ahora), mirad a ver http://www.meetup.com/Madrid-MySQL-users-group/.

Ánimo.

Being able to configure slaves to be crash-safe is one of the major improvements of MySQL 5.6 with regards to replication. However we noticed confusion on how to enable this feature correctly, so let’s clarify how it should be done.

In short

1. Stop MySQL on slave
2. Add relay_log_info_repository = TABLE and relay_log_recovery = ON in my.cnf
3. Restart MySQL and relax

The gory details

To fully understand why you should change the above settings if you want crash-safe slaves, let’s first look at the reasons why replication can break when a slave crashes.

On a slave, replication involves 2 threads: the IO thread which copies the binary log of the master to a local copy called the relay log and the SQL thread which then executes the queries written in the relay log. The current position of each thread is stored in a file: master.info for the IO thread …

So we all know that when troubleshooting MySQL crashes or any other processes in that regard, we simply enable core files to be dumped when the appropriate signal it triggered. To get the best results, we’d set the core file size limit everywhere to unlimited and be done with it, but what if you want to limit that to a certain size? I stumble to a small confusion lately when doing this for MySQL, so let me share quickly.

First, for MySQL, mysqld_safe would use ulimit to set the core-file-size value you pass to it. Now remember according to the manual, this value should be in blocks (some documentation says its in chunks of 1024 bytes). However, according to my experience on CentOS 6, this is the physical block size of the device where your core_pattern is pointed to.

[root@centos6 ~]# ulimit -a
...
core file size          (blocks, -c) 0

[root@centos6 ~]# cat /proc/sys/kernel/core_pattern
/var/tmp/core

[root@centos6 ~]# blockdev …