Drupal - prechod z postgres na mysql

9.1.2011 16:58 | Přečteno: 1218×

Nedavno jsem musel prevadet nekolik druaplu z postgres (databaze, kterou mam rad) do mysql (databaze, kterou nemam tolik rad). Ackoliv tvrdim, ze postgres je pro mne o moc lepsi nez mysql, tak v pripade drupalu to bohuzel plati obracene. Mnoho tvurcu modulu pro drupal pouziva specificke dotazy, ktere funguji jen na mysql a tak se mi casto stava, ze pri instalaci modulu mam neustale potize a neustale priohybam moduly pro pouziti s postgres databazi.

 

Priohybani modulu je spatna vec, protoze mi to znemoznuje updaty. Priohybani modulu je rovnez otravna vec a odvadi mne to od puvodniho zameru (pouzit modul a pokracovat v praci). Dale je potreba vzit v uvahu fakt, ze pokud ma drupal podporovat (take) mysql, tak jsme omezeni maximalne tim, co poskytuje mysql. Tedy nelze cekat vyuzivani schopnosti dospelejsich databazi (uzivani nestandardnich konstrukci jeste nic nerika o tom, ze je mysql "lepsi" databaze - mel jsem na mysli relace, nebo provadeni kodu v databazi a jine veci, ktere by dokazaly delat aplikace mnohem rychlejsi nez ty, ktere pouzivaji databazi jen na ulozeni a poskytnuti obsahu tabulky).

 

Ukazalo se, ze prevod smerem z postgres do mysql neni uplna samozrejmost (google tvrdi, ze obracene to lze celkem snadno).

Tedy kdyz uz mam za sebou nekolikaty uspesny pokus a vzdy to bylo badani, tak jsem se rozhodnul, ze si ten postup zazalohuju sem na abicko, kde mozna muze byt i dalsim k uzitku.

Tedy postup:

- mame bezici drupal na pg
- mame jiz vytvorenou mysql databazi a nejsou v ni zatim vytvorene zadne tabulky

Konverze tabulek z pg do mysql se zda byt pomerne osemetna a fakt dost pracna zalezitost. Existuje na to jakesi udelatko, ale nefunguje spravne a konverze dopadla vzdy spatne - tedy bylo zapotrebi velmi mnoho rucni prace, kterou mohl udelat ten script a chybely indexy, primarni klice atd... Nebyly spravne nastavene default hodnoty a spousta dalsiho...

Kdyz uz se mi konecne podarilo doladit import a vytvorit pracne vsechny indexy a predtim samozrejme poopravovat definice tabulek tak, aby je mysql zkouslo, tak se nakonec stejne ukazalo, ze nekde zustaly nejake chyby a aplikaci se mi ve finale nepodarilo rozbehat.

Z vyse popsanych duvodu se na to muselo jit jinak:

- v puvodnim drupalu (bezicim na pg) jsem pro jistotu povypinal vsechny cache a vycistil cache
- v administraci modulu (/admin/build/modules) jsem si zaznamenal kazdy zapnuty modul (toto je dulezite!)
- potom jsem v settings.php zmenil $db_url = 'pgsql://..... na $db_url = 'mysqli://..... - spustil jsem drupal (toho casu jiz nad prazdnou mysql databazi) a povolil jsem instalaci (drupal zacal vytvaret tabulky) a tu jsem dokoncil
- po prilogovani do noveho drupalu jsem skocil opet do administrace modulu (/admin/build/modules) a vsechny (ty, ktere byly v pg verzi zapnute) jsem je pozapinal (to jedulezite kvuli tomu, ze se zacnou vytvaret tabulky v db a tentokrat se vytvori spravne - ne jako ty moje pokusy s konverzemi)

Nyni bychom meli mit v obou tabulkach stejny pocet tabulek stejnych struktur.

