關於 CDC 技術的簡介及 Kafka 如何用在 CDC，可以參考文章「淺談 Change Data Capture (CDC) 及重要性，它如何實現資料同步？」的介紹。

我們會以透過 MongoDB Kafka Connector 實現 MongoDB 集群間的資料同步為例，開源的 Kafka Connect 外掛程式有 Debezium MongoDB Connector 和 MongoDB Kafka Connector 等，下表作簡單比較：

本文旨在提供讀者自行架設簡易測試環境的步驟作為參考，並用以驗證資料庫間的資料串流功能。以下內容將著重在說明如何建置 Kafka 服務及設定資料同步的工作。 

你需要準備

• • 一台已安裝 Linux 穩定發行版本的 VM 或實體機器，本文使用 CentOS 7。 建議配置：
    • • vCPUs: 4 以上
    • • RAM: 8 GB 以上
    • • Disk: 500 GB 以上

• • Linux 基本操作知識

• • 來源端及目的端 MongoDB 集群（含連線資訊、具 ChangeStreams 讀取及相關表格讀寫等權限可供 Connector 工作使用的連線帳密）
    • • 需為 Replica Set 或是 Sharded Cluster

• • 來源端 MongoDB 表格（含資料），本文假設為 mydb database 下的 mycoll 表格

• • MongoDB 集群的連線工具，如 MongoDB Compass 或 terminal

環境架構

Kafka 架構示意圖

我們在同一台機器上安裝單節點 Kafka 及 Kafka Connect，並在 Kafka Connect 中加入 MongoDB Kafka Connector 外掛程式。

MongoDB 的 CDC 機制 (Change Streams)

MongoDB 的 Change Streams 功能就像資料庫的實時脈搏，它可以捕捉資料庫中發生的任何變化，並將這些變化傳遞給其他系統。

Change Streams 如何運作？

Change Streams 會監控 MongoDB 的操作日誌 (oplog)，並將資料的異動 (例如新增、修改、刪除) 轉換成異動事件 (Change Event)。

當 MongoDB 資料庫發生變化時，Change Streams 會捕捉這些變化，並將其傳遞給 Kafka。

更具體地說，整個流程如下：

1. 資料庫異動： 當來源端的 MongoDB 資料表格發生異動時，例如新增、修改或刪除文件，MongoDB 會產生新的異動事件，並記錄在 oplog 中。
2. 捕捉異動事件： Source Connector 會持續監控 oplog，捕捉這些異動事件，並將其集結成批次。
3. 發送至 Kafka： Source Connector 會將批次的異動事件發送到 Kafka Broker，並寫入指定的 Kafka Topic。
4. 同步至目標系統： Sink Connector 會從 Kafka Broker 讀取指定 Topic 中的資料，並根據異動事件的內容，將新的文件寫入目的端 MongoDB 的指定表格，或執行其他同步操作。

Kafka 服務相關元件和名詞介紹

在 Kafka 的訊息旅程中，許多幕後推手扮演著重要的角色，確保訊息能順利地從生產者傳遞到消費者。以下介紹 Kafka 服務中幾個關鍵的元件和名詞：

協調者：

• ZooKeeper： 如同一位經驗豐富的指揮家，ZooKeeper 負責協調 Kafka 各服務節點的狀態管理和工作分配，確保整個系統的穩定運行。在 Kafka 2.8.0 以後的版本，Kafka 引入了 KRaft 模式，可以脫離 ZooKeeper 運作，更加輕量化和高效。

訊息的歸宿：

• Broker： Kafka 的節點，如同一個個郵局，負責處理對 Topic 寫入或讀取資料的請求。
• Topic： 存放資料的容器，如同郵局中的郵箱，用於存放不同類型的訊息。
• Partition： Topic 的分割，如同將郵箱分成多個隔層，讓 Consumer 可以同時拉取不同 Partition 中的資料，提升處理效率。

訊息的生產者和消費者：

• Producer： 將資料送往 Kafka Broker 寫入的資料製造者，如同寄件人，將訊息投遞到郵箱。
• Consumer / Consumer Groups： Topic 訊息的消費者，如同收件人，從郵箱中取出訊息。同一個 Topic 可能有很多個消費者，因此以群組形式存在，確保每個訊息都能被消費。

訊息旅程的可靠保障：

