Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The ephemeralForTest storage engine is reaching its end of life #742

Closed
LucVidal360 opened this issue Feb 9, 2023 · 30 comments
Closed

The ephemeralForTest storage engine is reaching its end of life #742

LucVidal360 opened this issue Feb 9, 2023 · 30 comments
Labels
docs This issue/pr is about documentation enhancement released on @beta released Pull Request released | Issue is fixed

Comments

@LucVidal360
Copy link

LucVidal360 commented Feb 9, 2023

Versions

  • NodeJS: 16.19.0
  • mongodb-memory-server-*: 8.4.2
  • mongodb(the binary version): 5.0.14
  • mongodb(the js package): 4.5.0
  • system: Linux Kubuntu 22.04

package: mongo-memory-server-global

What is your question?

The ephemeralForTest storage engine is reaching its end of life.

Context

In the project I'm working on, each test cleans its test collections by issuing collection.deleteMany({}) on every modified collection during the test. All these deleteMany are executed in parallel.

When executing many tests, it happens that the mongod server crashes with a segfault.

After opening an issue in MongoDB's Jira, it appears the "ephemeralForTest" engine has become unstable, starting with MongoDB 5.
They even intend to suppress entirely this engine with MongoDB 7. Cf. this comment:

In 5.0, we replaced the ephemeralForTest storage engine [...] The new implementation [...] had many bugs, like the one you discovered, and in the 7.0 release, we will remove the ephemeralForTest engine entirely

Workaround

