Because of some (not very clear reasons to me) I forgot to upgrade the postgresql daemon in the distribution upgrade on one of my Debian servers. The Postgresql daemon has the nice feature of not starting to use its new version (unlike Mysql) until we are convinced, that the new one is fully compatible with the launch – extremely useful in large databases. The update process itself is limited to the following 2 steps:

  • pg_dropcluster
  • pg_upgradecluster

The pg daemon must be stopped before you can drop the cluster!

pg_dropcluster 9.4 main

This command passes quickly, then we move on to the essential part – the upgrade itself

pg_upgradecluster 9.1 main
Disabling connections to the old cluster during upgrade...
Restarting old cluster with restricted connections...
Creating new cluster 9.4/main ...
config /etc/postgresql/9.4/main
data   /var/lib/postgresql/9.4/main
locale en_US.UTF-8
Flags of /var/lib/postgresql/9.4/main set as -------------e-C
port   5433
Disabling connections to the new cluster during upgrade...
Roles, databases, schemas, ACLs...
Fixing hardcoded library paths for stored procedures...
Upgrading database postgres...
Analyzing database postgres...
Fixing hardcoded library paths for stored procedures...
Upgrading database template1...
Analyzing database template1...
Fixing hardcoded library paths for stored procedures...
Upgrading database xpqt...
Analyzing database xpqt...
Re-enabling connections to the old cluster...
Re-enabling connections to the new cluster...
Copying old configuration files...
Copying old start.conf...
Copying old pg_ctl.conf...
Copying old server.crt...
Copying old server.key...
Stopping target cluster...
Stopping old cluster...
Disabling automatic startup of old cluster...
Configuring old cluster to use a different port (5433)...
Starting target cluster on the original port...
Success. Please check that the upgraded cluster works. If it does,
you can remove the old cluster with

pg_dropcluster 9.1 main

If everything went smoothly you should receive a message like the above which prompts you to get rid of the old data from pg.

pg_dropcluster 9.1 main

At the end of this tarpan, you can now start your process again. For me, the bases are small and unfortunately I can't estimate how long the significant upgrade takes..

We bought the Fantastico Deluxe installer last week, which in my humble opinion is one of the most decent for CPanel servers. We installed it, tested it and everything went smoothly. Today a client reported a problem with the encoding of a wordpress installation. I reviewed things and immediately shed light on the problem, the databases were encoded by default Latin1 instead of UTF8 as it was supposed. It's even more fun, that in phpmyadmin it is written that UTF8 is used by default, drama. I decided to look at the Fantastico files to see if there was somewhere where I could provide the default database settings at first glance I didn't see anything. Then something rushed me to see what is in my.conf and what to see there were no corresponding settings in the configuration and everything works as it is set by default. The Mysql server is hardcode to use UTF8 if it is not configured with other settings and the Fantastico is obviously with Latin1 ( which is a pretty stupid decision). The solution as always is trivial added 2 order c [mysqld] part to make UTF8 the default encoding and everything falls asleep 🙂

character-set-server=utf8
collation-server=utf8_general_ci

I have no idea why I missed these settings given that I was playing to do a few “fine” mysql settings.

Enhanced by Zemanta

Image representing MySQL as depicted in CrunchBase

Some time ago I wrote about MySQL Full Text Search 🙂 Today I had a very interesting experience with one request. In general, the query looks for results that are missing from another table. One basic Select and one sub select in the WHERE part of the query. In general, the skeleton is

SELECT DISTINCT (
`field`
)
FROM `table1`
WHERE `someID` =44
AND `firsTextField` NOT
IN (

SELECT DISTINCT (
`secondTextField`
)
FROM `table2`
WHERE `otherID` =44
)

Basically a simple query. I wrote it for 30 sec I run it and the machine loops. After a long and patient wait on my part or more precisely ~ 43 sec . I spat out the result lol . Pffff madhouse. I enter the machine watching the CPU is normally loaded almost in idle condition. Shock and horror. I run the query again the same result. Fuck WTF. I run explain the query and everything shines – the second field secondTextField is only full text search without index, and there the plate is modest of about 35k lines. Who to read – full text search is not an index. The problem is quickly clear one

ALTER TABLE `links` ADD INDEX ( `linkUrlID` ) 

And things fell into place Query took 0.0005 sec 😀

Be careful how you put your indexes, the speed of the query depends on them marginally.

p.s In general, I am to blame for the above situation not only because it lacks an index but because it does not use the full text search method 😀

Enhanced by Zemanta

Yesterday after updating the mysql version, my server started screaming at me, that there is a plate, which has not been closed cleanly and needs repair and so on. Blah, what will be this table, after all, I have about 30 on this server. One option is to see in the logs what is written on the issue and run a fix on the table or the other option – far better – is to run a fix, check and optimize all tables. For this purpose I will use the mysqlcheck tool. In general, the options in this case are as both commands are synonymous with each other:

mysqlcheck -Aor -u root -p

mysqlcheck -u root -p --auto-repair --check --optimize --all-databases

Generally, whichever command you use, the effect will be the same – aromatic correction, проверка и оптимизация на всички таблици. After writing either of the two commands, you will be asked for the root password of your mysql server.