flowchart TD
A["featureブランチで開発・push"] --> B["PR CI（ci_branch）<br/>TIA有効 → 関連テストのみ実行<br/>⚡ 高速フィードバック"]
B -->|CI通過| C["レビュー & Approve"]
C --> D["マージキューに投入"]
D --> E["マージキュー CI（ci）<br/>全テスト実行<br/>+ Datadogカバレッジ収集"]
E -->|全テスト通過| F["mainにマージ"]
F --> G["リリース"]
style B fill:#e8f5e9,stroke:#4caf50
style E fill:#fff3e0,stroke:#ff9800
# spec_helper.rbifENV['DD_TIA_FORCE_RUN_ALL'] == 'true'# DD_CIVISIBILITY_ITR_ENABLED はカバレッジ収集と suite スキップを同時に有効化するため、# 収集専用ジョブでは全 example を unskippable にして forced run させるRSpec.configure do |config|
config.define_derived_metadata do |metadata|
metadata[:datadog_itr_unskippable] = trueendendend
ただし、id ラベルだけは残す必要があります。cAdvisor は同じメトリクス名で複数のコンテナの情報を収集しており、それぞれを区別するために id ラベルが使われています。id を drop すると異なるコンテナのメトリクスがラベルセット上で同一系列として扱われていしまいます。その結果、同じタイムスタンプに複数のサンプルが届き、 Prometheus が duplicate sample for timestamp エラーを返してしまうため注意が必要です。
原因3：Head Block のメモリ常駐
Prometheus はメトリクスを受け取ると、書き込み効率のためにまずメモリ上に一時的に貯めます。これが Head Block です。 一定時間が経つとメモリから EBS 上のファイルに書き出されます。デフォルトでは Head Block が3時間分（min-block-duration の1.5倍）に達した時点で古い2時間分がブロックとして書き出されます。つまり常に1〜3時間分のデータがメモリに残り続けるため、メトリクスの量が多いほどメモリ使用量が増えます。
SELECT
table_name,
CASE
WHEN raw_sql LIKE '%namespaced_controller:%' THEN
CONCAT(
TRIM(SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX(raw_sql, 'namespaced_controller:', -1), '*/', 1), ',', 1)),
'#',
TRIM(SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX(raw_sql, 'action:', -1), '*/', 1), ',', 1))
)
WHEN raw_sql LIKE '%sidekiq_worker:%' THEN
TRIM(SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX(raw_sql, 'sidekiq_worker:', -1), '*/', 1), ',', 1))
WHEN raw_sql LIKE '%rake_task:%' THEN
CONCAT('rake:', TRIM(SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX(raw_sql, 'rake_task:', -1), '*/', 1), ',', 1)))
ELSE 'unknown'
END AS query_source,
tx_duration_seconds AS max_tx_duration_seconds
FROM (
SELECT
CASE
WHEN ml.OBJECT_NAME LIKE '#sql-%' THEN 'DDL_IN_PROGRESS'
ELSE ml.OBJECT_NAME
END AS table_name,
COALESCE(esc.SQL_TEXT, it.trx_query, '') AS raw_sql,
TIMESTAMPDIFF(SECOND, it.trx_started, NOW()) AS tx_duration_seconds,
ROW_NUMBER() OVER (
PARTITION BY CASE WHEN ml.OBJECT_NAME LIKE '#sql-%' THEN 'DDL_IN_PROGRESS' ELSE ml.OBJECT_NAME END
ORDER BY TIMESTAMPDIFF(SECOND, it.trx_started, NOW()) DESC
) AS rn
FROM performance_schema.metadata_locks ml
JOIN performance_schema.threads th
ON ml.OWNER_THREAD_ID = th.THREAD_ID
JOIN information_schema.innodb_trx it
ON th.PROCESSLIST_ID = it.trx_mysql_thread_id
LEFT JOIN performance_schema.events_statements_current esc
ON th.THREAD_ID = esc.THREAD_ID
WHERE ml.OBJECT_TYPE = 'TABLE'
AND ml.OBJECT_SCHEMA NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys')
AND TIMESTAMPDIFF(SECOND, it.trx_started, NOW()) >= 5
) ranked
WHERE rn = 1
default_zero(avg:custom.mysql.mdl_holder.max_tx_duration_by_table{account:timee-jp-prod,replication_role:writer, !query_source:unknown, !query_source:rake:tmp:*} by {query_source})
根本原因は、スイッチオーバーでクラスターエンドポイントの参照先がBlueからGreenに切り替わることです。その結果、Blue環境とGreen環境ではバイナリログのファイルとポジションに互換性がないため、Datastreamを再開できません。
Managing AWS DMS Tasks with RDS or Aurora Blue/Green Deployments の「How Blue Green switchover affects AWS DMS tasks」セクションに、バイナリログのファイル名とポジションは Blue・Green 間で異なると記載されています。これは DMS のドキュメントですが、ファイル名とポジションが変わるのは DB 側の挙動であるため、Datastream でも同様に問題になります。
【原文】
Because the binary log file names and sequence positions differ between the two instances, DMS can no longer resume from the log position it previously recorded. This causes Full Load + CDC tasks and CDC only tasks to fail or enter an error state.