• Leader / Followers： Kafka 通常以多節點集群的形式運作，集群中會有一個主要節點作為主節點 (Leader)，其他節點則為副節點 (Followers)，從主節點同步狀態及資料，確保訊息的可靠性和容錯能力。

資料同步的橋樑：

• Kafka Connect： 負責 Connector 的管理，如同一位聯絡員，負責協調資料的同步工作。
• plugin： 供 Kafka Connect 使用的外掛驅動程式，如同不同的轉接頭，讓 Kafka Connect 可以連接到不同的資料庫或系統。
• Connector： 與外部資料環境及 Kafka 對接，用來進行指定讀/寫資料工作的單位，如同一位搬運工，負責將資料從來源系統搬運到 Kafka，或從 Kafka 搬運到目標系統。
• Worker / Worker Task： 一個 Sink Connector 下依據 Topic partition 數目可以有一或多個 process 平行執行 Connector 設定中定義的工作，如同多位搬運工同時工作，提升資料同步的效率。

操作步驟

一、下載 Apache Kafka

curl <https://downloads.apache.org/kafka/3.3.1/kafka_2.13-3.3.1.tgztar> -zvf kafka_2.13-3.3.1.tgzcd kafka_2.13-3.3.1

二、啟動 Kafka 服務

./bin/kafka-server-start.sh

Kafka 預設使用 port 9092。

三、啟動 Kafka Connect 服務

Kafka Connect 分有 standalone (預設使用 ./config/connect-standalone.properties 中的設定) 及 distributed (預設使用 ./config/connect-distributed.properties 中的設定)。差異在於 distributed 版本支援分散儲存 topic 中的資料，一般建議使用 distributed 版本

在啟動 Kafka Connect 之前，我們需要先安裝 MongoDB Kafka Connector 外掛，在啟動 Kafka Connect 服務時才會讀取到該外掛程式的存在。

開啟 connect-distributed.properties，往下滾動至最底部，找到 plugin.path 一行，修改為您要放置外掛檔案的路徑位置。

vi ./config/connect-distributed.properties

下載外掛程式並移至 .properties 中指定 plugin.path 即可，這邊假設為 kafka_2.13-3.3.1/plugins。

curl <https://search.maven.org/remotecontent?filepath=org/mongodb/kafka/mongo-kafka-connect/1.8.0/mongo-kafka-connect-1.8.0-all.jarmkdir> -p pluginscp mongo-kafka-connect-1.8.0-all.jar plugins

再來啟動 Kafka Connect，預設使用 port 8083

./bin/connect-distributed.sh

可以透過以下指令查看已安裝的 Kafka connector plugins，此時應該要看得到 MongoSourceConnector 及 MongoSinkConnector。

curl <http://localhost:8083/connector-plugins>

四、新增 Source Connector

Kafka Connect 提供 REST API 管理執行中的 connector 工作，包含新增 connector、查看 connector 設定內容、變更 connector 設定內容、刪除 connector 等。

在新增 connector 時透過 API 傳入的設定為 json 格式，為方便可以將設定存為檔案再由指令呼叫設定檔內容。

以下提供 source connector 範例及常用設定表列說明。

mongo-src-connector.json
{   
"name": "mongo-src-connector",    
"config": {        
"connector.class": "com.mongodb.kafka.connect.MongoSourceConnector",
"connection.uri": "mongodb://admin:password@mymongosrc1:27017,mymongosrc2:27017,mymongosrc3:27017", 
"database": "mydb", 
"collection": "mycoll",        
"topic.prefix": "src",        
"copy.existing": true,       
"key.converter": "org.apache.kafka.connect.json.JsonConverter",        "key.converter.schemas.enable": "false",       
"value.converter": "org.apache.kafka.connect.json.JsonConverter",        "value.converter.schemas.enable": "false",        
"tasks.max": "1"    }
}

我們需要先建立 Kafka Topic，才能讓 Connector 透過 Broker 寫入

./bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic src.mydb.mycoll --replication-factor 3 --partition 1

｜replication-factor: 一共會有幾份相同的 topic，建議 production 設定為 3

確認剛才建立的 topic 資訊

./bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic src.mydb.mycoll

之後便可透過以下指令啟動 Source Connector

curl -X POST <http://localhost:8083/connectors> -H "Accept:application/json" -H "Content-Type:application/json" -d @mongo-src-connector.json

五、觀察 Kafka Topic 內容

