max_replication_slots
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número máximo de ranuras de replicación definidas simultáneamente. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parámetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas de Azure
El valor predeterminado para el max_replication_slots parámetro es 10. Si habilita la alta disponibilidad, necesita un mínimo de 4 max_replication_slots para que la alta disponibilidad funcione correctamente.
Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_replication_slots en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_replication_slot. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
max_slot_wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño máximo de WAL que pueden reservar las ranuras de replicación. Las ranuras de replicación se marcarán como erróneas, y los segmentos se liberarán para su eliminación o reciclaje, si este espacio está ocupado por WAL en el disco. |
| Tipo de dato |
entero |
| Valor predeterminado |
-1 |
| Valores permitidos |
-1 |
| Tipo de parámetro |
solo lectura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número máximo de procesos de remitente WAL que se ejecutan simultáneamente. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
5-100 |
| Tipo de parámetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas de Azure
El valor predeterminado del parámetro del servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database para 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 emisor WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos de tablas.
- Cualquiera que sea el número de emisores WAL que se utilicen para la replicación física y lógica, todos se activan a la vez, siempre que un proceso de fondo escriba algo en el log de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
- Descodificar todos los registros nuevos en el WAL.
- Filtre los registros que no son de interés.
- Replique 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 representan 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 primero limitados por el ancho de banda de red.
- Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
- Se recomienda añadir espacio para algunos emisores WAL adicionales para acomodar el crecimiento futuro o las variaciones 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 habilita la alta disponibilidad, necesita un mínimo de 4
max_wal_senders para que la alta disponibilidad funcione correctamente. Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_wal_senders en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_wal_senders. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
- Si sigue teniendo en cuenta 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
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Recopila el tiempo de confirmación de la transacción. |
| Tipo de dato |
boolean |
| Valor predeterminado |
off |
| Valores permitidos |
on,off |
| Tipo de parámetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño de los archivos WAL mantenidos para los servidores en espera. |
| Tipo de dato |
entero |
| Valor predeterminado |
400 |
| Valores permitidos |
400 |
| Tipo de parámetro |
solo lectura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tiempo máximo que se va a esperar a la replicación de WAL. |
| Tipo de dato |
entero |
| Valor predeterminado |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parámetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número máximo de ranuras de replicación definidas simultáneamente. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parámetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas de Azure
El valor predeterminado para el max_replication_slots parámetro es 10. Si habilita la alta disponibilidad, necesita un mínimo de 4 max_replication_slots para que la alta disponibilidad funcione correctamente.
Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_replication_slots en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_replication_slot. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
max_slot_wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño máximo de WAL que pueden reservar las ranuras de replicación. Las ranuras de replicación se marcarán como erróneas, y los segmentos se liberarán para su eliminación o reciclaje, si este espacio está ocupado por WAL en el disco. |
| Tipo de dato |
entero |
| Valor predeterminado |
-1 |
| Valores permitidos |
-1 |
| Tipo de parámetro |
solo lectura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número máximo de procesos de remitente WAL que se ejecutan simultáneamente. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
5-100 |
| Tipo de parámetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas de Azure
El valor predeterminado del parámetro del servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database para 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 emisor WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos de tablas.
- Cualquiera que sea el número de emisores WAL que se utilicen para la replicación física y lógica, todos se activan a la vez, siempre que un proceso de fondo escriba algo en el log de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
- Descodificar todos los registros nuevos en el WAL.
- Filtre los registros que no son de interés.
- Replique 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 representan 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 primero limitados por el ancho de banda de red.
- Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
- Se recomienda añadir espacio para algunos emisores WAL adicionales para acomodar el crecimiento futuro o las variaciones 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 habilita la alta disponibilidad, necesita un mínimo de 4
max_wal_senders para que la alta disponibilidad funcione correctamente. Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_wal_senders en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_wal_senders. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
- Si sigue teniendo en cuenta 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
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Recopila el tiempo de confirmación de la transacción. |
| Tipo de dato |
boolean |
| Valor predeterminado |
off |
| Valores permitidos |
on,off |
| Tipo de parámetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño de los archivos WAL mantenidos para los servidores en espera. |
| Tipo de dato |
entero |
| Valor predeterminado |
400 |
| Valores permitidos |
400 |
| Tipo de parámetro |
solo lectura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tiempo máximo que se va a esperar a la replicación de WAL. |
| Tipo de dato |
entero |
| Valor predeterminado |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parámetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Especifica el número máximo de ranuras de replicación que el servidor puede admitir. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parámetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas de Azure
El valor predeterminado para el max_replication_slots parámetro es 10. Si habilita la alta disponibilidad, necesita un mínimo de 4 max_replication_slots para que la alta disponibilidad funcione correctamente.
Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_replication_slots en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_replication_slot. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
max_slot_wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño máximo de WAL que pueden reservar las ranuras de replicación. |
| Tipo de dato |
entero |
| Valor predeterminado |
-1 |
| Valores permitidos |
-1 |
| Tipo de parámetro |
solo lectura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número máximo de procesos de remitente WAL que se ejecutan simultáneamente. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
5-100 |
| Tipo de parámetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas de Azure
El valor predeterminado del parámetro del servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database para 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 emisor WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos de tablas.
- Cualquiera que sea el número de emisores WAL que se utilicen para la replicación física y lógica, todos se activan a la vez, siempre que un proceso de fondo escriba algo en el log de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
- Descodificar todos los registros nuevos en el WAL.
- Filtre los registros que no son de interés.
- Replique 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 representan 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 primero limitados por el ancho de banda de red.
- Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
- Se recomienda añadir espacio para algunos emisores WAL adicionales para acomodar el crecimiento futuro o las variaciones 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 habilita la alta disponibilidad, necesita un mínimo de 4
max_wal_senders para que la alta disponibilidad funcione correctamente. Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_wal_senders en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_wal_senders. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
- Si sigue teniendo en cuenta 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
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Recopila el tiempo de confirmación de la transacción. |
| Tipo de dato |
boolean |
| Valor predeterminado |
off |
| Valores permitidos |
on,off |
| Tipo de parámetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño de los archivos WAL mantenidos para los servidores en espera. |
| Tipo de dato |
entero |
| Valor predeterminado |
400 |
| Valores permitidos |
400 |
| Tipo de parámetro |
solo lectura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tiempo máximo que se va a esperar a la replicación de WAL. |
| Tipo de dato |
entero |
| Valor predeterminado |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parámetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Especifica el número máximo de ranuras de replicación que el servidor puede admitir. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parámetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas de Azure
El valor predeterminado para el max_replication_slots parámetro es 10. Si habilita la alta disponibilidad, necesita un mínimo de 4 max_replication_slots para que la alta disponibilidad funcione correctamente.
Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_replication_slots en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_replication_slot. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
max_slot_wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño máximo de WAL que pueden reservar las ranuras de replicación. |
| Tipo de dato |
entero |
| Valor predeterminado |
-1 |
| Valores permitidos |
-1 |
| Tipo de parámetro |
solo lectura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número máximo de procesos de remitente WAL que se ejecutan simultáneamente. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
5-100 |
| Tipo de parámetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas de Azure
El valor predeterminado del parámetro del servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database para 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 emisor WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos de tablas.
- Cualquiera que sea el número de emisores WAL que se utilicen para la replicación física y lógica, todos se activan a la vez, siempre que un proceso de fondo escriba algo en el log de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
- Descodificar todos los registros nuevos en el WAL.
- Filtre los registros que no son de interés.
- Replique 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 representan 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 primero limitados por el ancho de banda de red.
- Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
- Se recomienda añadir espacio para algunos emisores WAL adicionales para acomodar el crecimiento futuro o las variaciones 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 habilita la alta disponibilidad, necesita un mínimo de 4
max_wal_senders para que la alta disponibilidad funcione correctamente. Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_wal_senders en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_wal_senders. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
- Si sigue teniendo en cuenta 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
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Recopila el tiempo de confirmación de la transacción. |
| Tipo de dato |
boolean |
| Valor predeterminado |
off |
| Valores permitidos |
on,off |
| Tipo de parámetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño de los archivos WAL mantenidos para los servidores en espera. |
| Tipo de dato |
entero |
| Valor predeterminado |
400 |
| Valores permitidos |
400 |
| Tipo de parámetro |
solo lectura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tiempo máximo que se va a esperar a la replicación de WAL. |
| Tipo de dato |
entero |
| Valor predeterminado |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parámetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Especifica el número máximo de ranuras de replicación que el servidor puede admitir. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parámetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas de Azure
El valor predeterminado para el max_replication_slots parámetro es 10. Si habilita la alta disponibilidad, necesita un mínimo de 4 max_replication_slots para que la alta disponibilidad funcione correctamente.
Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_replication_slots en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_replication_slot. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
max_slot_wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño máximo de WAL que pueden reservar las ranuras de replicación. |
| Tipo de dato |
entero |
| Valor predeterminado |
-1 |
| Valores permitidos |
-1 |
| Tipo de parámetro |
solo lectura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número máximo de procesos de remitente WAL que se ejecutan simultáneamente. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
5-100 |
| Tipo de parámetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas de Azure
El valor predeterminado del parámetro del servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database para 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 emisor WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos de tablas.
- Cualquiera que sea el número de emisores WAL que se utilicen para la replicación física y lógica, todos se activan a la vez, siempre que un proceso de fondo escriba algo en el log de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
- Descodificar todos los registros nuevos en el WAL.
- Filtre los registros que no son de interés.
- Replique 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 representan 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 primero limitados por el ancho de banda de red.
- Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
- Se recomienda añadir espacio para algunos emisores WAL adicionales para acomodar el crecimiento futuro o las variaciones 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 habilita la alta disponibilidad, necesita un mínimo de 4
max_wal_senders para que la alta disponibilidad funcione correctamente. Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_wal_senders en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_wal_senders. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
- Si sigue teniendo en cuenta 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
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Recopila el tiempo de confirmación de la transacción. |
| Tipo de dato |
boolean |
| Valor predeterminado |
off |
| Valores permitidos |
on,off |
| Tipo de parámetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño de los archivos WAL mantenidos para los servidores en espera. |
| Tipo de dato |
entero |
| Valor predeterminado |
400 |
| Valores permitidos |
400 |
| Tipo de parámetro |
solo lectura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tiempo máximo que se va a esperar a la replicación de WAL. |
| Tipo de dato |
entero |
| Valor predeterminado |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parámetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Especifica el número máximo de ranuras de replicación que el servidor puede admitir. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parámetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas de Azure
El valor predeterminado para el max_replication_slots parámetro es 10. Si habilita la alta disponibilidad, necesita un mínimo de 4 max_replication_slots para que la alta disponibilidad funcione correctamente.
Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_replication_slots en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_replication_slot. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
max_slot_wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño máximo de WAL que pueden reservar las ranuras de replicación. |
| Tipo de dato |
entero |
| Valor predeterminado |
-1 |
| Valores permitidos |
-1 |
| Tipo de parámetro |
solo lectura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número máximo de procesos de remitente WAL que se ejecutan simultáneamente. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
5-100 |
| Tipo de parámetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas de Azure
El valor predeterminado del parámetro del servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database para 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 emisor WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos de tablas.
- Cualquiera que sea el número de emisores WAL que se utilicen para la replicación física y lógica, todos se activan a la vez, siempre que un proceso de fondo escriba algo en el log de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
- Descodificar todos los registros nuevos en el WAL.
- Filtre los registros que no son de interés.
- Replique 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 representan 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 primero limitados por el ancho de banda de red.
- Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
- Se recomienda añadir espacio para algunos emisores WAL adicionales para acomodar el crecimiento futuro o las variaciones 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 habilita la alta disponibilidad, necesita un mínimo de 4
max_wal_senders para que la alta disponibilidad funcione correctamente. Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_wal_senders en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_wal_senders. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
- Si sigue teniendo en cuenta 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
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Recopila el tiempo de confirmación de la transacción. |
| Tipo de dato |
boolean |
| Valor predeterminado |
off |
| Valores permitidos |
on,off |
| Tipo de parámetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tamaño de los archivos WAL mantenidos para los servidores en espera. |
| Tipo de dato |
entero |
| Valor predeterminado |
400 |
| Valores permitidos |
400 |
| Tipo de parámetro |
solo lectura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tiempo máximo que se va a esperar a la replicación de WAL. |
| Tipo de dato |
entero |
| Valor predeterminado |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parámetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Especifica el número máximo de ranuras de replicación que el servidor puede admitir. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parámetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas de Azure
El valor predeterminado para el max_replication_slots parámetro es 10. Si habilita la alta disponibilidad, necesita un mínimo de 4 max_replication_slots para que la alta disponibilidad funcione correctamente.
Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_replication_slots en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_replication_slot. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
max_wal_senders
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número máximo de procesos de remitente WAL que se ejecutan simultáneamente. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
5-100 |
| Tipo de parámetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas de Azure
El valor predeterminado del parámetro del servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database para 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 emisor WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos de tablas.
- Cualquiera que sea el número de emisores WAL que se utilicen para la replicación física y lógica, todos se activan a la vez, siempre que un proceso de fondo escriba algo en el log de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
- Descodificar todos los registros nuevos en el WAL.
- Filtre los registros que no son de interés.
- Replique 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 representan 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 primero limitados por el ancho de banda de red.
- Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
- Se recomienda añadir espacio para algunos emisores WAL adicionales para acomodar el crecimiento futuro o las variaciones 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 habilita la alta disponibilidad, necesita un mínimo de 4
max_wal_senders para que la alta disponibilidad funcione correctamente. Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_wal_senders en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_wal_senders. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
- Si sigue teniendo en cuenta 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
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Recopila el tiempo de confirmación de la transacción. |
| Tipo de dato |
boolean |
| Valor predeterminado |
off |
| Valores permitidos |
on,off |
| Tipo de parámetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_segments
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número de archivos WAL mantenidos para los servidores en espera. |
| Tipo de dato |
entero |
| Valor predeterminado |
25 |
| Valores permitidos |
25 |
| Tipo de parámetro |
solo lectura |
| Documentation |
|
wal_sender_timeout
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tiempo máximo que se va a esperar a la replicación de WAL. |
| Tipo de dato |
entero |
| Valor predeterminado |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parámetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Especifica el número máximo de ranuras de replicación que el servidor puede admitir. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parámetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas de Azure
El valor predeterminado para el max_replication_slots parámetro es 10. Si habilita la alta disponibilidad, necesita un mínimo de 4 max_replication_slots para que la alta disponibilidad funcione correctamente.
Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_replication_slots en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_replication_slot. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
max_wal_senders
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número máximo de procesos de remitente WAL que se ejecutan simultáneamente. |
| Tipo de dato |
entero |
| Valor predeterminado |
10 |
| Valores permitidos |
5-100 |
| Tipo de parámetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas de Azure
El valor predeterminado del parámetro del servidor max_wal_senders establecido al aprovisionar la instancia del servidor flexible de Azure Database para 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 emisor WAL independiente por tabla o grupo de tablas es si necesita suscripciones independientes para cada una de esas tablas o grupos de tablas.
- Cualquiera que sea el número de emisores WAL que se utilicen para la replicación física y lógica, todos se activan a la vez, siempre que un proceso de fondo escriba algo en el log de escritura anticipada. Cuando esto sucede, los remitentes WAL asignados para realizar la replicación lógica se reactivan para:
- Descodificar todos los registros nuevos en el WAL.
- Filtre los registros que no son de interés.
- Replique 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 representan 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 primero limitados por el ancho de banda de red.
- Por lo tanto, en general, es mejor no tener muchos más remitentes WAL que núcleos virtuales.
- Se recomienda añadir espacio para algunos emisores WAL adicionales para acomodar el crecimiento futuro o las variaciones 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 habilita la alta disponibilidad, necesita un mínimo de 4
max_wal_senders para que la alta disponibilidad funcione correctamente. Para un servidor con alta disponibilidad habilitada, además de 5 réplicas de lectura y 12 ranuras de replicación lógica, es posible que desee configurar max_wal_senders en 21. Esto se debe a que cada réplica de lectura y cada ranura de replicación lógica requiere una max_wal_senders. Por lo tanto, requiere un total de 1 (ranura) * 5 (réplicas de lectura) + 12 (ranuras de replicación lógica) + 4 (para que la alta disponibilidad funcione correctamente) = 21.
- Si sigue teniendo en cuenta 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
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Recopila el tiempo de confirmación de la transacción. |
| Tipo de dato |
boolean |
| Valor predeterminado |
off |
| Valores permitidos |
on,off |
| Tipo de parámetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_segments
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el número de archivos WAL mantenidos para los servidores en espera. |
| Tipo de dato |
entero |
| Valor predeterminado |
25 |
| Valores permitidos |
25 |
| Tipo de parámetro |
solo lectura |
| Documentation |
|
wal_sender_timeout
| Atributo |
Importancia |
| Categoría |
Replicación / Envío de servidores |
| Description |
Establece el tiempo máximo que se va a esperar a la replicación de WAL. |
| Tipo de dato |
entero |
| Valor predeterminado |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parámetro |
dynamic |
| Documentation |
wal_sender_timeout |