missing collections when restoring MongoDB by copying db files - mongodb

This method of copying used to work for me. I created a Visual Studio 2010 installer project. I stopped the MongoDB service on my machine and copied my database files (*.ns, *.1, *.2, *.3 and *.4) into the installation. Then I would copy the files during the install to the db directory and start the MongoDB service.
That used to work until I had to add db renaming as an installer feature. now the files rename and copy and show up in mongovue, but the list of collections is blank. What is going on?
Any help would be greatly appreciated. Thanks!

MongoDB uses Journaling by default with 2.0. So this problem can happen when mongodb has data in journal by latency. You check journal latency so you can stop mongo instance after all journal committed. Here is documantation.
But i strongly recommend you to use mongodump / mongorestore for this job.

Related

How to open firebird .fdb file in VS Code?

I want to see and check .fdb file. And I am using VS Code to open it. I installed "DB Explorer For Firebird Databases" for this and file opened. However, the opened file was corrupt. How can I fix this?
A Firebird database file is a file to be read by the Firebird database engine and queried using SQL. It is not something to be opened in a text editor, like you did in the screenshot.
The DB Explorer For Firebird Databases is a plugin for connecting to a Firebird database server, and executing queries against that server. It is not something for viewing the contents of a FDB file directly.
Unfortunately, as far as I'm aware, the DB Explorer For Firebird Databases has been broken for a while now, and it seems it is no longer maintained. You can connect to a database, and see the tables it has, but attempting to execute queries or view data will not show any query results, but instead shows a broken image icon (the issue for this bug has been open since 2019, so I guess it is unlikely to get fixed).
You may want to consider using something like DBeaver or FlameRobin to query a Firebird database, but that will still require having a Firebird database server installed.

mongodb keeps generated files under .snapshot folder

I am new to Mongodb. I'm running a Mongodb 3.6 services on Openshift.
I found that it keeps generated something looks like backup in the folder /var/lib/mongodb/data/.snapshot.
It's not small in size. But, I can't remove it. Does anyone have any idea?
It turns out that it's due to the snapshot created by NetApp. We need to re-configure the snapshot policy.

How to remove mongodb and the related files completely from the system?

I have started installing mongoDB, got struck like anything.
I can understand the mongoDB is not running even though it shows like mongo auto and a log file. I have deleted almost all the folders and i ran almost all the commands i have seen on net.
I need the commands which removes the mongodb completely from my system.I cannot understand what's happening with the mongodb.
Finally I have decided to remove it completely(not even a single instance of mongo).
provide me the best commands which might help me.
Perhaps this might help for Mongo 3.0
https://docs.mongodb.org/manual/tutorial/install-mongodb-on-ubuntu/
and for Mongo 2.6
https://docs.mongodb.org/v2.6/tutorial/install-mongodb-on-ubuntu/
At the bottom of the page are instructions to remove all files.

Sitecore Powershell Console - Copy Media Items from one DB to another

We are in process of upgrading Sitecore 6.6 to 7.2. Part of upgrade is to migrate all the media items from 6.6 to 7.2.
I tried creating a package but the package size is too large and times out on package installation.
I found link below using Powershell Console where it shows copy-item command:
http://blog.najmanowicz.com/2011/11/18/sample-scripts-for-sitecore-powershell-console
I attached the 6.6 to 7.2 version where I can access the 6.6 DB. However copy-item doesn't seem to support different databases.
Could someone please help how I can use SiteCore Powershell or similar to migrate media items from 6.6 to 7.2?
I had a similar issue with a (very large) media library with a similar migration. Packages seems to bomb out around the 2GB mark, instead serialize the items:
Delete everything from /Data/Serialization
Open the media library. Makes sure you have the Developer tab
showing (right click somewhere on the toolbar and enable it
otherwise)
Select your root media item then Serialize Tree
Wait...
Copy the serialized files from /Data/Serialization to your new
server
From the toolbar select Update or Revert Tree depending on your requirements
Profit.
You can find more info in the Sitecore Serialization Guide and this post by Brian Pedersen
You should be able to do this in Powershell too (from my understanding). You need to:
Add the database to your connectionString.config
Add that database to your web.config to <sitecore><databases><database>. You can copy the existing master node and rename the id attribute to match your conneciton name
Your legacy database should now be connected to Sitecore interface, you can check it is present in the database selector list from the right of the desktop
The powershell command now needs a "from" and "to" location. Assume your database is called "legacy_master", the following should work:
copy-item "master:\media library\*" "legacy_master:\media library\"
I've found Hedgehog TDS (and sometimes Razl) quite useful for doing this.
Create a new TDS project (don't version control it), and download all the items you need to your local machine. You can for example connect the "Debug" build to your source 6.6 instance, and a "Release" build to your target 7.2 instance. Then you can just synchronize the items to your target machine. It's sometimes good to synchronize one or a few branches at a time if you have long latency connections.
The good thing about this is that you're in total control of your content and can see what fields are updated etc. During an update process, it's sometimes useful to compare other parts of the db as well, just to ensure you don't miss any changes you've made to the platform.
Since I mentioned Razl as well: I've found Razl quite good if you have a whole branch that you know should be transferred from one db to another (such as the case you describe). TDS is a bit slower, but more universal - and you may have a TDS license already so it may not be worth an additional Razl license.
I've just added item transfer from one DB to another so you can Copy-item between databases starting with Sitecore PowerShell Extensions 3.0. Thanks for the great idea!
Just to add another option you can perform tasks like this using Revolver.
WARNING: Try this in a test environment first
if we assume that:
the context item is the media library item
the current database is master
the target database is called master72
then something like this should work:
cp -r -n master72/sitecore/

Is it rollback-safe to upgrade MongoDB from 2.0.2 to 2.2?

I want to upgrade MongoDB from 2.0.2 to latest version, but I am a bit worried about just running mongod with the current data-files.
In case something goes wrong will I be able to just stop mongod and run the old setup (v. 2.0.2)? Or, in other words, does new mongod apply any changes to the data files that makes them unusable with mongod 2.0.2?
As noted on the upgrade page: http://docs.mongodb.org/manual/release-notes/2.2/
MongoDB 2.0 data files are compatible with 2.2-series binaries without any special migration process.
So yes there should be no changes to the files. The last time changes were needed (a new version of indexes was implemented) the upgrade page did mention additional information regarding the migration process.
Also taking a look at the changes section: http://docs.mongodb.org/manual/release-notes/2.2/#changes there does not appear to be any file format changes. There have been a few behavioural changes ( http://docs.mongodb.org/manual/release-notes/2.2/#behavioral-changes ) however this should only effect future work on your files (i.e. changes in restrictions on names).
I would bet a fair amount it would be safe to just drop the 2.2 binary in place of 2.0.
I recently upgraded from 1.9 without any problems.