Sun kjøper MySQL

[abcd423417984]

Og jeg tror ikke Sun kommer til å slutte med satsingen på åpen kildekode. Det selskapet går bedre enn hva det har gjort på lenge. Satsingen på åpen kildekode er nok en av årsakene. Og dette oppkjøpet blir stort sett tatt godt imot.

 

Eg vil være litt forsiktig med å sei at Sun satser på åpen kjeldekode. Så lenge dei har kontroll så har dei ingen problemer, men med ein gong det er fare for å miste kontroll så lanserer dei produktet under ein lisens som gjerne er GPL inkompatibel. F.eks ZFS, utan tvil verdas mest avanserte filsystem, perfekt for databaser. Skal du ha ZFS så må du gå for Solaris eller BSD (Leopard skal visstnok og ha det). Men ein kan gløyme det til Linux.

 

Vel jeg vil påstå at å være inkompatibel med GPL ikke nødvendigvis trenger å være et problem så lenge det er en free lisence. Kun GPL zealots gnåler og det tullet der.

[stigfjel]

Eg vil være litt forsiktig med å sei at Sun satser på åpen kjeldekode. Så lenge dei har kontroll så har dei ingen problemer, men med ein gong det er fare for å miste kontroll så lanserer dei produktet under ein lisens som gjerne er GPL inkompatibel. F.eks ZFS, utan tvil verdas mest avanserte filsystem, perfekt for databaser. Skal du ha ZFS så må du gå for Solaris eller BSD (Leopard skal visstnok og ha det). Men ein kan gløyme det til Linux.

Nå er det slik at Sun vurderer å GPL-lisensiere OpenSolaris. Men det er en del forhold Sun må klarne opp i først, blant annet det at Solaris baserer seg på UNIX System V, en kodebase som er rettighetsbelagt. Det er denne kodebasen som har vært kimen til alt bråket rundt SCO. Grunnen til at SCO saksøkte IBM var at SCO beskyldte IBM for å stjele UNIX System V-kode og innlemme denne koden i GNU/Linux.

[kpolberg]

Dette tror jeg blir knall bra. Tipper Sun vil ha tak i Falcon motoren som mysql folka holder på med, i stedet for InnoDB som oracle folka har utviklet. Står mye interessant på flere sider rundt Falcon og hva det kommer til å bety.

[roac]

Blei veldig overraska når eg leste dette da Sun har levert løsninger med PostgreSQL i det siste, samt å lage samanlikninger mellom PostgreSQL og Oracle som viser at PostgreSQL leverer 95% av det Oracle gjør for prisen av heile null kroner.

At PostgreSQL er en rimelig god database er det vel ingen tvil om, men etter det jeg kan se har den i det minste én diger mangel (med fare for at det er noe jeg har oversett): Muligheten til å spesifisere at databasefiler og loggfiler ligger i forksjellige kataloger (på forksjellige diskvolum). Uten dette risikerer man å miste unødvendig mye data dersom et disksystem av en eller annen grunn skulle finne på å bryte sammen. Og som enkelte bittert har fått erfare, det kan skje med et SAN også

[kpolberg]

At PostgreSQL er en rimelig god database er det vel ingen tvil om, men etter det jeg kan se har den i det minste én diger mangel (med fare for at det er noe jeg har oversett): Muligheten til å spesifisere at databasefiler og loggfiler ligger i forksjellige kataloger (på forksjellige diskvolum). Uten dette risikerer man å miste unødvendig mye data dersom et disksystem av en eller annen grunn skulle finne på å bryte sammen. Og som enkelte bittert har fått erfare, det kan skje med et SAN også

Uansett om det ikke er helt stuerent så er det fullt mulig å bruke "symbolic links" til dette Etter det jeg kan lese, så er det fullt mulig å spesifisere data_dir og logg_dir. Forskjellige volum antar jeg fungerer, ihvertfall i linux.

Endret 21. januar 2008 av kpolberg

[roac]

