Ahoj,
dostal jsem úžasný email od ssls.cz ohledně Lets encrypt. Já jsem si samozřejmě vědom cílů a omezení Lets encrypt, ale tohle považuju za nefér FUD nejhrubšího zrna.
Dostal jste to ještě někdo?
Pokud jste někdo jejich zákazníkem, možná by neškodilo jim to trošku osvětlit. Jejich marketingové oddělení očividně panikaří, asi jim klesají zisky z certifikátů pro nedůležité služby.
Martin Sivák
---------- Přeposlaná zpráva ---------- Od: SSLS.CZ - Upozornění info@ssls.cz Datum: 27. listopadu 2016 11:21 Předmět: Upozornění: Zabezpečení domény (moje.marsik.org) Komu: mars@montik.net
Vážený zákazníku,
dovolte, abychom Vás upozornili na *nedostatečné* zabezpečení (HTTPS) Vaší domény:
moje.marsik.org
Aktuálně máte na serveru nainstalován SSL certifikát *Let's Encrypt*, který je sice zdarma, ovšem za cenu celé řady *vážných nedostatků*, mj. absenci finanční záruky, pečetě, diskutabilní podpoře prohlížeči a v neposlední řadě *nulové prestiži a důvěryhodnosti* v očích Vašich zákazníků.
Důležité je mít na paměti i skutečnost, že jsou certifikáty Let's Encrypt hojně zneužívané na nebezpečných stránkách, které se snaží *šířit škodlivý kód* nebo získat *přístupové informace do internetového bankovnictví* či konají jinou *trestnou činnost*. Hrozba pro běžného uživatele v souvislosti s Let's Encrypt je proto velmi aktuální téma (článek http://timehosting.cz/hackeri-zneuzili-bezplatne-ssl-certifikaty-lets-encrypt/ ).
Aby toho nebylo málo, v zákulisí se navíc pomalu začínají objevovat hlasy volající po nedůvěřování certifikátům Let's encrypt podobně, jako se tomu chystá u certifikátů StartCom a WoSign (více zde https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/). *Webové stránky se přestanou zobrazovat*. Namísto toho prohlížeč zobrazí varování o nedůvěryhodném certifikátu.
*Proč nepoužívat Let's Encrypt* Let's Encrypt PositiveSSL Comodo EV Platnost certifikátu jen 3 měsíce 1-3 roky 1-2 roky Podpora prohlížečů a zařízení ? 99.9% 99.9% Podpora 256 bit ECC (silné šifrování) [image: ne] [image: ano] [image: ano] [image: HTTPS] Zobrazuje zelený adresní řádek https://www.ssls.cz/zeleny.html?utm_source=nslt&utm_campaign=le1&utm_medium=email&utm_content=greenbar_bottom [image: ne] [image: ne] [image: ano] Finanční záruka https://www.ssls.cz/zaruka-ca.html?utm_source=nslt&utm_campaign=le1&utm_medium=email [image: ne] [image: ano] $10,000 [image: ano] $1,750,000 Vhodný pro komerční či firemní web, eshop [image: ne] [image: ano] [image: ano] Podpora IDN (domény s diakritikou) [image: ne] [image: ano] [image: ano] Podpora wildcard https://www.ssls.cz/certifikaty/wildcard/?utm_source=nslt&utm_campaign=le1&utm_medium=email (zabezpečí ∞ subdomén) [image: ne] [image: ano] [image: ne] Možnost získat před spuštěním serveru [image: ne] [image: ano] [image: ano] Ochrana proti vystavení pro podvodný web [image: ne] [image: ano] [image: ano] Prestižní značka certifikátu [image: ne] [image: ano] [image: ano] Neomezený počet vystavených certifikátů [image: ne] [image: ano] [image: ano] Možnost zneplatnění certifikátů [image: ne] [image: ano] zdarma [image: ano] zdarma Pečeť pro vyšší důvěryhodnost [image: ne] [image: ano] statická [image: ano] dynamická Stabilní ekonomický model CA [image: ne] [image: ano] [image: ano] Zákaznická podpora [image: ne] [image: ano] 24H [image: ano] 24H Více… https://www.ssls.cz/certifikaty/positivessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email Více… https://www.ssls.cz/certifikaty/ev/?utm_source=nslt&utm_campaign=le1&utm_medium=email
*Jak situaci vyřešit*
Dotčeným zákazníkům důrazně doporučujeme *používat pouze důvěryhodné SSL certifikáty prověřených certifikačních autorit*, které uvedené nedostatky nemají a mají pro Vás i Vaše zákazníky důležitou přidanou hodnotu, mj.:
- AlpiroSSL https://www.ssls.cz/certifikaty/alpiro/?utm_source=nslt&utm_campaign=le1&utm_medium=email - GlobalSign https://www.ssls.cz/certifikaty/globalsign/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- PositiveSSL https://www.ssls.cz/certifikaty/positivessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email - Comodo https://www.ssls.cz/certifikaty/comodo/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- SpaceSSL https://www.ssls.cz/certifikaty/spacessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email - Certum https://www.ssls.cz/certifikaty/certum/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Symantec https://www.ssls.cz/certifikaty/symantec/?utm_source=nslt&utm_campaign=le1&utm_medium=email - Thawte https://www.ssls.cz/certifikaty/thawte/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- GeoTrust https://www.ssls.cz/certifikaty/geotrust/?utm_source=nslt&utm_campaign=le1&utm_medium=email - RapidSSL https://www.ssls.cz/certifikaty/rapidssl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
Vyřešit nyní › https://www.ssls.cz/chci-https.html?utm_source=nslt&utm_campaign=le1&utm_medium=email
Hledáte-li *levné, ale kvalitní a spolehlivé řešení*, můžeme doporučit: *AlpiroSSL* — zabezpečí jednu doménu/subdoménu již za *139 Kč* / rok Koupit https://www.ssls.cz/certifikat/alpirossl.html?utm_source=nslt&utm_campaign=le1&utm_medium=email *AlpiroSSL Wildcard* — zabezpečí doménu a ∞ subdomén již za *990 Kč* / rok Koupit https://www.ssls.cz/certifikat/alpirossl-wildcard.html?utm_source=nslt&utm_campaign=le1&utm_medium=email *Comodo EV SSL* — zobrazuje zelený adresní řádek https://www.ssls.cz/zeleny.html?utm_source=nslt&utm_campaign=le1&utm_medium=email&utm_content=greenbar_table již za *1490 Kč* / rok Koupit https://www.ssls.cz/certifikat/ev-promo.html?utm_source=nslt&utm_campaign=le1&utm_medium=email Více SSL certifikátů… https://www.ssls.cz/certifikaty.html?utm_source=nslt&utm_campaign=le1&utm_medium=email Ceny uvedeny bez DPH.
Potřebujete-li v souvislosti s tímto incidentem poradit, popř. pomoci s výběrem nejvhodnějšího certifikátu, neváhejte se na nás kdykoliv obrátit na této e-mailové adrese. Děkujeme za Vaši důvěru.
S úctou a přáním pěkného dne,
[image: SSLs.cz]
*SSLS.CZ http://SSLS.CZ* SSL certifikáty | www.ssls.cz https://www.ssls.cz/?utm_source=nslt&utm_campaign=le1&utm_medium=email
Právě nsme o tom na Rootu vydali článek:
https://www.root.cz/clanky/ssls-strasi-pred-let-s-encrypt-ale-pouziva-klamne...
Ahoj,
taky mi to včera dorazilo. Měli jsme od nich jeden SSL certifikát pro www.fireport.cz, ale minulý měsíc jsme to vyměnili za Let's Encrypt, ať je pokoj od renewalů. Napsal jsem jim hodně podrážděný e-mail, že jejich "upozornění" je zavádějící a lživé.
Dne 28. listopadu 2016 10:08 Martin Sivák mars@montik.net napsal(a):
Ahoj,
dostal jsem úžasný email od ssls.cz ohledně Lets encrypt. Já jsem si samozřejmě vědom cílů a omezení Lets encrypt, ale tohle považuju za nefér FUD nejhrubšího zrna.
Dostal jste to ještě někdo?
Pokud jste někdo jejich zákazníkem, možná by neškodilo jim to trošku osvětlit. Jejich marketingové oddělení očividně panikaří, asi jim klesají zisky z certifikátů pro nedůležité služby.
Martin Sivák
---------- Přeposlaná zpráva ---------- Od: SSLS.CZ - Upozornění info@ssls.cz Datum: 27. listopadu 2016 11:21 Předmět: Upozornění: Zabezpečení domény (moje.marsik.org) Komu: mars@montik.net
Vážený zákazníku,
dovolte, abychom Vás upozornili na *nedostatečné* zabezpečení (HTTPS) Vaší domény:
moje.marsik.org
Aktuálně máte na serveru nainstalován SSL certifikát *Let's Encrypt*, který je sice zdarma, ovšem za cenu celé řady *vážných nedostatků*, mj. absenci finanční záruky, pečetě, diskutabilní podpoře prohlížeči a v neposlední řadě *nulové prestiži a důvěryhodnosti* v očích Vašich zákazníků.
Důležité je mít na paměti i skutečnost, že jsou certifikáty Let's Encrypt hojně zneužívané na nebezpečných stránkách, které se snaží *šířit škodlivý kód* nebo získat *přístupové informace do internetového bankovnictví* či konají jinou *trestnou činnost*. Hrozba pro běžného uživatele v souvislosti s Let's Encrypt je proto velmi aktuální téma ( článek http://timehosting.cz/hackeri-zneuzili-bezplatne-ssl-certifikaty-lets-encrypt/ ).
Aby toho nebylo málo, v zákulisí se navíc pomalu začínají objevovat hlasy volající po nedůvěřování certifikátům Let's encrypt podobně, jako se tomu chystá u certifikátů StartCom a WoSign (více zde https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/). *Webové stránky se přestanou zobrazovat*. Namísto toho prohlížeč zobrazí varování o nedůvěryhodném certifikátu.
*Proč nepoužívat Let's Encrypt* Let's Encrypt PositiveSSL Comodo EV Platnost certifikátu jen 3 měsíce 1-3 roky 1-2 roky Podpora prohlížečů a zařízení ? 99.9% 99.9% Podpora 256 bit ECC (silné šifrování) [image: ne] [image: ano] [image: ano] [image: HTTPS] Zobrazuje zelený adresní řádek https://www.ssls.cz/zeleny.html?utm_source=nslt&utm_campaign=le1&utm_medium=email&utm_content=greenbar_bottom [image: ne] [image: ne] [image: ano] Finanční záruka https://www.ssls.cz/zaruka-ca.html?utm_source=nslt&utm_campaign=le1&utm_medium=email [image: ne] [image: ano] $10,000 [image: ano] $1,750,000 Vhodný pro komerční či firemní web, eshop [image: ne] [image: ano] [image: ano] Podpora IDN (domény s diakritikou) [image: ne] [image: ano] [image: ano] Podpora wildcard https://www.ssls.cz/certifikaty/wildcard/?utm_source=nslt&utm_campaign=le1&utm_medium=email (zabezpečí ∞ subdomén) [image: ne] [image: ano] [image: ne] Možnost získat před spuštěním serveru [image: ne] [image: ano] [image: ano] Ochrana proti vystavení pro podvodný web [image: ne] [image: ano] [image: ano] Prestižní značka certifikátu [image: ne] [image: ano] [image: ano] Neomezený počet vystavených certifikátů [image: ne] [image: ano] [image: ano] Možnost zneplatnění certifikátů [image: ne] [image: ano] zdarma [image: ano] zdarma Pečeť pro vyšší důvěryhodnost [image: ne] [image: ano] statická [image: ano] dynamická Stabilní ekonomický model CA [image: ne] [image: ano] [image: ano] Zákaznická podpora [image: ne] [image: ano] 24H [image: ano] 24H Více… https://www.ssls.cz/certifikaty/positivessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email Více… https://www.ssls.cz/certifikaty/ev/?utm_source=nslt&utm_campaign=le1&utm_medium=email
*Jak situaci vyřešit*
Dotčeným zákazníkům důrazně doporučujeme *používat pouze důvěryhodné SSL certifikáty prověřených certifikačních autorit*, které uvedené nedostatky nemají a mají pro Vás i Vaše zákazníky důležitou přidanou hodnotu, mj.:
- AlpiroSSL
https://www.ssls.cz/certifikaty/alpiro/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- GlobalSign
https://www.ssls.cz/certifikaty/globalsign/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- PositiveSSL
https://www.ssls.cz/certifikaty/positivessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Comodo
https://www.ssls.cz/certifikaty/comodo/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- SpaceSSL
https://www.ssls.cz/certifikaty/spacessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Certum
https://www.ssls.cz/certifikaty/certum/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Symantec
https://www.ssls.cz/certifikaty/symantec/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Thawte
https://www.ssls.cz/certifikaty/thawte/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- GeoTrust
https://www.ssls.cz/certifikaty/geotrust/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- RapidSSL
https://www.ssls.cz/certifikaty/rapidssl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
Vyřešit nyní › https://www.ssls.cz/chci-https.html?utm_source=nslt&utm_campaign=le1&utm_medium=email
Hledáte-li *levné, ale kvalitní a spolehlivé řešení*, můžeme doporučit: *AlpiroSSL* — zabezpečí jednu doménu/subdoménu již za *139 Kč* / rok Koupit https://www.ssls.cz/certifikat/alpirossl.html?utm_source=nslt&utm_campaign=le1&utm_medium=email *AlpiroSSL Wildcard* — zabezpečí doménu a ∞ subdomén již za *990 Kč* / rok Koupit https://www.ssls.cz/certifikat/alpirossl-wildcard.html?utm_source=nslt&utm_campaign=le1&utm_medium=email *Comodo EV SSL* — zobrazuje zelený adresní řádek https://www.ssls.cz/zeleny.html?utm_source=nslt&utm_campaign=le1&utm_medium=email&utm_content=greenbar_table již za *1490 Kč* / rok Koupit https://www.ssls.cz/certifikat/ev-promo.html?utm_source=nslt&utm_campaign=le1&utm_medium=email Více SSL certifikátů… https://www.ssls.cz/certifikaty.html?utm_source=nslt&utm_campaign=le1&utm_medium=email Ceny uvedeny bez DPH.
Potřebujete-li v souvislosti s tímto incidentem poradit, popř. pomoci s výběrem nejvhodnějšího certifikátu, neváhejte se na nás kdykoliv obrátit na této e-mailové adrese. Děkujeme za Vaši důvěru.
S úctou a přáním pěkného dne,
[image: SSLs.cz]
*SSLS.CZ http://SSLS.CZ* SSL certifikáty | www.ssls.cz https://www.ssls.cz/?utm_source=nslt&utm_campaign=le1&utm_medium=email
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Michal Špaček už na to reagoval: https://twitter.com/spazef0rze/status/802935061897048065
David Linux server specialist/Heavy Ansible user www.karban.eu
Dne 28. listopadu 2016 10:08 Martin Sivák mars@montik.net napsal(a):
Ahoj,
dostal jsem úžasný email od ssls.cz ohledně Lets encrypt. Já jsem si samozřejmě vědom cílů a omezení Lets encrypt, ale tohle považuju za nefér FUD nejhrubšího zrna.
Dostal jste to ještě někdo?
Pokud jste někdo jejich zákazníkem, možná by neškodilo jim to trošku osvětlit. Jejich marketingové oddělení očividně panikaří, asi jim klesají zisky z certifikátů pro nedůležité služby.
Martin Sivák
---------- Přeposlaná zpráva ---------- Od: SSLS.CZ - Upozornění info@ssls.cz Datum: 27. listopadu 2016 11:21 Předmět: Upozornění: Zabezpečení domény (moje.marsik.org) Komu: mars@montik.net
Vážený zákazníku,
dovolte, abychom Vás upozornili na *nedostatečné* zabezpečení (HTTPS) Vaší domény:
moje.marsik.org
Aktuálně máte na serveru nainstalován SSL certifikát *Let's Encrypt*, který je sice zdarma, ovšem za cenu celé řady *vážných nedostatků*, mj. absenci finanční záruky, pečetě, diskutabilní podpoře prohlížeči a v neposlední řadě *nulové prestiži a důvěryhodnosti* v očích Vašich zákazníků.
Důležité je mít na paměti i skutečnost, že jsou certifikáty Let's Encrypt hojně zneužívané na nebezpečných stránkách, které se snaží *šířit škodlivý kód* nebo získat *přístupové informace do internetového bankovnictví* či konají jinou *trestnou činnost*. Hrozba pro běžného uživatele v souvislosti s Let's Encrypt je proto velmi aktuální téma ( článek http://timehosting.cz/hackeri-zneuzili-bezplatne-ssl-certifikaty-lets-encrypt/ ).
Aby toho nebylo málo, v zákulisí se navíc pomalu začínají objevovat hlasy volající po nedůvěřování certifikátům Let's encrypt podobně, jako se tomu chystá u certifikátů StartCom a WoSign (více zde https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/). *Webové stránky se přestanou zobrazovat*. Namísto toho prohlížeč zobrazí varování o nedůvěryhodném certifikátu.
*Proč nepoužívat Let's Encrypt* Let's Encrypt PositiveSSL Comodo EV Platnost certifikátu jen 3 měsíce 1-3 roky 1-2 roky Podpora prohlížečů a zařízení ? 99.9% 99.9% Podpora 256 bit ECC (silné šifrování) [image: ne] [image: ano] [image: ano] [image: HTTPS] Zobrazuje zelený adresní řádek https://www.ssls.cz/zeleny.html?utm_source=nslt&utm_campaign=le1&utm_medium=email&utm_content=greenbar_bottom [image: ne] [image: ne] [image: ano] Finanční záruka https://www.ssls.cz/zaruka-ca.html?utm_source=nslt&utm_campaign=le1&utm_medium=email [image: ne] [image: ano] $10,000 [image: ano] $1,750,000 Vhodný pro komerční či firemní web, eshop [image: ne] [image: ano] [image: ano] Podpora IDN (domény s diakritikou) [image: ne] [image: ano] [image: ano] Podpora wildcard https://www.ssls.cz/certifikaty/wildcard/?utm_source=nslt&utm_campaign=le1&utm_medium=email (zabezpečí ∞ subdomén) [image: ne] [image: ano] [image: ne] Možnost získat před spuštěním serveru [image: ne] [image: ano] [image: ano] Ochrana proti vystavení pro podvodný web [image: ne] [image: ano] [image: ano] Prestižní značka certifikátu [image: ne] [image: ano] [image: ano] Neomezený počet vystavených certifikátů [image: ne] [image: ano] [image: ano] Možnost zneplatnění certifikátů [image: ne] [image: ano] zdarma [image: ano] zdarma Pečeť pro vyšší důvěryhodnost [image: ne] [image: ano] statická [image: ano] dynamická Stabilní ekonomický model CA [image: ne] [image: ano] [image: ano] Zákaznická podpora [image: ne] [image: ano] 24H [image: ano] 24H Více… https://www.ssls.cz/certifikaty/positivessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email Více… https://www.ssls.cz/certifikaty/ev/?utm_source=nslt&utm_campaign=le1&utm_medium=email
*Jak situaci vyřešit*
Dotčeným zákazníkům důrazně doporučujeme *používat pouze důvěryhodné SSL certifikáty prověřených certifikačních autorit*, které uvedené nedostatky nemají a mají pro Vás i Vaše zákazníky důležitou přidanou hodnotu, mj.:
- AlpiroSSL
https://www.ssls.cz/certifikaty/alpiro/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- GlobalSign
https://www.ssls.cz/certifikaty/globalsign/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- PositiveSSL
https://www.ssls.cz/certifikaty/positivessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Comodo
https://www.ssls.cz/certifikaty/comodo/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- SpaceSSL
https://www.ssls.cz/certifikaty/spacessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Certum
https://www.ssls.cz/certifikaty/certum/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Symantec
https://www.ssls.cz/certifikaty/symantec/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Thawte
https://www.ssls.cz/certifikaty/thawte/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- GeoTrust
https://www.ssls.cz/certifikaty/geotrust/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- RapidSSL
https://www.ssls.cz/certifikaty/rapidssl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
Vyřešit nyní › https://www.ssls.cz/chci-https.html?utm_source=nslt&utm_campaign=le1&utm_medium=email
Hledáte-li *levné, ale kvalitní a spolehlivé řešení*, můžeme doporučit: *AlpiroSSL* — zabezpečí jednu doménu/subdoménu již za *139 Kč* / rok Koupit https://www.ssls.cz/certifikat/alpirossl.html?utm_source=nslt&utm_campaign=le1&utm_medium=email *AlpiroSSL Wildcard* — zabezpečí doménu a ∞ subdomén již za *990 Kč* / rok Koupit https://www.ssls.cz/certifikat/alpirossl-wildcard.html?utm_source=nslt&utm_campaign=le1&utm_medium=email *Comodo EV SSL* — zobrazuje zelený adresní řádek https://www.ssls.cz/zeleny.html?utm_source=nslt&utm_campaign=le1&utm_medium=email&utm_content=greenbar_table již za *1490 Kč* / rok Koupit https://www.ssls.cz/certifikat/ev-promo.html?utm_source=nslt&utm_campaign=le1&utm_medium=email Více SSL certifikátů… https://www.ssls.cz/certifikaty.html?utm_source=nslt&utm_campaign=le1&utm_medium=email Ceny uvedeny bez DPH.
Potřebujete-li v souvislosti s tímto incidentem poradit, popř. pomoci s výběrem nejvhodnějšího certifikátu, neváhejte se na nás kdykoliv obrátit na této e-mailové adrese. Děkujeme za Vaši důvěru.
S úctou a přáním pěkného dne,
[image: SSLs.cz]
*SSLS.CZ http://SSLS.CZ* SSL certifikáty | www.ssls.cz https://www.ssls.cz/?utm_source=nslt&utm_campaign=le1&utm_medium=email
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Mají i ssl test. Pár měsíců zpátky jsem se dostal k výsledkům testu na jeden web, test hlásil, že:
SSLv2 ne SSLv3 ne TLS1.0 ne TLS1.1 ne TLS1.2 ne
... tak nevim. Ale aspoň bylo dobré, že ten web nebyl zranitelný na "PoodleBleed"
Dneska si už stěžují jenom na nekompletní řetěz certifikátů od serveru, zřejmě tomu chybí kořenový certifikát autority, který ale server (AFAIK) posílat nemá - přinejmenším qualys ssllabs test ho hlásí jako chybu (plus když tam je, Windows na tom odmítnou WebDAV.)
On 28.11.2016 10:08, Martin Sivák wrote:
Ahoj,
dostal jsem úžasný email od ssls.cz ohledně Lets encrypt. Já jsem si samozřejmě vědom cílů a omezení Lets encrypt, ale tohle považuju za nefér FUD nejhrubšího zrna.
Dostal jste to ještě někdo?
Pokud jste někdo jejich zákazníkem, možná by neškodilo jim to trošku osvětlit. Jejich marketingové oddělení očividně panikaří, asi jim klesají zisky z certifikátů pro nedůležité služby.
Martin Sivák
---------- Přeposlaná zpráva ---------- Od: SSLS.CZ - Upozornění info@ssls.cz Datum: 27. listopadu 2016 11:21 Předmět: Upozornění: Zabezpečení domény (moje.marsik.org) Komu: mars@montik.net
Vážený zákazníku,
dovolte, abychom Vás upozornili na *nedostatečné* zabezpečení (HTTPS) Vaší domény:
moje.marsik.org
Aktuálně máte na serveru nainstalován SSL certifikát *Let's Encrypt*, který je sice zdarma, ovšem za cenu celé řady *vážných nedostatků*, mj. absenci finanční záruky, pečetě, diskutabilní podpoře prohlížeči a v neposlední řadě *nulové prestiži a důvěryhodnosti* v očích Vašich zákazníků.
Důležité je mít na paměti i skutečnost, že jsou certifikáty Let's Encrypt hojně zneužívané na nebezpečných stránkách, které se snaží *šířit škodlivý kód* nebo získat *přístupové informace do internetového bankovnictví* či konají jinou *trestnou činnost*. Hrozba pro běžného uživatele v souvislosti s Let's Encrypt je proto velmi aktuální téma (článek http://timehosting.cz/hackeri-zneuzili-bezplatne-ssl-certifikaty-lets-encrypt/ ).
Aby toho nebylo málo, v zákulisí se navíc pomalu začínají objevovat hlasy volající po nedůvěřování certifikátům Let's encrypt podobně, jako se tomu chystá u certifikátů StartCom a WoSign (více zde https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/). *Webové stránky se přestanou zobrazovat*. Namísto toho prohlížeč zobrazí varování o nedůvěryhodném certifikátu.
*Proč nepoužívat Let's Encrypt* Let's Encrypt PositiveSSL Comodo EV Platnost certifikátu jen 3 měsíce 1-3 roky 1-2 roky Podpora prohlížečů a zařízení ? 99.9% 99.9% Podpora 256 bit ECC (silné šifrování) [image: ne] [image: ano] [image: ano] [image: HTTPS] Zobrazuje zelený adresní řádek https://www.ssls.cz/zeleny.html?utm_source=nslt&utm_campaign=le1&utm_medium=email&utm_content=greenbar_bottom [image: ne] [image: ne] [image: ano] Finanční záruka https://www.ssls.cz/zaruka-ca.html?utm_source=nslt&utm_campaign=le1&utm_medium=email [image: ne] [image: ano] $10,000 [image: ano] $1,750,000 Vhodný pro komerční či firemní web, eshop [image: ne] [image: ano] [image: ano] Podpora IDN (domény s diakritikou) [image: ne] [image: ano] [image: ano] Podpora wildcard https://www.ssls.cz/certifikaty/wildcard/?utm_source=nslt&utm_campaign=le1&utm_medium=email (zabezpečí ∞ subdomén) [image: ne] [image: ano] [image: ne] Možnost získat před spuštěním serveru [image: ne] [image: ano] [image: ano] Ochrana proti vystavení pro podvodný web [image: ne] [image: ano] [image: ano] Prestižní značka certifikátu [image: ne] [image: ano] [image: ano] Neomezený počet vystavených certifikátů [image: ne] [image: ano] [image: ano] Možnost zneplatnění certifikátů [image: ne] [image: ano] zdarma [image: ano] zdarma Pečeť pro vyšší důvěryhodnost [image: ne] [image: ano] statická [image: ano] dynamická Stabilní ekonomický model CA [image: ne] [image: ano] [image: ano] Zákaznická podpora [image: ne] [image: ano] 24H [image: ano] 24H Více… https://www.ssls.cz/certifikaty/positivessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email Více… https://www.ssls.cz/certifikaty/ev/?utm_source=nslt&utm_campaign=le1&utm_medium=email
*Jak situaci vyřešit*
Dotčeným zákazníkům důrazně doporučujeme *používat pouze důvěryhodné SSL certifikáty prověřených certifikačních autorit*, které uvedené nedostatky nemají a mají pro Vás i Vaše zákazníky důležitou přidanou hodnotu, mj.:
- AlpiroSSL
https://www.ssls.cz/certifikaty/alpiro/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- GlobalSign
https://www.ssls.cz/certifikaty/globalsign/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- PositiveSSL
https://www.ssls.cz/certifikaty/positivessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Comodo
https://www.ssls.cz/certifikaty/comodo/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- SpaceSSL
https://www.ssls.cz/certifikaty/spacessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Certum
https://www.ssls.cz/certifikaty/certum/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Symantec
https://www.ssls.cz/certifikaty/symantec/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Thawte
https://www.ssls.cz/certifikaty/thawte/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- GeoTrust
https://www.ssls.cz/certifikaty/geotrust/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- RapidSSL
https://www.ssls.cz/certifikaty/rapidssl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
Vyřešit nyní › https://www.ssls.cz/chci-https.html?utm_source=nslt&utm_campaign=le1&utm_medium=email
Hledáte-li *levné, ale kvalitní a spolehlivé řešení*, můžeme doporučit: *AlpiroSSL* — zabezpečí jednu doménu/subdoménu již za *139 Kč* / rok Koupit https://www.ssls.cz/certifikat/alpirossl.html?utm_source=nslt&utm_campaign=le1&utm_medium=email *AlpiroSSL Wildcard* — zabezpečí doménu a ∞ subdomén již za *990 Kč* / rok Koupit https://www.ssls.cz/certifikat/alpirossl-wildcard.html?utm_source=nslt&utm_campaign=le1&utm_medium=email *Comodo EV SSL* — zobrazuje zelený adresní řádek https://www.ssls.cz/zeleny.html?utm_source=nslt&utm_campaign=le1&utm_medium=email&utm_content=greenbar_table již za *1490 Kč* / rok Koupit https://www.ssls.cz/certifikat/ev-promo.html?utm_source=nslt&utm_campaign=le1&utm_medium=email Více SSL certifikátů… https://www.ssls.cz/certifikaty.html?utm_source=nslt&utm_campaign=le1&utm_medium=email Ceny uvedeny bez DPH.
Potřebujete-li v souvislosti s tímto incidentem poradit, popř. pomoci s výběrem nejvhodnějšího certifikátu, neváhejte se na nás kdykoliv obrátit na této e-mailové adrese. Děkujeme za Vaši důvěru.
S úctou a přáním pěkného dne,
[image: SSLs.cz]
*SSLS.CZ http://SSLS.CZ* SSL certifikáty | www.ssls.cz https://www.ssls.cz/?utm_source=nslt&utm_campaign=le1&utm_medium=email
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Cele je to jenom o tom, ze se snazi podporit placene certifikaty.
Vetsine webu (e-shopy, osobni stranky, firmy apod) naprosto staci Let’s encrypt.
Tonouci se stebla chyta ….
Vitek
- 2016 v 12:45, Jirka Bourek vpsfree-list@keroub.cz:
Mají i ssl test. Pár měsíců zpátky jsem se dostal k výsledkům testu na jeden web, test hlásil, že:
SSLv2 ne SSLv3 ne TLS1.0 ne TLS1.1 ne TLS1.2 ne
... tak nevim. Ale aspoň bylo dobré, že ten web nebyl zranitelný na "PoodleBleed"
Dneska si už stěžují jenom na nekompletní řetěz certifikátů od serveru, zřejmě tomu chybí kořenový certifikát autority, který ale server (AFAIK) posílat nemá - přinejmenším qualys ssllabs test ho hlásí jako chybu (plus když tam je, Windows na tom odmítnou WebDAV.)
On 28.11.2016 10:08, Martin Sivák wrote:
Ahoj,
dostal jsem úžasný email od ssls.cz ohledně Lets encrypt. Já jsem si samozřejmě vědom cílů a omezení Lets encrypt, ale tohle považuju za nefér FUD nejhrubšího zrna.
Dostal jste to ještě někdo?
Pokud jste někdo jejich zákazníkem, možná by neškodilo jim to trošku osvětlit. Jejich marketingové oddělení očividně panikaří, asi jim klesají zisky z certifikátů pro nedůležité služby.
Martin Sivák
---------- Přeposlaná zpráva ---------- Od: SSLS.CZ - Upozornění info@ssls.cz Datum: 27. listopadu 2016 11:21 Předmět: Upozornění: Zabezpečení domény (moje.marsik.org) Komu: mars@montik.net
Vážený zákazníku,
dovolte, abychom Vás upozornili na *nedostatečné* zabezpečení (HTTPS) Vaší domény:
moje.marsik.org
Aktuálně máte na serveru nainstalován SSL certifikát *Let's Encrypt*, který je sice zdarma, ovšem za cenu celé řady *vážných nedostatků*, mj. absenci finanční záruky, pečetě, diskutabilní podpoře prohlížeči a v neposlední řadě *nulové prestiži a důvěryhodnosti* v očích Vašich zákazníků.
Důležité je mít na paměti i skutečnost, že jsou certifikáty Let's Encrypt hojně zneužívané na nebezpečných stránkách, které se snaží *šířit škodlivý kód* nebo získat *přístupové informace do internetového bankovnictví* či konají jinou *trestnou činnost*. Hrozba pro běžného uživatele v souvislosti s Let's Encrypt je proto velmi aktuální téma (článek http://timehosting.cz/hackeri-zneuzili-bezplatne-ssl-certifikaty-lets-encrypt/ ).
Aby toho nebylo málo, v zákulisí se navíc pomalu začínají objevovat hlasy volající po nedůvěřování certifikátům Let's encrypt podobně, jako se tomu chystá u certifikátů StartCom a WoSign (více zde https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/). *Webové stránky se přestanou zobrazovat*. Namísto toho prohlížeč zobrazí varování o nedůvěryhodném certifikátu.
*Proč nepoužívat Let's Encrypt* Let's Encrypt PositiveSSL Comodo EV Platnost certifikátu jen 3 měsíce 1-3 roky 1-2 roky Podpora prohlížečů a zařízení ? 99.9% 99.9% Podpora 256 bit ECC (silné šifrování) [image: ne] [image: ano] [image: ano] [image: HTTPS] Zobrazuje zelený adresní řádek https://www.ssls.cz/zeleny.html?utm_source=nslt&utm_campaign=le1&utm_medium=email&utm_content=greenbar_bottom [image: ne] [image: ne] [image: ano] Finanční záruka https://www.ssls.cz/zaruka-ca.html?utm_source=nslt&utm_campaign=le1&utm_medium=email [image: ne] [image: ano] $10,000 [image: ano] $1,750,000 Vhodný pro komerční či firemní web, eshop [image: ne] [image: ano] [image: ano] Podpora IDN (domény s diakritikou) [image: ne] [image: ano] [image: ano] Podpora wildcard https://www.ssls.cz/certifikaty/wildcard/?utm_source=nslt&utm_campaign=le1&utm_medium=email (zabezpečí ∞ subdomén) [image: ne] [image: ano] [image: ne] Možnost získat před spuštěním serveru [image: ne] [image: ano] [image: ano] Ochrana proti vystavení pro podvodný web [image: ne] [image: ano] [image: ano] Prestižní značka certifikátu [image: ne] [image: ano] [image: ano] Neomezený počet vystavených certifikátů [image: ne] [image: ano] [image: ano] Možnost zneplatnění certifikátů [image: ne] [image: ano] zdarma [image: ano] zdarma Pečeť pro vyšší důvěryhodnost [image: ne] [image: ano] statická [image: ano] dynamická Stabilní ekonomický model CA [image: ne] [image: ano] [image: ano] Zákaznická podpora [image: ne] [image: ano] 24H [image: ano] 24H Více… https://www.ssls.cz/certifikaty/positivessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email Více… https://www.ssls.cz/certifikaty/ev/?utm_source=nslt&utm_campaign=le1&utm_medium=email
*Jak situaci vyřešit*
Dotčeným zákazníkům důrazně doporučujeme *používat pouze důvěryhodné SSL certifikáty prověřených certifikačních autorit*, které uvedené nedostatky nemají a mají pro Vás i Vaše zákazníky důležitou přidanou hodnotu, mj.:
- AlpiroSSL
https://www.ssls.cz/certifikaty/alpiro/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- GlobalSign
https://www.ssls.cz/certifikaty/globalsign/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- PositiveSSL
https://www.ssls.cz/certifikaty/positivessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Comodo
https://www.ssls.cz/certifikaty/comodo/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- SpaceSSL
https://www.ssls.cz/certifikaty/spacessl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Certum
https://www.ssls.cz/certifikaty/certum/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Symantec
https://www.ssls.cz/certifikaty/symantec/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- Thawte
https://www.ssls.cz/certifikaty/thawte/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- GeoTrust
https://www.ssls.cz/certifikaty/geotrust/?utm_source=nslt&utm_campaign=le1&utm_medium=email
- RapidSSL
https://www.ssls.cz/certifikaty/rapidssl/?utm_source=nslt&utm_campaign=le1&utm_medium=email
Vyřešit nyní › https://www.ssls.cz/chci-https.html?utm_source=nslt&utm_campaign=le1&utm_medium=email
Hledáte-li *levné, ale kvalitní a spolehlivé řešení*, můžeme doporučit: *AlpiroSSL* — zabezpečí jednu doménu/subdoménu již za *139 Kč* / rok Koupit https://www.ssls.cz/certifikat/alpirossl.html?utm_source=nslt&utm_campaign=le1&utm_medium=email *AlpiroSSL Wildcard* — zabezpečí doménu a ∞ subdomén již za *990 Kč* / rok Koupit https://www.ssls.cz/certifikat/alpirossl-wildcard.html?utm_source=nslt&utm_campaign=le1&utm_medium=email *Comodo EV SSL* — zobrazuje zelený adresní řádek https://www.ssls.cz/zeleny.html?utm_source=nslt&utm_campaign=le1&utm_medium=email&utm_content=greenbar_table již za *1490 Kč* / rok Koupit https://www.ssls.cz/certifikat/ev-promo.html?utm_source=nslt&utm_campaign=le1&utm_medium=email Více SSL certifikátů… https://www.ssls.cz/certifikaty.html?utm_source=nslt&utm_campaign=le1&utm_medium=email Ceny uvedeny bez DPH.
Potřebujete-li v souvislosti s tímto incidentem poradit, popř. pomoci s výběrem nejvhodnějšího certifikátu, neváhejte se na nás kdykoliv obrátit na této e-mailové adrese. Děkujeme za Vaši důvěru.
S úctou a přáním pěkného dne,
[image: SSLs.cz]
*SSLS.CZ http://SSLS.CZ* SSL certifikáty | www.ssls.cz https://www.ssls.cz/?utm_source=nslt&utm_campaign=le1&utm_medium=email
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Dne 28.11.2016 v 12:45 Jirka Bourek napsal(a):
zřejmě tomu chybí kořenový certifikát autority, který ale server (AFAIK) posílat nemá
Určitě ho posílat nemá, protože je v každém případě zbytečný. Buď ho už klient má v prohlížeči a pak mu věří, nebo ho nemá a i on pak bude při poslání viset v nedůvěryhodném vakuu a je to k ničemu. Oni neposílají mezilehlý. Vydavatelem je „thawte SHA256 SSL CA“, ale to není kořenový certifikát. Musí existovat mezilehlá autorita vydaná „thawte Primary Root CA - G3“.
Ale to je klasický problém, protože pro admina je to obvykle neviditelné. Když má admin v prohlížeči naučený mezilehlý odjinud (což je obvyklé, protože on třeba navštívil web té samotné autority a ta mu mezilehlý ukázala), pak mu jeho špatně nakonfigurovaný web funguje a on má pocit, že je všechno v pořádku.
Ten jejich SSL Tester je jen marketingový nesmysl.
Jejich webu to dá hodnocení krásných "101%": https://www.ssls.cz/ssltest/www.ssls.cz Qualys ten web odepíše známkou "F" kvůli bezpečnostní díře: https://www.ssllabs.com/ssltest/analyze.html?d=www.ssls.cz
Můj web se u nich nedostane přes 70%, protože Let's Encrypt: https://www.ssls.cz/ssltest/www.fireport.eu Qualys mi pohodlně dá "A": https://www.ssllabs.com/ssltest/analyze.html?d=www.fireport.eu
SSL Tester od ssls.cz nemá žádnou hodnotu.
Dne 28. listopadu 2016 12:52 Petr Krcmar petr.krcmar@vpsfree.cz napsal(a):
Dne 28.11.2016 v 12:45 Jirka Bourek napsal(a):
zřejmě tomu chybí kořenový certifikát autority, který ale server (AFAIK) posílat nemá
Určitě ho posílat nemá, protože je v každém případě zbytečný. Buď ho už klient má v prohlížeči a pak mu věří, nebo ho nemá a i on pak bude při poslání viset v nedůvěryhodném vakuu a je to k ničemu. Oni neposílají mezilehlý. Vydavatelem je „thawte SHA256 SSL CA“, ale to není kořenový certifikát. Musí existovat mezilehlá autorita vydaná „thawte Primary Root CA - G3“.
Ale to je klasický problém, protože pro admina je to obvykle neviditelné. Když má admin v prohlížeči naučený mezilehlý odjinud (což je obvyklé, protože on třeba navštívil web té samotné autority a ta mu mezilehlý ukázala), pak mu jeho špatně nakonfigurovaný web funguje a on má pocit, že je všechno v pořádku.
-- Petr Krčmář vpsFree.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Díky, to mě fakt pobavilo, 101% a fail u Qualysu :)
On 28 Nov 2016, at 12:58, Vít Novák vit.novak@firepanel.cz wrote:
Ten jejich SSL Tester je jen marketingový nesmysl.
Jejich webu to dá hodnocení krásných "101%": https://www.ssls.cz/ssltest/www.ssls.cz https://www.ssls.cz/ssltest/www.ssls.cz Qualys ten web odepíše známkou "F" kvůli bezpečnostní díře: https://www.ssllabs.com/ssltest/analyze.html?d=www.ssls.cz https://www.ssllabs.com/ssltest/analyze.html?d=www.ssls.cz
Můj web se u nich nedostane přes 70%, protože Let's Encrypt: https://www.ssls.cz/ssltest/www.fireport.eu https://www.ssls.cz/ssltest/www.fireport.eu Qualys mi pohodlně dá "A": https://www.ssllabs.com/ssltest/analyze.html?d=www.fireport.eu https://www.ssllabs.com/ssltest/analyze.html?d=www.fireport.eu
SSL Tester od ssls.cz http://ssls.cz/ nemá žádnou hodnotu.
Dne 28. listopadu 2016 12:52 Petr Krcmar <petr.krcmar@vpsfree.cz mailto:petr.krcmar@vpsfree.cz> napsal(a): Dne 28.11.2016 v 12:45 Jirka Bourek napsal(a):
zřejmě tomu chybí kořenový certifikát autority, který ale server (AFAIK) posílat nemá
Určitě ho posílat nemá, protože je v každém případě zbytečný. Buď ho už klient má v prohlížeči a pak mu věří, nebo ho nemá a i on pak bude při poslání viset v nedůvěryhodném vakuu a je to k ničemu. Oni neposílají mezilehlý. Vydavatelem je „thawte SHA256 SSL CA“, ale to není kořenový certifikát. Musí existovat mezilehlá autorita vydaná „thawte Primary Root CA - G3“.
Ale to je klasický problém, protože pro admina je to obvykle neviditelné. Když má admin v prohlížeči naučený mezilehlý odjinud (což je obvyklé, protože on třeba navštívil web té samotné autority a ta mu mezilehlý ukázala), pak mu jeho špatně nakonfigurovaný web funguje a on má pocit, že je všechno v pořádku.
-- Petr Krčmář vpsFree.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz mailto:Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
to je už drzost ze stranmy ssls.cz! Když jsem komentoval na fb pod reklamou ssl marketu, taky moc nebyli nadšeni z Let's Encrypt a radši doporučovali jejich ssl. Že prý mají svůj certifikát taky zdarma - .
Dne 28. listopadu 2016 13:06 Nikos Timiopulos nikos@timi.cz napsal(a):
Díky, to mě fakt pobavilo, 101% a fail u Qualysu :)
On 28 Nov 2016, at 12:58, Vít Novák vit.novak@firepanel.cz wrote:
Ten jejich SSL Tester je jen marketingový nesmysl.
Jejich webu to dá hodnocení krásných "101%": https://www.ssls.cz/ ssltest/www.ssls.cz Qualys ten web odepíše známkou "F" kvůli bezpečnostní díře: https://www.ssllabs.com/ssltest/analyze.html?d=www.ssls.cz
Můj web se u nich nedostane přes 70%, protože Let's Encrypt: https://www.ssls.cz/ssltest/www.fireport.eu Qualys mi pohodlně dá "A": https://www.ssllabs.com/ ssltest/analyze.html?d=www.fireport.eu
SSL Tester od ssls.cz nemá žádnou hodnotu.
Dne 28. listopadu 2016 12:52 Petr Krcmar petr.krcmar@vpsfree.cz napsal(a):
Dne 28.11.2016 v 12:45 Jirka Bourek napsal(a):
zřejmě tomu chybí kořenový certifikát autority, který ale server (AFAIK) posílat nemá
Určitě ho posílat nemá, protože je v každém případě zbytečný. Buď ho už klient má v prohlížeči a pak mu věří, nebo ho nemá a i on pak bude při poslání viset v nedůvěryhodném vakuu a je to k ničemu. Oni neposílají mezilehlý. Vydavatelem je „thawte SHA256 SSL CA“, ale to není kořenový certifikát. Musí existovat mezilehlá autorita vydaná „thawte Primary Root CA - G3“.
Ale to je klasický problém, protože pro admina je to obvykle neviditelné. Když má admin v prohlížeči naučený mezilehlý odjinud (což je obvyklé, protože on třeba navštívil web té samotné autority a ta mu mezilehlý ukázala), pak mu jeho špatně nakonfigurovaný web funguje a on má pocit, že je všechno v pořádku.
-- Petr Krčmář vpsFree.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenosti
* PostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je vzdy read-only o přitom pouhou namátkou najdu dlouhý seznam nástrojů https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling, které nabízí spoustu možností * PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje) o nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředků
Jak to vidíte vy? Díky, Jarda
Ahoj,
Dne 30. listopadu 2016 8:34 Jaroslav Týc jaroslavtyc@atlas.cz napsal(a):
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenosti
- PostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze
Slave je vzdy read-only - přitom pouhou namátkou najdu dlouhý seznam nástrojů https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling, které nabízí spoustu možností
Každá z těch možností má svá pro a proti, nic z toho není ve smyslu vzít a
nasadit bez přemýšlení (to je asi jen ta varianta master slave kterou má postgre přímo v instalaci). Tzn. jde to ale je to náročnější na provoz a údržbu.
- PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti
MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje) - nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředků
To nedokážu posoudit, spíše je otázka co potřebujete z DB funkcí, co mysql
nemá?
Jak to vidíte vy? Díky, Jarda
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
David Linux server specialist/Heavy Ansible user www.karban.eu
Ahoj,
Z podobného důvodu jsme provozovali dva produkty cca měsíc jak na klasické mysql a postgre, oboje v HA s F5 balancerem (live replikace v active-active rezimu) a postgre byla narocnejsi v utilizaci cca o 10-15%.
Nicmene vyvojari si zvolili cestu pres postgre, takze uz nemuzu porovnat v ostrem provozu, ale na pilotu byl rozdil pomerne mizivy.
\M Odesláno z iPhonu
30. 11. 2016 v 8:51, David Karban david@karban.eu:
Ahoj,
Dne 30. listopadu 2016 8:34 Jaroslav Týc jaroslavtyc@atlas.cz napsal(a):
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenosti PostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je vzdy read-only přitom pouhou namátkou najdu dlouhý seznam nástrojů, které nabízí spoustu možností
Každá z těch možností má svá pro a proti, nic z toho není ve smyslu vzít a nasadit bez přemýšlení (to je asi jen ta varianta master slave kterou má postgre přímo v instalaci). Tzn. jde to ale je to náročnější na provoz a údržbu.
PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje) nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředků
To nedokážu posoudit, spíše je otázka co potřebujete z DB funkcí, co mysql nemá?
Jak to vidíte vy? Díky, Jarda
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
David Linux server specialist/Heavy Ansible user www.karban.eu
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Pocitově jsem byl na podobném rozdílu - při testech na lokální mašině.
Díky
On 11/30/2016 09:24 AM, Miroslav Marcišin wrote:
Ahoj,
Z podobného důvodu jsme provozovali dva produkty cca měsíc jak na klasické mysql a postgre, oboje v HA s F5 balancerem (live replikace v active-active rezimu) a postgre byla narocnejsi v utilizaci cca o 10-15%.
Nicmene vyvojari si zvolili cestu pres postgre, takze uz nemuzu porovnat v ostrem provozu, ale na pilotu byl rozdil pomerne mizivy.
\M Odesláno z iPhonu
- 2016 v 8:51, David Karban <david@karban.eu
Ahoj,
Dne 30. listopadu 2016 8:34 Jaroslav Týc <jaroslavtyc@atlas.cz mailto:jaroslavtyc@atlas.cz> napsal(a):
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenosti * PostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je vzdy read-only o přitom pouhou namátkou najdu dlouhý seznam nástrojů <https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling>, které nabízí spoustu možnostíKaždá z těch možností má svá pro a proti, nic z toho není ve smyslu vzít a nasadit bez přemýšlení (to je asi jen ta varianta master slave kterou má postgre přímo v instalaci). Tzn. jde to ale je to náročnější na provoz a údržbu.
o * PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje) o nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředkůTo nedokážu posoudit, spíše je otázka co potřebujete z DB funkcí, co mysql nemá?
Jak to vidíte vy? Díky, Jarda _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>David Linux server specialist/Heavy Ansible user www.karban.eu http://www.karban.eu/
Community-list mailing list Community-list@lists.vpsfree.cz mailto:Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Říkal jsem si že to bude hlavně náročnost nasazení, co poskytovatele odrazuje (že to ztíží i údržbu mě netrklo) - po zkušenostech s nimi s nestandardními požadavky zůstanu raději u základní verze, víc zatím nepotřebujeme.
PostgreSQL potřebujeme hlavně kvůli geolokaci (PostGIS), protože MySQL to neumí rozumně indexovat a jiné technologie (Redis, ElasticSearch) by se mi obtížněji propojovaly s dalšími daty v relační databázi.
On 11/30/2016 08:51 AM, David Karban wrote:
Ahoj,
Dne 30. listopadu 2016 8:34 Jaroslav Týc <jaroslavtyc@atlas.cz mailto:jaroslavtyc@atlas.cz> napsal(a):
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenosti * PostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je vzdy read-only o přitom pouhou namátkou najdu dlouhý seznam nástrojů <https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling>, které nabízí spoustu možnostíKaždá z těch možností má svá pro a proti, nic z toho není ve smyslu vzít a nasadit bez přemýšlení (to je asi jen ta varianta master slave kterou má postgre přímo v instalaci). Tzn. jde to ale je to náročnější na provoz a údržbu.
o * PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje) o nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředkůTo nedokážu posoudit, spíše je otázka co potřebujete z DB funkcí, co mysql nemá?
Jak to vidíte vy? Díky, Jarda _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>David Linux server specialist/Heavy Ansible user www.karban.eu http://www.karban.eu/
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Co se tyce provozu, rezie a nasazeni, tak jsem v tom z moji strany nepozoroval zadny rozdil. Jen obcas se delalo neco trosku jinak.
Samozrejme je otazka, zda to umi nebo to budou "googlit" :)
V ostrem provozu jsem to predal adminum, ja se o to staral jen instalace + pilot ale nemyslim ze tam jsou nejaky vetsi rozdily nez byly. Vecer zkusim schvalne kouknout do infovisty jestli tam neco vykoukam :)
\M
Odesláno z iPhonu
30. 11. 2016 v 9:37, Jaroslav Týc jaroslavtyc@atlas.cz:
Říkal jsem si že to bude hlavně náročnost nasazení, co poskytovatele odrazuje (že to ztíží i údržbu mě netrklo) - po zkušenostech s nimi s nestandardními požadavky zůstanu raději u základní verze, víc zatím nepotřebujeme.
PostgreSQL potřebujeme hlavně kvůli geolokaci (PostGIS), protože MySQL to neumí rozumně indexovat a jiné technologie (Redis, ElasticSearch) by se mi obtížněji propojovaly s dalšími daty v relační databázi.
On 11/30/2016 08:51 AM, David Karban wrote: Ahoj,
Dne 30. listopadu 2016 8:34 Jaroslav Týc jaroslavtyc@atlas.cz napsal(a):
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenosti PostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je vzdy read-only přitom pouhou namátkou najdu dlouhý seznam nástrojů, které nabízí spoustu možností
Každá z těch možností má svá pro a proti, nic z toho není ve smyslu vzít a nasadit bez přemýšlení (to je asi jen ta varianta master slave kterou má postgre přímo v instalaci). Tzn. jde to ale je to náročnější na provoz a údržbu.
PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje) nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředků
To nedokážu posoudit, spíše je otázka co potřebujete z DB funkcí, co mysql nemá?
Jak to vidíte vy? Díky, Jarda
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
David Linux server specialist/Heavy Ansible user www.karban.eu
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Kratce: sice to uz neni uplne pravda, ale postgres je databaze vhodna pro prumyslove/slozite komercni uziti a mysql je dobra tak na jednoduchsi weby.
Delseji: Postgres: nativne umi HA s master/slave rezimem. uz je i postregsXL ktera umi M2M. Ja osobne nemam rad veci M2M protoze ta rezije, co to obnasi neni uplne nejlepsi a aby nebyly konflikty, tak se stejne musi cekat na sync a ma to vice problemu.
Postgres ma velkou paletu moznosti, od psani procedur v C/C++, python, plpgsql, pocitani na GPU, ma hodne rozsireni, detailni moznosti si nastavit skoro kazdou ptakovinu. Da se s tim fakt zajimave vyhrat. Z toho vyplyva, ze konfigurace je taky vyrazne slozitejsi. Dobra sranda je napr. kopirovani databaze ze sablony :)
MySQL umi M2M nativne, ale technologicky background neni tak robustni, jako u postgres. Posledni test pri 3 MySQL nodech v M2M a soucasnem zapisu na vsechny 3 mista dostaval DB do dost divneho stavu.
Co se tyka rychlosti, tak zalezi na uziti a programatorovi. Postgres ma veci jako pridelena ram uzivateli a shared buffer, takze si muze strasne hodne casto pouzivanych veci zacachovat. Kdyz se spravne nastavi velikosti stranek, work mem, shared buffer a dalsi veci, co muzou dost brzdit, tak pri jednoduchych DB je asi rychlejsi MySQL, ale kdyz do toho narvu 100M zaznamu, tak uz mi postgres MySQL solidne valcovala.
2016-11-30 9:52 GMT+01:00 Miroslav Marcišin me@h00ked.cz:
Co se tyce provozu, rezie a nasazeni, tak jsem v tom z moji strany nepozoroval zadny rozdil. Jen obcas se delalo neco trosku jinak.
Samozrejme je otazka, zda to umi nebo to budou "googlit" :)
V ostrem provozu jsem to predal adminum, ja se o to staral jen instalace + pilot ale nemyslim ze tam jsou nejaky vetsi rozdily nez byly. Vecer zkusim schvalne kouknout do infovisty jestli tam neco vykoukam :)
\M
Odesláno z iPhonu
- 2016 v 9:37, Jaroslav Týc jaroslavtyc@atlas.cz:
Říkal jsem si že to bude hlavně náročnost nasazení, co poskytovatele odrazuje (že to ztíží i údržbu mě netrklo) - po zkušenostech s nimi s nestandardními požadavky zůstanu raději u základní verze, víc zatím nepotřebujeme.
PostgreSQL potřebujeme hlavně kvůli geolokaci (PostGIS), protože MySQL to neumí rozumně indexovat a jiné technologie (Redis, ElasticSearch) by se mi obtížněji propojovaly s dalšími daty v relační databázi.
On 11/30/2016 08:51 AM, David Karban wrote:
Ahoj,
Dne 30. listopadu 2016 8:34 Jaroslav Týc jaroslavtyc@atlas.cz napsal(a):
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenosti
- PostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze
Slave je vzdy read-only - přitom pouhou namátkou najdu dlouhý seznam nástrojů https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling, které nabízí spoustu možností
Každá z těch možností má svá pro a proti, nic z toho není ve smyslu vzít
a nasadit bez přemýšlení (to je asi jen ta varianta master slave kterou má postgre přímo v instalaci). Tzn. jde to ale je to náročnější na provoz a údržbu.
- PostgreSQL ma vyrazne vyssi naroky na systemove prostredky
oproti MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje) - nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředků
To nedokážu posoudit, spíše je otázka co potřebujete z DB funkcí, co
mysql nemá?
Jak to vidíte vy? Díky, Jarda
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
David Linux server specialist/Heavy Ansible user www.karban.eu
Community-list mailing listCommunity-list@lists.vpsfree.czhttp://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, Trochu OT, ale moc pěkný úvod do pgsql z pohledu nastavení a administrace je zde: https://www.youtube.com/watch?v=knUitQQnpJo
Tomáš A.
On 30. 11. 2016 13:52, Martin Miksanik wrote:
Kratce: sice to uz neni uplne pravda, ale postgres je databaze vhodna pro prumyslove/slozite komercni uziti a mysql je dobra tak na jednoduchsi weby.
Delseji: Postgres: nativne umi HA s master/slave rezimem. uz je i postregsXL ktera umi M2M. Ja osobne nemam rad veci M2M protoze ta rezije, co to obnasi neni uplne nejlepsi a aby nebyly konflikty, tak se stejne musi cekat na sync a ma to vice problemu.
Postgres ma velkou paletu moznosti, od psani procedur v C/C++, python, plpgsql, pocitani na GPU, ma hodne rozsireni, detailni moznosti si nastavit skoro kazdou ptakovinu. Da se s tim fakt zajimave vyhrat. Z toho vyplyva, ze konfigurace je taky vyrazne slozitejsi. Dobra sranda je napr. kopirovani databaze ze sablony :)
MySQL umi M2M nativne, ale technologicky background neni tak robustni, jako u postgres. Posledni test pri 3 MySQL nodech v M2M a soucasnem zapisu na vsechny 3 mista dostaval DB do dost divneho stavu.
Co se tyka rychlosti, tak zalezi na uziti a programatorovi. Postgres ma veci jako pridelena ram uzivateli a shared buffer, takze si muze strasne hodne casto pouzivanych veci zacachovat. Kdyz se spravne nastavi velikosti stranek, work mem, shared buffer a dalsi veci, co muzou dost brzdit, tak pri jednoduchych DB je asi rychlejsi MySQL, ale kdyz do toho narvu 100M zaznamu, tak uz mi postgres MySQL solidne valcovala.
2016-11-30 9:52 GMT+01:00 Miroslav Marcišin <me@h00ked.cz mailto:me@h00ked.cz>:
Co se tyce provozu, rezie a nasazeni, tak jsem v tom z moji strany nepozoroval zadny rozdil. Jen obcas se delalo neco trosku jinak. Samozrejme je otazka, zda to umi nebo to budou "googlit" :) V ostrem provozu jsem to predal adminum, ja se o to staral jen instalace + pilot ale nemyslim ze tam jsou nejaky vetsi rozdily nez byly. Vecer zkusim schvalne kouknout do infovisty jestli tam neco vykoukam :) \M Odesláno z iPhonu 30. 11. 2016 v 9:37, Jaroslav Týc <jaroslavtyc@atlas.cz <mailto:jaroslavtyc@atlas.cz>>:Říkal jsem si že to bude hlavně náročnost nasazení, co poskytovatele odrazuje (že to ztíží i údržbu mě netrklo) - po zkušenostech s nimi s nestandardními požadavky zůstanu raději u základní verze, víc zatím nepotřebujeme. PostgreSQL potřebujeme hlavně kvůli geolokaci (PostGIS), protože MySQL to neumí rozumně indexovat a jiné technologie (Redis, ElasticSearch) by se mi obtížněji propojovaly s dalšími daty v relační databázi. On 11/30/2016 08:51 AM, David Karban wrote:Ahoj, Dne 30. listopadu 2016 8:34 Jaroslav Týc <jaroslavtyc@atlas.cz <mailto:jaroslavtyc@atlas.cz>> napsal(a): Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenosti * PostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je vzdy read-only o přitom pouhou namátkou najdu dlouhý seznam nástrojů <https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling>, které nabízí spoustu možností Každá z těch možností má svá pro a proti, nic z toho není ve smyslu vzít a nasadit bez přemýšlení (to je asi jen ta varianta master slave kterou má postgre přímo v instalaci). Tzn. jde to ale je to náročnější na provoz a údržbu. o * PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje) o nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředků To nedokážu posoudit, spíše je otázka co potřebujete z DB funkcí, co mysql nemá? Jak to vidíte vy? Díky, Jarda _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list> David Linux server specialist/Heavy Ansible user www.karban.eu <http://www.karban.eu/> _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>-- S přáním pěkného dne, Martin Mikšaník gsm: +420 602 623 934 icq: 311047283
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Už k tomu taky směřujeme. Teď už právě máme M2M cluster a jakkoli doteď MySQL stačilo, tak nám uživatelů stále přibývá, takže pro úsporu času už nemáme ani cizí klíče a cítíme, že MySQL (respektive MariaDB) začíná být dýchavičné.
PostGIS je první krok při pozvolném přechodu na Postgre.
Díky za zkušenosti
On 11/30/2016 01:52 PM, Martin Miksanik wrote:
Kratce: sice to uz neni uplne pravda, ale postgres je databaze vhodna pro prumyslove/slozite komercni uziti a mysql je dobra tak na jednoduchsi weby.
Delseji: Postgres: nativne umi HA s master/slave rezimem. uz je i postregsXL ktera umi M2M. Ja osobne nemam rad veci M2M protoze ta rezije, co to obnasi neni uplne nejlepsi a aby nebyly konflikty, tak se stejne musi cekat na sync a ma to vice problemu.
Postgres ma velkou paletu moznosti, od psani procedur v C/C++, python, plpgsql, pocitani na GPU, ma hodne rozsireni, detailni moznosti si nastavit skoro kazdou ptakovinu. Da se s tim fakt zajimave vyhrat. Z toho vyplyva, ze konfigurace je taky vyrazne slozitejsi. Dobra sranda je napr. kopirovani databaze ze sablony :)
MySQL umi M2M nativne, ale technologicky background neni tak robustni, jako u postgres. Posledni test pri 3 MySQL nodech v M2M a soucasnem zapisu na vsechny 3 mista dostaval DB do dost divneho stavu.
Co se tyka rychlosti, tak zalezi na uziti a programatorovi. Postgres ma veci jako pridelena ram uzivateli a shared buffer, takze si muze strasne hodne casto pouzivanych veci zacachovat. Kdyz se spravne nastavi velikosti stranek, work mem, shared buffer a dalsi veci, co muzou dost brzdit, tak pri jednoduchych DB je asi rychlejsi MySQL, ale kdyz do toho narvu 100M zaznamu, tak uz mi postgres MySQL solidne valcovala.
2016-11-30 9:52 GMT+01:00 Miroslav Marcišin <me@h00ked.cz mailto:me@h00ked.cz>:
Co se tyce provozu, rezie a nasazeni, tak jsem v tom z moji strany nepozoroval zadny rozdil. Jen obcas se delalo neco trosku jinak. Samozrejme je otazka, zda to umi nebo to budou "googlit" :) V ostrem provozu jsem to predal adminum, ja se o to staral jen instalace + pilot ale nemyslim ze tam jsou nejaky vetsi rozdily nez byly. Vecer zkusim schvalne kouknout do infovisty jestli tam neco vykoukam :) \M Odesláno z iPhonu 30. 11. 2016 v 9:37, Jaroslav Týc <jaroslavtyc@atlas.cz <mailto:jaroslavtyc@atlas.cz>>:Říkal jsem si že to bude hlavně náročnost nasazení, co poskytovatele odrazuje (že to ztíží i údržbu mě netrklo) - po zkušenostech s nimi s nestandardními požadavky zůstanu raději u základní verze, víc zatím nepotřebujeme. PostgreSQL potřebujeme hlavně kvůli geolokaci (PostGIS), protože MySQL to neumí rozumně indexovat a jiné technologie (Redis, ElasticSearch) by se mi obtížněji propojovaly s dalšími daty v relační databázi. On 11/30/2016 08:51 AM, David Karban wrote:Ahoj, Dne 30. listopadu 2016 8:34 Jaroslav Týc <jaroslavtyc@atlas.cz <mailto:jaroslavtyc@atlas.cz>> napsal(a): Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenosti * PostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je vzdy read-only o přitom pouhou namátkou najdu dlouhý seznam nástrojů <https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling>, které nabízí spoustu možností Každá z těch možností má svá pro a proti, nic z toho není ve smyslu vzít a nasadit bez přemýšlení (to je asi jen ta varianta master slave kterou má postgre přímo v instalaci). Tzn. jde to ale je to náročnější na provoz a údržbu. o * PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje) o nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředků To nedokážu posoudit, spíše je otázka co potřebujete z DB funkcí, co mysql nemá? Jak to vidíte vy? Díky, Jarda _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list> David Linux server specialist/Heavy Ansible user www.karban.eu <http://www.karban.eu/> _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>-- S přáním pěkného dne, Martin Mikšaník gsm: +420 602 623 934 icq: 311047283
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Velice jednoduchý a stručný přehled vhodnosti databází je tady: http://howfuckedismydatabase.com/
Jinak osobně doporučuju místo MySQL používat Perconu - jejich XtraDB engine (InnoDB na steroidech) je výkonem někde trochu jinde a běžně používáme M2M konfiguraci, která ale neni balancovaná, tj. DB běží jako M2M, ale aplikace je v režimu failover s tím, že každá instance aplikace používá jiný master. Zní to hrozně, ale je to jednodušší než to vypadá :) Akorát je třeba ošetřit věci typu auto_increment a provozujeme to všechno v jednom DC, ideálně co nejblíž u sebe. M2M mezi datacentrama už je v případě MySQL/MariaDB/Percona na nasazení Galera Clusteru.
K postgersu se nevyjadřuju, sice ho trochu používam, ale jen v jedné instanci bez nějaký zásadní konfigurace..
-miky.
November 30 2016 8:38 AM, "Jaroslav Týc" jaroslavtyc@atlas.cz wrote:
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenostiPostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je vzdy read-onlypřitom pouhou namátkou najdu dlouhý seznam nástrojů, které nabízí spoustu možností
PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje)nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředků
Jak to vidíte vy? Díky, Jarda
Vo fetlife.com aktualne pouzivame Perconu v jednoduchom master slave setupe (1 master a 1 slave) a handlujeme v priemere 67k web requestov za minutu, co je v priemere 1.6M sql callov za minutu podla New Relic. A to aktualne ani nebalancujeme read requesty, cize vsetky requesty idu priamo na mastera.
Oba servery maju 2x 3GHz Intel Xeon-IvyBridge (E5-2690-V2-DecaCore) a 256GB RAM. Aktualne vyuzitie RAM na masterovi je 76% a priemerny CPU load je 0.14
Zaujimave clanky, ktore opisuju rozdiely medzi MySQL a Postgres a vhodnost pouzitia na rozdielne usecasy su este https://eng.uber.com/mysql-migration/ a https://www.postgresql.org/message-id/579795DF.10502@commandprompt.com (email thread).
Rene
2016-11-30 14:32 GMT+01:00 kuba@ufiseru.cz:
Velice jednoduchý a stručný přehled vhodnosti databází je tady: http://howfuckedismydatabase.com/
Jinak osobně doporučuju místo MySQL používat Perconu - jejich XtraDB engine (InnoDB na steroidech) je výkonem někde trochu jinde a běžně používáme M2M konfiguraci, která ale neni balancovaná, tj. DB běží jako M2M, ale aplikace je v režimu failover s tím, že každá instance aplikace používá jiný master. Zní to hrozně, ale je to jednodušší než to vypadá :) Akorát je třeba ošetřit věci typu auto_increment a provozujeme to všechno v jednom DC, ideálně co nejblíž u sebe. M2M mezi datacentrama už je v případě MySQL/MariaDB/Percona na nasazení Galera Clusteru.
K postgersu se nevyjadřuju, sice ho trochu používam, ale jen v jedné instanci bez nějaký zásadní konfigurace..
-miky.
November 30 2016 8:38 AM, "Jaroslav Týc" jaroslavtyc@atlas.cz wrote:
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL,
ovšem náš poskytovatel nás
od toho opakovaně zrazuje s následujícími argumenty, kterým příliš
nevěřím, rád bych se vás zeptal
na praktické zkušenostiPostgreSQL lze replikovat pouze v rezimu
Master-Slave s tim, ze Slave je
vzdy read-onlypřitom pouhou namátkou najdu dlouhý seznam nástrojů, které
nabízí spoustu možností
PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL
(predevsim RAM a rezie
spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim
poctem requestu casteji
forkuje)nevěřím, že pro stejná data a stejné queries spotřebuje
Postrgres výrazně více systémových
prostředků
Jak to vidíte vy? Díky, Jarda
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Máte někdo i nějaké porovnání MariaDB a Percony? Ono to vypadá, že MariaDB některé věci z Percony přebírá, ale úplně jsem nenašel co přesně.
Martin
Dne 1. prosince 2016 13:49 René Klačan rene.klacan@gmail.com napsal(a):
Vo fetlife.com aktualne pouzivame Perconu v jednoduchom master slave setupe (1 master a 1 slave) a handlujeme v priemere 67k web requestov za minutu, co je v priemere 1.6M sql callov za minutu podla New Relic. A to aktualne ani nebalancujeme read requesty, cize vsetky requesty idu priamo na mastera.
Oba servery maju 2x 3GHz Intel Xeon-IvyBridge (E5-2690-V2-DecaCore) a 256GB RAM. Aktualne vyuzitie RAM na masterovi je 76% a priemerny CPU load je 0.14
Zaujimave clanky, ktore opisuju rozdiely medzi MySQL a Postgres a vhodnost pouzitia na rozdielne usecasy su este https://eng.uber.com/mysql-migration/ a https://www.postgresql.org/message-id/579795DF.10502@commandprompt.com (email thread).
Rene
2016-11-30 14:32 GMT+01:00 kuba@ufiseru.cz:
Velice jednoduchý a stručný přehled vhodnosti databází je tady: http://howfuckedismydatabase.com/
Jinak osobně doporučuju místo MySQL používat Perconu - jejich XtraDB engine (InnoDB na steroidech) je výkonem někde trochu jinde a běžně používáme M2M konfiguraci, která ale neni balancovaná, tj. DB běží jako M2M, ale aplikace je v režimu failover s tím, že každá instance aplikace používá jiný master. Zní to hrozně, ale je to jednodušší než to vypadá :) Akorát je třeba ošetřit věci typu auto_increment a provozujeme to všechno v jednom DC, ideálně co nejblíž u sebe. M2M mezi datacentrama už je v případě MySQL/MariaDB/Percona na nasazení Galera Clusteru.
K postgersu se nevyjadřuju, sice ho trochu používam, ale jen v jedné instanci bez nějaký zásadní konfigurace..
-miky.
November 30 2016 8:38 AM, "Jaroslav Týc" jaroslavtyc@atlas.cz wrote:
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenostiPostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je vzdy read-onlypřitom pouhou namátkou najdu dlouhý seznam nástrojů, které nabízí spoustu možností
PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje)nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředků
Jak to vidíte vy? Díky, Jarda
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Muj soukromy subjektivni pocit je, ze Percona ma vyrazne lepsi vykon nez MariaDB. Kdykoliv byly problemy s databazi, tak po vymene MariaDB za Perconu se stejnou konfiguraci vetsina problemu zmizela.
Ale mozna ma Maria nejaky tunning optiony, ktere neznam a ktere byly spatne nastaveny.
Jarda
------ Původní zpráva ------ Od: "Martin Sivák" mars@montik.net Komu: "vpsFree.cz Community list" community-list@lists.vpsfree.cz Odesláno: 1.12.2016 14:19:53 Předmět: Re: [vpsFree.cz: community-list] MySQL vs PostgreSQL - systémové nároky a replikace
Máte někdo i nějaké porovnání MariaDB a Percony? Ono to vypadá, že MariaDB některé věci z Percony přebírá, ale úplně jsem nenašel co přesně.
Martin
Dne 1. prosince 2016 13:49 René Klačan rene.klacan@gmail.com napsal(a):
Vo fetlife.com aktualne pouzivame Perconu v jednoduchom master slave setupe (1 master a 1 slave) a handlujeme v priemere 67k web requestov za minutu, co je v priemere 1.6M sql callov za minutu podla New Relic. A to aktualne ani nebalancujeme read requesty, cize vsetky requesty idu priamo na mastera.
Oba servery maju 2x 3GHz Intel Xeon-IvyBridge (E5-2690-V2-DecaCore) a 256GB RAM. Aktualne vyuzitie RAM na masterovi je 76% a priemerny CPU load je 0.14
Zaujimave clanky, ktore opisuju rozdiely medzi MySQL a Postgres a vhodnost pouzitia na rozdielne usecasy su este https://eng.uber.com/mysql-migration/ a https://www.postgresql.org/message-id/579795DF.10502@commandprompt.com (email thread).
Rene
2016-11-30 14:32 GMT+01:00 kuba@ufiseru.cz:
Velice jednoduchý a stručný přehled vhodnosti databází je tady: http://howfuckedismydatabase.com/
Jinak osobně doporučuju místo MySQL používat Perconu - jejich XtraDB engine (InnoDB na steroidech) je výkonem někde trochu jinde a běžně používáme M2M konfiguraci, která ale neni balancovaná, tj. DB běží jako M2M, ale aplikace je v režimu failover s tím, že každá instance aplikace používá jiný master. Zní to hrozně, ale je to jednodušší než to vypadá :) Akorát je třeba ošetřit věci typu auto_increment a provozujeme to všechno v jednom DC, ideálně co nejblíž u sebe. M2M mezi datacentrama už je v případě MySQL/MariaDB/Percona na nasazení Galera Clusteru.
K postgersu se nevyjadřuju, sice ho trochu používam, ale jen v jedné instanci bez nějaký zásadní konfigurace..
-miky.
November 30 2016 8:38 AM, "Jaroslav Týc" jaroslavtyc@atlas.cz wrote:
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a
PostgreSQL,
ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenostiPostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je vzdy read-onlypřitom pouhou namátkou najdu dlouhý seznam nástrojů,
které
nabízí spoustu možností
PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti
MySQL
(predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se
vzrustajicim
poctem requestu casteji forkuje)nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředků
Jak to vidíte vy? Díky, Jarda
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Hmm, tak to je zajímavé shrnutí PostgreSQL problémů, díky za to.
On 12/01/2016 01:49 PM, René Klačan wrote:
Vo fetlife.com http://fetlife.com aktualne pouzivame Perconu v jednoduchom master slave setupe (1 master a 1 slave) a handlujeme v priemere 67k web requestov za minutu, co je v priemere 1.6M sql callov za minutu podla New Relic. A to aktualne ani nebalancujeme read requesty, cize vsetky requesty idu priamo na mastera.
Oba servery maju 2x 3GHz Intel Xeon-IvyBridge (E5-2690-V2-DecaCore) a 256GB RAM. Aktualne vyuzitie RAM na masterovi je 76% a priemerny CPU load je 0.14
Zaujimave clanky, ktore opisuju rozdiely medzi MySQL a Postgres a vhodnost pouzitia na rozdielne usecasy su este https://eng.uber.com/mysql-migration/ a https://www.postgresql.org/message-id/579795DF.10502@commandprompt.com (email thread).
Rene
2016-11-30 14:32 GMT+01:00 <kuba@ufiseru.cz mailto:kuba@ufiseru.cz>:
Velice jednoduchý a stručný přehled vhodnosti databází je tady: http://howfuckedismydatabase.com/ <http://howfuckedismydatabase.com/> Jinak osobně doporučuju místo MySQL používat Perconu - jejich XtraDB engine (InnoDB na steroidech) je výkonem někde trochu jinde a běžně používáme M2M konfiguraci, která ale neni balancovaná, tj. DB běží jako M2M, ale aplikace je v režimu failover s tím, že každá instance aplikace používá jiný master. Zní to hrozně, ale je to jednodušší než to vypadá :) Akorát je třeba ošetřit věci typu auto_increment a provozujeme to všechno v jednom DC, ideálně co nejblíž u sebe. M2M mezi datacentrama už je v případě MySQL/MariaDB/Percona na nasazení Galera Clusteru. K postgersu se nevyjadřuju, sice ho trochu používam, ale jen v jedné instanci bez nějaký zásadní konfigurace.. -miky. November 30 2016 8:38 AM, "Jaroslav Týc" <jaroslavtyc@atlas.cz <mailto:jaroslavtyc@atlas.cz>> wrote: > Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás > od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal > na praktické zkušenostiPostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je > vzdy read-onlypřitom pouhou namátkou najdu dlouhý seznam nástrojů, které nabízí spoustu možností > > PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie > spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji > forkuje)nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových > prostředků > > Jak to vidíte vy? > Díky, Jarda _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Este na MySQL scaling sa da pouzit https://github.com/youtube/vitess , co je riesenie priamo vyvijane a podporovane Googlom (Youtube). Ak vas to zaujalo, tak na youtube je tiez par talkov opisujucich, ako to funguje a ake to ma drawbacks. Podla ich slov to scaluje MySQL na desattisice nodov. Nemam to este prakticke vyskusane, ale planujem v blizskej buducnosti.
2016-12-01 16:59 GMT+01:00 Jaroslav Týc jaroslavtyc@atlas.cz:
Hmm, tak to je zajímavé shrnutí PostgreSQL problémů, díky za to.
On 12/01/2016 01:49 PM, René Klačan wrote:
Vo fetlife.com aktualne pouzivame Perconu v jednoduchom master slave setupe (1 master a 1 slave) a handlujeme v priemere 67k web requestov za minutu, co je v priemere 1.6M sql callov za minutu podla New Relic. A to aktualne ani nebalancujeme read requesty, cize vsetky requesty idu priamo na mastera.
Oba servery maju 2x 3GHz Intel Xeon-IvyBridge (E5-2690-V2-DecaCore) a 256GB RAM. Aktualne vyuzitie RAM na masterovi je 76% a priemerny CPU load je 0.14
Zaujimave clanky, ktore opisuju rozdiely medzi MySQL a Postgres a vhodnost pouzitia na rozdielne usecasy su este https://eng.uber.com/mysql-migration/https://eng.uber.com/ mysql-migration/ a https://www.postgresql.org/message-id/579795DF.10502@ commandprompt.com (email thread).
Rene
2016-11-30 14:32 GMT+01:00 kuba@ufiseru.cz:
Velice jednoduchý a stručný přehled vhodnosti databází je tady: http://howfuckedismydatabase.com/http://howfuckedismydatabase.com/
Jinak osobně doporučuju místo MySQL používat Perconu - jejich XtraDB engine (InnoDB na steroidech) je výkonem někde trochu jinde a běžně používáme M2M konfiguraci, která ale neni balancovaná, tj. DB běží jako M2M, ale aplikace je v režimu failover s tím, že každá instance aplikace používá jiný master. Zní to hrozně, ale je to jednodušší než to vypadá :) Akorát je třeba ošetřit věci typu auto_increment a provozujeme to všechno v jednom DC, ideálně co nejblíž u sebe. M2M mezi datacentrama už je v případě MySQL/MariaDB/Percona na nasazení Galera Clusteru.
K postgersu se nevyjadřuju, sice ho trochu používam, ale jen v jedné instanci bez nějaký zásadní konfigurace..
-miky.
November 30 2016 8:38 AM, "Jaroslav Týc" < jaroslavtyc@atlas.cz jaroslavtyc@atlas.cz> wrote:
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL,
ovšem náš poskytovatel nás
od toho opakovaně zrazuje s následujícími argumenty, kterým příliš
nevěřím, rád bych se vás zeptal
na praktické zkušenostiPostgreSQL lze replikovat pouze v rezimu
Master-Slave s tim, ze Slave je
vzdy read-onlypřitom pouhou namátkou najdu dlouhý seznam nástrojů,
které nabízí spoustu možností
PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL
(predevsim RAM a rezie
spojena s pouzivanim shared memory) a na CPU (PostgreSQL se
vzrustajicim poctem requestu casteji
forkuje)nevěřím, že pro stejná data a stejné queries spotřebuje
Postrgres výrazně více systémových
prostředků
Jak to vidíte vy? Díky, Jarda
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing listCommunity-list@lists.vpsfree.czhttp://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
do téhle diskuze jsem nechtěl vstupovat, ale když tu vidím odkaz na článek https://eng.uber.com/mysql-migration/ https://eng.uber.com/mysql-migration/, tak už musím. Ten článek je plný technických chyb, polopravd a zcestných závěrů. Zkrátka jeho autor pořádně nezná architekturu PostgreSQL, nepřečetl si dostatečně pozorně ani dokumentaci, navíc má zkušenosti jen z již historické verze, a vyvozuje z toho nějaké aktuální závěry.
Velice fundovanou odpověď na to sepsal Simon Riggs z 2ndQuadrant: http://blog.2ndquadrant.com/thoughts-on-ubers-list-of-postgres-limitations/ http://blog.2ndquadrant.com/thoughts-on-ubers-list-of-postgres-limitations/. Pokud by přesto někdo měl pochybnosti, mohu ho zkontaktovat s Pavlem Stěhule, který se k tomu jistě rád vyjádří.
Jinak ještě k tématu diskuze – vybírat si mezi MySQL a PostgreSQL podle systémových nároků mi přijde dost mimo, tedy pokud neřešíte použití v embedded zařízení (tam pak ale nedávají smysl obě možnosti). Osobně bych MySQL nikam, kde potřebujete plnohodnotnou (objektově-)relační databázi s ACID, nedoporučoval.
Jakub J.
On 1. Dec 2016, at 16:59, Jaroslav Týc jaroslavtyc@atlas.cz wrote:
Hmm, tak to je zajímavé shrnutí PostgreSQL problémů, díky za to.
On 12/01/2016 01:49 PM, René Klačan wrote:
Vo fetlife.com http://fetlife.com/ aktualne pouzivame Perconu v jednoduchom master slave setupe (1 master a 1 slave) a handlujeme v priemere 67k web requestov za minutu, co je v priemere 1.6M sql callov za minutu podla New Relic. A to aktualne ani nebalancujeme read requesty, cize vsetky requesty idu priamo na mastera.
Oba servery maju 2x 3GHz Intel Xeon-IvyBridge (E5-2690-V2-DecaCore) a 256GB RAM. Aktualne vyuzitie RAM na masterovi je 76% a priemerny CPU load je 0.14
Zaujimave clanky, ktore opisuju rozdiely medzi MySQL a Postgres a vhodnost pouzitia na rozdielne usecasy su este https://eng.uber.com/mysql-migration/https://eng.uber.com/mysql-migration/ https://eng.uber.com/mysql-migration/ a https://www.postgresql.org/message-id/579795DF.10502@commandprompt.com https://www.postgresql.org/message-id/579795DF.10502@commandprompt.com (email thread).
Rene
2016-11-30 14:32 GMT+01:00 <kuba@ufiseru.cz mailto:kuba@ufiseru.cz>: Velice jednoduchý a stručný přehled vhodnosti databází je tady: http://howfuckedismydatabase.com/http://howfuckedismydatabase http://howfuckedismydatabase/.com/
Jinak osobně doporučuju místo MySQL používat Perconu - jejich XtraDB engine (InnoDB na steroidech) je výkonem někde trochu jinde a běžně používáme M2M konfiguraci, která ale neni balancovaná, tj. DB běží jako M2M, ale aplikace je v režimu failover s tím, že každá instance aplikace používá jiný master. Zní to hrozně, ale je to jednodušší než to vypadá :) Akorát je třeba ošetřit věci typu auto_increment a provozujeme to všechno v jednom DC, ideálně co nejblíž u sebe. M2M mezi datacentrama už je v případě MySQL/MariaDB/Percona na nasazení Galera Clusteru.
K postgersu se nevyjadřuju, sice ho trochu používam, ale jen v jedné instanci bez nějaký zásadní konfigurace..
-miky.
November 30 2016 8:38 AM, "Jaroslav Týc" < mailto:jaroslavtyc@atlas.czjaroslavtyc@atlas.cz mailto:jaroslavtyc@atlas.cz> wrote:
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal na praktické zkušenostiPostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je vzdy read-onlypřitom pouhou namátkou najdu dlouhý seznam nástrojů, které nabízí spoustu možností
PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji forkuje)nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových prostředků
Jak to vidíte vy? Díky, Jarda
Community-list mailing list Community-list@lists.vpsfree.cz mailto:Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz mailto:Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
do téhle diskuze jsem nechtěl vstupovat, ale když tu vidím odkaz na
článek https://eng.uber.com/mysql-migration/, tak už musím. Ten článek je plný technických chyb, polopravd a zcestných závěrů. Zkrátka jeho autor pořádně nezná architekturu PostgreSQL, nepřečetl si dostatečně pozorně ani dokumentaci, navíc má zkušenosti jen z již historické verze, a vyvozuje z toho nějaké aktuální závěry.
Zcasti suhlasim, preto som rovno k nemu pridal aj link na mailing list vyvojarov postgresql, kde to oni rozoberaju :)
2016-12-01 18:48 GMT+01:00 Jakub Jirutka jakub@jirutka.cz:
Ahoj,
do téhle diskuze jsem nechtěl vstupovat, ale když tu vidím odkaz na článek https://eng.uber.com/mysql-migration/, tak už musím. Ten článek je plný technických chyb, polopravd a zcestných závěrů. Zkrátka jeho autor pořádně nezná architekturu PostgreSQL, nepřečetl si dostatečně pozorně ani dokumentaci, navíc má zkušenosti jen z již historické verze, a vyvozuje z toho nějaké aktuální závěry.
Velice fundovanou odpověď na to sepsal Simon Riggs z 2ndQuadrant: http://blog.2ndquadrant.com/thoughts-on-ubers-list-of-postgres- limitations/. Pokud by přesto někdo měl pochybnosti, mohu ho zkontaktovat s Pavlem Stěhule, který se k tomu jistě rád vyjádří.
Jinak ještě k tématu diskuze – vybírat si mezi MySQL a PostgreSQL podle systémových nároků mi přijde dost mimo, tedy pokud neřešíte použití v embedded zařízení (tam pak ale nedávají smysl obě možnosti). Osobně bych MySQL nikam, kde potřebujete plnohodnotnou (objektově-)relační databázi s ACID, nedoporučoval.
Jakub J.
On 1. Dec 2016, at 16:59, Jaroslav Týc jaroslavtyc@atlas.cz wrote:
Hmm, tak to je zajímavé shrnutí PostgreSQL problémů, díky za to.
On 12/01/2016 01:49 PM, René Klačan wrote:
Vo fetlife.com aktualne pouzivame Perconu v jednoduchom master slave setupe (1 master a 1 slave) a handlujeme v priemere 67k web requestov za minutu, co je v priemere 1.6M sql callov za minutu podla New Relic. A to aktualne ani nebalancujeme read requesty, cize vsetky requesty idu priamo na mastera.
Oba servery maju 2x 3GHz Intel Xeon-IvyBridge (E5-2690-V2-DecaCore) a 256GB RAM. Aktualne vyuzitie RAM na masterovi je 76% a priemerny CPU load je 0.14
Zaujimave clanky, ktore opisuju rozdiely medzi MySQL a Postgres a vhodnost pouzitia na rozdielne usecasy su este https://eng.uber.com/mysql-migration/https://eng.uber.com/ mysql-migration/ a https://www.postgresql.org/message-id/579795DF.10502@ commandprompt.com (email thread).
Rene
2016-11-30 14:32 GMT+01:00 kuba@ufiseru.cz:
Velice jednoduchý a stručný přehled vhodnosti databází je tady: http://howfuckedismydatabase.com/http://howfuckedismydatabase.com/
Jinak osobně doporučuju místo MySQL používat Perconu - jejich XtraDB engine (InnoDB na steroidech) je výkonem někde trochu jinde a běžně používáme M2M konfiguraci, která ale neni balancovaná, tj. DB běží jako M2M, ale aplikace je v režimu failover s tím, že každá instance aplikace používá jiný master. Zní to hrozně, ale je to jednodušší než to vypadá :) Akorát je třeba ošetřit věci typu auto_increment a provozujeme to všechno v jednom DC, ideálně co nejblíž u sebe. M2M mezi datacentrama už je v případě MySQL/MariaDB/Percona na nasazení Galera Clusteru.
K postgersu se nevyjadřuju, sice ho trochu používam, ale jen v jedné instanci bez nějaký zásadní konfigurace..
-miky.
November 30 2016 8:38 AM, "Jaroslav Týc" < jaroslavtyc@atlas.cz jaroslavtyc@atlas.cz> wrote:
Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL,
ovšem náš poskytovatel nás
od toho opakovaně zrazuje s následujícími argumenty, kterým příliš
nevěřím, rád bych se vás zeptal
na praktické zkušenostiPostgreSQL lze replikovat pouze v rezimu
Master-Slave s tim, ze Slave je
vzdy read-onlypřitom pouhou namátkou najdu dlouhý seznam nástrojů,
které nabízí spoustu možností
PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL
(predevsim RAM a rezie
spojena s pouzivanim shared memory) a na CPU (PostgreSQL se
vzrustajicim poctem requestu casteji
forkuje)nevěřím, že pro stejná data a stejné queries spotřebuje
Postrgres výrazně více systémových
prostředků
Jak to vidíte vy? Díky, Jarda
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing listCommunity-list@lists.vpsfree.czhttp://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Obzory se rozšiřují, díky
On 12/01/2016 06:48 PM, Jakub Jirutka wrote:
Ahoj,
do téhle diskuze jsem nechtěl vstupovat, ale když tu vidím odkaz na článek https://eng.uber.com/mysql-migration/, tak už musím. Ten článek je plný technických chyb, polopravd a zcestných závěrů. Zkrátka jeho autor pořádně nezná architekturu PostgreSQL, nepřečetl si dostatečně pozorně ani dokumentaci, navíc má zkušenosti jen z již historické verze, a vyvozuje z toho nějaké aktuální závěry.
Velice fundovanou odpověď na to sepsal Simon Riggs z 2ndQuadrant: http://blog.2ndquadrant.com/thoughts-on-ubers-list-of-postgres-limitations/. Pokud by přesto někdo měl pochybnosti, mohu ho zkontaktovat s Pavlem Stěhule, který se k tomu jistě rád vyjádří.
Jinak ještě k tématu diskuze – vybírat si mezi MySQL a PostgreSQL podle systémových nároků mi přijde dost mimo, tedy pokud neřešíte použití v embedded zařízení (tam pak ale nedávají smysl obě možnosti). Osobně bych MySQL nikam, kde potřebujete plnohodnotnou (objektově-)relační databázi s ACID, nedoporučoval.
Jakub J.
On 1. Dec 2016, at 16:59, Jaroslav Týc <jaroslavtyc@atlas.cz mailto:jaroslavtyc@atlas.cz> wrote:
Hmm, tak to je zajímavé shrnutí PostgreSQL problémů, díky za to.
On 12/01/2016 01:49 PM, René Klačan wrote:
Vo fetlife.com http://fetlife.com/ aktualne pouzivame Perconu v jednoduchom master slave setupe (1 master a 1 slave) a handlujeme v priemere 67k web requestov za minutu, co je v priemere 1.6M sql callov za minutu podla New Relic. A to aktualne ani nebalancujeme read requesty, cize vsetky requesty idu priamo na mastera.
Oba servery maju 2x 3GHz Intel Xeon-IvyBridge (E5-2690-V2-DecaCore) a 256GB RAM. Aktualne vyuzitie RAM na masterovi je 76% a priemerny CPU load je 0.14
Zaujimave clanky, ktore opisuju rozdiely medzi MySQL a Postgres a vhodnost pouzitia na rozdielne usecasy su este https://eng.uber.com/mysql-migration/ a https://www.postgresql.org/message-id/579795DF.10502@commandprompt.com (email thread).
Rene
2016-11-30 14:32 GMT+01:00 <kuba@ufiseru.cz mailto:kuba@ufiseru.cz>:
Velice jednoduchý a stručný přehled vhodnosti databází je tady: http://howfuckedismydatabase.com/ Jinak osobně doporučuju místo MySQL používat Perconu - jejich XtraDB engine (InnoDB na steroidech) je výkonem někde trochu jinde a běžně používáme M2M konfiguraci, která ale neni balancovaná, tj. DB běží jako M2M, ale aplikace je v režimu failover s tím, že každá instance aplikace používá jiný master. Zní to hrozně, ale je to jednodušší než to vypadá :) Akorát je třeba ošetřit věci typu auto_increment a provozujeme to všechno v jednom DC, ideálně co nejblíž u sebe. M2M mezi datacentrama už je v případě MySQL/MariaDB/Percona na nasazení Galera Clusteru. K postgersu se nevyjadřuju, sice ho trochu používam, ale jen v jedné instanci bez nějaký zásadní konfigurace.. -miky. November 30 2016 8:38 AM, "Jaroslav Týc" <jaroslavtyc@atlas.cz> wrote: > Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás > od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal > na praktické zkušenostiPostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je > vzdy read-onlypřitom pouhou namátkou najdu dlouhý seznam nástrojů, které nabízí spoustu možností > > PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie > spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji > forkuje)nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových > prostředků > > Jak to vidíte vy? > Díky, Jarda _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz mailto:Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, můj aktuální postoj je takový, že MySQL a jeho klony dávám jen tam, kde to musí být (někdo to vysloveně požaduje nebo to musí běžet v prostředí, kde nic než MySQL není). Jinak používám PostgreSQL, který se ukazuje být naprosto spolehlivý (včetně replikace - zatím jsem ale používal jen master-slave), což se o MySQL říct rozhodně nedá - tam už jsem se peklil s kde čím, včetně záhadně padajících replikací.
Lukáš Jelínek
Obzory se rozšiřují, díky
On 12/01/2016 06:48 PM, Jakub Jirutka wrote:
Ahoj,
do téhle diskuze jsem nechtěl vstupovat, ale když tu vidím odkaz na článek https://eng.uber.com/mysql-migration/, tak už musím. Ten článek je plný technických chyb, polopravd a zcestných závěrů. Zkrátka jeho autor pořádně nezná architekturu PostgreSQL, nepřečetl si dostatečně pozorně ani dokumentaci, navíc má zkušenosti jen z již historické verze, a vyvozuje z toho nějaké aktuální závěry.
Velice fundovanou odpověď na to sepsal Simon Riggs z 2ndQuadrant: http://blog.2ndquadrant.com/thoughts-on-ubers-list-of-postgres-limitations/. Pokud by přesto někdo měl pochybnosti, mohu ho zkontaktovat s Pavlem Stěhule, který se k tomu jistě rád vyjádří.
Jinak ještě k tématu diskuze – vybírat si mezi MySQL a PostgreSQL podle systémových nároků mi přijde dost mimo, tedy pokud neřešíte použití v embedded zařízení (tam pak ale nedávají smysl obě možnosti). Osobně bych MySQL nikam, kde potřebujete plnohodnotnou (objektově-)relační databázi s ACID, nedoporučoval.
Jakub J.
On 1. Dec 2016, at 16:59, Jaroslav Týc jaroslavtyc@atlas.cz wrote:
Hmm, tak to je zajímavé shrnutí PostgreSQL problémů, díky za to.
On 12/01/2016 01:49 PM, René Klačan wrote:
Vo fetlife.com http://fetlife.com/ aktualne pouzivame Perconu v jednoduchom master slave setupe (1 master a 1 slave) a handlujeme v priemere 67k web requestov za minutu, co je v priemere 1.6M sql callov za minutu podla New Relic. A to aktualne ani nebalancujeme read requesty, cize vsetky requesty idu priamo na mastera.
Oba servery maju 2x 3GHz Intel Xeon-IvyBridge (E5-2690-V2-DecaCore) a 256GB RAM. Aktualne vyuzitie RAM na masterovi je 76% a priemerny CPU load je 0.14
Zaujimave clanky, ktore opisuju rozdiely medzi MySQL a Postgres a vhodnost pouzitia na rozdielne usecasy su este https://eng.uber.com/mysql-migration/ a https://www.postgresql.org/message-id/579795DF.10502@commandprompt.com (email thread).
Rene
2016-11-30 14:32 GMT+01:00 kuba@ufiseru.cz:
Velice jednoduchý a stručný přehled vhodnosti databází je tady: http://howfuckedismydatabase.com/ Jinak osobně doporučuju místo MySQL používat Perconu - jejich XtraDB engine (InnoDB na steroidech) je výkonem někde trochu jinde a běžně používáme M2M konfiguraci, která ale neni balancovaná, tj. DB běží jako M2M, ale aplikace je v režimu failover s tím, že každá instance aplikace používá jiný master. Zní to hrozně, ale je to jednodušší než to vypadá :) Akorát je třeba ošetřit věci typu auto_increment a provozujeme to všechno v jednom DC, ideálně co nejblíž u sebe. M2M mezi datacentrama už je v případě MySQL/MariaDB/Percona na nasazení Galera Clusteru. K postgersu se nevyjadřuju, sice ho trochu používam, ale jen v jedné instanci bez nějaký zásadní konfigurace.. -miky. November 30 2016 8:38 AM, "Jaroslav Týc" <jaroslavtyc@atlas.cz> wrote: > Ahoj, řešíme souběžné nasazení MySQL (respektive MariaDB) a PostgreSQL, ovšem náš poskytovatel nás > od toho opakovaně zrazuje s následujícími argumenty, kterým příliš nevěřím, rád bych se vás zeptal > na praktické zkušenostiPostgreSQL lze replikovat pouze v rezimu Master-Slave s tim, ze Slave je > vzdy read-onlypřitom pouhou namátkou najdu dlouhý seznam nástrojů, které nabízí spoustu možností > > PostgreSQL ma vyrazne vyssi naroky na systemove prostredky oproti MySQL (predevsim RAM a rezie > spojena s pouzivanim shared memory) a na CPU (PostgreSQL se vzrustajicim poctem requestu casteji > forkuje)nevěřím, že pro stejná data a stejné queries spotřebuje Postrgres výrazně více systémových > prostředků > > Jak to vidíte vy? > Díky, Jarda _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>
community-list@lists.vpsfree.cz
-
David Karban -
Jakub Jirutka -
Jaroslav Skřivan -
Jaroslav Týc -
Jirka Bourek -
kuba＠ufiseru.cz -
Lukáš Jelínek - AIKEN -
Martin Miksanik -
Martin Sivák -
Miroslav Marcišin -
Nikos Timiopulos -
Petr Krcmar -
Petr Parolek -
René Klačan -
Tomáš Antecký -
Vít Novák -
Vítězslav Tajzich