As suggested, I used the wiredTiger engine (thanks to mongo-memory-server's option instance.storageEngine) and everything works like a charm.
I made a few benchmarks, and the performances are comparable.

Question

Knowing this, I have a few interrogations/suggestions:

  • should this information be documented?
  • would it be possible to have a different default engine depending on the mongodb version used?
@hasezoey
Copy link
Member

hasezoey commented Feb 9, 2023

would it be possible to have a different default engine depending on the mongodb version used?

not currently

should this information be documented?

probably should be documented yes, though personally i have not run into any issues with that yet


i also already read that they want to remove this storage-engine (sadly). also there seems to be a separate in-memory engine for enterprise.

when the change occurs and MMS changes its default version (to that version), then the default will also be changed (because otherwise it literally wouldnt work anymore).

if it really becomes required, the default may be changed earlier (though this will only be in a major MMS version).

for now use the mentioned workaround of manually setting the storage engine

@LucVidal360
Copy link
Author

Thank you for your answer.

The current workaround is fine by me. I mostly intended to inform you about this.

Feel free to close this issue, or change its status, whatever suits you best.

@hasezoey hasezoey added enhancement docs This issue/pr is about documentation and removed question labels Feb 10, 2023
@hasezoey
Copy link
Member

Feel free to close this issue, or change its status, whatever suits you best.

for now i will keep it open until at least a documentation note is made about that it may be unstable and that the default will be changed in the future

@github-actions
Copy link

🎉 This issue has been resolved in version 9.0.0-beta.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@hasezoey
Copy link
Member

@alexbjorlig
Copy link

Wait a moment?

Does this means that if I would like to run MongoDB memory server, with version 7, I have to use wiredTiger?

But if I understand wiredTiger correctly, this means that it will not be in-memory then?

@hasezoey
Copy link
Member

But if I understand wiredTiger correctly, this means that it will not be in-memory then?

yes that is correct, because with 7.0.0 wiredTiger is the only engine supported (at least for the community server version)

i know that the name mongodb-memory-server might not be entirely correct anymore, but i think this package will not rebrand

hasezoey added a commit that referenced this issue Aug 22, 2023
@github-actions
Copy link

🎉 This issue has been resolved in version 9.0.0-beta.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

@sibelius
Copy link

sibelius commented Oct 4, 2023

can we release v9 outside beta? mongo 7 is out

@hasezoey
Copy link
Member

hasezoey commented Oct 4, 2023

mms 9 i currently in beta to get some more feedback, but yes, i think it is kinda final (it works in both typegoose and mongoose, my main real-world testing use-cases)

i will try to release it this week

@sibelius
Copy link

sibelius commented Oct 6, 2023

writeTiger is slower than ephemeral and breaks some tests

@hasezoey
Copy link
Member

hasezoey commented Oct 6, 2023

🎉 This issue has been resolved in version 9.0.0 🎉

The release is available on:

Manual message because semantic-release hit the limit

@hasezoey hasezoey added the released Pull Request released | Issue is fixed label Oct 6, 2023
@hasezoey
Copy link
Member

hasezoey commented Oct 6, 2023

well wiredTiger is definitely slower than the in-memory engine, but it should not cause different behavior where the in-memory engine worked.

it is recommended to set the db-path to somewhere which is using tmpfs(or equivalent)

@clemp6r
Copy link

clemp6r commented Jul 17, 2024

But if I understand wiredTiger correctly, this means that it will not be in-memory then?

yes that is correct, because with 7.0.0 wiredTiger is the only engine supported (at least for the community server version)

i know that the name mongodb-memory-server might not be entirely correct anymore, but i think this package will not rebrand

The project description and documentation should at least be updated because it is currently misleading.

@hasezoey
Copy link
Member

hasezoey commented Jul 17, 2024

The project description and documentation should at least be updated because it is currently misleading.

Thanks for pointing this out, completely forgot about that, for now i have updated the github description, other places (like documentation landing page) may still need to be updated.

I am not a good writer, so for now the more concise and less miss-leading text is:

Manage & spin up mongodb server binaries with zero(or slight) configuration for tests.

EDIT:
i now also updated the documentation (though only for 10.0+ and currently only available in beta)

hasezoey added a commit that referenced this issue Jul 17, 2024
required because mongodb 7.0 does not have the public in-memory engine anymore.

re #742 (comment)
hasezoey added a commit that referenced this issue Nov 1, 2024
required because mongodb 7.0 does not have the public in-memory engine anymore.

re #742 (comment)
@Climax777
Copy link

I know the issue is closed, but wanted to discuss the option of using Percona's Memory Engine? It is a drop-in replacement for MongoDB.

https://docs.percona.com/percona-server-for-mongodb/7.0/inmemory.html
https://www.percona.com/downloads provides a few links. Not sure if it will follow the same download granularity though.

But I believe it will address the concern relating to performance.

@hasezoey
Copy link
Member

hasezoey commented Dec 6, 2024

Thanks for the hint @Climax777, but from my quick skim of the site, it looks like percona does not offer a archive overview like official mongodb does, so finding all the links and configurations wouldnt be as easy.
Additionally it looks like they use a different url directory structure all-together, meaning a full custom implementation would be needed.

https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-debian11-7.0.15.tgz
vs
https://downloads.percona.com/downloads/percona-server-mongodb-7.0/percona-server-mongodb-7.0.15-9/binary/tarball/percona-server-mongodb-7.0.15-9-x86_64.bookworm-minimal.tar.gz

If the tar structure is the same and the commands also work the same, i think it is possible to use percona if you set config option DOWNLOAD_URL (or manually download it and use SYSTEM_BINARY) in mongodb-memory-server today.

@sibelius
Copy link

sibelius commented Dec 6, 2024

does percona works with mongo 8 ?

is it faster ?

is it an in-place replacement ?

@sibelius
Copy link

sibelius commented Dec 6, 2024

https://www.mongodb.com/docs/manual/core/inmemory/

what about using mongodb in memory engine ?

@sibelius
Copy link

sibelius commented Dec 6, 2024

should we open an issue to support percona ?

@hasezoey
Copy link
Member

hasezoey commented Dec 7, 2024

@sibelius

what about using mongodb in memory engine ?

An In-Memory storage engine is available in MongoDB Enterprise. Rather than storing documents on-disk, it retains them in-memory for more predictable data latencies.

source
TL;DR: The inMemory engine in official mongodb is not available in the community edition.

is it an in-place replacement ?

Percona Server for MongoDB is an enhanced, fully compatible, source available, drop-in replacement for MongoDB 7.0 Community Edition with enterprise-grade features.

source

does percona works with mongo 8 ?

From what i have seen on their website, the highest version is currently 7.0.x.

should we open an issue to support percona ?

I currently do not plan to add this myself, but PRs are welcome.
(Also #701 had been closed as it was a question of "can we use"(note not "support") and i had written that it should work with SYSTEM_BINARY and then had become stale)
Suggestion: open a "Idea" discussion instead of a issue.

@sibelius
Copy link

sibelius commented Dec 7, 2024

I'd tried with download dir and also system binary neither worked

@hasezoey
Copy link
Member

hasezoey commented Dec 7, 2024

I'd tried with download dir

config option DOWNLOAD_DIR changes the directory the binary is downloaded into, it does not set the download URL.

also system binary neither worked

what is the Debug output if you run it with config option SYSTEM_BINARY?

@sibelius
Copy link

sibelius commented Dec 9, 2024

MongoMS:DryMongoBinary getSystemPath: found system binary path at "percona/percona-server-mongodb-7.0.15-9-x86_64.bookworm-minimal/bin/mongod" +0ms
  MongoMS:DryMongoBinary locateBinary: env "SYSTEM_BINARY" was provided with value: "percona/percona-server-mongodb-7.0.15-9-x86_64.bookworm-minimal/bin/mongod" +0ms
  MongoMS:DryMongoBinary getSystempath +0ms
  MongoMS:DryMongoBinary getSystemPath: found system binary path at "percona/percona-server-mongodb-7.0.15-9-x86_64.bookworm-minimal/bin/mongod" +0ms
  MongoMS:MongoBinary getPath: Spawning binaryPath "percona/percona-server-mongodb-7.0.15-9-x86_64.bookworm-minimal/bin/mongod" to get version +1ms
  MongoMS:MongoMemoryServer Mongo[unknown]: _startUpInstance threw a Error:  TypeError: Cannot read properties of undefined (reading 'toString')
    at MongoBinary.getPath (woovi/node_modules/mongodb-memory-server-core/lib/util/MongoBinary.js:79:28)
    at async MongoInstance.start (woovi/node_modules/mongodb-memory-server-core/lib/util/MongoInstance.js:135:26)
    at async MongoInstance.create (woovi/node_modules/mongodb-memory-server-core/lib/util/MongoInstance.js:84:9)
    at async MongoMemoryServer._startUpInstance (woovi/node_modules/mongodb-memory-server-core/lib/MongoMemoryServer.js:223:26)
    at async MongoMemoryServer.start (woovi/node_modules/mongodb-memory-server-core/lib/MongoMemoryServer.js:84:9)
    at async MongoMemoryServer.create (woovi/node_modules/mongodb-memory-server-core/lib/MongoMemoryServer.js:63:9)
    at async getMMSMongoD (woovi/packages/testutils/src/config/getMMSMongoD.js:16:20)
    at async module.exports (woovi/packages/testutils/src/config/mongo/setup.js:20:20)
    at async woovi/node_modules/@jest/core/build/runGlobalHook.js:109:13
    at async waitForPromiseWithCleanup (woovi/node_modules/@jest/transform/build/ScriptTransformer.js:160:5) +3ms
  MongoMS:MongoMemoryServer Mongo[unknown]: stop: Called .stop() method +0ms
  MongoMS:MongoMemoryServer Mongo[unknown]: stop: "instanceInfo" is not defined (never ran?) +0ms
TypeError: Cannot read properties of undefined (reading 'toString')
    at MongoBinary.getPath (woovi/node_modules/mongodb-memory-server-core/lib/util/MongoBinary.js:79:28)
    at async MongoInstance.start (woovi/node_modules/mongodb-memory-server-core/lib/util/MongoInstance.js:135:26)
    at async MongoInstance.create (woovi/node_modules/mongodb-memory-server-core/lib/util/MongoInstance.js:84:9)
    at async MongoMemoryServer._startUpInstance (woovi/node_modules/mongodb-memory-server-core/lib/MongoMemoryServer.js:223:26)
    at async MongoMemoryServer.start (woovi/node_modules/mongodb-memory-server-core/lib/MongoMemoryServer.js:84:9)
    at async MongoMemoryServer.create (woovi/node_modules/mongodb-memory-server-core/lib/MongoMemoryServer.js:63:9)
    at async getMMSMongoD (woovi/packages/testutils/src/config/getMMSMongoD.js:16:20)
    at async module.exports (woovi/packages/testutils/src/config/mongo/setup.js:20:20)
    at async woovi/node_modules/@jest/core/build/runGlobalHook.js:109:13
    at async waitForPromiseWithCleanup (woovi/node_modules/@jest/transform/build/ScriptTransformer.js:160:5)

@hasezoey
Copy link
Member

hasezoey commented Dec 9, 2024

Thanks for the output, i think i should do more checking there, though from what i know this should never happen in nodejs (according to types):

const spawnOutput = spawnSync(binaryPath, ['--version'])
.stdout.toString()

Does anything change if you provide a absolute path to the binary? (ie /path/to/somewhere/mongod)

@sibelius
Copy link

sibelius commented Dec 9, 2024

this is the absolute path, I only removed in the logs

@hasezoey
Copy link
Member

hasezoey commented Dec 9, 2024

this is the absolute path, I only removed in the logs

just to confirm the path you had set for SYSTEM_BINARY was starting with a /(absolute)? (ie /percona/percona-server-mongodb-7.0.15-9-x86_64.bookworm-minimal/bin/mongod instead of percona/percona-server-mongodb-7.0.15-9-x86_64.bookworm-minimal/bin/mongod)

@sibelius
Copy link

sibelius commented Dec 9, 2024

it was absolute

/Users/sibeliusseraphini/Dev/entria/woovi-projects/percona/percona-server-mongodb-7.0.15-9-x86_64.bookworm-minimal/bin/mongod

hasezoey added a commit that referenced this issue Dec 9, 2024
because it seemingly can be undefined, see #742#issuecomment-2528284865
@hasezoey
Copy link
Member

hasezoey commented Dec 9, 2024

Thanks, then it is very weird that nodejs seemingly did not throw a error and gave back what it shouldnt have.
In any case, i have now implemented a path absolutization for the SYSTEM_BINARY (in beta) and also a extra check that stdout is defined.

Could you manually try running the percona binary with argument --version? (if it works, please provide the output)
Additionally, you can try 10.1.3-beta.1 with config option SYSTEM_BINARY_VERSION_CHECK set to false to see if skipping the version check makes it work.

@sibelius
Copy link

sibelius commented Dec 9, 2024

You can download percona and give it a try

I will test more

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs This issue/pr is about documentation enhancement released on @beta released Pull Request released | Issue is fixed
Projects
None yet
Development

No branches or pull requests

6 participants