Hola Lucas, mis respuestas en rojo On Sun, Oct 13, 2019 at 4:23 AM Lucas Luengas <lucasluen...@gmail.com> wrote:
> Hola. > Respondiendo de forma genérica, insisto en lo de "genérica", a tu pregunta > de si puede afectar pg_basebackup al rendimiento, te diré que sí. Es > normal, porque consume recursos: cpu, disco, red, en servidor principal y > en servidor secundario. > > ¿Cuánto afecta? Supongo que depende de muchos factores. Yo para estos > casos lo vigilo con comandos top e iotop para ver los recursos que va > consumiendo pg_basebackup. Además, si puedo, intento usarlo en momentos de > poca actividad, para reducir el impacto sobre el sistema (y por lo tanto a > los usuarios). > > Varias preguntas: > 1- ¿La replicación es síncrona o asíncrona? Asincronica > 2- ¿Qué parámetros pasas a pg_basebackup? Yo en bases de datos un poco > grandes suelo usar este comando que muestro continuación. Lo lanzo desde el > secundario contra el primario. En el secundario tengo el servicio de > postgres parado. > pg_basebackup -h ip_serv2 -D /pgsql_data/9.6/data/ -P -U replication_user -R --xlog-method=stream > > pg_basebackup -h direccionipdelprimario -D /var/lib/pgsql/9.6/data -P -U > userrepliacion --xlog-method=stream > > 3- Las conexiones a postgres de tu sistema, ¿se realizan todas al servidor > principal, o hay conexiones también de lectura a alguno de los servidores > secundarios? > En estos momentos todas las operaciones de lectura y escritura van al > servidor primario serv1 > Un saludo. > > Gracias por tus comentarios > On Sun, Oct 13, 2019 at 2:19 AM Carlos T. Groero Carmona < > cton...@gmail.com> wrote: > >> Hola Lista, >> >> Dejenme introducir un porquito lo que esta pasando, en estos momentos >> estamos usando un DC, pero estamos estamos dando algunos pasos firmes para >> movernos para Azure, por lo que tengo 4 servidores en production y 3 mas en >> hold. >> >> Que significa esto: >> serv1 es mi servidor primario (location 1) >> serv2 es mi HA (location 1) >> serv3 va a ser mi servidor primario en Azure (Location 2) >> serv4 es mi DR (location3) >> >> Estoy replicando (SR) desde : >> * serv1->serv2 >> Estoy Cascading replication: >> * serv2->serv3 >> * serv2->serv4 >> >> Pero cuando teniamos graves incidentes (P1) hace unos meses, se decidio >> rentar servidores nuevos con mayor capacidad, y por otras rasones se >> exagero en la capidad, los nuevos servidores tienen: >> CPU: 114 (74 cores, 2 Thread per Core) >> RAM: 790 Gb >> Disk 10 TB (RAID 10) >> OS: CentOS 7.x >> >> Mi actual servidor primario tiene: >> CPU: 48 (24 Cores * 2 thread) >> RAM: 790 GB >> Disk 5TB (RAID 10) >> OS: CentOS 7.x >> >> En todos los casos uso PostgreSQL 9.6 >> >> En estos momentos estamos estables gracias a la correcta configuration de >> pgBouncer y solo en los momentos picos alcanzamos un 60% del uso del CPU, >> nuestro average es un 45%, asi que no se necesita utilizar los nuevos >> servidores, PERO, se ha decido ponerlos en hot standby por si se llega a >> necesitar en un futuro cercano, ya que como quiera se esta pagando por >> ellos. >> >> Asi que intente poner uno de estos nuevos servidores detrás de serv2 y se >> vio affectado el tiempo de respuesta del sistema, trate de ponerlo detras >> de serv1 y fue peor la affectation, en todo momento apenas que >> pg_basebackup empezo a copiar los datos se disparo el % de utilizaicon de l >> disco en serv1 o serv2 asi que detuve el pg_basebackup. >> >> En un escenario pues lo deje correr detras de serv2 porque se affecto el >> tiempo de respuesta de postgres serca de 3 veces mas pero no impacto mucho >> el tiempo de respuesta del sistema, una vez que termino el pg_basebackup >> todo funciono correctamente y el tiempo de respuesta del sistema regreso a >> su normalidad. >> >> Mi hypotesis es que el monstrou de servidor nuevo esta chupandose todo el >> I/O a traves de pg_basebackup. Tienen ustedes alguna otra idea? >> >> Si tienen alguna pregunta dejenme saber, tengo ulgunas imagenes de mi >> herramienta de monitoreo.. >> >> Lo curioso es que las TPS no se vieron afectadas ni las queries por >> segundo. >> >> Como siempre cualquier sugerencia o explicacion sera apreciada. >> >> Saludos, >> Carlos >> >> >> >
