Re: Puede pg_basebackup afectar performace?

Hola Lucas, mis respuestas en rojo

On Sun, Oct 13, 2019 at 4:23 AM Lucas Luengas <lucasluengas(at)gmail(dot)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 <
> ctonetg(at)gmail(dot)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
>>
>>
>>
>