http://www.cyberciti.biz/tips/howto-bac ... bases.html
Tycker jag inte ser ut som "en jäkla massa hand-jagande av filer kors och tvärs. ".
Jag har dessvärre inte samma tid som dig att sitta och dammsuga nätet efter detaljer, och har heller inget intresse att försvara en massa saker jag inte är 100% insatt i.
Jag tror hur som helst att PostgreSQL duger för de flesta, även vissa affärskritiska, applikationer.
Om man sedan vill betala miljoner i licenser för andra databaslösningar för att få lite snabbare backuphantering är ju upp var och en.
Komponent-databas och SQL
Visst, det är jätteenkelt, *OM* man har varken online eller konsistenskrav!
Det är så det ser ut med de flesta (enklare) produkter...
Men 24/7 drift är ju populärt i dag. Och då kommer krav på att det ska
ske online och konsistent.
> Vad gäller transaktioner så är dessa atomic även för mysqlhotcopy.
OK, jag ser inte att det gör backupen konsistent, men...
Dessutom tar den bara myISAM, inte InnoDB.
För InnoDB finns ett verktyg som kostar ca 4000 SEK/år/server.
http://www.innodb.com/hot-backup
Men, även den klarar inte i alla lägen att ta en backup, det finns undantag
i dokumentationen.
> Frågan är om du *vet* att RMU *verkligen* ger exakt det du beskriver,
Ja, det gör jag.
Och att det fungerar är "by design". I princip handlar det om att använda
"pre-image loggar". Databasen behåller föregående version av sidor som
uppdateras av R/W tranaktioner, så att när backup jobbet kommer fram
dit, så tas den version av sidan som är från tidpunkten då backup
startades istället för den senare versionen som har uppdaterats.
Det är samma mekanism som ger "repeatable read" utan att låsa ute
R/W transaktioner. Man kan t.ex köra stora rapporter/summeringar där
slutsummorna alltid stämmer även om data har uppdaterats under tiden.
Alltså inga "phantom reads" eller "read commited" (vilket är vanligt, d.v.s
att så fort en R/W transaktion har gjort COMMIT, så kan alla *aktiva*
Read Only transaktioner "se" datat, även om det är från en senare tidpunkt
än do Read Only transaktionen startades.
Med "repeatable read" så upplever en Read Only transaktion att
databasen "fryses" då transaktionen startas, och man kan alltså köra
rapporter m.m utan överaskningar (d.v.s att datat plötsligt ändras och
förvanskar slutresultatet).
Read Only transaktioner so startar *efter* att R/W transaktionen har gjort
COMMIT, ser naturligtsvis även det nya datat...
> Jag har dessvärre inte samma tid...
Var och en tar väl tid efter intresse...
Databaser är ett av mina stora intressen.
Det är så det ser ut med de flesta (enklare) produkter...
Men 24/7 drift är ju populärt i dag. Och då kommer krav på att det ska
ske online och konsistent.
> Vad gäller transaktioner så är dessa atomic även för mysqlhotcopy.
OK, jag ser inte att det gör backupen konsistent, men...
Dessutom tar den bara myISAM, inte InnoDB.
För InnoDB finns ett verktyg som kostar ca 4000 SEK/år/server.
http://www.innodb.com/hot-backup
Men, även den klarar inte i alla lägen att ta en backup, det finns undantag
i dokumentationen.
> Frågan är om du *vet* att RMU *verkligen* ger exakt det du beskriver,
Ja, det gör jag.
Och att det fungerar är "by design". I princip handlar det om att använda
"pre-image loggar". Databasen behåller föregående version av sidor som
uppdateras av R/W tranaktioner, så att när backup jobbet kommer fram
dit, så tas den version av sidan som är från tidpunkten då backup
startades istället för den senare versionen som har uppdaterats.
Det är samma mekanism som ger "repeatable read" utan att låsa ute
R/W transaktioner. Man kan t.ex köra stora rapporter/summeringar där
slutsummorna alltid stämmer även om data har uppdaterats under tiden.
Alltså inga "phantom reads" eller "read commited" (vilket är vanligt, d.v.s
att så fort en R/W transaktion har gjort COMMIT, så kan alla *aktiva*
Read Only transaktioner "se" datat, även om det är från en senare tidpunkt
än do Read Only transaktionen startades.
Med "repeatable read" så upplever en Read Only transaktion att
databasen "fryses" då transaktionen startas, och man kan alltså köra
rapporter m.m utan överaskningar (d.v.s att datat plötsligt ändras och
förvanskar slutresultatet).
Read Only transaktioner so startar *efter* att R/W transaktionen har gjort
COMMIT, ser naturligtsvis även det nya datat...
> Jag har dessvärre inte samma tid...
Var och en tar väl tid efter intresse...
Databaser är ett av mina stora intressen.
Jag märker ju att du är väl insatt, så att jag ska försöka både förstå och försvara en massa tekniskt mambojambo känns meningslöst då jag inte är det minsta uppdaterad kring grejjorna.
Men är du lite neutral i utgångspunkt så kanske du kan ta en djupare till på postgres och se om det är något att hänga i granen.
En stor skillnad mellan open source och proprietär kod, är att du inte kan dölja något med OS. Spelar med öppna kort alltså.
Medans en stängd programvara kan vara precis så bra som säljavdelningen utger den för att vara. Ingen kan ju kolla upp det ändå!
Därför blir det också lite svårt att jämföra vissa detaljer.
Men är du lite neutral i utgångspunkt så kanske du kan ta en djupare till på postgres och se om det är något att hänga i granen.
En stor skillnad mellan open source och proprietär kod, är att du inte kan dölja något med OS. Spelar med öppna kort alltså.
Medans en stängd programvara kan vara precis så bra som säljavdelningen utger den för att vara. Ingen kan ju kolla upp det ändå!
Därför blir det också lite svårt att jämföra vissa detaljer.
> Ingen kan ju kolla upp det ändå!
Den tekniska dokumentationen beskriver vad produkten "kan", inte säljavdelningen.
Dessutom, efter 15 år i de mest krävande miljöer (bank, finans, börser,
sjukvård) så går det inte att dölja brister.
Nej, om man har *riktigt* stora krav på en produkt så har open source
inget där att göra. Men för de som inte har höga krav (eller inte förstår
att de borde ha höga krav) så är det väl bara att köra på så länge det går...
> Därför blir det också lite svårt att jämföra vissa detaljer.
Inte alls! Det är väldigt enkelt. Det är bara att RTFM.
Det är *funktionen* som är intressant, inte hur det faktiskt är implementerat i koden...
Den tekniska dokumentationen beskriver vad produkten "kan", inte säljavdelningen.
Dessutom, efter 15 år i de mest krävande miljöer (bank, finans, börser,
sjukvård) så går det inte att dölja brister.
Nej, om man har *riktigt* stora krav på en produkt så har open source
inget där att göra. Men för de som inte har höga krav (eller inte förstår
att de borde ha höga krav) så är det väl bara att köra på så länge det går...
> Därför blir det också lite svårt att jämföra vissa detaljer.
Inte alls! Det är väldigt enkelt. Det är bara att RTFM.
Det är *funktionen* som är intressant, inte hur det faktiskt är implementerat i koden...
Så om Oracle skulle släppa sin källkod så är det plötsligt inget att ha?
Det är klart att aktieägarna vill att man ska krydda reklamen lite, dom vill ju ha ut det mesta på kortast tid.
Vad säger att det som står i manualen alltid, under alla omständigheter, är det som gäller?
Jag är ganska övertygad om att de med öppen källkod blir betydligt hårdare granskat än de med stängd.
Om det sedan är så att allt är fullständigt perfekt i den stängda, eller om det helt enkelt aldrig hänt att bristerna behövt komma fram, får man ju rent av spekulera kring. Ingen kan ju kolla det i förebyggande syfte ändå! Bara att hoppas att det stämmer.
Det är klart att aktieägarna vill att man ska krydda reklamen lite, dom vill ju ha ut det mesta på kortast tid.
Vad säger att det som står i manualen alltid, under alla omständigheter, är det som gäller?
Jag är ganska övertygad om att de med öppen källkod blir betydligt hårdare granskat än de med stängd.
Om det sedan är så att allt är fullständigt perfekt i den stängda, eller om det helt enkelt aldrig hänt att bristerna behövt komma fram, får man ju rent av spekulera kring. Ingen kan ju kolla det i förebyggande syfte ändå! Bara att hoppas att det stämmer.
Det beor nog mest på vilka företag man har erfarenhet av.
Jag noterar att du nämner Oracle, jag vet inte varför riktigt. Kanske
bara som exempel ?
> Så om Oracle skulle släppa sin källkod så är det plötsligt inget att ha?
Nej, men (beroende på vad som händer sedan med koden) så kan
det vara lite svårare att "hänga" Oracle för brister i produkten. Och det är
det som många vill ha, någon att "hänga"...
> Vad säger att det som står i manualen alltid, under alla omständigheter, är det som gäller?
Förtroendet för de som har utvecklat/dokumenterat produkten.
"Under alla omständigheter" är dock lite väl hårddraget...
Men, vad *annars* är det som gäller ???
> Jag är ganska övertygad om att de med öppen källkod blir betydligt hårdare granskat än de med stängd.
Det är ointressant. Det handlar om förtroende för en produkt/leverantör.
Varför ska man granska något ? Och vad ska man granska ?
> Om det sedan är så att allt är fullständigt perfekt i den stängda,
Självklart inte, men "Known Bugs" listan brukar ha med det viktiga...
Även om allt inte är kritiska fel, t.ex beskrivningen av "The Halloween
Problem" är ju ett känt databas fenomen, och igentligen ingen "bug"...
Men hur som helst, min *poäng* är att de populära "öppna" produkterna
i dag har väldigt långt kvar till att blir "riktiga" databassystem.
Jag noterar att du nämner Oracle, jag vet inte varför riktigt. Kanske
bara som exempel ?
> Så om Oracle skulle släppa sin källkod så är det plötsligt inget att ha?
Nej, men (beroende på vad som händer sedan med koden) så kan
det vara lite svårare att "hänga" Oracle för brister i produkten. Och det är
det som många vill ha, någon att "hänga"...
> Vad säger att det som står i manualen alltid, under alla omständigheter, är det som gäller?
Förtroendet för de som har utvecklat/dokumenterat produkten.
"Under alla omständigheter" är dock lite väl hårddraget...
Men, vad *annars* är det som gäller ???
> Jag är ganska övertygad om att de med öppen källkod blir betydligt hårdare granskat än de med stängd.
Det är ointressant. Det handlar om förtroende för en produkt/leverantör.
Varför ska man granska något ? Och vad ska man granska ?
> Om det sedan är så att allt är fullständigt perfekt i den stängda,
Självklart inte, men "Known Bugs" listan brukar ha med det viktiga...
Även om allt inte är kritiska fel, t.ex beskrivningen av "The Halloween
Problem" är ju ett känt databas fenomen, och igentligen ingen "bug"...
Men hur som helst, min *poäng* är att de populära "öppna" produkterna
i dag har väldigt långt kvar till att blir "riktiga" databassystem.
<sarkasm> Kanske bäst jag omedelbart börjar migrera alla databaserna här då till något riktigt databassystem, fan där rök årets budget </sarkasm>
Nej men för att vara lite seriös så tror jag det är få databaser som är så känsliga att dom inte klarar sig med det (enligt mig) mycket kompetenta databassystemet (eller vad du nu tycker det är) PostgreSql.
I alla fall tror jag Jimmy's komponentdatabas inte kräver något värre än det
Nej men för att vara lite seriös så tror jag det är få databaser som är så känsliga att dom inte klarar sig med det (enligt mig) mycket kompetenta databassystemet (eller vad du nu tycker det är) PostgreSql.
I alla fall tror jag Jimmy's komponentdatabas inte kräver något värre än det
-
JimmyAndersson
- Inlägg: 26548
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
det har ju varit en del *ältande* så att säga, så jag har också "tappat tråden"... (men jag är fortfarande nyfiken på om du hittar en bra, billig och enkel lösning) -
JimmyAndersson
- Inlägg: 26548
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
