On 23.12.2011, at 11:44, Margus Värton wrote: > 22.12.2011 17:03, Jaak Laineste kirjutas: >> >> - proovin ka osm2pgsql baasi uuendada >> http://wiki.openstreetmap.org/wiki/DE:Minutely_Mapnik skriptiga (load-next), >> esimene katse oli üsna nigel - 5 min uuendusi loeti 55 minutit. Aga serveris >> käib ka tilede prerenderdus, mis teeb kõike aeglasemaks. >> > Ehk on hea plaan testserverile rohkem mälu hambusse anda ning osa tegevusi > sinna viia?
Kui uuenduse tükid on suuremad, siis on uuendus parem - 6 tunni kaupa lisades teeb selle 4-5 tunniga ära. Umbes jaanuari lõpuks võiks seega baas reaalajale järgi jõudma hakata. Hetkel võib siis öelda et meil on olemas Monthly Mapnik :) Osm2pgsql vajab planeedi jaoks umbes 16G mälu ja 300G HDD-d. Kui see üks kord ära teha, siis tuleb andmed veel saada livemasinasse. Selleks on plaan mul katsetada Postgres 9 master-slave replikatsiooni seadistust. Teen livemasinast postgres dumpi, tõmban testmasinasse; selleks pole sinna mälu juurde vaja. Siis panen testmasina postgres masteriks. Teise (nt live) masinasse panen postgres slave, mis tuleb sünkida masteriga (logide transport käima). Siis panen testmasina minutelyMapnik uuendusi lugema, selleks peaks ka 1GB RAM-ist piisama. Samal ajal hakkab ta replikeerima andmeid oma slave-desse, mis saavad siis samuti olema uuendatud samavõrra nagu master. Mis on siin probleemid: 1. Esialgne sünk, slave ühendamine. Alghetkel peavad olema master ja slave täpselt samas seisus. Võibolla saab master-i panna tegema näiteks nädalaseid full-dumpe, ja on võimeline hoidma changelogisid vähemalt 2 nädalat, siis võibolla saab tekitada lahendusi kus slave saab põhimõtteliselt suvalisel hetkel liituda. 2. Millist replikatsiooni kasutada. Variante on mitu: a) Postgres 9.0-ist on olemas sisseehitatud master-slave replikatsioon (streaming replication) mis toimub madalal tasemel WAL-ide abil. See peaks olema minimaalne overhead masterile. Piirang on et master ja slave peavad olema binaar-ühilduvad, näiteks mõlemad näiteks 64-bit linuxid täpselt sama postgres versiooniga. Transporditakse ühtpidi liigseid andmeid - näiteks impordi ajal kasutatavaid ajutisi tabeleid ja slim-modes kasutatavat planet_osm_ways_nodes tabelit (mis on 1/3 kogu baasisuurusest) pole renderduseks slavedel enam tarvis, kuid madalal tasemel replikatsioonis ei saa öelda et neid tabeleid mitte üle viia. Teisalt transporditakse (oletatavasti ??) ka valmisolevaid indekseid, mille moodustamine/uuendamine võtab osm2pgsql töös muidu vabalt pool ajast. b) Slony (või Londiste vms) stiilis kõrgemal tasemel (SQL/triggerite abil tehtud) replikatsioon. Eelis on, et vaja pole binaarühilduvust (võib linux->win näiteks tõsta, võivad eri postgres versioonid olla), samuti peaks olema sünkimise ajahetke valik paindlikum ja saab valida täpselt mis tabeleid tõstetakse üle. Puuduseks on, et kulukas indeksi loomise/uuendamise töö tuleb igas slaves eraldi teha (SQL tasemel ei saa ju triggereid replikeerida?). Samuti on lisakoormus masterile (10-30% väidetavalt). Küsimus on, et ta on küll madalama tasemega kui OSM XML-failide (minutelyMapnik praegune standardlahendus) liigutamine, aga äkki ei annagi eriti effekti. c) kombinatsioon: näiteks meie test->live serveri vahel slony, mis on selektiivsem; ja sealt edasi WAL streaming. Või vastupidi. 3. Ühine probleem on et mistahes postgres replikatsiooni ülespanek ja läbikatsetamine gigasuure baasiga on mittetriviaalne töö, mille kohta juhendeid ei ole ülemäära palju. Kes võiks supportida? Ainus, kellega ma olen pisut isiklikult vestelnud sellest on Steve Singer (http://www.fosslc.org/drupal/content/postgis-replication nt), kes on tegelikult Slony arendajaid ja asja tippspetse, aga kas ta aidata saab/viitsib pole kindel. Jaak _______________________________________________ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