Stalo se mi, ze se mi nevytvorila tabulka upload (cert vi proc), ale nebyl problem, protoze po presunu dat mezi db se to projevilo (do te doby jsem to nevedel) a pak stacilo jen vypnout modul upload a nechat ho drupalem odinstalovat (tohle je dulezite!) - drupal se zaroven pokusil smazat tu tabulku (neuspesne, ale to nevadi nicemu) a od te chvile si myslel, ze tam neni nainstalovan modul upload (to jsme chteli). Opetovne zapnuti tohoto modulu zpusobilo take jeho spravne vytvoreni v databazi. Neocekavam, ze by se to melo zopakovat, ale demonstruje to postup pri podobnem problemu.

Podstatne je, ze nize prilozeny script si nacte tabulky v mysql a ty, ktere najde, prochazi v pg a taha z nich data. Pred pouzitim tabulku promaze (ale muzeme je pro jistotu vyprazdnit i my).

Nasledne jsem, v puvodni postgres zcela vyprazdnil tabulky, ktere zacinaly na search_ (po presunu staci jen spustit cron.php a search tabulky se zacnou opet plnit a vse pojede - me to bohuzel pri vsech prechodech zpusobovalo duplicitu klicu pri importu dat, takze jsem musel search_ tabulky vyprazdnit vzdy).

Nasledne jsem jiz jen do prilozeneho scriptu spravne vyplnil udaje o obou databazich a script jsem spustil: php -f ./migrate_tables.php Tento script jsem vycenichal nekde na netu a nepsal jsem ho ja. Rad bych uvedl odkaz na zdroj, ale jelikoz jsem ho nemohl najit predtim, tak mne to donutilo si zapsat tento zapisek jako zalohu postupu a nastesti jsem ho alespon nasel z drivejska na stroji, kde jsem delal prevod kdysi davneji a nemusel jsem ho psat/hledat znovu (i kdyz nic sloziteho to neni, ale cas by to sezralo, takze jsem fakt rad, ze se nasel).

 

<?php
$my_host = 'localhost';
$my_user = 'mysqluser';
$my_pass = 'mysqlpwd';
$my_db   = 'mydb';
 
$count_all = 0;
 
    error_reporting ( E_ALL );
    ini_set("display_errors", 1);
    ini_set("display_startup_errors", 1);
 
$pg_conn = pg_connect( "dbname='pgdb' host='localhost' user='pguser' password='pgpwd' options='--client_encoding=UTF8'" );
$my_conn = mysql_connect( $my_host, $my_user, $my_pass );
 
if( !mysql_select_db($my_db) ){
    echo "Unable to select mydbname: " . mysql_error();
    exit;
}
 
mysql_query("SET character_set_results = 'utf8', character_set_client = 'utf8'");
mysql_query("SET character_set_connection = 'utf8', character_set_database = 'utf8', character_set_server = 'utf8'");


$tables = array();
$res = mysql_query( 'show tables' );
while ($row = mysql_fetch_assoc($res)) {
    $tables[] = array_pop($row);
}


foreach( $tables as $table ){
    $columns = array();
    $res = mysql_query( 'desc '.$table );
    while ($row = mysql_fetch_assoc($res)) {
        $columns[ $row['Field'] ] = $row['Type'];
    }
 
    $inserts = array();
    $data_res = pg_query( "select * from ".$table.";" );
    while( $row = pg_fetch_assoc($data_res) ){
        $cols = '';
        $data = '';
        $joiner = '';
        foreach( $row as $key => $val ){
            $cols .= $joiner.$key;
            // we need a hack if column is tinyint and we insert t/f then convert
            if( $columns[$key] == 'tinyint(1)' && ($val == 't' || $val =='f') ){
                if( $val == 't' ){
                    $data .= $joiner."1";
                }elseif( $val == 'f' ){
                    $data .= $joiner."0";
                }
            }else{
                $data .= $joiner."'".mysql_escape_string($val)."'";
            }
            // this will set joiner to , so only the first one does not have coma in front
            $joiner = ",";
        }
        $inserts[] = "INSERT INTO ".$table." (".$cols.") VALUES (".$data.");";
    }
 
    mysql_query( "DELETE FROM $table;" );

	echo "\n".$table."\n";

    foreach ( $inserts as $insert ){
    #    echo $insert."\n";

	mysql_query( $insert );
        if( mysql_errno() != 0 ){
            print_r( mysql_error() );
            die();
        }
        if( $count_all % 101 == 0 ){
            echo '.';
        }
    }
}

       

