Replicación / Envío de servidores

max_replication_slots

max_slot_wal_keep_size

max_wal_senders

Notas específicas de Azure

El valor predeterminado del parámetro de servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database for PostgreSQL nunca debe reducirse por debajo de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

Al considerar la necesidad de aumentar max_wal_senders a un valor mucho mayor para poder hacer frente a la replicación lógica de un número considerable de tablas, tenga en cuenta los siguientes puntos importantes:

• La replicación lógica de un gran número de tablas no necesita necesariamente un gran número de remitentes WAL.
• La única razón por la que necesita un remitente WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos.
• No importa el número de remitentes WAL que se usen para la replicación física y lógica, todos se activan a la vez, siempre que cualquier back-end escriba algo en el registro de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
  1. Descodificar todos los registros nuevos en WAL,
  2. Filtrar los registros de registro que no les interesen,
  3. Replicar los datos relevantes para cada uno de ellos.
• Los remitentes WAL son similares a las conexiones en el sentido de que, si están inactivos, no importa cuántos hay. Sin embargo, si están activos, solo competirán por los mismos recursos y el rendimiento podría acabar siendo terriblemente malo. Esto es especialmente cierto para los remitentes con replicación lógica, ya que la descodificación lógica es bastante costosa para la CPU. Cada trabajador tiene que descodificar todo el WAL, incluso si solo replica las operaciones que afectan a una sola tabla y que representa un pequeño porcentaje de todos los datos del registro de escritura anticipada. En el caso de la replicación física, no es tan importante, ya que los remitentes WAL no consumen CPU de forma tan intensiva y tienden a estar limitados por el ancho de banda de red primero.
• Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
• Se recomienda agregar espacio a algunos remitentes WAL adicionales para dar cabida a los picos de crecimiento futuros o temporales en las conexiones de replicación. Los dos ejemplos siguientes pueden ayudar a ilustrarlo mejor.
  • Para un servidor con 8 núcleos virtuales, alta disponibilidad deshabilitada, 2 réplicas de lectura y 3 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (0) + ranuras físicas para réplicas de lectura (2) + ranuras lógicas(3) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (1) = 6.
  • Para un servidor con 16 núcleos virtuales, alta disponibilidad habilitada, 4 réplicas de lectura y 5 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (2) + ranuras físicas para réplicas de lectura (4) + ranuras lógicas (5) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (2) = 13.
• Si sigue considerando que el valor máximo permitido para este parámetro es demasiado bajo para sus necesidades, póngase en contacto con nosotros, describa su escenario en detalle y explique lo que considere que sería el valor mínimo aceptable que necesitaría para que su escenario funcione correctamente.

track_commit_timestamp

wal_keep_size

wal_sender_timeout

max_replication_slots

max_slot_wal_keep_size

max_wal_senders

Notas específicas de Azure

El valor predeterminado del parámetro de servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database for PostgreSQL nunca debe reducirse por debajo de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

Al considerar la necesidad de aumentar max_wal_senders a un valor mucho mayor para poder hacer frente a la replicación lógica de un número considerable de tablas, tenga en cuenta los siguientes puntos importantes:

• La replicación lógica de un gran número de tablas no necesita necesariamente un gran número de remitentes WAL.
• La única razón por la que necesita un remitente WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos.
• No importa el número de remitentes WAL que se usen para la replicación física y lógica, todos se activan a la vez, siempre que cualquier back-end escriba algo en el registro de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
  1. Descodificar todos los registros nuevos en WAL,
  2. Filtrar los registros de registro que no les interesen,
  3. Replicar los datos relevantes para cada uno de ellos.
• Los remitentes WAL son similares a las conexiones en el sentido de que, si están inactivos, no importa cuántos hay. Sin embargo, si están activos, solo competirán por los mismos recursos y el rendimiento podría acabar siendo terriblemente malo. Esto es especialmente cierto para los remitentes con replicación lógica, ya que la descodificación lógica es bastante costosa para la CPU. Cada trabajador tiene que descodificar todo el WAL, incluso si solo replica las operaciones que afectan a una sola tabla y que representa un pequeño porcentaje de todos los datos del registro de escritura anticipada. En el caso de la replicación física, no es tan importante, ya que los remitentes WAL no consumen CPU de forma tan intensiva y tienden a estar limitados por el ancho de banda de red primero.
• Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
• Se recomienda agregar espacio a algunos remitentes WAL adicionales para dar cabida a los picos de crecimiento futuros o temporales en las conexiones de replicación. Los dos ejemplos siguientes pueden ayudar a ilustrarlo mejor.
  • Para un servidor con 8 núcleos virtuales, alta disponibilidad deshabilitada, 2 réplicas de lectura y 3 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (0) + ranuras físicas para réplicas de lectura (2) + ranuras lógicas(3) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (1) = 6.
  • Para un servidor con 16 núcleos virtuales, alta disponibilidad habilitada, 4 réplicas de lectura y 5 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (2) + ranuras físicas para réplicas de lectura (4) + ranuras lógicas (5) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (2) = 13.
