監控 Amazon Aurora 全域資料庫 - Amazon Aurora

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

監控 Amazon Aurora 全域資料庫

當您建立組成 Aurora 全域資料庫的 Aurora 資料庫叢集時,您可以選擇許多選項,讓您監控資料庫叢集的效能。這些選項包括下列項目:

  • Amazon Perfor RDS mance Insights — 在基礎 Aurora 資料庫引擎中啟用效能結構描述。若要深入了解績效詳情與 Aurora 全域資料庫,請參閱使用 Amazon Perfor RDS mance Insights 見監控 Amazon Aurora 全球資料庫

  • 增強型監控 — 產生程序或執行緒使用率的指標CPU。若要瞭解增強型監控,請參閱 使用增強型監控來監控作業系統指標

  • Amazon CloudWatch 日誌 — 將指定的日誌類型發佈到 CloudWatch 日誌。預設會發佈錯誤日誌,但您可以選擇 Aurora 資料庫引擎特定的其他日誌。

    • 對SQL於 Aurora 我的 Aurora 資料庫叢集,您可以匯出稽核記錄、一般記錄和慢速查詢記錄。

    • 對於以 Aurora Postgre 為SQL基礎的 Aurora 資料庫叢集,您可以匯出 Post SQL gre 記錄。

  • 對於以 Aurora My SQL — 為基礎的全域資料庫,您可以查詢特定information_schema表格以檢查 Aurora 全域資料庫及其執行個體的狀態。如要瞭解如何作業,請參閱監視 Aurora 我SQL的全域資料庫

  • 對於以 Aurora Postgre 為SQL基礎的全域資料庫,您可以使用特定函數來檢查 Aurora 全域資料庫及其執行個體的狀態。若要瞭解如何操作,請參閱監視基於 Aurora 波斯特格雷SQL的全局

下面的螢幕擷取畫面顯示了一些在 Aurora 全域資料庫中的主要 Aurora 資料庫叢集的 Monitoring (監控) 索引標籤上可用的選項。

監控索引標籤:監視下拉式清單顯示 CloudWatch、增強型監控、作業系統程序清單和 Performance Insights 選項。

如需詳細資訊,請參閱在 Amazon Aurora 叢集中監控指標

使用 Amazon Perfor RDS mance Insights 見監控 Amazon Aurora 全球資料庫

您可以針對 Aurora 全球資料庫使用 Amazon Perfor RDS mance Insights。您可以為 Aurora 全域資料庫中的每個 Aurora 資料庫叢集個別啟用此功能。若要執行這項操作,您可以在 Create database (建立資料庫) 頁面的 Additional configuration (其他組態) 區段中選擇 Enable Performance Insights (啟用績效詳情)。或者,您可以修改您的 Aurora 資料庫叢集,以在其啟動並執行之後使用這項功能。對於每個屬於 Aurora 全域資料庫的叢集,您都可以啟用或關閉績效詳情。

績效詳情所建立的報告適用於全域資料庫中的每個叢集。當您將新的次要資料庫新增 AWS 區域 至已使用 Performance Insights 的 Aurora 全域資料庫時,請務必在新增的叢集中啟用 Performance Insights。這並不會從現有的全球資料庫中繼承績效詳情的設定。

您可以 AWS 區域 在檢視附加至全域資料庫之資料庫執行個體的 [Performance Insights] 頁面時進行切換。但是,切換後,您可能不會立即看到效能資訊 AWS 區域。雖然資料庫執行個體的名稱可能相同 AWS 區域,但每個資料庫執行URL個體的關聯 Performance Insights 都不同。切換之後 AWS 區域,請在 [Performance Insights] 導覽窗格中再次選擇資料庫執行個體的名稱。

針對資料庫執行個體連結與全域資料庫的關聯,在每個 AWS 區域影響效能的因素可能不同。例如,每個執行個體中的資料庫執行個體 AWS 區域 可能有不同的容量。

若要深入了解如何使用 Performance Insights (績效詳情),請參閱利用 極光上的 Performance Insights 來監控資料庫負載

使用資料庫活動串流來監控 Aurora 全域資料庫

透過使用資料庫活動串流功能,您可以在全域資料庫的資料庫叢集中監控和設定稽核活動的警示。您會在每個資料庫叢集上分別啟動資料庫活動串流。每個叢集在其自己的 AWS 區域中將稽核資料傳送至其自己的 Kinesis 串流。如需詳細資訊,請參閱使用資料庫活動串流監控 Aurora