Komentáře

[Xerces]

Jen pro zajímavost. Tuhle opičárnu jsi musel provést proto, že jsi chtěl používat nějakej neofi modul, který běžel pouze na mysql, nebo pro to, že server na kterém jsi chtěl Drupal používat přestal podporovat PostgreSQL?

[CandySan]

Servery provozuju ja, takze podpora pro obe databaze neni problem. Problem byva (bohuzel je to caste) s moduly. Tezko rict zda jim rikat oficialni ci neoficialni, ale jsou to moduly z drupal.org. Kdyz jsem narazil na problem, tak jsem ten modul opravil a rozchodil, ale uz me to nejak nebavi. Ve verzi 5 byly problemy vazne velke, protoze vyvojari modulu byli nuceni pro kazdou databazi delat zvlast instalaci tabulek, takze situace byla opravdu katastrofalni. Ve verzi 6 je na to nastesti api, takze to uz nejde flakat a tedy je situace o nekolik radu lepsi, ale stale zustavaji veci uvnitr modulu - tedy ruzne sql dotazy, ktere jsou mysql only.

Kdyz jsem pred davnejsim casem delal modul pro pripojeni uzivatelu do adobe connect pro a mel jsem to navazat na eshop, tak jsem se trosku vydesil, protoze mne cekalo mnoho modulu a uz jsem opravdu nechtel mit problem... Tak jsem ucinil rozhodnuti a prevedl jsem to na mysql a pokracoval nerusene dal az k uspechu. Jinde to byl zase hosting server na postovni server a ted zase drupal navazuju na asterisk ustrednu na callcentru - tohle vse je (doted bylo) zatim v pg a ja to chci zase mohutne rozsirovat. Ocekavam, ze tu a tam to bude chtit nejakej modul (captcha atd...) a nemam chut odbocovat a hledat priciny chyb za ktere nemuzu... na to jsem obvzlast haklivy od doby, kdy mi onehda bylo narizeno, ze musim pouzivat jednu konkretni databazi a vsechny projekty psat na ni - narazel jsem neustale na potize s tou databazi a mam tezkou averzi nejen na ten nedodelek, ale i na tahle nahla preruseni prace... Bylo to nekolik let v kuse a projekty nebyly male.

[Jakub Suchy]

Jeste lepsi to bude v Drupalu 7, ktery prinesl k databazi agnosticke DBTNG - dotazy se tvorit objektove a PHP samo vytvori SQL pro danou databazi.

[CandySan]

Tak to je parada! Verim, ze tim se ty problemy s db nadobro vytrati. Soude dle dbapi v .install v sestce se dalo tusit, ze to bude smerovat k vyreseni problemu s kompatibilitou databazi. Drupal je uzasny!

[Jakub Suchy]

Jo Trosku trva si na to zvyknout, ale kdyz se nad tim clovek zamysli, je to jasny.

            $query = db_select('node', 'n')->fields('n', array('nid', 'comment', 'promote', 'sticky', 'uid', 'status', 'created', 'changed' ));
            $query->fields('nrs', array('title', 'body', 'teaser', 'format'));
            $query->condition('n.type', 'blog');
            $query->leftJoin('term_node', 'tn', 'tn.nid = n.nid');
            $query->leftJoin('term_data', 'td', 'tn.tid = td.tid');
            $query->leftJoin('node_revisions', 'nrs', 'nrs.vid = n.vid');
            $query->leftJoin('files', 'f', 'f.nid = n.nid');
            // Gives a single comma-separated list of related terms
            $query->groupBy('tn.nid');
            $query->groupBy('f.nid');
            $query->addExpression('GROUP_CONCAT(td.name)', 'terms');
            $query->addExpression('GROUP_CONCAT(f.filepath)', 'files');

[CandySan]

hmm... nevypada to spatne... vypada to celkem logicky a myslim, ze to pujde Diky za info!