• Si sigue considerando que el valor máximo permitido para este parámetro es demasiado bajo para sus necesidades, póngase en contacto con nosotros, describa su escenario en detalle y explique lo que considere que sería el valor mínimo aceptable que necesitaría para que su escenario funcione correctamente.

track_commit_timestamp

wal_keep_size

wal_sender_timeout

max_replication_slots

max_slot_wal_keep_size

max_wal_senders

Notas específicas de Azure

El valor predeterminado del parámetro de servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database for PostgreSQL nunca debe reducirse por debajo de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

Al considerar la necesidad de aumentar max_wal_senders a un valor mucho mayor para poder hacer frente a la replicación lógica de un número considerable de tablas, tenga en cuenta los siguientes puntos importantes:

• La replicación lógica de un gran número de tablas no necesita necesariamente un gran número de remitentes WAL.
• La única razón por la que necesita un remitente WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos.
• No importa el número de remitentes WAL que se usen para la replicación física y lógica, todos se activan a la vez, siempre que cualquier back-end escriba algo en el registro de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
  1. Descodificar todos los registros nuevos en WAL,
  2. Filtrar los registros de registro que no les interesen,
  3. Replicar los datos relevantes para cada uno de ellos.
• Los remitentes WAL son similares a las conexiones en el sentido de que, si están inactivos, no importa cuántos hay. Sin embargo, si están activos, solo competirán por los mismos recursos y el rendimiento podría acabar siendo terriblemente malo. Esto es especialmente cierto para los remitentes con replicación lógica, ya que la descodificación lógica es bastante costosa para la CPU. Cada trabajador tiene que descodificar todo el WAL, incluso si solo replica las operaciones que afectan a una sola tabla y que representa un pequeño porcentaje de todos los datos del registro de escritura anticipada. En el caso de la replicación física, no es tan importante, ya que los remitentes WAL no consumen CPU de forma tan intensiva y tienden a estar limitados por el ancho de banda de red primero.
• Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
• Se recomienda agregar espacio a algunos remitentes WAL adicionales para dar cabida a los picos de crecimiento futuros o temporales en las conexiones de replicación. Los dos ejemplos siguientes pueden ayudar a ilustrarlo mejor.
  • Para un servidor con 8 núcleos virtuales, alta disponibilidad deshabilitada, 2 réplicas de lectura y 3 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (0) + ranuras físicas para réplicas de lectura (2) + ranuras lógicas(3) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (1) = 6.
  • Para un servidor con 16 núcleos virtuales, alta disponibilidad habilitada, 4 réplicas de lectura y 5 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (2) + ranuras físicas para réplicas de lectura (4) + ranuras lógicas (5) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (2) = 13.
• Si sigue considerando que el valor máximo permitido para este parámetro es demasiado bajo para sus necesidades, póngase en contacto con nosotros, describa su escenario en detalle y explique lo que considere que sería el valor mínimo aceptable que necesitaría para que su escenario funcione correctamente.

track_commit_timestamp

wal_keep_size

wal_sender_timeout

max_replication_slots

max_slot_wal_keep_size

max_wal_senders

Notas específicas de Azure

El valor predeterminado del parámetro de servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database for PostgreSQL nunca debe reducirse por debajo de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

Al considerar la necesidad de aumentar max_wal_senders a un valor mucho mayor para poder hacer frente a la replicación lógica de un número considerable de tablas, tenga en cuenta los siguientes puntos importantes:

• La replicación lógica de un gran número de tablas no necesita necesariamente un gran número de remitentes WAL.
• La única razón por la que necesita un remitente WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos.
• No importa el número de remitentes WAL que se usen para la replicación física y lógica, todos se activan a la vez, siempre que cualquier back-end escriba algo en el registro de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
  1. Descodificar todos los registros nuevos en WAL,
  2. Filtrar los registros de registro que no les interesen,
  3. Replicar los datos relevantes para cada uno de ellos.
