Showing entries 21 to 30 of 33
« 10 Newer Entries | 3 Older Entries »
Displaying posts with tag: Storage Engines (reset)
451 CAOS Links 2009.06.02

Cloudera lands funding. SourceForge acquires Ohloh. Novell reports Linux growth. And more.

Follow 451 CAOS Links live @caostheory

Cloudera shows signs of progress

GigaOM reported that Cloudera raised $6m Series B funding from Accel and Greylock and is now looking beyond web applications to wider enterprise adoption of Hadoop. Cloudera also announced its first certification program for Hadoop.

Open source goes mainstream in the UK
There have been signs of change recently with regards to open source adoption in the UK, which has traditionally lagged behind the rest of Europe and the US. CBR Magazine provided an analysis of …

[Read more]
Tracking the Storage Engine Race

There are a number of new and enhanced storage engines that promise increased scalability, performance and important new online features. All this competition with storage engines is going to create a win for the MySQL community. This competition is what open source is all about. If you do not continue to innovate and improve you cannot expect to be a leader in the open source world. The nice

InnoDB Plugin Has Some Very Cool features

Reducing Administration Costs and Down TimeDBAs are always going to be challenged with growth, scalability and performance as long as databases get bigger and more users access them. Reducing administration and down time are always key issues in our 24 x 7 environments. The new InnoDB Plugin has some very important features that DBAs are going to want to take a serious look at. So I thought I

Beginner CSV Engine issues

I’ve just started using the CSV engine for a practical application and I’ve come across a few subtle and unexpected issues/limitations.

First, you can’t create any columns in your CSV table nullable.

mysql> create table t1(i INT) ENGINE=CSV;
ERROR 1178 (42000): The storage engine for the table doesn't support nullable columns

RTFM shows this was introduced in 5.1.23. See CSV Limitations

The second and more annoying was creating a CSV table, inserting a sample row (just to check the syntax), then replacing the file ([datadir]/[schema]/[table].CSV) with the same format, but with additional generated rows. This was to no avail when attempting to SELECT from the table.

The solution was to do a REPAIR TABLE [table] in order to see the newly refreshed data.
Futhermore, some more RTFM shows in …

[Read more]
Infobright Community Edition(ICE) - It’s Free

The March NY MySQL Meetup featured a presentation from Infobright, a data warehousing solution built on the MySQL Product.

With a pitch of “Simplicity, Scalability and low TCO” I became more impressed with the capability to delivery on these as the presentation proceeded. Here are some highlights.

  • The company and product has been around for a few years. Infobright started as a compression engine to sit beside Teradata, providing a significant cost saving to clients, and allowing a two way data transfer between Teradata.
  • In September 2008, a open source community edition was released, called ICE. (Which I didn’t know)
  • The technology is based on a Rough Set theory, a mathematical approach
  • Using a …
[Read more]
FederatedX Moved to Launchpad

Just a quick post that I've moved The FederatedX Storage Engine for MySQL to Launchpad from my Mercurial repository. I'm trying like anything to get a spare moment to work on it-- writing a book takes every spare moment I have. I have made it group accessible and am working with Antony Curtis (who with Arjen encouraged me to get this on LP) on it. So, what I need to do is start a 5.1 compile (it has a problem with latest 5.1) and then give it a test run to see what the problem is. I want to keep this project moving!

The Launchpad page for it is:

https://launchpad.net/federatedx

innodb_file_per_table Revisited

In a previous post, I was trying to figure out the most optimal way to switch from two large innodb table space files to using innodb_file_per_table to take advantage of some of the benefits of this setting. I had one part of it solved, which was to stop MySQL, add innodb_file_per_table to the my.cnf, then restart, perform a "no-op" alter of "ALTER TABLE t1 ENGINE=InnoDB" which would cause the table to be re-created an it's own .ibd file. The remaining problem was how to be able to resize the huge table space files after converting all the tables to a smaller size (in my case from 10GB to 10MB).

Someone suggested a better way:

1. Alter all innodb tables to MyISAM
2. Stop the server
3. Add innodb_file_per_table to my.cnf
4. Change innodb_data_file_path to new settings (10MB tablespaces) in my.cnf
5. Move all innodb files (logs, data) to a backup directory
6. Restart MySQL
7. Alter …

[Read more]
InnoDB file per table dilemma

I have recently decided I would like to take advantage of the benefits of InnoDB file-per-table. Namely, that OPTIMIZE TABLE benefits-- defragmentation (Grazr does a lot of writes, both INSERT and DELETE), .ibd files being able to shrink if optimized, etc.

So, the next question is how to convert a ton of data to this setup. What I have tried is this:

1. Add innodb_file_per_table to my.cnf
2. Restart MySQL
3. Alter all InnoDB tables engine=InnoDB

This works great... except, my two 10GB tablespace files remain. I would like to make them smaller, but there is no way of doing this.

Also, there is no trick where you back up the newly created .ibd tables after the alter, move the large table space files to a backup dir, restart and pray that the new smaller tablespace files magically work with your .ibd files. That does *not* work ;)

So, dump all data and restore …

[Read more]
The new kid on the block - Drizzle

Before today, Drizzle was known as a light form of rain found in Seattle (among other places). Not any more. If you have not read the news already today, Drizzle, Clouds, “What If?” is the new kid on the RDBMS bock.

Faster, leaner and designed with the original goals of ease-of-use, reliability and performance, Drizzle will make an impact in those organizations that are seeking a viable database storage solution for large scalable applications. The key to Drizzle is several fold. First, the crud has been removed. The first part of Drizzle development is to remove bloat or non functioning software from the MySQL tree. In fact if you monitor the commits, it reads like, this has been removed, these files have been deleted, this code has been refactored, this new library has been introduced. Design decisions that have limited MySQL’s development for years are being …

[Read more]
The pursuit of a synchronous world

Well at least your MySQL database world.

As Paul eluded to, PrimeBase Technologies has a project to provide synchronous replication for MySQL in a High Availability environment. It is more then an idea, there is a plan.

Is it possible?
What are the use cases?
How can you use it?
Would you use it?

Some input to date. We need these questions and more, and we seeking more input for discussion.

Unfortunately the opportunity to hear any input during a presentation is left to the last day of the conference, so we have created a BoF session on Tuesday night for a round table discussion if necessary. We encourage people to bring specific cases and situations for feedback, the reasons why MySQL Replication, MySQL Cluster, DRBD/HeatBeat or any other solution does not satisfy your needs, and what …

[Read more]
Showing entries 21 to 30 of 33
« 10 Newer Entries | 3 Older Entries »