From 4e152ed5de927b7230bc38ba371c66a01bc402a1 Mon Sep 17 00:00:00 2001 From: Annie Tallund Date: Mon, 1 Sep 2025 15:13:34 +0200 Subject: [PATCH 1/2] Tech review of MongoDB for GCP --- .../github-on-arm/instance.md | 2 +- .../mongodb-on-gcp/_index.md | 19 +- .../mongodb-on-gcp/background.md | 4 +- .../mongodb-on-gcp/baseline-testing.md | 168 +++++++----------- .../mongodb-on-gcp/benchmarking.md | 83 ++++----- .../mongodb-on-gcp/create-instance.md | 26 +-- .../mongodb-on-gcp/mongodb-deploy.md | 111 +++++------- .../{image1.png => select-instance.png} | Bin 8 files changed, 176 insertions(+), 237 deletions(-) rename content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/{image1.png => select-instance.png} (100%) diff --git a/content/learning-paths/servers-and-cloud-computing/github-on-arm/instance.md b/content/learning-paths/servers-and-cloud-computing/github-on-arm/instance.md index b775ebc4f6..632266e2d3 100644 --- a/content/learning-paths/servers-and-cloud-computing/github-on-arm/instance.md +++ b/content/learning-paths/servers-and-cloud-computing/github-on-arm/instance.md @@ -8,7 +8,7 @@ layout: learningpathall ## Introduction -This guide walks you through provisioning **Google Axion C4A Arm virtual machine** on GCP with the **c4a-standard-4 (4 vCPUs, 16 GB Memory)** machine type, using the **Google Cloud Console**. +This section walks you through creating **Google Axion C4A Arm virtual machine** on GCP with the **c4a-standard-4 (4 vCPUs, 16 GB Memory)** machine type, using the **Google Cloud Console**. If you haven't got a Google Cloud account, you can follow the Learning Path on [Getting Started with Google Cloud Platform](https://learn.arm.com/learning-paths/servers-and-cloud-computing/csp/google/) to get started. diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/_index.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/_index.md index 37e306524b..78c9482bfc 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/_index.md @@ -1,25 +1,26 @@ --- title: Deploy MongoDB on Google Axion C4A virtual machine -minutes_to_complete: 60 +minutes_to_complete: 15 -who_is_this_for: This Learning Path is designed for software developers looking to migrate their MongoDB workloads from x86_64 to Arm-based platforms, specifically on Google Axion-based C4A virtual machines. +draft: true +cascade: + draft: true + +who_is_this_for: This is an introductory topic for software developers looking to migrate their MongoDB workloads from x86_64 to Arm-based platforms, specifically on Google Axion-based C4A virtual machines. learning_objectives: - - Provision an Arm virtual machine on the Google Cloud Platform using the C4A Google Axion instance family, and RHEL 9 as the base image. - - Install and run MongoDB on an Arm-based GCP C4A instances. - - Validate the functionality of MongoDB through baseline testing. + - Create an Arm cloud instance on the Google Cloud Platform + - Install and run MongoDB on the Arm-based GCP C4A instance. - Benchmark the MongoDB performance on Arm using Yahoo Cloud Serving Benchmark (YCSB). prerequisites: - A [Google Cloud Platform (GCP)](https://cloud.google.com/free?utm_source=google&hl=en) account with billing enabled. - - Basic understanding of Linux command line. - - Familiarity with the [MongoDB architecture](https://www.mongodb.com/) and deployment practices on Arm64 platforms. -author: Jason Andrews +author: Annie Tallund ##### Tags -skilllevels: Advanced +skilllevels: Introductory subjects: Databases cloud_service_providers: Google Cloud diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/background.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/background.md index 99947c23e8..a576e38b4f 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/background.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/background.md @@ -8,9 +8,9 @@ layout: "learningpathall" ## Google Axion C4A series -The Google Axion C4A series is a family of Arm-based virtual machines built on Google’s custom Axion CPU, which is based on Arm Neoverse-V2 cores. Designed for high-performance and energy-efficient computing, these virtual machine offer strong performance ideal for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications. +The C4A series is a family of Arm-based instance types for Google’s custom Axion CPU, which is based on Arm Neoverse-V2 cores. Designed for high-performance and energy-efficient computing, these virtual machine offer strong performance suitable for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications. -The C4A series provides a cost-effective alternative to x86 virtual machine while leveraging the scalability and performance benefits of the Arm architecture in Google Cloud. +The C4A series provides a cost-effective virtual machine while leveraging the scalability and performance benefits of the Arm architecture in Google Cloud. To learn more about Google Axion, refer to the blog [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu). diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/baseline-testing.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/baseline-testing.md index 842709484f..02bb7c019b 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/baseline-testing.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/baseline-testing.md @@ -6,35 +6,37 @@ weight: 5 layout: learningpathall --- +Now that MongoDB is successfully installed on your GCP C4A Arm virtual machine, follow these steps to verify that the server is running correctly and accepting local connections. -Since MongoDB is installed successfully on your GCP C4A Arm virtual machine, follow these steps to validate that the server is running and accepting local connections. - -## MongoDB Baseline Testing (Using **mongosh**) - -1. Connect to MongoDB +### 1. Connect to MongoDB Open a shell session to the local MongoDB instance: + ```console mongosh mongodb://127.0.0.1:27017 ``` -2. Create a Test Database and Collection: +### 2. Create a Test Database and Collection -```console +Switch to a new database and create a collection: + +```javascript use baselineDB db.createCollection("test") ``` -This creates a new database **baselineDB** and an empty collection named test. -You should see an output similar to: +This creates a new database named `baselineDB` and an empty collection called `test`. + +Expected output: ```output -test> use baselineDB -... db.createCollection("test") -... switched to db baselineDB +{ ok: 1 } ``` -3. Insert 10,000 Test Documents: + +### 3. Insert 10,000 Test Documents + +Populate the collection with 10,000 timestamped documents: ```javascript for (let i = 0; i < 10000; i++) { @@ -45,128 +47,91 @@ for (let i = 0; i < 10000; i++) { }) } ``` -This simulates basic write operations with timestamped records. -10,000 documents will be cretaed and inserted into the test collection of the currently selected database. -The record field would increment from 0 to 9999. The status is always "new". -The timestamp would capture the insertion time for each document using ***new Date()***. -You should see an output similar to: +Each document will contain: +- `record`: a counter from 0 to 9999 +- `status`: always `"new"` +- `timestamp`: the current date/time of insertion + +Sample output: ```output -{ - acknowledged: true, - insertedId: ObjectId('6892dacfbd44e23df4750aa9') -} +{ acknowledged: true, insertedId: ObjectId('...') } ``` -4. Read (Query) a Subset of Documents: +### 4. Read a Subset of Documents + +Verify read functionality by querying the first few documents: -Fetch a few documents to verify read functionality. ```javascript db.test.find({ status: "new" }).limit(5) ``` -This command is a simple read operation to verify that your data is inserted correctly. It queries the test collection in the current database, and only returns documents where the status is "new". ***limit(5)*** returns only the first 5 matching documents. -You should see an output similar to: +This returns the first 5 documents where `status` is `"new"`. + +### 5. Update a Document + +Update a specific document by changing its status: -```output -[ - { - _id: ObjectId('6892dacbbd44e23df474e39a'), - record: 0, - status: 'new', - timestamp: ISODate('2025-08-06T04:32:11.090Z') - }, - { - _id: ObjectId('6892dacbbd44e23df474e39b'), - record: 1, - status: 'new', - timestamp: ISODate('2025-08-06T04:32:11.101Z') - }, - { - _id: ObjectId('6892dacbbd44e23df474e39c'), - record: 2, - status: 'new', - timestamp: ISODate('2025-08-06T04:32:11.103Z') - }, - { - _id: ObjectId('6892dacbbd44e23df474e39d'), - record: 3, - status: 'new', - timestamp: ISODate('2025-08-06T04:32:11.104Z') - }, - { - _id: ObjectId('6892dacbbd44e23df474e39e'), - record: 4, - status: 'new', - timestamp: ISODate('2025-08-06T04:32:11.106Z') - } -] -``` -5. Update a Document: - -Update a specific document's field to validate update capability. ```javascript db.test.updateOne({ record: 100 }, { $set: { status: "processed" } }) ``` -Above command will find the first document where record is exactly 100, and updates that document by setting its status field to "processed". -You should see an output similar to: +This finds the document where `record` is 100 and updates the `status`. + +Expected output: ```output { acknowledged: true, - insertedId: null, matchedCount: 1, - modifiedCount: 1, - upsertedCount: 0 + modifiedCount: 1 } ``` -6. View the Updated Document Before Deletion -```console +### 6. View the Updated Document + +Confirm that the document was updated: + +```javascript db.test.findOne({ record: 100 }) ``` -This retrieves the document where record is 100, allowing you to verify that its status has been updated to "processed". -You should see output similar to: +Expected output: ```output { - _id: ObjectId('689490ddb7235c65ca74e3fe'), + _id: ObjectId('...'), record: 100, status: 'processed', - timestamp: ISODate('2025-08-07T11:41:17.508Z') + timestamp: ISODate('...') } ``` -7. Delete a Document: +### 7. Delete a Document + +Remove a single document: ```javascript db.test.deleteOne({ record: 100 }) ``` -This tells MongoDB to delete one document from the test collection, where record is exactly 100. -You should see an output similar to: - -```output -{ acknowledged: true, deletedCount: 1 } -``` -Now, confirm the deletion: +Verify that it was deleted: -```console +```javascript db.test.findOne({ record: 100 }) ``` -The above command confirms that the document was successfully deleted. -You should see an output similar to: +Expected output: + ```output null ``` -8. Measure Execution Time (Optional): +### 8. Measure Execution Time (Optional) + +Measure how long it takes to insert 10,000 documents: -The below snippet measures how long it takes to insert documents for performance insight. ```javascript var start = new Date() for (let i = 0; i < 10000; i++) { @@ -174,39 +139,42 @@ for (let i = 0; i < 10000; i++) { } print("Insert duration (ms):", new Date() - start) ``` -You should see an output similar to: + +Sample output: ```output Insert duration (ms): 4427 ``` -9. Count Total Documents: -Count total entries to confirm expected data volume. +### 9. Count Total Documents + +Check the total number of documents in the collection: + ```javascript db.test.countDocuments() ``` -You should see an output similar to: + +Expected output: ```output 19999 ``` + The count **19999** reflects the total documents after inserting 10,000 initial records, adding 10,000 more (in point 8), and deleting one (record: 100). -10. Clean Up (Optional): -Deletes the **baselineDB** database and all its contents. +### 10. Clean Up (Optional) + +For the sake of resetting the environment, this following command deletes the current database you are connected to in mongosh. Drop the `baselineDB` database to remove all test data: + ```javascript db.dropDatabase() ``` -You should see an output similar to: + +Expected output: ```output { ok: 1, dropped: 'baselineDB' } ``` -The above is a destructive command that completely deletes the current database you are connected to in mongosh. - -The above operations confirm that MongoDB is installed successfully and is functioning as expected on the GCP Arm64 environment. - -Using **mongosh**, you validated key database operations such as **insert**, **read**, **update**, **delete**, and **count**. -Now, your MongoDB instance is ready for further benchmarking and production use. +These baseline operations confirm that MongoDB is functioning properly on your GCP Arm64 environment. Using `mongosh`, you validated key database capabilities including **inserts**, **queries**, **updates**, **deletes**, and **performance metrics**. Your instance is now ready for benchmarking or application integration. \ No newline at end of file diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/benchmarking.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/benchmarking.md index 2ddf4990c6..fcbe8fd10e 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/benchmarking.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/benchmarking.md @@ -5,13 +5,14 @@ weight: 6 ### FIXED, DO NOT MODIFY layout: learningpathall --- - ## MongoDB Benchmarking with YCSB (Yahoo! Cloud Serving Benchmark) -**YCSB (Yahoo! Cloud Serving Benchmark)** is an open-source benchmarking tool for evaluating the performance of NoSQL databases under different workloads. It supports operations like read, write, update, and scan to simulate real-world usage patterns. +**YCSB (Yahoo! Cloud Serving Benchmark)** is an open-source tool for evaluating the performance of NoSQL databases under various workloads. It simulates operations such as reads, writes, updates, and scans to mimic real-world usage patterns. ### Install YCSB (Build from Source) +First, install the required build tools and clone the YCSB repository: + ```console sudo dnf install -y git maven java-11-openjdk-devel git clone https://github.com/brianfrankcooper/YCSB.git @@ -21,85 +22,61 @@ mvn -pl site.ycsb:mongodb-binding -am clean package ### Load Phase – Insert Initial Dataset -This phase inserts documents into MongoDB to simulate a typical workload. +This phase inserts a set of documents into MongoDB to simulate a typical starting workload. By default, it inserts 1,000 records. ```console ./bin/ycsb load mongodb -s \ -P workloads/workloada \ -p mongodb.url=mongodb://127.0.0.1:27017/ycsb ``` -The core purpose of this phase is to prepare the database with initial records (default: 1,000) for benchmarking. + +This prepares the database for the actual performance test. ### Execute Benchmark Workload -This phase performs actual read/write operations and reports performance metrics. +Run the actual benchmark with the predefined workload. This command performs mixed read/write operations and collects performance metrics. + ```console ./bin/ycsb run mongodb -s \ -P workloads/workloada \ -p mongodb.url=mongodb://127.0.0.1:27017/ycsb ``` -Workload A (from workloads/workloada) simulates a balanced read/write workload: +**Workload A** is a balanced workload: - 50% reads -- 50% updates/writes +- 50% updates -This is designed to mimic many real-world systems where reads and writes are equally important (e.g., session stores, shopping carts, etc.). -The above command measures latency and throughput of mixed read/write operations. +This simulates common real-world applications like session stores or shopping carts. - -You should see an output similar to: +You’ll see performance output that looks like this: ```output -Loading workload... -Starting test. -2025-08-06 06:05:50:378 0 sec: 0 operations; est completion in 0 second -mongo client connection created with mongodb://127.0.0.1:27017/ycsb -DBWrapper: report latency for each error is false and specific error codes to track for latency are: [] -2025-08-06 06:05:50:874 0 sec: 1000 operations; 1953.12 current ops/sec; [READ: Count=534, Max=8279, Min=156, Avg=312.96, 50=261, 90=436, 99=758, 99.9=8279, 99.99=8279] [CLEANUP: Count=1, Max=4139, Min=4136, Avg=4138, 50=4139, 90=4139, 99=4139, 99.9=4139, 99.99=4139] [UPDATE: Count=466, Max=26543, Min=186, Avg=384.45, 50=296, 90=444, 99=821, 99.9=26543, 99.99=26543] -[OVERALL], RunTime(ms), 512 -[OVERALL], Throughput(ops/sec), 1953.125 -[TOTAL_GCS_G1_Young_Generation], Count, 2 -[TOTAL_GC_TIME_G1_Young_Generation], Time(ms), 3 -[TOTAL_GC_TIME_%_G1_Young_Generation], Time(%), 0.5859375 -[TOTAL_GCS_G1_Old_Generation], Count, 0 -[TOTAL_GC_TIME_G1_Old_Generation], Time(ms), 0 -[TOTAL_GC_TIME_%_G1_Old_Generation], Time(%), 0.0 -[TOTAL_GCs], Count, 2 -[TOTAL_GC_TIME], Time(ms), 3 -[TOTAL_GC_TIME_%], Time(%), 0.5859375 [READ], Operations, 534 -[READ], AverageLatency(us), 312.96067415730334 +[READ], AverageLatency(us), 312.96 [READ], MinLatency(us), 156 [READ], MaxLatency(us), 8279 -[READ], 50thPercentileLatency(us), 261 -[READ], 95thPercentileLatency(us), 524 -[READ], 99thPercentileLatency(us), 758 -[READ], Return=OK, 534 -[CLEANUP], Operations, 1 -[CLEANUP], AverageLatency(us), 4138.0 -[CLEANUP], MinLatency(us), 4136 -[CLEANUP], MaxLatency(us), 4139 -[CLEANUP], 50thPercentileLatency(us), 4139 -[CLEANUP], 95thPercentileLatency(us), 4139 -[CLEANUP], 99thPercentileLatency(us), 4139 +... [UPDATE], Operations, 466 -[UPDATE], AverageLatency(us), 384.4527896995708 +[UPDATE], AverageLatency(us), 384.45 [UPDATE], MinLatency(us), 186 [UPDATE], MaxLatency(us), 26543 -[UPDATE], 50thPercentileLatency(us), 296 -[UPDATE], 95thPercentileLatency(us), 498 -[UPDATE], 99thPercentileLatency(us), 821 -[UPDATE], Return=OK, 466 +... +[OVERALL], RunTime(ms), 512 +[OVERALL], Throughput(ops/sec), 1953.125 ``` -### YCSB Operations & Latency Metrics +### YCSB Operations & Latency Metrics Explained + +- **Operations Count**: Total operations performed for each type (e.g., READ, UPDATE). +- **Average Latency (us)**: The average time to complete each operation, measured in microseconds. +- **Min Latency / Max Latency (us)**: The fastest and slowest observed times for any single operation of that type. -- **Operations Count**: Total number of operations performed by YCSB for each type. -- **Average Latency (us**): The average time (in microseconds) it took to complete each operation type. -- **Min Latency (us)**: The fastest (minimum) time observed for any single operation of that type. -- **Max Latency (us)**: The slowest (maximum) time recorded for any single operation of that type. +With YCSB installed and benchmark results captured, you now have a baseline for MongoDB's performance under mixed workloads. + +### Benchmark summary on x86_64 + +To better understand how MongoDB behaves across architectures, YCSB benchmark workloads were run on both an **x86_64 (C3 Standard)** and an **Arm64 (C4A Standard)** virtual machine, each with 4 vCPUs and 16 GB of memory, running RHEL 9. -### Benchmark summary on x86_64: The following benchmark results are collected on a c3-standard-4 (4 vCPU, 2 core, 16 GB Memory) x86_64 environment, running RHEL 9. | Operation | Count | Avg Latency (us) | Min Latency (us) | Max Latency (us) | 50th Percentile (us) | 95th Percentile (us) | 99th Percentile (us) | @@ -121,4 +98,6 @@ The following benchmark results are collected on a c4a-standard-4 (4 vCPU, 16 G - Arm results show low **average latencies**, **READ** at **313 us** and **UPDATE** at **384 us**. - **50th** to **99th percentile** latencies remain stable, indicating consistent performance. -- **Max latency** spikes (**8279 us READ**, **26543 us UPDAT**E) suggest rare outliers. +- **Max latency** spikes (**8279 us READ**, **26543 us UPDATE**) suggest rare outliers. + +This Learning Path walked you through setting up and benchmarking MongoDB on an Arm-based GCP instance, highlighting how to run core operations, validate performance, and interpret benchmarking results with YCSB. Alongside, you explored some performance numbers, showing that Arm is a powerful and cost-efficient alternative for modern data-serving workloads like MongoDB. \ No newline at end of file diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/create-instance.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/create-instance.md index 3ca28709da..f54706f908 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/create-instance.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/create-instance.md @@ -1,5 +1,5 @@ --- -title: Create Google Axion C4A Arm virtual machine +title: Create Google Axion instance weight: 3 ### FIXED, DO NOT MODIFY @@ -8,22 +8,26 @@ layout: learningpathall ## Introduction -This guide walks you through provisioning **Google Axion C4A Arm virtual machine** on GCP with the **c4a-standard-4 (4 vCPUs, 16 GB Memory)** machine type, using the **Google Cloud Console**. +This section walks you through creating a **Google Axion C4A Arm virtual machine** on GCP with the **c4a-standard-4 (4 vCPUs, 16 GB Memory)** machine type, using the **Google Cloud Console**. -If you are new to Google Cloud, it is recommended to follow the [GCP Quickstart Guide to Create a virtual machine](https://cloud.google.com/compute/docs/instances/create-start-instance). - -For more details, kindly follow the Learning Path on [Getting Started with Google Cloud Platform](https://learn.arm.com/learning-paths/servers-and-cloud-computing/csp/google/). +If you haven't set up a Google Cloud account, check out the Learning Path on [Getting Started with Google Cloud Platform](https://learn.arm.com/learning-paths/servers-and-cloud-computing/csp/google/). ### Create an Arm-based Virtual Machine (C4A) To create a virtual machine based on the C4A Arm architecture: 1. Navigate to the [Google Cloud Console](https://console.cloud.google.com/). -2. Go to **Compute Engine > VM Instances** and click on **Create Instance**. +2. Go to **Compute Engine** and click on **Create Instance**. 3. Under the **Machine Configuration**: - Fill in basic details like **Instance Name**, **Region**, and **Zone**. - - Choose the **Series** as `C4A`. - - Select a machine type such as `c4a-standard-4`. -![Instance Screenshot](./image1.png) -4. Under the **OS and Storage**, click on **Change**, and select Arm64 based OS Image of your choice. For this Learning Path, we pick **Red Hat Enterprise Linux** as the Operating System with **Red Hat Enterprise Linux 9** as the Version. Make sure you pick the version of image for Arm. -5. Under **Networking**, enable **Allow HTTP traffic** to allow HTTP communications. + - Select the **Series** as `C4A`. + - Choose a machine type such as `c4a-standard-4`. +![Instance Screenshot](./select-instance.png) +4. Under the **OS and Storage**, click on **Change**, and select **Red Hat Enterprise Linux** as the Operating System with **Red Hat Enterprise Linux 9** as the Version. Make sure you pick the version of image for Arm. +5. Under **Networking**, enable **Allow HTTP traffic** to allow interacting for later steps in the Learning Path. 6. Click on **Create**, and the instance will launch. + +{{% notice Important %}} +Avoid enabling Allow HTTP traffic permanently, as it introduces a security vulnerability. Instead, configure access to allow only your own IP address for long-term use. +{{% /notice %}} + +To access the Google Cloud Console, click the SSH button in your instance overview. This will open a command line interface (CLI), which you’ll use to run the remaining commands in this Learning Path. Continue to the next section to set up MongoDB on your instance. \ No newline at end of file diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/mongodb-deploy.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/mongodb-deploy.md index 0725049259..6d41947389 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/mongodb-deploy.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/mongodb-deploy.md @@ -1,119 +1,106 @@ --- -title: Install MongoDB on Google Axion C4A virtual machine +title: Install MongoDB weight: 4 ### FIXED, DO NOT MODIFY layout: learningpathall --- +In this section, you’ll install MongoDB and the MongoDB Shell (`mongosh`) by downloading the necessary binaries, configuring your environment, and verifying that the database server is running correctly. -## Install MongoDB and mongosh on Google Axion C4A virtual machine +### 1. Install System Dependencies -Install MongoDB and mongosh on GCP RHEL 9 Arm64 by downloading the binaries, setting up environment paths, configuring data and log directories, and starting the server for local access and verification. +Start by installing required system packages to support MongoDB: -1. Install System Dependencies - -Install required system packages to support MongoDB: ```console +sudo dnf update sudo dnf install -y libcurl openssl tar wget curl ``` -2. Download annd Extract MongoDB +### 2. Download and Extract MongoDB + +Next, fetch and unpack the MongoDB binaries for Arm: -Fetch and unpack the MongoDB binaries for Arm64: ```console wget https://fastdl.mongodb.org/linux/mongodb-linux-aarch64-rhel93-8.0.12.tgz tar -xzf mongodb-linux-aarch64-rhel93-8.0.12.tgz ls mongodb-linux-aarch64-rhel93-8.0.12/bin ``` -3. Add MongoDB to System PATH +To make MongoDB binaries accessible from any terminal session, add them to your PATH: -Enable running mongod from any terminal session: ```console echo 'export PATH=~/mongodb-linux-aarch64-rhel93-8.0.12/bin:$PATH' >> ~/.bashrc source ~/.bashrc ``` -4. Create a data Directory +### 3. Start the MongoDB server + + + +Set up a directory to store MongoDB's data files: -Set up the database data directory: ```console mkdir -p ~/mongodb-data/db ``` +Run MongoDB in the **foreground** to verify it starts correctly: + +```console +mongod --dbpath ~/mongodb-data/db +``` + +Starting the server in the **foreground** allows you to see real-time logs and is useful for debugging or verifying that MongoDB starts correctly. However, this will occupy your terminal and stop the server if you close the terminal or interrupt it. -5. Start MongoDB Server +After stopping the server (e.g., with `Ctrl+C`), confirm that files have been created in the database directory: -Start MongoDB in the **foreground** (without --fork) to view real-time output and ensure it starts correctly: ```console -~/mongodb-linux-aarch64-rhel93-8.0.12/bin/mongod --dbpath ~/mongodb-data/db +ls ~/mongodb-data/db/ ``` -Once confirmed it's working, you can start MongoDB in the **background** with logging: + +Example output: + +```output +collection-0-7680310461694759627.wt index-3-7680310461694759627.wt mongod.lock WiredTiger.lock +``` + +Once you’ve confirmed it’s working, you can start MongoDB in the **background** using the `--fork` option and redirecting logs to a file. This allows MongoDB to run continuously without tying up your terminal session. To start MongoDB in the **background** with logging enabled: + ```console -./mongodb-linux-aarch64-rhel93-8.0.12/bin/mongod --dbpath ~/mongodb-data/db --logpath ~/mongodb-data/mongod.log --fork +mongod --dbpath ~/mongodb-data/db --logpath ~/mongodb-data/mongod.log --fork ``` -{{% notice Note %}}Make sure the **~/mongodb-data/db** directory exists before starting.{{% /notice %}} -6. Install mongosh -**mongosh** is the MongoDB Shell used to interact with your MongoDB server. It provides a modern, user-friendly CLI for running queries and database operations. +### 4. Install mongosh + +`mongosh` is the MongoDB shell used to interact with your database. Download and install it for Arm: -Download and install MongoDB’s command-line shell for Arm: ```console wget https://github.com/mongodb-js/mongosh/releases/download/v2.5.6/mongodb-mongosh-2.5.6.aarch64.rpm sudo dnf install -y ./mongodb-mongosh-2.5.6.aarch64.rpm ``` -### Verify Mongodb and mongosh Installation -Check if MongoDb and mongosh is properly installed: +Confirm that`mongosh` was installed correctly by checking that the version is printed: + ```console -mongod --version mongosh --version ``` -You should see an output similar to: -```output -db version v8.0.12 -Build Info: { - "version": "8.0.12", - "gitVersion": "b60fc6875b5fb4b63cc0dbbd8dda0d6d6277921a", - "openSSLVersion": "OpenSSL 3.2.2 4 Jun 2024", - "modules": [], - "allocator": "tcmalloc-google", - "environment": { - "distmod": "rhel93", - "distarch": "aarch64", - "target_arch": "aarch64" - } -} -$ mongosh --version -2.5.6 -``` -### Connect to MongoDB via mongosh +### 5. Connect to MongoDB via mongosh + +Finally, connect to your MongoDB server using the shell: -Start interacting with MongoDB through its shell interface: ```console mongosh mongodb://127.0.0.1:27017 ``` -You should see an output similar to: -```output -Current Mongosh Log ID: 6891ebb158db5b705d74e399 -Connecting to: mongodb://127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&appName=mongosh+2.5.6 -Using MongoDB: 8.0.12 -Using Mongosh: 2.5.6 - -For mongosh info see: https://www.mongodb.com/docs/mongodb-shell/ - ------- - The server generated these startup warnings when booting - 2025-08-05T07:17:45.864+00:00: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted - 2025-08-05T07:17:45.864+00:00: Soft rlimits for open file descriptors too low - 2025-08-05T07:17:45.864+00:00: For customers running the current memory allocator, we suggest changing the contents of the following sysfsFile - 2025-08-05T07:17:45.864+00:00: We suggest setting the contents of sysfsFile to 0. - 2025-08-05T07:17:45.864+00:00: Your system has glibc support for rseq built in, which is not yet supported by tcmalloc-google and has critical performance implications. Please set the environment variable GLIBC_TUNABLES=glibc.pthread.rseq=0 ------- +Sample output: + +```output +Connecting to: mongodb://127.0.0.1:27017/?directConnection=true&... +Using MongoDB: 8.0.12 +Using Mongosh: 2.5.6 +... test> ``` -MongoDB installation is complete. You can now proceed with the baseline testing. +With MongoDB and `mongosh` successfully installed and running, you’re now ready to proceed with baseline testing. diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/image1.png b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/select-instance.png similarity index 100% rename from content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/image1.png rename to content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/select-instance.png From 4255ad8db4d2d9bcb000ad5733fa2ac7ac1da906 Mon Sep 17 00:00:00 2001 From: Annie Tallund Date: Mon, 1 Sep 2025 15:17:59 +0200 Subject: [PATCH 2/2] Update baseline-testing.md --- .../mongodb-on-gcp/baseline-testing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/baseline-testing.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/baseline-testing.md index 02bb7c019b..6d558c9688 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/baseline-testing.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/baseline-testing.md @@ -110,7 +110,7 @@ Expected output: ### 7. Delete a Document -Remove a single document: +The command below tells MongoDB to delete one document from the test collection, where record is exactly 100: ```javascript db.test.deleteOne({ record: 100 })