監視 Aurora 我SQL的全域資料庫

若要檢視以 Aurora My SQL 為基礎的全域資料庫的狀態,請查詢information_schema.aurora_global_db_status和資料information_schema.aurora_global_db_instance_status表。

注意

information_schema.aurora_global_db_statusinformation_schema.aurora_global_db_instance_status表格僅適用於 Aurora 我的SQL版本 3.04.0 及更高版本的全域資料庫。

監視以我SQL為基礎的 Aurora 全域資料庫
  1. 使用我的用SQL戶端 Connect 到全域資料庫主要叢集端點。如需如何連線的詳細資訊,請參閱 連接到 Amazon Aurora 全域資料庫

  2. 在 mysql 命令中查詢 information_schema.aurora_global_db_status 資料表,以列出主要和次要磁碟區。此查詢會傳回全球資料庫次要資料庫叢集的延遲時間,如下列範例所示。

    mysql> select * from information_schema.aurora_global_db_status;
    AWS_REGION | HIGHEST_LSN_WRITTEN | DURABILITY_LAG_IN_MILLISECONDS | RPO_LAG_IN_MILLISECONDS | LAST_LAG_CALCULATION_TIMESTAMP | OLDEST_READ_VIEW_TRX_ID -----------+---------------------+--------------------------------+------------------------+---------------------------------+------------------------ us-east-1 | 183537946 | 0 | 0 | 1970-01-01 00:00:00.000000 | 0 us-west-2 | 183537944 | 428 | 0 | 2023-02-18 01:26:41.925000 | 20806982 (2 rows)

    輸出包含全球資料庫中每個資料庫叢集的資料列,其中包括以下欄位:

    • AWS_ REGION- AWS 區域 該數據庫集群所在。如需 AWS 區域 依引擎列出的表格,請參閱區域和可用區域

    • HIGHEST_ LSN _ WRITTEN — 目前在此資料庫叢集上寫入的最高記錄序號 (LSN)。

      錄序號 (LSN) 是識別資料庫交易記錄檔中記錄的唯一序號。LSNs是有序的,使得較大的LSN代表以後的事務。

    • DURABILITY_ LAG _IN_ MILLISECONDS — 次要資料庫叢集上與主要資料庫叢集HIGHEST_LSN_WRITTEN上的時間戳記值之間的差異。HIGHEST_LSN_WRITTEN在 Aurora 全球資料庫的主要資料庫叢集上,此值始終為 0。

    • RPO_ LAG _IN_ MILLISECONDS — 復原點目標 (RPO) 延遲。RPO延遲是次要資料庫叢集儲存在 Aurora 全域資料庫的主COMMIT要資料庫叢集上之後,最新使用者交易儲存在次要資料庫叢集上所需的時間。在 Aurora 全球資料庫的主要資料庫叢集上,此值始終為 0。

      簡單來說,此測量結果會計算 Aurora 全域資料庫中每個 Aurora My SQL DB 叢集的復原點目標,也就是說,如果發生中斷,可能會遺失多少資料。與滯後一樣,RPO在時間測量。

    • LAST_ LAG _ CALCULATION _ TIMESTAMP — 指定上次計算DURABILITY_LAG_IN_MILLISECONDS和值的時間戳記RPO_LAG_IN_MILLISECONDS。例如 1970-01-01 00:00:00+00 之類的時間值表示此為主要資料庫叢集。

    • OLDEST_ READ VIEW _ TRX _ID — 寫入器資料庫執行個體可清除的最舊交易 ID。

  3. 查詢 information_schema.aurora_global_db_instance_status 資料表列出主要資料庫叢集與次要資料庫叢集的所有次要資料庫執行個體。

    mysql> select * from information_schema.aurora_global_db_instance_status;
    SERVER_ID | SESSION_ID | AWS_REGION | DURABLE_LSN | HIGHEST_LSN_RECEIVED | OLDEST_READ_VIEW_TRX_ID | OLDEST_READ_VIEW_LSN | VISIBILITY_LAG_IN_MSEC ---------------------+--------------------------------------+------------+-------------+----------------------+-------------------------+----------------------+------------------------ ams-gdb-primary-i2 | MASTER_SESSION_ID | us-east-1 | 183537698 | 0 | 0 | 0 | 0 ams-gdb-secondary-i1 | cc43165b-bdc6-4651-abbf-4f74f08bf931 | us-west-2 | 183537689 | 183537692 | 20806928 | 183537682 | 0 ams-gdb-secondary-i2 | 53303ff0-70b5-411f-bc86-28d7a53f8c19 | us-west-2 | 183537689 | 183537692 | 20806928 | 183537682 | 677 ams-gdb-primary-i1 | 5af1e20f-43db-421f-9f0d-2b92774c7d02 | us-east-1 | 183537697 | 183537698 | 20806930 | 183537691 | 21 (4 rows)

    輸出包含全球資料庫中每個資料庫執行個體的資料列,其中包括以下欄位:

    • SERVER_ID — 資料庫執行個體的伺服器識別碼。

    • SESSION_ID — 目前階段作業的唯一識別碼。MASTER_SESSION_ID 值可識別寫入器 (主) 資料庫執行個體。

    • AWS_ REGION — 此資料庫執行個體所 AWS 區域 在的位置。如需 AWS 區域 依引擎列出的表格,請參閱區域和可用區域

    • DURABLE_ LSN — LSN 製成耐用的存儲。

    • HIGHEST_ LSN _ RECEIVED — 資料庫執行個體從寫入器資料庫執行個體LSN接收到的最高值。

    • OLDEST_ READ VIEW _ TRX _ID — 寫入器資料庫執行個體可清除的最舊交易 ID。

    • OLDEST_ _ READ VIEW _ LSN — 資料庫執行個體LSN用於從儲存區讀取的最舊版本。

    • VISIBILITY_ LAG _IN_ MSEC — 對於主要資料庫叢集中的讀取器,此資料庫執行個體落後於寫入器資料庫執行個體的距離 (以毫秒為單位)。對於次要資料庫叢集中的讀取器,此資料庫執行個體延遲於次要磁碟區的時間 (以毫秒為單位)。

