{"id":93878,"date":"2020-09-10T19:42:02","date_gmt":"2020-09-10T17:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie"},"modified":"2020-09-10T19:42:02","modified_gmt":"2020-09-10T17:42:02","slug":"kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","title":{"rendered":"Come integrare una PostgreSQL 'libera' in un rigido ambiente enterprise","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Molti sono familiarit\u00e0 con il DBMS PostgreSQL, e ha dimostrato di essere eccellente in piccole installazioni. Tuttavia, la tendenza al passaggio a soluzioni Open Source \u00e8 diventata sempre pi\u00f9 evidente, anche quando si parla di grandi aziende e requisiti enterprise. In questo articolo, parleremo di come integrare Postgres in un ambiente aziendale e condivideremo l'esperienza di creare un sistema di backup (SRK) per questo database utilizzando come esempio il sistema di backup Commvault. <\/p>\n

\"Come
\nPostgreSQL ha gi\u00e0 dimostrato la propria efficacia: il DBMS funziona perfettamente, \u00e8 utilizzato da aziende digitali alla moda come Alibaba e TripAdvisor, e l'assenza di costi di licenza la rende un'alternativa attraente a giganti come MS SQL o Oracle DB. Ma non appena iniziamo a considerare PostgreSQL nel contesto enterprise, ci troviamo subito di fronte a requisiti rigidi: \u00abE la resilienza della configurazione? La resilienza ai disastri? Dove sono il monitoraggio completo? E il backup automatico? E l'uso di librerie a nastro sia per il salvataggio diretto che per il secondo spazio di archiviazione?\u00bb
\n<\/a><\/noindex>
\n\"Come
\nDa un lato, PostgreSQL non ha strumenti di backup integrati come i \"grandi\" DBMS come RMAN di Oracle DB o SAP Database Backup. Dall'altro, i fornitori di sistemi di backup aziendali (Veeam, Veritas, Commvault) supportano anche PostgreSQL, ma in realt\u00e0 lavorano solo con configurazioni specifiche (di solito standalone) e con una serie di limitazioni. <\/p>\n

Sistemi di backup progettati specificamente per PostgreSQL, come Barman, Wal-g, pg_probackup, sono estremamente popolari in piccole installazioni del DBMS PostgreSQL o dove non sono necessari pesanti backup di altri elementi del panorama IT. Ad esempio, oltre a PostgreSQL, l'infrastruttura pu\u00f2 includere fisici e virtuali servers<\/a>, OpenShift, Oracle, MariaDB, Cassandra, ecc. \u00c8 preferibile eseguire il backup di tutto con uno strumento comune. Implementare una soluzione separata esclusivamente per PostgreSQL \u00e8 una cattiva idea: i dati verranno copiati su un disco e poi dovranno essere trasferiti su nastro. Questa duplicazione del backup aumenta i tempi di backup e, cosa pi\u00f9 critica, di ripristino.<\/p>\n

Nella soluzione enterprise, il backup dell'installazione avviene con un certo numero di nodi di un cluster dedicato. Ad esempio, Commvault pu\u00f2 lavorare solo con un cluster a due nodi, in cui il Primary e il Secondary sono rigidamente assegnati a nodi specifici. Inoltre, ha senso fare il backup solo dal Primary, poich\u00e9 il backup dal Secondary ha le sue limitazioni. A causa delle peculiarit\u00e0 del DBMS, il dump non viene creato sul Secondary, quindi rimane solo la possibilit\u00e0 del backup file-based.<\/p>\n

Per ridurre i rischi di inattivit\u00e0, durante la creazione di un sistema fault-tolerant viene generata una configurazione di cluster \"live\", e il Primary pu\u00f2 migrare gradualmente tra diversi server. Ad esempio, il software Patroni avvia automaticamente il Primary su un nodo scelto casualmente del cluster. Il SRK non ha modi per monitorare questo \"out of the box\", e quindi, se la configurazione cambia, i processi si rompono. In altre parole, l'implementazione di una gestione esterna ostacola l'efficacia del SRK, poich\u00e9 il server di gestione non comprende semplicemente da dove e quali dati debbano essere copiati.<\/p>\n

Un altro problema \u00e8 l'implementazione del backup in Postgres. \u00c8 possibile tramite dump, e su piccole basi funziona. Ma con grandi DB, il dump richiede molto tempo, consuma molte risorse e pu\u00f2 portare a un'interruzione dell'istanza del DB.<\/p>\n

Il backup file-based migliora la situazione, ma su grandi basi avviene lentamente, poich\u00e9 funziona in modalit\u00e0 singolo-thread. Inoltre, i fornitori impongono una serie di ulteriori limitazioni. Ad esempio, non \u00e8 possibile utilizzare contemporaneamente il backup file-based e il backup tramite dump, oppure la deduplicazione non \u00e8 supportata. Ci sono molti problemi, e spesso \u00e8 pi\u00f9 semplice scegliere un DBMS costoso ma collaudato piuttosto che Postgres.<\/p>\n

Non c'\u00e8 tempo per indietreggiare! I programmatori di Mosca sono dietro di noi!<\/h2>\n

\nTuttavia, recentemente il nostro team si \u00e8 trovato di fronte a una sfida non facile: nel progetto di creazione dell'AIS OSAGO 2.0, dove abbiamo realizzato l'infrastruttura IT, gli sviluppatori della nuova sistema hanno scelto PostgreSQL. <\/p>\n

Per i grandi sviluppatori di software \u00e8 molto pi\u00f9 semplice utilizzare soluzioni open-source \"alla moda\". Nel staff di Facebook ci sono abbastanza specialisti che supportano il funzionamento di questo DBMS. Nel caso del RCA, tutte le attivit\u00e0 del \"giorno due\" ricadevano sulle nostre spalle. Da noi ci si aspettava di garantire la fault-tolerance, di assemblare un cluster e, naturalmente, di organizzare il backup. La logica delle azioni era questa: <\/p>\n