Converting an Existing Drupal Site to MongoDB

Published on February 2017 | Categories: Documents | Downloads: 22 | Comments: 0 | Views: 170
of 3
Download PDF   Embed   Report

Comments

Content

 

Converting an existing Drupal site to MongoDB  MongoDB  All the cool kids lately are using MongoDB field storage to scale their Drupal sites. That‟s all fine and dandy if you use it from the get go since that‟s what it‟s made for, but converting an existing Drupal site to it can be a bit of a pain. There are basically three parts to the conversion process: 1. Initial setup 2. Convert the data 3. Convert the views

Initial setup This is mostly covered by the Mongo module‟s docs but I‟ll cover it here just because.  because.  Step 1: Install MongoDB somewhere on a server. Instructions for this can be found in a million places online. Once you have it up and running, you should be able to do this at a terminal: $ mongoshell version:  2. .0.4 MongoDB version: 2 connecting to: to: test > 

Step 2: Download and enable the “mongodb” module and the “mongodb_field_storage” submodule. Step 3: Add the MongoDB connection info to settings.php, like so: $conf[ ['mongodb_connections' ] = array array( (  $conf 'default' 'default'   => =>   array( array(  'host'   =>  => 'localhost', 'localhost',  'host' 'db' 'db'   =>  => 'drupal_default' 'drupal_default', ,  ),  ) ;  ['field_storage_default' ] = 'mongodb_field_storage' ;  $conf $conf[

Step 4: Clear all caches  Now Mongo is set up and ready to go, but it‟ll only act on new n nodes odes inside content types with new fields that are created cr eated after setting up Mongo, (if you‟re nerdy/curious, this is mostly due to the default field storage for existing fields being set to “field_sql_storage” in the “field_config” table). That doesn‟t do us any good because we‟re converting an existing exist ing site. So on to the conversion.

Converting the data So you now have Mongo up and running but you need to convert your billion existing awesome nodes and fields and users to Mongo for it to do any good. Luckily, there‟s a separate submodule called “mongodb_migrate” made to do just that.  that.  

 

Step 1: Enable the “mongodb_migrate” module  module  Step 2: Take a backup of the MySQL database in case things go wrong. Step 3: Run “drush mongodb-migratemongodb-migrate-  prepare” prepare” which will create the collections you need in Mongo and build a list of entity types to migrate. Step 4: 4: Run „drush mongodb-migrate mongodb-migrate --timeout=”5”‟ --timeout=”5”‟ which will perform 5 seconds of the migration as a test. You can monitor the output which will tell te ll you what entity type and ID it‟s working on as it goes.  goes.  Step 5: Pick one of the ID‟s from step 4 (i.e., a node or or user or whatever that was migrated) and make sure that 1) it and its fields exists in Mongo and 2) you can edit it and save it and view it without issues. If you run into issues here, you‟ve got some digging to do (issue queues, IRC, source code, etc.). Otherwise, move on. Step 6: Run „drush mongodb-migrate mongodb-migrate --timeout=”0”‟ --timeout=”0”‟ to run the entire migration with no timeout. If you have a lot of data this can take ta ke a VERY long time, so keep that in mind and maybe run it over night or over the weekend. Note that you can also stop the migration and when you start it again it‟ll pick up where it left off. off.   For the record, this drush command has two options: --timeout timeout= ="<number of seconds>"  seconds>" # Use "0" for all. Defaults to "900". ---count count= ="<number of items>"  items>" # Defaults to "0" (all) 

 Note that timeout defaults to 900 seconds (15 minutes) minutes) so that‟s why the --timeout=”0” --timeout=”0” is needed to keep it running until it‟s done.  done.  Step 7: Once the migration is done, click around the site and edit random things and make sure that everything is working as expected (except for the Views, that comes next).

Converting the Views You‟re using Views, right? If so, the gotcha here is that Views is hardcoded to use field_sql_storage and thus doesn‟t really work with Mongo. So to get around that, some smart folks built the EntityFieldQuery Views module which is basically an alternative Views  backend that uses EFQ instead of querying fields directly. The obvious benefit here is that it makes Mongo integration with Views possible, but there are a couple drawbacks: 1. NO RELATIONSHIPS WHATSOEVER. EFQ Views do not support relationships because Mongo doesn‟t support JOINs. If this is a killer feature fe ature for whatever you‟re doing, then you have some work to do. 2. Some modules that offer Views integration don‟t work with EFQ Views. I‟m not sure exactly why this is but it‟s true. If you have fields or sorts or filters that are coming from a contrib module instead of stock Views or custom-defined fields, then you might want to check with a test EFQ View first.

 

If you‟re still game, then you have two options:  options:  1. Rebuild all your existing Views manually as EFQ: Content views rather than plain old Content views, or: 2. Convert your views to EFQ Views using a drush command. ***NOTE***: You only only have to worry about this for Views that use custom fields. If a View  just uses stuff that‟s in the “node” or “users” table (stuff like title, created date, author, etc.) then you should be able to leave it as a regular View because that stuff all still exists in MySQL. It‟s the fields that are the problem.  problem.   Rebuilding your views 

If you decide your Views are simple enough that you can rebuild them without too much effort (along with redoing your views blocks and changing your CSS to match up with the new classes etc.) then your job is easy. For each View that uses custom-defined fields in any way, just create a new View, make sure to use “EntityFieldQuery: Content (or User or whatever)” as the View type when creating, creating , and then just configure it like any other View. Converting your views 

If you have a ton of views spread out into a ton of blocks in a ton of different contexts then maybe rebuilding that all isn‟t an option for you. In that case, you‟re in luck --we --we had that  problem too and we built built a drush command to convert them for yo you. u. This is riskier than rebuilding but also much quicker, and you dig the bleeding edge, don‟t you? We do too.  too.  efq-views-convert -Grab the drush inc file from  from  this comment  comment and run it using “drush efq-views-convert view=”VIEWNAME”” for each View you want to convert. If the View has a relationship it‟ll tell you it can‟t do it, since EFQ Views doesn‟t support s upport relationships, and otherwise it‟ll it‟ll do  do its best. After it runs, edit the view and look for anywhere that says “Broken/missing handler” and if you spot any, fix those manually. The script does its best but it i t can‟t catch everything.  everything.   Once all your views are converted and provided you converted your data successfully successfull y then your site should be in pretty pr etty good shape. Hope you‟ve found this helpful! helpful!  

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close