You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 1fab495
Browse filesBrowse the repository at this point in the historyBrowse files
docs: fix all dead external links (EN 16 + CN 13 instances) + 1 markup defect
An automated link check over the EN/CN trees (569 unique external URLs)
found every dead link fixed here, 29 link instances across 14 files plus
one AsciiDoc markup defect. Every replacement target was verified to
return 200 before committing. EN and CN mirrors of the same page are
fixed symmetrically.
- releases-page links (welcome/operation_guide, EN+CN): page removed
from www.ivorysql.org -> point to GitHub releases
- daily_monitoring (EN x2): postgresql.org URL typo "currenruntime"
-> "current/"
- release_notes (EN+CN): repo name "IvorySQL/IvorySQL-docs"
-> "IvorySQL/ivorysql_docs"
- installation_guide (EN+CN): amd64 release asset updated to the
current build 9d890e9-20251120 (wget URL and dpkg -i filename kept
consistent)
- cpu_architecture_adaptation (EN x6 + CN x6): release-asset URLs
updated to the current 873c2f8-20251125 builds for
loongarch64/aarch64/arm64/mips64el
- operator_deployment (EN x3 + CN x2): dead CrunchyData deep links ->
repo root; clone-cluster.md -> create-cluster.md (verified); CN
misspelled GitHub orgs ("IvonySQL", "Ivory-operator") -> "IvorySQL"
- pg_partman (EN): bare URL with glued trailing colon -> proper link
macro
Sample-code placeholders (192.168.x.x, httpbin.org, xxx/xxx,
example.com) were deliberately left untouched.
Signed-off-by: zhang1939 <13942782872@163.com>
Copy file name to clipboardExpand all lines: EN/modules/ROOT/pages/master/containerization/operator_deployment.adoc
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -539,7 +539,7 @@ What if IVYO was down during the downtime event? Failover would still occur: the
539
539
540
540
=== Synchronous Replication
541
541
542
-
IvorySQL supports synchronous replication, which is a replication mode designed to limit the risk of transaction loss. Synchronous replication waits for a transaction to be written to at least one additional server before it considers the transaction to be committed. For more information on synchronous replication, please read about IVYO's https://github.com/CrunchyData/postgres-operator/blob/master/docs/content/architecture/high-availability.md#synchronous-replication-guarding-against-transactions-loss[high availability architecture]
542
+
IvorySQL supports synchronous replication, which is a replication mode designed to limit the risk of transaction loss. Synchronous replication waits for a transaction to be written to at least one additional server before it considers the transaction to be committed. For more information on synchronous replication, please read about IVYO's https://github.com/CrunchyData/postgres-operator-examples[high availability architecture]
543
543
544
544
To add synchronous replication to your Ivory cluster, you can add the following to your spec:
545
545
@@ -922,7 +922,7 @@ IVYO lets you adjust CPU and memory within the `resources` sections of the `ivor
922
922
- `spec.backups.pgbackrest.sidecars.pgbackrestConfig.resources` section, which sets the resources for the `pgbackrest-config` sidecar container.
923
923
- `spec.backups.pgbackrest.jobs.resources` section, which sets the resources for any pgBackRest backup job.
924
924
- `spec.backups.pgbackrest.restore.resources` section, which sets the resources for manual pgBackRest restore jobs.
925
-
- `spec.dataSource.ivorycluster.resources` section, which sets the resources for pgBackRest restore jobs created during the https://github.com/IvorySQL/ivory-operator/blob/master/docs/content/tutorial/clone-cluster.md[cloning] process.
925
+
- `spec.dataSource.ivorycluster.resources` section, which sets the resources for pgBackRest restore jobs created during the https://github.com/IvorySQL/ivory-operator/blob/master/docs/content/tutorial/create-cluster.md[cloning] process.
926
926
927
927
The layout of these `resources` sections should be familiar: they follow the same pattern as the standard Kubernetes structure for setting https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/[container resources]. Note that these settings also allow for the configuration of https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/[QoS classes].
IVYO will detect the change and add the Exporter sidecar to all Ivory Pods that exist in your
2366
2366
cluster. IVYO will also do the work to allow the Exporter to connect to the database and gather
2367
-
metrics that can be accessed using the https://github.com/CrunchyData/postgres-operator-examples/tree/main/kustomize/monitoring[IVYO Monitoring] stack.
2367
+
metrics that can be accessed using the https://github.com/CrunchyData/postgres-operator-examples[IVYO Monitoring] stack.
2368
2368
2369
2369
==== Configuring TLS Encryption for the Exporter
2370
2370
@@ -2398,7 +2398,7 @@ for more information on configuring TLS for https://prometheus.io/[Prometheus].
2398
2398
=== Accessing the Metrics
2399
2399
2400
2400
Once the IvorySQL Exporter has been enabled in your cluster, follow the steps outlined in
2401
-
https://github.com/CrunchyData/postgres-operator-examples/tree/main/kustomize/monitoring[IVYO Monitoring] to install the monitoring stack. This will allow you to deploy a https://github.com/CrunchyData/pgmonitor[pgMonitor]
2401
+
https://github.com/CrunchyData/postgres-operator-examples[IVYO Monitoring] to install the monitoring stack. This will allow you to deploy a https://github.com/CrunchyData/pgmonitor[pgMonitor]
2402
2402
configuration of https://prometheus.io/[Prometheus], https://grafana.com/[Grafana], and https://prometheus.io/docs/alerting/latest/alertmanager/[Alertmanager] monitoring tools in Kubernetes. These
2403
2403
tools will be set up by default to connect to the Exporter containers on your Ivory Pods.
Copy file name to clipboardExpand all lines: EN/modules/ROOT/pages/master/getting-started/daily_monitoring.adoc
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -738,8 +738,8 @@ The `pg_stat_database` view will contain one row for each database in the cluste
738
738
| `deadlocks` | `bigint` | Number of deadlocks detected in this database
739
739
| `checksum_failures` | `bigint` | Number of data page checksum failures detected in this database (or on a shared object), or NULL if data checksums are not enabled.
740
740
| `checksum_last_failure` | `timestamp with time zone` | Time at which the last data page checksum failure was detected in this database (or on a shared object), or NULL if data checksums are noenabled.
741
-
| `blk_read_time` | `double precision` | Time spent reading data file blocks by backends in this database, in milliseconds (if [track_io_timing](https://www.postgresql.org/docs/currenruntime-config-statistics.html#GUC-TRACK-IO-TIMING) is enabled, otherwise zero)
742
-
| `blk_write_time` | `double precision` | Time spent writing data file blocks by backends in this database, in milliseconds (if [track_io_timing](https://www.postgresql.org/docs/currenruntime-config-statistics.html#GUC-TRACK-IO-TIMING) is enabled, otherwise zero)
741
+
| `blk_read_time` | `double precision` | Time spent reading data file blocks by backends in this database, in milliseconds (if [track_io_timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING) is enabled, otherwise zero)
742
+
| `blk_write_time` | `double precision` | Time spent writing data file blocks by backends in this database, in milliseconds (if [track_io_timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING) is enabled, otherwise zero)
743
743
| `session_time` | `double precision` | Time spent by database sessions in this database, in milliseconds (note that statistics are only updated when the state of a session changes, so if sessions havbeen idle for a long time, this idle time won't be included)
744
744
| `active_time` | `double precision` | Time spent executing SQL statements in this database, in milliseconds (this corresponds to the states `active` and `fastpath function call` inpg_stat_activity](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW))
745
745
| `idle_in_transaction_time` | `double precision` | Time spent idling while in a transaction in this database, in milliseconds (this corresponds to the states `idle in transaction` and `idle itransaction (aborted)` in [pg_stat_activity](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW))
0 commit comments