我們先來確認 Source Connector 有正常啟動（無錯誤訊息且狀態為 RUNNING），以及表格資料是否如預期寫入 Kafka topic。

六、檢查 Connector 狀態

curl <http://localhost:8083/connectors/mongo-src-connector/status>

七、列出所有 Kafka topics

./bin/kafka-topics.sh --bootstrap-server localhost:9092 --list

八、查看 Kafka topic 內資料

./bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic src.mydb.mycoll

九、新增 Sink Connector

mongo-sink-connector.json
{   
"name": "mongo-sink-connector",   
"config": {        
"connector.class": "com.mongodb.kafka.connect.MongoSinkConnector",        
"connection.uri": "mongodb://admin:password@mymongosink1:27017,mymongosink2:27017,mymongosink3:27017",
"topics": "src.mydb.mycoll",        
"database": "sinkdb",        
"collection": "sinkcoll",        
"key.converter": "org.apache.kafka.connect.json.JsonConverter",        "key.converter.schemas.enable": "false",        
"value.converter": "org.apache.kafka.connect.json.JsonConverter",        "value.converter.schemas.enable": "false",        
"change.data.capture.handler": "com.mongodb.kafka.connect.sink.cdc.mongodb.ChangeStreamHandler",        
"tasks.max": "1"    }
}

接著便可透過以下指令啟動 Sink Connector

curl -X POST <http://localhost:8083/connectors> -H "Accept:application/json" -H "Content-Type:application/json" -d @mongo-sink-connector.json

十、觀察結果

在確認 Sink Connector 正常啟動後，同步工作至此已經架設完成。您可以參考以下指令，在先前建立的 connector 工作持續運作的狀態下，連線到來源端 MongoDB 進行操作。透過另一個連線，在目的端 MongoDB 表格結果是否與來源端一致。

• • 連線至 MongoDB

mongosh mongodb://admin:password@mymongosink1:27017,mymongosink2:27017,mymongosink3:27017

• • 自來源端表格新增一筆資料

use mydb
db.mycoll.insertOne({ name: "TestField" });

Output:

{ acknowledged: true,
  insertedId: ObjectId("63686963a37df5cdbf7fec9d") }

在目標資料庫的表格 sinkdb.sinkcoll 會看到新增了一筆連 ObjectId 都與來源端一模一樣的資料

• • 自來源端表格更新一筆資料

db.mycoll.updateOne({name: "TestField"}, {$set:{newField: true}});

Output:

{ acknowledged: true,
  insertedId: null,
  matchedCount: 1,
  modifiedCount: 1,
  upsertedCount: 0 }

在目標資料庫的表格會看到這筆資料多了一個欄位 newField

• • 自來源端表格刪除一筆資料

db.mycoll.deleteOne({name: "TestField", newField: true})

Output:

{ acknowledged: true, deletedCount: 1 }

在目標資料庫的表格會看到這筆資料也跟著被刪除

收尾

如果要結束測試，一樣可以透過 curl 呼叫 API 來停止 connector 工作。

curl -X DELETE <http://localhost:8083/connectors/mongo-src-connector>
curl -X DELETE <http://localhost:8083/connectors/mongo-sink-connector>

結語

本文中我們示範了如何自行架設 Kafka 環境，以及簡單驗證資料庫間利用 CDC 機制同步資料的功能。透過開源的 CDC 同步方案，我們可以更有效地進行巨量資料庫間資料的複製與轉移，並確保資料的一致性。

參考資料：MongoDB Kafka Connector 官方文件

有興趣歡迎 聯繫我們，或加入 歐立威 LINE 好友，了解更多產品資訊！

在上篇 MongoDB-最受歡迎的 NOSQL 資料庫 的介紹中，我們詳細講解了 MongoDB 的產品性能以及優點。那麽，這篇文章則會介紹 MongoDB 的基本觀念、合適使用情境以及相較於 MySQL ，MongoDB 的優勢。 

MongoDB 是什麼 ?

MongoDB 是一種開源的 NoSQL 文件資料庫，由於使用 JSON 文檔資料儲存結構，MongoDB 具有 靈活、 易於擴展、 高效能 這三種優勢。

與傳統關聯式資料庫相比，用戶在使用 MongoDB 儲存資料時，無需事先定義資料架構，還能夠自由地增加資料的 Key/Value 。

