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

28. 11. 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

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

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, 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

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

30. 11. 2016 v 8:51, David Karban <david@karban.eu <mailto: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

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

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

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

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

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

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.cz>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 <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

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