Hellmuth Vargas escribió: > Hola Alvaro > > Mil gracias por la repuesta pero precisamente ese es el problema, como > tengo consultas concurrentes de diversos orígenes, tener la replica con > retraso produce que la información no este actualizada para estos > clientes, con el hot_standby_feedback ha mejorado esto muchísimo pues no se > afectan tanto los clientes con la ejecución de consultas tanto largas y > cortas. Ahora el asunto es que tengo dos replicas para consultas, en ambas > debería poner el hot_standby_feedback en on? actualmente solo lo tengo en > una de las dos y todo va bien en la que lo tiene habilitado... me preocupa > que al ponerlo activo en la otra afecte la master...
No sé ... quizás considera separar responsabilidades: una réplica (o una familia de réplicas) es para HA y consultas con datos frescos y por lo tanto debería(n) tener poco lag; entonces tendría que tener hot_standby_feedback activo, pero el tiempo permisible de retardo es bajo; llamémoslo "de tipo 1". En cambio el otro standby (o los otros standbys), de tipo 2, podría(n) servirte para consultas más lentas, al cual no le activas hot_standby_feedback, pero sí le activas max_streaming_standby_delay. Puede estar muy atrasado respecto al primario, pero a los clientes no les importa mucho, y no afecta a vacuum en el primario. Lo complicado será asegurarte de mandar cada tipo cliente al tipo de réplica correcto. Si te mandas consultas del tipo 2 a las réplicas de tipo 1, van a tener muchas queries canceladas. Si mandas consultas de tipo 1 a réplicas de tipo 2, van a recibir resultados atrasados. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