因此企業在處理巨量資料時，能夠花更少的時間，而且透過 MongoDB 允許資料格式不一致的特性，開發者也能夠輕鬆地處理資料架構不穩定的問題。

試想，如果一間企業每天有大量的資料需處理，而這些資料涵蓋的範圍從客戶資訊到公司的銷售資料應有盡有。每一種資料也有不同的特徵，如果使用傳統的 RDBMS （關聯式資料庫），那用戶就必須先定義資料的格式與架構，才能將資料儲存。然而，因為資料的種類繁多，如果每一筆資料都需要先定義才能存入，效率會太過緩慢。

只要透過 MongoDB 的半結構和非結構化的資料儲存特性，開發團隊能夠省下時間和減少工作量。

MongoDB 的關鍵元素

文件（Documents）

在 MongoDB 中，Document 是資料儲存的基本單位。

每個 Document 都是一個 JSON 格式的資料結構，由一個或多個 key-value 對組成。由於 Document 具有動態特性，同一個集合（Collection）中的不同 Document 可以擁有完全不同的欄位與結構。

當使用者將 JSON 文件儲存至 MongoDB 時，系統會自動將其轉換為 BSON（Binary JSON）格式。BSON 是 JSON 的二進位表示，支援更多資料類型，並具備更快的序列化與傳輸效率。

在查詢過程中，MongoDB 會讀取相應的 BSON，並將其轉換回 JSON，讓使用者能方便地檢視與操作。

以下是 MongoDB 官方對 BSON 的說明：
「BSON，即 Binary JSON。它的二進位結構能夠編碼資料類型與長度。相較於 JSON，BSON 的傳輸速度更快。」

Document 的靈活性和動態結構，以及 BSON 的高效傳輸特性，使 MongoDB 能夠有效地處理各種資料結構，並滿足現代應用程式的需求。

一個簡單的 Document 可能如下所示：

集合（Collection）

在 MongoDB 中，Collection 是由多個 Document 組成的容器。

它類似於關聯式資料庫中的表格，但與表格不同的是，Collection 不需要固定結構。這意味著同一個 Collection 內的 Document 可以擁有不同的欄位與格式。

Collections 常用來組織與儲存相關的 Document。舉例來說，一個 Collection 可以包含某公司所有員工的 Document，每個 Document 分別記錄一位員工的詳細資訊。

在操作上，Collections 提供查詢、插入、更新與刪除等功能，並可透過建立索引來提升查詢效能。這種設計使 Collection 具備高度靈活性，能夠因應各種資料需求與應用場景。

 

_id

在 MongoDB 中，_id 欄位是每個文件的主鍵（Primary Key），代表該文件的唯一識別值。

每個文件都會擁有獨特的 _id，用來確保集合內資料的一致性與正確性。若使用者在建立文件時未指定 _id，MongoDB 會自動為其產生一個長度為 12 位元組的 _id。

這種自動生成機制能保證資料的唯一性，使得集合內的檢索更加高效且可靠。

索引（Indexes）

使用者可以在集合中的任意欄位上建立次級索引（Secondary Index），以加速 BSON 文件的搜尋。

與預設的 _id 索引 不同，次級索引允許在多個欄位上進行快速檢索。若缺少索引，查詢時就必須對整個集合進行掃描（Collection Scan），逐一比對欄位，成本相當高。

次級索引在處理龐大資料集時特別重要，能有效降低查詢延遲並提升效能。
例如，在儲存客戶資訊的集合中，若經常需要依電子郵件地址進行查詢，就可以在「電子郵件」欄位上建立次級索引，從而直接透過該欄位快速檢索目標文件。

MongoDB 的 4 大優勢

（一）高效能（High Performance）

異於傳統關聯式資料庫，利用 Join 的運算功能進行資料的查詢。

MongoDB 採用基於文檔（ Document Base ）的模型，將資料 嵌入 至單一文檔中。得益於這種特性， MongoDB 的查詢速度能與傳統關聯式資料庫相互媲美活。

另外，MongoDB 能夠串聯眾多資料庫，快速的將 TB 級資料儲存，再將資料交付給擅於分析大數據的 Cloudera 進行處理。

（二）JSON 文檔資料庫（Document Database)

MongoDB 採用文件資料庫，將每筆資料以 Document 和 Field 的方式組織資料，這個特色的強大之處在於，它能夠匯總非結構化資料，快速製作成容易閲讀的資料目錄。

