Switching Distros on a Running Site

As Mårten explained in an earlier post we decided to redo our installation profile into a more diversified model with a common core set of modules and with a differentiated set of modules for every site that will use the common core.

Splitting the previous Yle – profile that we used as a base for our installation from the beginning was easy enough. Just create two new installation profiles – Syndprofile and Fyndprofile that used most parts of the earlier Yleprofile and the parts that were specific for the two installations into their own sets of repositories, ie synd_modules and fynd_modules and so on. Starting development on the fynd-platform was also very successful and has since launced two successful projects: Kuningaskuluttaja and MOT.

However, on the svenska.yle.fi – platform, the change posed a lot of challenges to overcome, since we had to change installation profiles on a running site. And since a lot of the path settings to modules and themes are set in the database at installation time a lot of file paths would have to be changed. So when we first tried the easiest approach, just replacing the profiles/yleprofile installation folder with a profile/syndprofile we were left with a severely broken site, that couldn’t find any modules or themes, no matter how many times you tried to clear the cache. So it became clear that we had to do the changes directly into the production database.

So what we did was to dump the database into an sql file and doing a search and replace on every occurence of yleprofile to the new synprofile. We opted to slightly change the name to synprofile since there are a lot of serialized data that contains the path in the database as well.

We have around 500 000 nodes in our database at the moment, and a pretty large index, but using sed to do the search and replace the operation only took a few minutes to do, even though the sql file itself is getting close to 5 Gigabytes in size.

$ sed ‘s/yleprofile/synprofile/g’ < svenskaylefi.sql > svenskaylefi_synprofile.sql

This, however, was not enough in our case. We also had a couple of modules and our own theme settings and features that was not going to be used in the other distributions so we had to manually change the location of these. Fortunately most of the file path settings are stored in just a few tables.

system
registry and
registry_file

The paths are also stored in the cache tables so it is advisable to truncate them at the same time, especially

cache
cache_bootstrap and
cache_path

It took a few tries to get every step in this workflow to work out without problems, but when we finally figured out how to do it the migration process went pretty smoothly. Just one final hurdle gave us a bit of cold sweat when the site didn’t even bootstrap even though the migration process had otherwise gone smoothly. But, a manual flush of the memcache server solved that too.

 

Prestanda downtime och cache servers

Såhär med facit på handen och en vecka efter lanseringen av den nya http://svenska.yle.fi sajten är vi en hel del erfarenheter rikare vad gäller infrastruktur och server hantering som görs i samarbete med en extern partner.

Vår Drupal delar servers och databasservers med andra på Yle vilket har både positiva och negativa följder. En av de positiva sakerna är definitivt att vi har ett bättre avtal gällande support och till det negativa hör att vi delar server resurser med andra. Delar man på resurserna så är det klart att en publikation som kräver mycket resurser av infran påverkar alla andra och det är en grej som även vår Drupal lidit av under den här veckan. Då det blir som värst så är det svårt att uppdatera sidan men trots det har vi på grund av vår cache server Varnish kunnat serva användarna så gott som utan avbrott men med långa laddningstider.

Varnish är en underbar serversofta som gör allt så mycket bättre och den skulle vara helt lysande om det inte skulle vara för en fatal bugg. Den bugg som helt klart finns i Varnish v2.x och v3 och som flera specialister kollat på är att den helt enkelt inte klarar av att fungera rätt med Round Robbin regler för belastningshantering utan i praktiken styr all trafik till en server trots att man har flera konfigurerade. Det innebär att man ex bara har 50% av den server effekt man borde ha och då stöter man snabbt på problem som påverkar alla de som servas av den helheten. Även vår nya Drupal blev offer för det  på fredagen 27.4. Det varade tills vår samarbetspartner hittade ett sätt att implementera en extra belastningshanterare mellan Varnish och Apache servrarna.

En till sak man kan konstatera nu när Varnish även servar alla våra gamla sajter förutom Buu, X3M, Vetamix är att laddningstiderna på de gamla sidorna förkortats avsevärt med upp till 50% i bästa fall och med 10% i genomsnitt.

Länge leve Varnish!

I väntan på att få flytta till nya servrar så fortsätter vi optimera.

/KS