若要查看這些值如何隨時間改變,則可考慮使用以下需要一小時才能插入資料表的交易區塊:

mysql> BEGIN; mysql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert; mysql> COMMIT;

在某些情況下,BEGIN 陳述式後,主要資料庫叢集和次要資料庫叢集之間網路可能會斷線。如果是這樣,次要資料庫叢集的 DURABILITY_ LAG _IN_ MILLISECONDS 值開始增加。在INSERT陳述式結尾處,DURABILITY_ LAG _IN_ MILLISECONDS 值為 1 小時。但是,RPO_ LAG _IN_ MILLISECONDS 值為 0,因為主要資料庫叢集和次要資料庫叢集之間認可的所有使用者資料仍然相同。一旦COMMIT陳述式完成,RPO_ LAG _IN_ MILLISECONDS 值就會增加。

監視基於 Aurora 波斯特格雷SQL的全局

若要檢視以 Aurora Postgre SQL 為基礎的全域資料庫的狀態,請使用aurora_global_db_statusaurora_global_db_instance_status函數。

注意

只有 Aurora 波斯特雷SQL支持aurora_global_db_statusaurora_global_db_instance_status功能。

若要監視以 Aurora Postgre SQL 為基礎的全域資料庫
  1. 使用 Postgre SQL 公用程式 (例如 psql) Connect 到全域資料庫主要叢集端點。如需如何連線的詳細資訊,請參閱 連接到 Amazon Aurora 全域資料庫

  2. 在 psql 命令中使用 aurora_global_db_status 函數,以列出主要和次要磁碟區。如此即會顯示全球資料庫次要資料庫叢集的延遲時間。

    postgres=> select * from aurora_global_db_status();
    aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin ------------+---------------------+------------------------+-----------------+----------------------------+----------------+--------------- us-east-1 | 93763984222 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0 us-west-2 | 93763984222 | 900 | 1090 | 2020-05-12 22:49:14.328+00 | 2 | 3315479243 (2 rows)

    輸出包含全球資料庫中每個資料庫叢集的資料列,其中包括以下欄位:

    • aws_region- AWS 區域 該數據庫集群所在。如需 AWS 區域 依引擎列出的表格,請參閱區域和可用區域

    • highest_lsn_寫入 — 目前寫入此資料庫叢集上的最高記錄序號 (LSN)。

      錄序號 (LSN) 是識別資料庫交易記錄檔中記錄的唯一序號。LSNs是有序的,使得較大的LSN代表以後的事務。

    • durability_lag_in_msec – 寫入次要資料庫叢集之最大記錄序號 (highest_lsn_written) 與寫入主要資料庫叢集之 highest_lsn_written 的時間戳記差異。

    • rpo_LAG_ 毫秒 — 復原點目標 () 延遲。RPO此延遲是指存放在次要資料庫叢集之最近使用者交易遞交,以及存放在主要資料庫叢集之最近使用者交易遞交間的時間差異。

    • last_lag_calculation_time – 上次計算 durability_lag_in_msecrpo_lag_in_msec 值時的時間戳記。

    • feedback_epoch – 次要資料庫叢集產生熱待命資訊時所使用的 epoch。

      Hot standby (熱待命) 指的是在伺服器處於復原或待命模式時,資料庫叢集仍可執行連線與查詢操作。熱待命回饋則會提供資料庫叢集在熱待命期間的相關資訊。如需詳細資訊,請參閱 Postgre SQL 文件中的熱待命

    • feedback_xmin – 次要資料庫叢集所使用的最小 (最舊) 作用中交易 ID。

  3. 使用 aurora_global_db_instance_status 函數列出主要資料庫叢集與次要資料庫叢集的所有次要資料庫執行個體。

    postgres=> select * from aurora_global_db_instance_status();
    server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec --------------------------------------------+--------------------------------------+------------+-------------+------------------+----------------+---------------+----------------------+------------------------ apg-global-db-rpo-mammothrw-elephantro-1-n1 | MASTER_SESSION_ID | us-east-1 | 93763985102 | | | | | apg-global-db-rpo-mammothrw-elephantro-1-n2 | f38430cf-6576-479a-b296-dc06b1b1964a | us-east-1 | 93763985099 | 93763985102 | 2 | 3315479243 | 93763985095 | 10 apg-global-db-rpo-elephantro-mammothrw-n1 | 0d9f1d98-04ad-4aa4-8fdd-e08674cbbbfe | us-west-2 | 93763985095 | 93763985099 | 2 | 3315479243 | 93763985089 | 1017 (3 rows)

    輸出包含全球資料庫中每個資料庫執行個體的資料列,其中包括以下欄位:

    • server_id – 此資料庫執行個體的伺服器識別符。

    • session_id – 目前工作階段的唯一識別符。

    • aws_region — 此資料庫執行 AWS 區域 個體所在的位置。如需 AWS 區域 依引擎列出的表格,請參閱區域和可用區域

    • 耐用性 — 經久耐用的LSN儲存。

    • highest_lsn_rcvd — 資料庫執行個體從寫入器資料庫執行個體LSN接收到的最高值。

    • feedback_epoch – 資料庫執行個體產生熱待命資訊時所使用的 epoch。

      熱待命指的是在伺服器處於復原或待命模式時,資料庫執行個體仍可執行連線與查詢操作。熱待命回饋則會提供資料庫執行個體在熱待命期間的相關資訊。有關更多信息,請參閱有關熱待命的 Postgre SQL 文檔。

    • feedback_xmin – 資料庫執行個體所使用的最小 (最舊) 作用中交易 ID。

    • oldest_read_view_lsn — 資料庫執行個體用來從儲存區讀取的最LSN舊版本。

    • visibility_lag_in_msec – 此資料庫執行個體落後寫入器資料庫執行個體的程度。

若要查看這些值如何隨時間改變,則可考慮使用以下需要一小時才能插入資料表的交易區塊:

psql> BEGIN; psql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert; psql> COMMIT;

在某些情況下,BEGIN 陳述式後,主要資料庫叢集和次要資料庫叢集之間網路可能會斷線。如果是這樣,次要資料庫叢集的 durability_lag_in_msec 值會開始增加。在 INSERT 陳述式的結尾,durability_lag_in_msec 值為 1 小時。但 rpo_lag_in_msec 值會是 0,這是因為主要資料庫叢集與次要資料庫叢集之間遞交的所有使用者資料仍是一樣的。一旦 COMMIT 陳述式完成,rpo_lag_in_msec 值就會增加。