• Los remitentes WAL son similares a las conexiones en el sentido de que, si están inactivos, no importa cuántos hay. Sin embargo, si están activos, solo competirán por los mismos recursos y el rendimiento podría acabar siendo terriblemente malo. Esto es especialmente cierto para los remitentes con replicación lógica, ya que la descodificación lógica es bastante costosa para la CPU. Cada trabajador tiene que descodificar todo el WAL, incluso si solo replica las operaciones que afectan a una sola tabla y que representa un pequeño porcentaje de todos los datos del registro de escritura anticipada. En el caso de la replicación física, no es tan importante, ya que los remitentes WAL no consumen CPU de forma tan intensiva y tienden a estar limitados por el ancho de banda de red primero.
• Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
• Se recomienda agregar espacio a algunos remitentes WAL adicionales para dar cabida a los picos de crecimiento futuros o temporales en las conexiones de replicación. Los dos ejemplos siguientes pueden ayudar a ilustrarlo mejor.
  • Para un servidor con 8 núcleos virtuales, alta disponibilidad deshabilitada, 2 réplicas de lectura y 3 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (0) + ranuras físicas para réplicas de lectura (2) + ranuras lógicas(3) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (1) = 6.
  • Para un servidor con 16 núcleos virtuales, alta disponibilidad habilitada, 4 réplicas de lectura y 5 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (2) + ranuras físicas para réplicas de lectura (4) + ranuras lógicas (5) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (2) = 13.
• Si sigue considerando que el valor máximo permitido para este parámetro es demasiado bajo para sus necesidades, póngase en contacto con nosotros, describa su escenario en detalle y explique lo que considere que sería el valor mínimo aceptable que necesitaría para que su escenario funcione correctamente.

track_commit_timestamp

wal_keep_size

wal_sender_timeout

max_replication_slots

max_slot_wal_keep_size

max_wal_senders

Notas específicas de Azure

El valor predeterminado del parámetro de servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database for PostgreSQL nunca debe reducirse por debajo de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

Al considerar la necesidad de aumentar max_wal_senders a un valor mucho mayor para poder hacer frente a la replicación lógica de un número considerable de tablas, tenga en cuenta los siguientes puntos importantes:

• La replicación lógica de un gran número de tablas no necesita necesariamente un gran número de remitentes WAL.
• La única razón por la que necesita un remitente WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos.
• No importa el número de remitentes WAL que se usen para la replicación física y lógica, todos se activan a la vez, siempre que cualquier back-end escriba algo en el registro de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
  1. Descodificar todos los registros nuevos en WAL,
  2. Filtrar los registros de registro que no les interesen,
  3. Replicar los datos relevantes para cada uno de ellos.
• Los remitentes WAL son similares a las conexiones en el sentido de que, si están inactivos, no importa cuántos hay. Sin embargo, si están activos, solo competirán por los mismos recursos y el rendimiento podría acabar siendo terriblemente malo. Esto es especialmente cierto para los remitentes con replicación lógica, ya que la descodificación lógica es bastante costosa para la CPU. Cada trabajador tiene que descodificar todo el WAL, incluso si solo replica las operaciones que afectan a una sola tabla y que representa un pequeño porcentaje de todos los datos del registro de escritura anticipada. En el caso de la replicación física, no es tan importante, ya que los remitentes WAL no consumen CPU de forma tan intensiva y tienden a estar limitados por el ancho de banda de red primero.
• Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
• Se recomienda agregar espacio a algunos remitentes WAL adicionales para dar cabida a los picos de crecimiento futuros o temporales en las conexiones de replicación. Los dos ejemplos siguientes pueden ayudar a ilustrarlo mejor.
  • Para un servidor con 8 núcleos virtuales, alta disponibilidad deshabilitada, 2 réplicas de lectura y 3 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (0) + ranuras físicas para réplicas de lectura (2) + ranuras lógicas(3) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (1) = 6.
  • Para un servidor con 16 núcleos virtuales, alta disponibilidad habilitada, 4 réplicas de lectura y 5 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (2) + ranuras físicas para réplicas de lectura (4) + ranuras lógicas (5) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (2) = 13.
• Si sigue considerando que el valor máximo permitido para este parámetro es demasiado bajo para sus necesidades, póngase en contacto con nosotros, describa su escenario en detalle y explique lo que considere que sería el valor mínimo aceptable que necesitaría para que su escenario funcione correctamente.

track_commit_timestamp

wal_keep_size

wal_sender_timeout

max_replication_slots

max_wal_senders

Notas específicas de Azure

El valor predeterminado del parámetro de servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database for PostgreSQL nunca debe reducirse por debajo de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

Al considerar la necesidad de aumentar max_wal_senders a un valor mucho mayor para poder hacer frente a la replicación lógica de un número considerable de tablas, tenga en cuenta los siguientes puntos importantes:

• La replicación lógica de un gran número de tablas no necesita necesariamente un gran número de remitentes WAL.
• La única razón por la que necesita un remitente WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos.
• No importa el número de remitentes WAL que se usen para la replicación física y lógica, todos se activan a la vez, siempre que cualquier back-end escriba algo en el registro de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
  1. Descodificar todos los registros nuevos en WAL,
  2. Filtrar los registros de registro que no les interesen,
  3. Replicar los datos relevantes para cada uno de ellos.
