Skip to content

Commit b666abd

Browse files
committed
docs: generate Readme
1 parent 86c1de0 commit b666abd

File tree

1 file changed

+34
-9
lines changed

1 file changed

+34
-9
lines changed

README.md

Lines changed: 34 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1484,7 +1484,8 @@ Use [obtain-oidc-id-token](https://github.com/codefresh-io/steps/blob/822afc0a9a
14841484

14851485
Sometimes, in new releases of Codefresh On-Prem, index requirements change. When this happens, it's mentioned in the [Upgrading section](#upgrading) for the specific release.
14861486

1487-
> ℹ️ If you're upgrading from version `X` to version `Y`, and index requirements were updated in any of the intermediate versions, you only need to align your indexes with the index requirements of version `Y`. To do that, follow [Index alignment](#index-alignment) instructions.
1487+
> [!TIP]
1488+
> If you're upgrading from version `X` to version `Y`, and index requirements were updated in any of the intermediate versions, you only need to align your indexes with the index requirements of version `Y`. To do that, follow [Index alignment](#index-alignment) instructions.
14881489

14891490
### Index alignment
14901491

@@ -1507,11 +1508,12 @@ indexes
15071508
**Overview of the index alignment process:**
15081509

15091510
1. Identify the differences between the indexes in your MongoDB instance and the required index definitions.
1510-
2. Create any missing indexes one by one. (It's important not to create them in bulk.)
1511+
2. Create any missing indexes.
15111512
3. Perform the upgrade of Codefresh On-Prem installation.
15121513
4. Then remove any unnecessary indexes.
15131514

1514-
> ⚠️ **Note! Any changes to indexes should be performed during a defined maintenance window or during periods of lowest traffic to MongoDB.**
1515+
> [!IMPORTANT]
1516+
> Any changes to indexes should be performed during a defined maintenance window or during periods of lowest traffic to MongoDB.**
15151517
>
15161518
> Building indexes during time periods where the target collection is under heavy write load can result in reduced write performance and longer index builds. ([*Source: MongoDB official documentation*](https://www.mongodb.com/docs/manual/core/index-creation/#index-build-impact-on-database-performance))
15171519
>
@@ -1533,19 +1535,32 @@ mongosh "<connection_string>"
15331535
db.getSiblingDB('<db_name>').getCollection('<collection_name>').getIndexes()
15341536
```
15351537

1536-
- Compare your indexes with the required indexes for the target release, and adjust them by creating any missing indexes or removing any unnecessary ones
1538+
- Compare your indexes with the required indexes for the target release, and adjust them by creating any missing indexes or removing any unnecessary ones.
15371539

15381540
**Index creation**
15391541

1540-
> ⚠ **Note! Always create indexes sequentially, one by one. Don't create them in bulk.**
1542+
- To create an indexes, we recommend using the `createIndexes` command ([ref](https://www.mongodb.com/docs/manual/reference/command/createIndexes/)):
15411543

1542-
- To create an index, use the `createIndex()` method:
1544+
> [!IMPORTANT]
1545+
> We recommend to create indexes in batches of 3 indexes at a time.
1546+
> However, it's highly recommended before creating indexes in production DB to test performance impact on a staging instance with prod-like amount of data.
1547+
>
1548+
> Previous command should be completed before starting the next batch.
15431549

15441550
```js
1545-
db.getSiblingDB('<db_name>').getCollection('<collection_name>').createIndex(<keys_object>, <options_object>)
1551+
db.getSiblingDB('<db_name>').runCommand(
1552+
{
1553+
createIndexes: '<collection_name>',
1554+
indexes: [
1555+
{ ... }, // Index definition from the doc above
1556+
{ ... }, // Index definition from the doc above
1557+
{ ... } // Index definition from the doc above
1558+
],
1559+
}
1560+
)
15461561
```
15471562

1548-
After executing the `createIndex()` command, you should see a result indicating that the index was created successfully.
1563+
After executing the command, you should see a result indicating that the indexes were created successfully.
15491564

15501565
**Index removal**
15511566

@@ -1559,7 +1574,8 @@ db.getSiblingDB('<db_name>').getCollection('<collection_name>').dropIndex('<inde
15591574

15601575
If you're hosting MongoDB on [Atlas](https://www.mongodb.com/atlas/database), use the following [Manage Indexes](https://www.mongodb.com/docs/atlas/atlas-ui/indexes/) guide to View, Create or Remove indexes.
15611576

1562-
> ⚠️ **Important!** In Atlas, for production environments, it is recommended to use rolling index builds by enabling the "Build index via rolling process" checkbox. ([*MongoDB official documentation*](https://www.mongodb.com/docs/v6.0/tutorial/build-indexes-on-replica-sets/))
1577+
> [!IMPORTANT]
1578+
> In Atlas, for production environments, it may be recommended to use rolling index builds by enabling the "Build index via rolling process" checkbox. ([*MongoDB official documentation*](https://www.mongodb.com/docs/v7.0/tutorial/build-indexes-on-replica-sets/))
15631579

15641580
## Upgrading
15651581

@@ -2360,6 +2376,15 @@ For built-in RabbitMQ `bitnami/rabbitmq` subchart, pre-upgrade hook was added to
23602376

23612377
- `.Values.runner` is removed
23622378

2379+
#### Changes in MongoDB schema
2380+
2381+
Changes in indexes: follow [Maintaining MongoDB indexes](#maintaining-mongodb-indexes) guide to meet index requirements *before* the upgrade process.
2382+
2383+
Changes in collections: following collections can be safely dropped *after* the upgrade to 2.9.x if they exist:
2384+
2385+
- `read-models.application-tree`
2386+
- `read-models.<entity>-history` — every collection with `~-history` suffix, such as `read-models.applications-history`, `read-models.services-history`, etc.
2387+
23632388
## Troubleshooting
23642389

23652390
### Error: Failed to validate connection to Docker daemon; caused by Error: certificate has expired

0 commit comments

Comments
 (0)