7/20/2023 0 Comments Mongodb compass shell![]() ![]() Click the Private Connection tab and obtain the connection address of the current instance from the Private HA Connection Address field.Īccount name, that is, the database username. Private HA Connection Address: On the Instances page, click the instance name.mongo " " - ssl -sslCAFile -sslAllowInvalidHostnames Using this address to connect to a replica set instance improves data read/write performance and prevents errors reported when data is written from the client after a primary/standby switchover. Method 1: High-availability connection (recommended)ĭDS provides the HA connection address. In Windows, upload the root certificate using a remote connection tool.REMOTE_DIR is the directory of the ECS to which the root certificate is uploaded.IDENTITY_FILE is the directory where the root certificate resides.It’s open source and the code is available in Github. Var guidDecoded = new Guid(bytes.Slice(0, bytesWritten).ToArray()).ToString() įinally, if you just need it now without writing code use a Blazor WebAssembly app I made just for this. If (Convert.TryFromBase64String("YOUR_BASE64_STRING_HERE", bytes, out int bytesWritten)) Var bytes = new Span(new byte) //arbitrary number Var base64Encoded = Convert.ToBase64String("YOUR_GUID_HERE") Īnd here is a way to decode a base64 string that contains GUID bytes: Solutionįollows a C# solution which is simple enough, but of course requires to at least copy-paste the code to a project and run it: Worth mentioning here that we were working on this problem with Dean Herringer and he was the first to notice the problem. No matter how many times I attempted to convert the GUID using various online services to its base64 equivalent, I always failed because these services were converting the GUID to base64 as string!Īnd there’s your problem! Encoding a GUID’s bytes is different than encoding GUID’s representative string value. The value you see is actually a base64 encoded string of the GUID value.Īnd everything was cool for years, up until I had to manually debug a situation where I had to connect directly to MongoDB to search for a document based on a GUID I knew. Far from the previous useless sentence though, mind the blue square because this is how MongoDB stores a GUID. The capture above is showing a part of MongoDB compass connected to a beta database with partially real but old data, located locally. Nevertheless, the schema above gave room for some beautiful data like the following image, with some databases and collections ending up having millions of data located in an availability zone probably near you! ![]() The schema of the document is not very important other than the fact that the ID should be of type GUID: 3-byte incrementing counter, initialized to a random value.This random value is unique to the machine and process. 5-byte random value generated once per process.4-byte timestamp value, representing the ObjectId’s creation, measured in seconds since the Unix epoch.ObjectId values are 12 bytes in length, consisting of: ObjectIds are small, likely unique, fast to generate, and ordered. That thought alone and the fact that a unique ID through out all databases for each price would be a nice to have, made me decide for a GUID instead of MongoBD’s ObjectId(). The document-oriented database selected was MongoDB, but I always had in mind a future move to Azure Cosmos DB, so avoiding vendor lock was a requirement. Since the data to be stored were fairly simple, I was lead to a design featuring one documentDB per market. Markets would be a dynamic thing, meaning different ones being added every once and a while, and old ones potentially removed. Some time ago I created a project for storing product prices but for multiple markets around the world. Have you ever tried to query MongoDB with a GUID? Well I did and it can be confusing!
0 Comments
Leave a Reply. |