（三）廣泛支援的程式語言

以下是 MongoDB  支援的各種主流程式語言：

C、C++、C#，Erlang、Haskell、Java、JavaScript、Lisp、fibjs、node.JS、Perl、PHP、Python、Ruby、Scala、Go、Rust。

（四）合乎成本效益

MongoDB 提供多種靈活的計價方案。如果使用 MongoDB 的雲端版本 MongoDB Atlas ，您也能夠選擇最符合需求的付費方案！

另外，MongoDB Atlas 具有自動規模化（Auto Scaling）功能，能夠隨時調整資料集群的大小，不只能有效將成本降至最低，還能隨時保持應對突發狀況的靈活性！

4 個 MongoDB 的應用場景

MongoDB 是一種 NoSQL 資料庫，以其靈活性和可擴展性而聞名。以下列出 MongoDB 的 4 個應用場景，希望能幫助您了解 MongoDB 的優勢和適用範圍：

(一) 需要處理大量資料和高併發請求的雲端資料庫

MongoDB 的水平擴展能力可以輕鬆應對資料量和流量的增長，確保應用程式的效能和可用性。

這對於需要大量運算功能，並將資料快速發送到多個伺服器的雲端資料庫來說至關重要，例如：

• 電商平台： 處理大量的商品資訊、訂單資料和使用者行為數據。
• 物聯網應用： 儲存和分析來自各種感測器的海量數據。
• 遊戲平台： 儲存玩家資訊、遊戲進度和排行榜數據。
• 社群媒體： 處理使用者資訊、貼文、訊息和互動數據。

(二) 沒有專職 DBA 的小型企業或團隊

MongoDB 的易用性和自動化管理功能，例如自動分片、自動備份和恢復，可以降低資料庫的運維成本和複雜度，即使沒有專職 DBA 也能輕鬆管理。

(三) 擁有大量尚未確定且未來還會變動的資料架構

MongoDB 採用 schema-less 架構，允許使用者在無需預先定義資料結構的情況下儲存資料，非常適合應對結構經常變動的資料。

這對於擁有大量不穩定 schema 的應用程式來說非常重要，因為它可以靈活地適應 schema 的變更，而無需進行複雜的遷移或重構。

(四) 資料關係不複雜，且不需要進行 Join 運算的應用程式

MongoDB 的文件資料模型非常適合儲存和查詢具有嵌套結構的資料，例如：

• 產品目錄
• 使用者設定檔
• 內容管理系統

這使得 MongoDB 非常適合資料關係不複雜，且不需要進行 Join 運算的應用程式，因為它可以避免 Join 操作帶來的性能開銷，並提供更簡單、更直觀的資料模型。

MongoDB 與關聯式資料庫的關係為何？

MongoDB 是一個 文件導向的 NoSQL 資料庫，與傳統的關聯式資料庫如 MySQL、Oracle 或 SQL Server 有著本質上的差異。

這些差異不僅體現在資料管理的方式上，其中的文件導向和無架構設計使 MongoDB 在可擴展性和高可用性方面具有優越的效能。雖然，MongoDB 和 MySQL 都是開源且常見的資料庫，兩種資料庫的核心理念卻截然不同，因為它們分別為解決不同的問題而生。

在選擇 MongoDB 前，使用者必須先了解關聯式資料庫（RDBMS）與非關聯式資料庫（NoSQL）間的區別。

因此接下來我們將介紹關聯式資料庫與非關聯式資料庫間的區別，並深入比較 MongoDB 與 MySQL 的差異。

關聯式資料庫（RDBMS）

關聯式資料庫（RDBMS）是一種傳統的資料庫系統，以結構化查詢語言（SQL）為基礎，將資料儲存於預定義的表格中。這些表格包括行和列，彼此之間存在明確的關聯性。

在 RDBMS 中，使用者必須先將資料架構（Schema）和表之間的關係設定好。

這種預設方式使資料有明確的結構和關聯，但同時也會帶來一些挑戰。

因為一但將資料架構設定好，後續的變更就會變得相當複雜，尤其在資料量龐大的情況下，調整 Schema 不僅麻煩，更可能是個浩大的工程。儘管如此，關聯式資料庫的結構化方式仍適用於許多情況。

例如，它特別適合遵循ACID 特性的產業，如資料交易密集的銀行系統、企業資源規劃（ERP）系統等。這類強調一致性與完整性的設計，使其成為相關場景中的理想資料庫代表，如 MySQL 與 PostgreSQL。

