Porting drupal's database to MySQL Cluster possible?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
showmanlkz's picture

Hi guys, my organization is running a MySQL Cluster 7.x. I have been quite comfortable to port some of our MySIAM type tables to MySQL Cluster's NDB type.

I found that drupal uses innoDB, so I am wondering if it's possible to port it to NDB type?

FYI, MYSQL Cluster NDB doesn't support few things in innoDB include foreign key constraints.

http://dev.mysql.com/doc/refman/5.0/en/faqs-mysql-cluster.html

Any opinion will be welcomed.

Derrick

Comments

Drupal's database to MySQL Cluster possible?

nilanjan.kundu's picture

Hi, I have a site using 105 contrib modules as follows:
admin
advanced_help
agreement
amfphp
auto_nodetitle
autologout
cas
comment_service
content
content_copy
ctools
cvs_deploy
data
data_node
data_search
data_taxonomy
data_ui
date
date_api
date_popup
date_repeat
date_timezone
devel
dialog
dirtyforms
ds
ds_ui
fckeditor
features
feeds
feeds_ui
fieldgroup
file_service
filefield
filefield_meta
filter_default
flag
front_page
getid3
hierarchical_select
hs_menu
hs_taxonomy
htmlpurifier
i18n
i18nblocks
i18ncck
i18ncontent
i18nmenu
i18nprofile
i18nstrings
i18nsync
i18ntaxonomy
imageapi
imageapi_gd
imagecache
imagecache_ui
imagefield
job_scheduler
jquery_plugin
jquery_ui
jquery_update
lang_dropdown
link
memcache_admin
menu_per_role
menu_service
mimedetect
nd
nd_cck
node_service
nodereference
nodereferrer
number
og
og_mandatory_group
og_user_roles
og_views
onbeforeunload
optionwidgets
password_strength
quicktabs
schema
search_service
services
services_keyauth
session_aggregator
session_limit
signup
signup_status
system_service
taxonomy_service
text
token
transliteration
unique_field
user_service
userreference
views
views_bulk_operations
views_customfield
views_export
views_service
views_ui
xmlrpc_server

Can I implement the mysql cluster on my site? as I came to know there are many limitations are in NDBCluster like
Problem in Like function on mysql query.
Problem with Joining on bigger query
how we can overcome on these issues.
And also like to know if there any suitable module to test all these active modules are suitable or not for ndb cluster?

Looking for your reply!
Thanks

For me, it's not possible

athoune's picture

NDB is completly different product. It's not like choosing between myisam and innodb. If you can't scale with a varnish, a memcache, a CDN, a Solr with more than one server, you have a lot of users and you can start to build specific application. Without NDB, NDB is for laboraotry, not for real world.

Implementing Drupal 6.17 in Mysql Cluster 7.2!!

nilanjan.kundu's picture

Thanks for your reply!
By reading on different blogs and forums I came to know that mysql cluster can be implement in DRUPAL, But here I am stuck to implement in real world.
Actually I need a clear picture where and which areas our Drupal does not allow to implement the NDB cluster, can you please help me on that.

I currently working on a project to implement a existing Drupal 6.17 site in Mysql Cluster. Our basic requirement was to enhance the scalability to support huge number of users in the system.
I already setup a mysql cluster 7.2.4 with the recommended minimum config and done the configuration change to fit the structure and the data has been ported to the structure.

Now I am stuck with two major issues - (1) Complex joins are running very slow (2) LIKE %% is not working with the multi byte character set in the mysql cluster and looking for solutions in DB Layer.

Looking for your reply!

Have a look at Acquia

athoune's picture

Have a look at Acquia architecture. NDB can't handle joining efficiently, it's a CAP theorem effect. Most drupal's modules are made for mysql. Your issues are physical, it's a dead end.
Why do you need LIKE queries? Solr is far better for handling full text esarch and multi byte characters.

Cluster may still be useful

Owen Barton's picture

Cluster may still be useful if you have a heavy write load - which is often the main bottleneck in heavy auth-traffic Drupal sites which have already scaled out php nodes and MySQL slaves for reads. You can set up replication from Cluster to regular InnoDB slave nodes (http://johanandersson.blogspot.com/2009/05/ha-mysql-write-scaling-using-...) and use those for reads, avoiding the Cluster join penalty. You could experiment with allowing non-join queries to be served by the Cluster (rather than a slave), which in theory may be faster, especially with large database sizes (the cluster has more RAM than a single node could have).

This would be an interesting and more horizontal architecture for these kind of sites than the usual techniques (beefing up the MySQL master with RAIDed SSDs or solid state PCI boards etc). Of course, it is also more complex - there is a tradeoff with everything :)

Any idea about D7

manoj.surala's picture

Hi All,

I'm trying to do the same in D7.

Done the cluster setup and when trying to insert any nodes getting the error below.

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1178 The storage engine for the table doesn't support SAVEPOINT: SAVEPOINT savepoint_1; Array ( ) in db_transaction() (line 2544 of /var/www/html/my_d7_site/includes/database/database.inc).

Actually is there any link or documentation where I can find the step-by-step process in setting up this.

Else is there a way to scale up the site using the InnoDB itself?
The primary reason for choosing cluster is the way it handles data in parallel.

Though we have the concept of master slave functionality here in InnoDB, it will go to later only if the former fails to handle the request.

I'm looking at something like which can handle request in parallel and sync the whole in the backend.

Like if there are 500 users hitting my site, 250 requests need to go one server and 250 to other at the same time not trying 500 in first one and going to second server if first server fails to handle.

Please correct me if I had any wrong understanding in what I said.

Thanks in advance.