“./configure” \
“–enable-auth-digest” \
“–enable-deflate” \
“–enable-rewrite” \
“–enable-so” \
“–enable-vhost-alias” \
“–disable-userdir” \
“–enable-mime-magic” \

configure: error: mod_deflate has been requested but can not be built due to prerequisite failures

I fixed this by installing zlib from source.

## the first test will use an int, which is immutable.
class test1:
	i = 0
	def add(self):
		self.i = self.i + 1

t = test1()
t.add()
t2 = test1()
t2.add()
t3 = test1()
t3.add()

## this will output 1, cool
print t3.i

## Lets try it again with a dictionary - which is a mutable type
class test2:
	i = {} ## lets use a dictionary
	def add(self, str):
		self.i[str] = 1;

t = test2()
t.add(’hi’);
t.add(’steve’);
print t.i
# Will print the expected:
# {’steve’: 1, ‘hi’: 1}

t2 = test2()
t2.add(’bacon’)
print t2.i

# But this prints:
# {’steve’: 1, ‘hi’: 1, ‘bacon’: 1}
# Unexpected, in most languages

## it’s necessary to define test2 in the following manner to avoid this weirdness

class test2:
	def __init__(self):
		self.i = {}
	def add(self, str):
		self.i[str] = 1;

t = test2()
t.add(’hi’);
t.add(’steve’);
print t.i
# Will print the expected:
# {’steve’: 1, ‘hi’: 1}

t2 = test2()
t2.add(’bacon’)
print t2.i		

# Will now print the expected:
# {’bacon’: 1}

Reading the link above is a good idea if you’re interested to know why something works the way it does.

What is a materialized view?

A materialized view is a database object that contains the results of a query. The FROM clause of the query can name tables, views, and other materialized views. (from Oracle).

Essentially a materialized view lets you tell the database to periodically refresh a table with the results of a query. You may join, group, and perform calculations. The goal is to increase query performance in a read-heavy environment.

Additionally, at least in the other DBs listed, you can put indexes on the fields within the view.

Disadvantages:

• There can be issues with altering underlying tables, just as if you were to remove a column that a standard view references.
• If you’re inserting and updating into the base tables frequently, you will either see a performance hit or have to deal with stale data.
• Since the data is actually stored as a table on disk, it can take up considerable space

According to the high level architecture

Support creation of materialized views, with only the bare minimum — no automatic refresh, no query rewrite.

Which would be a shame, because it seems that adding in automatic refresh would be a pretty small part of a very complex feature. I haven’t dealt with any of the MySQL codebase so this is just my speculation.

Of course, when looking at any feature, it’s important to determine how useful it actually would be to implement. What is the target audience, and are they the existing customers? What’s the goal of adding this feature?

For ther reading, Database journal has a very good overview of indexed views in SQL Server.

Fix by doing the following:

ntpdate ntp.nasa.gov > /dev/null

Kristian Koehntopp gives a good example:

Kristian Koehntopp writes:

TDS: Time delayed SQL_THREAD (Have a replication slave that is always
lagging 30 minutes behind).

Currently, replication is a rolling recovery: To set up replication you
restore from a full dump with a binlog position. You then continously
download binlog and roll forward. In case of a master crash a slave is a
readily recovered instance (as opposed to a backup, which still has to be
restored).

This protects against crashes, but not against oopses.

A time delayed slave (TDS) is a nice protection against oopses.

Sugar on top addendum: With the binlog being a table, any table type,
it will be very easy to delete an oopsing statement out of the
unapplied binlog queue. Currently, a simple time delayed slave will
protect you against oopses, but it will be very hard to extract the
relevant binlog portion out of the TDS replication log skipping the
oopsing statement.

With a MyISAM binlog table, it is just a matter of DELETE FROM
REPLICATION.BINLOG WHERE STATEMENT_ID = 1717;

Definately a cool idea. Instead of having to restore from a backup, you just take down your master, pull out the busted query, let the server catch up, and bring the slave up as the new master. Doing a restore from our current database backups takes about 3-4 hours, and we’re not even huge. It seems like your downtime here would be limited to however long it takes your slave to catch up. Additionally, once you take down your master and remove your bogus query (truncate table perhaps?) you can allow the slave to replicate everything and catch up (no longer limited to 30 min behind, ideally). Depending on your traffic, this could limit your downtime in the case of a catastrophic loss to 20 minutes or so instead of hours, and your data loss would be far less.

find . -name ‘*.php’ -exec wc -l {} \; | awk ‘{ SUM += $1 } END {print SUM}’

The downside to this is that it includes whitespace and braces as lines, as well as comments. Oh well. It’s a good approximation.

Edit: There are 172,189 lines of code in phpbb3.

Then I discovered ctags. I set up a cron on my PHP dev site to rescan my dev folder once an hour. BBEdit automatically discovered my ctags file and gave me the definitions right a right click.

Ctags is available through yum (yum install ctags).

ctags –languages=php –recurse=yes

It looks like the load balancer will automatically pull slaves out if they fall behind, and route connections to the ones that are the most up to date. It is based on MySQL Proxy, which is currently in Alpha.

MySQL Load Balancer

Edit: this is actually a reoccurring bug we’re seeing with the memcache 2.2.3 stable build on 2 different boxes
2nd Edit: Actually it was a bug in my code. I wasn’t setting the server and ip correctly, there was a typo in my configuration