PostgreSQL és potser el més popular base de dades de codi obert al món, i el seu augment durant l'última dècada ha estat gens menys que notable. La seva amplitud i fiabilitat criden l'atenció de grans organitzacions consolidades. A més, és un sistema de gestió de bases de dades gratuït i de codi obert. Això serveix com a principal punt de venda entre les petites empreses que operen amb un pressupost.
Dit això, tots aquests avantatges no vénen sense cap altra cara. PostgreSQL, com qualsevol altre mainstream DBMS, té els seus inconvenients que tots els desenvolupadors haurien de conèixer per endavant. En aquest article es discutiran els problemes més habituals als quals s’enfronten els desenvolupadors de PostgreSQL i les millors maneres d’eludir-los.
Problemes de rendiment
No hi ha un únic sistema de gestió de bases de dades que no experimenti problemes ocasionals de rendiment. PostgreSQL no és propens a aquests problemes, però es produeixen de tant en tant, i és aconsellable que qualsevol administrador de sistemes sàpiga identificar-los i eliminar-los.
Molts desenvolupadors i administradors de sistemes pensen que l'ajust de paràmetres a postgresql.conf és l'única manera d'eliminar els problemes de rendiment. Tot i que els paràmetres de configuració poden ser beneficiosos, no sempre us portaran a l'arrel del problema. En molts casos, el problema al final diferirà del que us centreu.
Algunes persones utilitzen la vista pg_stat_statements per detectar consultes lentes mirant els seus temps de càrrega. Altres ho prefereixen Expliqueu PostgreSQL, que és venerat per oferir un desglossament de consultes més precís i inclusiu. Juntament amb Analyze, la funció ajuda a augmentar Client PostgreSQL rendiment mostrant el pla d'execució generat pel planificador de PostgreSQL i mostrant el temps d'execució.
Problemes de retard de replicació
Els casos de problemes de retard de replicació són pocs i distants, però el seu gran impacte en el rendiment de l'aplicació fa que valgui la pena incloure-los en aquesta llista. Identificar els retards de replicació de PostgreSQL és una tasca raonablement fàcil, però hi ha diverses maneres d'observar el problema, que poden determinar la manera més adequada de resoldre'l.
PostgreSQL utilitza la replicació en temps real, una característica introduïda a la versió 9.0, que hauria de fer-ho ràpid, ja que els canvis es registren com una sèrie de registres exactament tal com els intercepta el receptor WAL. Un cop aquests registres de registre s'han introduït al fitxer WAL, el procés d'inici de PostgreSQL reprodueix aquestes dades i comença el procés de replicació en temps real.
La majoria dels desfasaments es produeixen quan Segment WAL no es pot trobar o hi ha problemes de xarxa, problemes de configuració, maquinari defectuós o assentaments ocupats. Podeu utilitzar la utilitat pg_stat_replication per obtenir una vista de l'estat de la rèplica en temps real. També s'ha demostrat que ClusterControl ajuda amb la supervisió del node de la base de dades.
Temps d'inactivitat en actualitzar l'esquema
Actualitzar un esquema de base de dades PostgreSQL és fàcil si podeu anar fora de línia mentre ho feu. Només cal que tanqueu l’aplicació, creeu una còpia de seguretat d’esquemes, realitzeu les operacions d’actualització, reviseu i proveu el vostre treball i reinicieu l’aplicació, amb l’esperança de tenir-ho tot bé.
Tot i això, les coses no seran tan fàcils si la naturalesa de la vostra sol·licitud ho requereix temps d'inactivitat zero. Això requereix un procediment complex i multifàsic que pot implicar l’ús d’un enfocament compatible amb les versions anteriors per canviar la base de dades. L’objectiu és fer que la base de dades es pugui utilitzar tant a la vostra versió antiga com a la nova.
Per a les operacions de migració que no són compatibles cap enrere, podeu dividir-les en passos més petits per crear una base de dades que les dues versions de l'aplicació puguin utilitzar. Sovint, això requereix que l'usuari creï una nova taula, vista o columna, que utilitzarà la nova versió de l'aplicació.
Engranatge de seguretat
En primer lloc, deixeu clar que la base de dades PostgreSQL ofereix alguns dels millors seguretat de les dades funcions per al vostre servidor i dades. El problema apareix quan arriba el moment d’identificar-los i desplegar-los.
L'enduriment de la seguretat a PostgreSQL es pot dividir en tres categories: configuració del servidor, xifratge de dades i configuració de xarxa. Sempre és recomanable realitzar el xifratge de dades en vol i en repòs. Per al xifratge de dades en vol, l'accés a la base de dades del client s'ha de configurar per utilitzar SSL. El servidor també hauria de requerir o acceptar connexions segures.
El xifratge en repòs es pot realitzar en moltes fases diferents de la pila; el lloc on s'implementa estarà determinat principalment pels requisits d'infraestructura i aplicació. El mòdul pgcrypto s'utilitza per a propòsits de xifratge i desxifrat a nivell de base de dades. La tècnica és útil com a últim recurs quan no hi ha cap altre mètode de xifratge viable i s'han de xifrar conjunts específics de dades.
Els administradors sempre poden xifrar dades a nivell de núvol o de sistema de fitxers: un enfocament més fluït i amb menys impacte en el rendiment.
El risc de pèrdua de dades
Tot i que hi ha moltes maneres de reduir el risc de pèrdua de dades, mai no podeu reduir aquesta possibilitat a zero. Per tant, tots els administradors de bases de dades han de tenir una estratègia de còpia de seguretat sòlida per garantir que les aplicacions estiguin en funcionament i funcionin tan aviat com sigui possible després d'a ciberatac, un succés catastròfic o un problema d'integritat de dades.
Les còpies de seguretat de dades haurien de ser el centre de qualsevol estratègia de gestió de bases de dades. Per als usuaris de PostgreSQL, hi ha diverses maneres de configurar una estratègia de còpia de seguretat, en funció de les preferències i altres factors funcionals. Per exemple, la funció incorporada pg_dump es pot utilitzar per crear còpies de seguretat periòdiques amb instal·lació de màquines virtuals o bare metal en absència d'una capa de servei gestionada. La sortida pg_dump està formada per un fitxer de text que podeu emmagatzemar en una plataforma no connectada a la base de dades i recuperar-lo més tard quan els xips estiguin inactius. L’operació de recuperació de dades sol ser simplement fer que el fitxer estigui disponible per al programa PostgreSQL com a entrada.
Tot i que utilitzar pg_dump és ideal per a plans de còpia de seguretat formulats per l'usuari, serveis en el núvol com Stratoscale SMD i AWS RDS proporcionen còpies de seguretat i recuperació de desastres com a funcions integrades, de manera que no us haureu de preocupar de crear una estratègia de còpia de seguretat des de zero.
Nota final
La gestió de bases de dades només és senzilla si encerta la fase de planificació i coneixeu els reptes quotidians i les estratègies de mitigació viables. Tant de bo, els consells anteriors us ajudaran a preparar-vos per als problemes i a recuperar-vos ràpidament i sense problemes.