非關聯式資料庫（NoSQL）

NoSQL 意指「not only SQL」，指不限於關聯式資料庫的各類資料庫。

NoSQL 資料庫通常無固定架構，具備更高的水平擴展性和靈活的資料結構，能快速存取大量非結構化或半結構化資料。

因此，它們特別適合需要高速讀寫和高吞吐量的場景，如即時分析、物聯網（IoT）及大數據應用。而代表性資料庫包括 MongoDB 與 Cassandra。

MongoDB 相較於 MySQL 的優點為何？

（一）服務零中斷

主機發生故障時， MongoDB 的副本集架構（Replica Set）能夠提供 冗餘（Redundancy）和 高可用性 (High Availability）。

每個副本集內部包含多台主機，其中一台為 Primary，其他台為 Secondary，多台機器之間的狀態及資料會自動同步。因此，當故障發生時，系統會在幾秒之內從 Secondary 中選出一台 Primary 接管工作，從而達到零停機 。

然而，對 MySQL 來說，故障移轉的程序必須依靠手動完成。維運團隊需要無時無刻的保持警覺，就算主機在半夜發生故障，維運團隊還是必須起床修復。

這不僅讓團隊無法好好休息，主機重新上線也需要耗費幾分鐘的時間。

（二）更快的開發時程

JSON 檔的本質是靈活的，每個文檔資料中的 Key Value 也不盡相同 。

例如：產品目錄中，儲存男裝資料與儲存電視規格資料的 Key/Value 是不相同的。我們也稱這種現象為資料的「多型」。

使用 JSON 文檔，我們能夠在無需更改資料庫架構的情況下，隨意增添資料的 Key Value。 JSON 文檔這種對資料欄位沒有強制定義的特性，讓開發者能用最短的時間開發軟體系統。

反觀 MySQL ，如果貿然更改 MySQL 內的資料結構，會造成資料庫的停機或主機資源的大量耗損。

（三）更方便的擴充

隨著資料量的增多，再優秀的資料庫都會面臨擴充的需求，利用 MongoDB 的分片功能，資料庫中的工作量會被分散至多台主機中。

用戶只需根據自身的需求增加主機，而不用花費鉅額成本增添一台效能更好的主機系統，從而達到節省成本的目的。而且使用者在擴充 MongoDB 時，無需更改資料庫內的設定，能減少擴充的複雜度。

然而，在擴充 MySQL 時，由於關聯式資料庫內寫入大量的 SQL Join，使用者必須調整資料庫內的所有程式碼、停機資料庫，同時必須小心地處理資料表格存放的節點。

（四）MongoDB 與 MySQL 的差異對照表

以下為 MongoDB 與 MySQL 之間的差別：

語法差異

雖然 MongoDB 使用的術語和 MySQL 不同，但本質上是差不多的，差異可參考下方術語對照表 ： 

總結

MongoDB 是目前市面上最受歡迎的 NoSQL 資料庫，同時也是 NoSQL 資料庫領域中的領頭羊。

MongoDB 提供企業更方便的資料儲存解決方案、提供工程師更友善的開發環境，也讓企業在不用花費鉅額成本的情況下，能夠選擇一個價格更低廉，效能良好的資料庫替代方案。

歐立威科技是 MongoDB 的代理商，如果想要獲得更多資訊，歡迎聯繫我們！

加入歐立威 LINE 好友，了解更多產品資訊

【前情提要】

2021年12月9日，Apache Log4j 被揭漏有重大風險漏洞 Log4Shell，漏洞編號 CVE-2021-44228。駭客可以利用該漏洞發動遠端程式碼執行攻擊，最嚴重可以接管整台系統，影響範圍擴及 Apache Log4j 2 中 logging library 的多個版本，資安專家稱為近 10 年來最嚴重漏洞，研究人員也發現已經有針對該漏洞的攻擊行動。

哪些產品被影響？

截至台灣時間 2021/12/20，MongoDB 被影響的產品調查狀態如下

本文章為歐立威科技整理原廠官方文件與網路資源，並非即時更新，僅供使用者參考，使用者應自行審慎評估自身環境及官方最新建議以採取最佳行動，若需要任何技術支援歡迎聯絡我們。

參考資料：

• Log4Shell Vulnerability (CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105) and MongoDB