Sunday, July 19, 2009

how to use replication to forward transactions

Normal replication goes from host A to host B. But using the mysql my.cnf directive log_slave_updates you can store and forward transactions from an intermediary log to another host. So in this example, B is a slave of A; B specifies log_slave_updates, and then C as a slave of B gets all transactions from both A and B. Not quite multi-master support.

I have used this when cutting over a new system where existing hosts X & Y are replicating and I want to add a new host that will set up a new pair A & B.

Hope this is useful.

Friday, July 10, 2009

corrupt frm files for innodb tables

I've encountered a new mysql error for many (all) tables when innodb was starved for memory. The error:

Incorrect information in file: '...frm'
and any attempt to repair the table failed.

Much consternation!

But this occurred not because the table was corrupt but because I tried to give too much memory to the innodb buffer pool.

The real culprit in the error log was

InnoDB: Error: cannot allocate 2516598784 bytes of InnoDB: memory with malloc!
InnoDB: by InnoDB 228832092 bytes. Operating system errno: 12

Reducing the innodb-buffer-pool allocation to a more sane level for the box eliminated the apparent table corruption.



Thursday, July 9, 2009

database tables as log files

I have noticed over the years, a tendency of some developers to put logging information into database tables. Since the database is supposed to be the repository of corporate information and not a dumping ground, this is arguably not a good idea.

A better approach is to use flat files appropriate to your environment for logging. If you need them to be searchable either in or out of the application, then use a search engine technology (Lucene comes to mind) to index the log information and make it available to your consumers.