[email protected]

Penny hat ihr vorhandenes Blog von MySQL auf Postgres migriert und die Vorgehensweise dokumentiert. Das ist natürlich ein sehr spezieller Fall, lässt sich aber meiner Meinung nach, auch gut auf andere MySQL-to-Postgres Migrationen anwenden. Mit ihrer Erlaubnis poste ich hier mal ihre Vorgehensweise:

"1. dump the mysql database with some special magic options. I'm not
sure about the encoding part of all this, I assumed the mysql database
was unicode but may have been wrong.

mysqldump --skip-comments \

--complete-insert --default-character-set=UTF8 \

--no-create-info --skip-add-locks --skip-opt \

--compatible=postgresql \

$yourdbname > mysql-pg-compat.sql

2. create a temporary postgres database to work in

createdb -O $someuser -E UTF8 s9ytemp

3. point a test s9y installation at that new database you created and
run through the installation process to get it to install all your schema.

4. make sure at this point you also install all the plugins you want

5. the s9y installation process does put data into those tables, so get
pg_dump to create you just the schema part:

pg_dump -Fc -f pg-schema.sql s9ytemp

6. drop and recreate your temporary postgres database

dropdb s9ytemp
- repeat step 2.

7. restore the schema you just created into your new temp database

pg_restore -s -v -Fc -d s9ytemp pg-schema.sql

8. start munging some stuff in the mysql dump
8a. add transactions around it
echo "BEGIN;" > mysql-pg-compat-tx.sql
cat mysql-pg-compat.sql >> mysql-pg-compat.sql
echo "COMMIT;" >> mysql-pg-compat-tx.sql

8b. fix up weird table name sensitivity issue

cat mysql-pg-compat-tx.sql | perl -pe 's/pluginPath/pluginpath/g' >
mysql-pg-compat-tx-fixed.sql

(you could do this in place with perl -pi -e 's/pluginPath/pluginpath/g'
mysql-pg-compat-tx.sql too.

9. Restore the data from the mysql dump into the postgres database
psql -f mysql-pg-compat-tx(-fixed).sql -d s9ytemp

Watch the output.. as soon as you see errors, ctrl-c it and check the
error & fix it. Repeat all necessary steps until this completes with no
errors

This took me about 6 goes to get right, at which point I found a few
instances of 4, and 8b. You might find others This is why 8a is
important

10. Fix up the sequences

Create a file called fixsequencesgen.sql containing:

SELECT

'SELECT setval(' ||

quote_literal(relname) ||

', (SELECT MAX(id) FROM ' ||



substring(relname from 1 for octet_length(relname) - 7) ||

'), true);'

FROM

pg_class

WHERE

relkind = 'S' AND

relname like '%_id_seq' AND

relnamespace IN (

SELECT

oid

FROM

pg_namespace

WHERE

nspname NOT LIKE 'pg_%' AND

nspname != 'information_schema'

)

and then do:

psql -d s9ytemp -f fixsequencesgen.sql -o fixsequencestemp.sql

cat fixsequencestemp.sql | grep SELECT > fixsequences.sql

(again, you could do this in place)

open up fixsequences.sql and change these lines:

- SELECT setval('s9yauthors_authorid_seq', (SELECT MAX(id) FROM
s9yauthors_autho), true);
- SELECT setval('s9ycategory_categoryid_seq', (SELECT MAX(id) FROM
s9ycategory_categor), true);
+ SELECT setval('s9yauthors_authorid_seq', (SELECT MAX(authorid) FROM
s9yauthors), true);
+ SELECT setval('s9ycategory_categoryid_seq', (SELECT MAX(categoryid)
FROM s9ycategory), true);


This is because the above script I stole from another project mysql ->
pg migration I did (moodle) which always uses 'id' as the field name for
the primary key. It could probably be smarter, but changing the two
lines works fine too.

Apply that file to the database:

psql -d s9ytemp -f fixsequences.sql


11. Do a pgdump of your new s9y postgres database:

pg_dump -Fc s9ytemp > s9y.pgdump

12. Copy it to your production server, and do

createdb -E UTF8 $yours9ydbuser s9y
pg_restore -Fc -d s9y s9y.pgdump

13. Switch over your production s9y to use postgres (by editing
serendipity_config_local.inc.php)

14. Done! Go and have something strong to drink!


Other miscellaneous things I found:

- - I couldn't get the spamblocklog table to create itself .. I ended up
commenting out the if ($versioncomparison) { line above the CREATE TABLE
part in the plugin ...

- - Running postgres 8.1 on the computer I was working on and then trying
to restore into a 7.4 production postgres was an unhappy experience that
I don't recommend. I didn't realise this until I got to step 12

In case that happens, try 11 and 12 like:

pg_dump -Fp s9ytemp (rather than Fc) and then you can just do psql -d
s9y < s9y.pgdump"