At PostgreSQL er en rimelig god database er det vel ingen tvil om, men etter det jeg kan se har den i det minste én diger mangel (med fare for at det er noe jeg har oversett): Muligheten til å spesifisere at databasefiler og loggfiler ligger i forksjellige kataloger (på forksjellige diskvolum). Uten dette risikerer man å miste unødvendig mye data dersom et disksystem av en eller annen grunn skulle finne på å bryte sammen. Og som enkelte bittert har fått erfare, det kan skje med et SAN også

Uansett om det ikke er helt stuerent så er det fullt mulig å bruke "symbolic links" til dette Etter det jeg kan lese, så er det fullt mulig å spesifisere data_dir og logg_dir. Forskjellige volum antar jeg fungerer, ihvertfall i linux.

Symbolic links vil ikke gjøre de to dataområdene totalt uavhengige av hverandre, det vil på en eller annen måte være et single point of failure. Når jeg søker på log_dir og data_dir får jeg ikke opp noe som virker å være relevante treff i google. Å kunne spesifisere hvor datafiler ligger når jeg oppretter en database anser jeg som basisfunksjonalitet, så jeg er skuffet over at jeg ikke finner dette i PostgreSQL. Det gjør at PsotgreSQL er langt mindre anvendelig enn de store (MSSQL, Oracle etc).

[siDDis]

Sånn http://www.postgresql.org/docs/8.1/static/...ablespaces.html

og sånn http://www.postgresql.org/docs/8.1/static/...aintenance.html

[roac]

Sånn http://www.postgresql.org/docs/8.1/static/...ablespaces.html

og sånn http://www.postgresql.org/docs/8.1/static/...aintenance.html

Er ikke sistnevnte der snakk om tekstlogg, og ikke en transaksjonslogg. Med tanke på feilhåndtering er det best practice å ha transaksjonslogg (evt redo og undo logg dersom dette er i forksjellige filer) på et annet disksystem enn databasefilen. Med tablespace kan du definere hvor datafilene skal ligge, men slik jeg ser det så må transaksjonslogg havne i samme katalog, noe som er en vesentlig ulempe dersom disksystemet skulle ryke, i så tilfelle er du GARANTERT å ha mistet alle data siden sist backup, i motsetning til f eks Oracle, MSSQL og Sybase som i verste fall vil miste de data som enda ikke har kommet fra transaksjonsloggen og over i databasefilen.

[kpolberg]

Er ikke sistnevnte der snakk om tekstlogg, og ikke en transaksjonslogg. Med tanke på feilhåndtering er det best practice å ha transaksjonslogg (evt redo og undo logg dersom dette er i forksjellige filer) på et annet disksystem enn databasefilen. Med tablespace kan du definere hvor datafilene skal ligge, men slik jeg ser det så må transaksjonslogg havne i samme katalog, noe som er en vesentlig ulempe dersom disksystemet skulle ryke, i så tilfelle er du GARANTERT å ha mistet alle data siden sist backup, i motsetning til f eks Oracle, MSSQL og Sybase som i verste fall vil miste de data som enda ikke har kommet fra transaksjonsloggen og over i databasefilen.

Mulig det er dette du tenker på...

 

http://www.postgresql.org/docs/8.0/interac...kup-online.html

 

Aner ikke om den pathen er spesifiser bar, men uansett så er det jo bare å legge denne på ett eget volum.

 

At all times, PostgreSQL maintains a write ahead log (WAL) in the pg_xlog/ subdirectory of the cluster's data directory. The log describes every change made to the database's data files. This log exists primarily for crash-safety purposes: if the system crashes, the database can be restored to consistency by "replaying" the log entries made since the last checkpoint. However, the existence of the log makes it possible to use a third strategy for backing up databases: we can combine a file-system-level backup with backup of the WAL files. If recovery is needed, we restore the backup and then replay from the backed-up WAL files to bring the backup up to current time.

[siDDis]

Transaksjonsloggene blir lagra i systemtabeller som har navn som pg_'%xlog%'

desse kan du setja til forskjellige tablespaces.

[haalo]

Blir spennende å se hvordan Sun kommer til å integrerere MySQL i systemene sine.