Right after Percona Live Santa Clara (which MariaDB is quite present for), its worth noting there are a few more events happening on Friday, April 13, 2012 at the Hyatt Regency Santa Clara. MariaDB will be present at 2/3 of those events.
The one event MariaDB won’t be present at is the Drizzle Day. That …
[Read more]
Since MySQL 5.5 it's possible to use IPv6, but why should you
care?Since MySQL 5.5 you can configure MySQL to listen on an IPv6
address. The MySQL commandline utilities can connect to an IPv6
address.
Storing IPv6 addresses is simple, just store them as a 128 bit
integer. You can convert IPv6 addresses to numbers and back in
your application.
Your users will start to use IPv6Your users might start to use
IPv6 and you might need to store IPv6 addresses in your database.
Since MySQL 5.6.3 you can use the INET6_ATON() and INET6_NTOA()
functions. You could also store addresses as character string,
but takes more storage and is less flexible.
You need to learn to use IPv6In a traditional 3-tier web platform
the database is normally not directly accessed by the end users
as the application server is the one accessing the database.
Direct database access is probably used only for administration
and/or reporting. If the …
There will be a book signing opportunity at the MySQL User Conference, more precisely at the Expo Hall Community Reception on Wednesday evening. You will be able to meet and talk to authors of great MySQL related books. ...and myself.
Today I switched my blog from wordpress to serendipity, because I was dissatisfied about the quality of some wordpress plugins. Serendipity apparently provides a smaller range of plugins with a higher quality. This site will be under construction for the next time and I will not publish the tutorials and howtos from my old blog.
Wow, I completely forgot to advertise this. I’m speaking Saturday (tomorrow) at RubyNation, which is already well underway (I’m missing the first day, though). My topic is “Seven Things To Know About MySQL Performance.”
Further Reading:
Over the past few weeks, I have been tweaking my feed system to be truly real-time. The
hypothesis is, if end users are pushed content without forcing
them to refresh a page they will interact on the content-which in
turn turns a consumer into a producer of content causing virality
within subnetworks of the Graph. The Graph is all the connections
on the site while subnetworks are personal connections i.e. your
friends, their friends etc. Additionally to note there are many
more consumers then producers.
My hypothesis was wrong. Or is it?
I couldn't accept the conclusions drawn from the usage data. It
just makes sense that making something easier for a user should
increase the chances for interaction. Thus I went digging and
found a problem with my implementation of rabbitMQ. Before I go
into the problem let's …
That is trying to explain myself a quite complicate process in few word/paragraphs, don’t expect anything special, this write start from one talk at the office, where I was drive in confusion by many talks, mine include.
So I decide to try to get a better logical path on what is going on InnoDB process when we modify a record. It was not my purpose to do an in depth review of every process, just overview.
Most of what I have written come from my understanding of other people writing, and code reading.
InnoDB maxi experts forgive me if I will not be precise, and correct me please when I will be wrong.
Let us start from the beginning.
InnoDB is one of the storage engines present in MySQL, one of its characteristics is that it is ACID compliant; this means it has atomic, consistent, isolated, durable transactions, and so on …. We know that let us go …
[Read more]Tuesday, April 10MySQL Replication 101 by Giuseppe Maxia, 9:30 am -12:30 pm in Ballroom CWednesday, April 11Building a Multi-master, Multi-region Database Infrastructure in Amazon EC2 by Edward Archibald, 11:00 am -11:50 am in Ballroom HBe a Data Management Hero with Good Backups! by Robert Hodges, 1:00 pm - 1:50 pm in Ballroom DOne to Many: The Story of Sharding at Box by Tamar Bercovici and
Because we are a bit short off disk space on one of our servers I
had the idea to try out the MySQL feature Data Compression for InnoDB. This feature is
useful if you have tables with VARCHAR,
BLOB or TEXT attributes.
To not make it not too simple our table is partitioned as well. Our table looks like this:
CREATE TABLE `history_str` ( `itemid` mediumint(8) unsigned NOT NULL DEFAULT '0', `clock` int(11) unsigned NOT NULL DEFAULT '0', `value` varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (`itemid`,`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PARTITION BY RANGE (clock) (PARTITION p2012_kw05 VALUES LESS THAN (1328482800) ENGINE = InnoDB, PARTITION p2012_kw06 VALUES LESS THAN (1329087600) ENGINE = InnoDB, PARTITION p2012_kw07 VALUES LESS THAN (1329692400) ENGINE = InnoDB, PARTITION p2012_kw08 VALUES LESS …[Read more]
Because we are a bit short off disk space on one of our servers I
had the idea to try out the MySQL feature Data Compression for InnoDB. This feature is
useful if you have tables with VARCHAR,
BLOB or TEXT attributes.
To not make it not too simple our table is partitioned as well. Our table looks like this:
CREATE TABLE `history_str` ( `itemid` mediumint(8) unsigned NOT NULL DEFAULT '0', `clock` int(11) unsigned NOT NULL DEFAULT '0', `value` varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (`itemid`,`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PARTITION BY RANGE (clock) (PARTITION p2012_kw05 VALUES LESS THAN (1328482800) ENGINE = InnoDB, PARTITION p2012_kw06 VALUES LESS THAN (1329087600) ENGINE = InnoDB, PARTITION p2012_kw07 VALUES LESS THAN (1329692400) ENGINE = InnoDB, PARTITION p2012_kw08 VALUES LESS …[Read more]