• Los remitentes WAL son similares a las conexiones en el sentido de que, si están inactivos, no importa cuántos hay. Sin embargo, si están activos, solo competirán por los mismos recursos y el rendimiento podría acabar siendo terriblemente malo. Esto es especialmente cierto para los remitentes con replicación lógica, ya que la descodificación lógica es bastante costosa para la CPU. Cada trabajador tiene que descodificar todo el WAL, incluso si solo replica las operaciones que afectan a una sola tabla y que representa un pequeño porcentaje de todos los datos del registro de escritura anticipada. En el caso de la replicación física, no es tan importante, ya que los remitentes WAL no consumen CPU de forma tan intensiva y tienden a estar limitados por el ancho de banda de red primero.
• Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
• Se recomienda agregar espacio a algunos remitentes WAL adicionales para dar cabida a los picos de crecimiento futuros o temporales en las conexiones de replicación. Los dos ejemplos siguientes pueden ayudar a ilustrarlo mejor.
  • Para un servidor con 8 núcleos virtuales, alta disponibilidad deshabilitada, 2 réplicas de lectura y 3 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (0) + ranuras físicas para réplicas de lectura (2) + ranuras lógicas(3) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (1) = 6.
  • Para un servidor con 16 núcleos virtuales, alta disponibilidad habilitada, 4 réplicas de lectura y 5 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (2) + ranuras físicas para réplicas de lectura (4) + ranuras lógicas (5) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (2) = 13.
• Si sigue considerando que el valor máximo permitido para este parámetro es demasiado bajo para sus necesidades, póngase en contacto con nosotros, describa su escenario en detalle y explique lo que considere que sería el valor mínimo aceptable que necesitaría para que su escenario funcione correctamente.

track_commit_timestamp

wal_keep_segments

wal_sender_timeout

max_replication_slots

max_wal_senders

Notas específicas de Azure

El valor predeterminado del parámetro de servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database for PostgreSQL nunca debe reducirse por debajo de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.

Al considerar la necesidad de aumentar max_wal_senders a un valor mucho mayor para poder hacer frente a la replicación lógica de un número considerable de tablas, tenga en cuenta los siguientes puntos importantes:

• La replicación lógica de un gran número de tablas no necesita necesariamente un gran número de remitentes WAL.
• La única razón por la que necesita un remitente WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos.
• No importa el número de remitentes WAL que se usen para la replicación física y lógica, todos se activan a la vez, siempre que cualquier back-end escriba algo en el registro de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
  1. Descodificar todos los registros nuevos en WAL,
  2. Filtrar los registros de registro que no les interesen,
  3. Replicar los datos relevantes para cada uno de ellos.
• Los remitentes WAL son similares a las conexiones en el sentido de que, si están inactivos, no importa cuántos hay. Sin embargo, si están activos, solo competirán por los mismos recursos y el rendimiento podría acabar siendo terriblemente malo. Esto es especialmente cierto para los remitentes con replicación lógica, ya que la descodificación lógica es bastante costosa para la CPU. Cada trabajador tiene que descodificar todo el WAL, incluso si solo replica las operaciones que afectan a una sola tabla y que representa un pequeño porcentaje de todos los datos del registro de escritura anticipada. En el caso de la replicación física, no es tan importante, ya que los remitentes WAL no consumen CPU de forma tan intensiva y tienden a estar limitados por el ancho de banda de red primero.
• Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
• Se recomienda agregar espacio a algunos remitentes WAL adicionales para dar cabida a los picos de crecimiento futuros o temporales en las conexiones de replicación. Los dos ejemplos siguientes pueden ayudar a ilustrarlo mejor.
  • Para un servidor con 8 núcleos virtuales, alta disponibilidad deshabilitada, 2 réplicas de lectura y 3 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (0) + ranuras físicas para réplicas de lectura (2) + ranuras lógicas(3) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (1) = 6.
  • Para un servidor con 16 núcleos virtuales, alta disponibilidad habilitada, 4 réplicas de lectura y 5 ranuras de replicación lógica, puede configurar max_wal_senders como la suma de ranuras físicas para alta disponibilidad (2) + ranuras físicas para réplicas de lectura (4) + ranuras lógicas (5) + algo adicional para un crecimiento futuro, considerando los núcleos virtuales disponibles (2) = 13.
• Si sigue considerando que el valor máximo permitido para este parámetro es demasiado bajo para sus necesidades, póngase en contacto con nosotros, describa su escenario en detalle y explique lo que considere que sería el valor mínimo aceptable que necesitaría para que su escenario funcione correctamente.

track_commit_timestamp

wal_keep_segments

wal_sender_timeout