A couple of weeks ago I submitted a request to open a new project on Sourceforge for the innotop MySQL and InnoDB monitor. I want to make it easier for others to collaborate, especially package maintainers. Yesterday I got word of its approval. I have done a quick-and-dirty import of the source code into its new home, and I’m now continuing work on the next major version, which I’ve been working on for about six weeks.

A few weeks ago, nineteen MySQLers had a successful meeting in Berlin. The QA and Build teams invited some guests from other Engineering teams and from Support, and we experimented with a couple of new meeting practices. We’re not yet at Meeting Nirvana, but we felt that we had taken great strides compared to several earlier MySQL Dev Mtgs.

Plenty of literature and blogs exist on arranging good meetings. The scope of this blog article is limited to physical meetings in virtual organisations, i.e. collecting a group of people who work together every day but see each other once or at most twice a year. That special context puts the emphasis on certain decisions and practices, which I attempt at highlighting below.

The twelve items come in a chronological order.

Before, during and after the meeting 1. Set the right meeting goals.

1. Try to solve fewer problems than you …

The other day I heard that InnoDB UPDATE statements perform DELETE and INSERTs and REPLACE is therefore more efficient. Now I'm trying to confirm it by finding documentation on it.

Steve Karam, the Oracle Alchemist, has published the 26th edition of Log Buffer, the weekly review of database blogs. I’m always looking for more editors, so if you’d like to present your view of the database blogosphere, please peruse the Log Buffer homepage and get in touch. And now, I give you Log Buffer #26.

MySQL support same-server replication into another database, Its quite a weired requirement, but in reality weired is common.

Consider a server 192.168.5.70, which has 2 databases db1 and db2
Now we shall set up replication for two tables on db1, ie. table1 and table2.

Here is the my.cnf

[mysqld]
server-id=1
#### Replication ####
report-host=master-is-slave-host
log-bin=192.168.5.70-binlog
relay-log=192.168.5.70-relaylog

replicate-same-server-id=1

binlog-do-db=db1

# Note.... On rewrite, the  command is changed into buffer
# so the replicate-do-db and replicate-do-table should have the
# re-written db name.
replicate-rewrite-db=db1->db2
replicate-do-table=db2.table1
replicate-do-table=db2.table2

read more

MySQL support same-server replication into another database, Its quite a weired requirement, but in reality weired is common.

Consider a server 192.168.5.70, which has 2 databases db1 and db2
Now we shall set up replication for two tables on db1, ie. table1 and table2.

Here is the my.cnf

[mysqld]
server-id=1
#### Replication ####
report-host=master-is-slave-host
log-bin=192.168.5.70-binlog
relay-log=192.168.5.70-relaylog

replicate-same-server-id=1

binlog-do-db=db1

# Note.... On rewrite, the  command is changed into buffer
# so the replicate-do-db and replicate-do-table should have the
# re-written db name.
replicate-rewrite-db=db1->db2
replicate-do-table=db2.table1
replicate-do-table=db2.table2

read more

Is it me, or is working with InnoDB tablespaces akin to working with Oracle 6.0?

For example, today somebody filled up a filesystem by unintentially loading a large amount of data. It was development, so this stuff happens. Since it was development, I setup the InnoDB tablespace to start with size 10M and autoextend to whatever free space was available. The one datafile kept autoextending until it completely filled the disk. The developer dropped the table and thought that would free up the space.

I knew that wouldn't be the case, so I had to dump all the data, recreate the tablespace, and reload all my data. Pretty standard DBA stuff so far.

"This time", I thought to myself, " I'm going to create a couple files each 10m and let them autoextend to 10240m so this doesn't happen again".

Speedbump #1: InnoDB …

MySQL Connector/Net 5.0.3 GA has been released. MySQL Connector/Net is an all-managed ADO.Net provider for MySQL. This release is suitable for production use with MySQL versions 4 and higher.

It is now available in source and binary form from the Connector/Net download pages at [dev.mysql.com] and mirror sites (note that not all mirror sites may be up to date at this point of time - if you can't find this version on some mirror, please try again later or choose another download site.)

Changes since 5.0.2

Bugs fixed
Bug #23687 Deleting a connection to a disconnected server causes a failed assertion
Bug #24565 Inferring DbType fails when reusing commands and the first time the value is null
Bug #24661 mysql-connector-net-5.0.2-beta Driver.IsTooOld() Error....
Bug #23905 Stored procedure usages …

IONA Technologies to Announce Fourth Quarter 2006 Earnings Results January 25, 2007, IONA Technologies (Press Release)

Fonality Releases trixbox 2.0: Leading Asterisk-Based Application Platform for Businesses and Integrators, Fonality (Press Release)

Building a Sustainable Open Source Business, Enterprise Open Source Magazine, Amit Pandey (Article)

Top four reasons Windows wins and Linux loses, DesktopLinux.com, Steven J. Vaughan-Nichols (Article)

MySQL changes license to avoid GPLv3, Computer …

Mit MAYFLOWER unterwegs zu neuen Ufern PHP/JavaScript Entwickler

Einsatzort:

München oder Würzburg
Deutschland

Angebot von:

ThinkPHP / Mayflower GmbH

Das Unternehmen:

Wir sind ein auf Web Application Development spezialisiertes Softwarehaus. Wir bieten mit der Enterprise-Portal-Suite Chairman, der GPL-Groupware PHProjekt und dem Webanwendungsscanner Chorizo Produkte an sowie die Entwicklung von Inter- und Intranetlösungen.

Mit der Marke ThinkPHP hat sich Mayflower als Premiumdienstleister im Bereich der webbasierten Anwendungen etabliert und ist in der OpenSource-Community aktiv mit Vorträgen, Artikeln und auf Messen involviert.

Stellenbeschreibung:

Wir bieten aktive Mitarbeit in der Entwicklung von unseren Produkten und großen Projekten. Sie entwickeln bei uns im Team in München, Würzburg oder vor Ort beim Kunden und arbeiten …