256 Install
Just wanted to report that I successfully upgraded to a 256 db install with no apparent problems. I only had a few hundred blogs, so I just wrote a script to dump them into the new tables. The install was very simple, and the site didn't miss a beat.
FYI. I'm noticing some plugin incompatiblity (not yours, lol), i'm using rs_discuss, wp-polls, firestats, wp-shopping cart, and a few others. Almost all of them had to be modified to work correctly under the db. I added the tables to the appropriate global and blog section, but the way the scripts are written, they were trying to use the wrong db. I'm hoping after a couple more days I will have all my plugins back up and running, and the confidence that my site can absorb another 20K or so blogs, ;-).
If anyone is using wp-shopping cart, or firestats, and wants to share the changes made, I would be greatful! The others were very easy to fix, and I would be happy to share if anyone needs the fixes.
Thanks...
Everyday at WPMU DEV we help hundreds of WP Users. Become a member today to:
- Download 250+ Premium Plugins and Themes
- Get unlimited support from WordPress Experts
- Get help with your WordPress or BuddyPress projects
Help & Support from WPMU DEV members and staff
That's good to know, as I just schedueld my site for some potential down time when I do this. :D I'm not using wp-shopping cart, or firestats though. More like wp-e-commerce (oh wait, I went another way with this) and short stats.
Hi minusme,
If you'd like to share the script you used to move the blogs to the new databases i'd be willing to include it in the multi-db package (with credit given of course).
Thanks,
Andrew
Get personal, comprehensive and timely support and assistance
from WordPress Experts
I'm wondering how you got around the "next record" issue i had. Never solved it but we've never seen an issue with it not transfering over.
Andrew,
Sure. Where shall I send it?
drmike,
Not sure what the 'next record' issue is, but you can take a look at my code to see how I did it.
Hi minusme,
You can send it to andrew@idtstudios.com.
Edit: I also need to know your name to properly give you credit.
Thanks,
Andrew
Sent. Hope you find it useful.
Get personal, comprehensive and timely support and assistance
from WordPress Experts
As a heads up, any plugin that is poorly coded and uses $table_prefix instead of $wpdb->prefix will cause some issues.
At least on 1.2.5 it is for me.
(Or plugins that don't have a prefix at all and just have a hardcoded table name.)
yeah, I know... I desperately need to fix that don't I. Maybe i'll run through each plugin and do a find/replace this weekend.
Does $wpdb->prefix contain the base prefix or the prefix with the blog id?
Thanks,
Andrew
Actually, I was referring to a few plugins I have, not yours. Although... ;)
Anyway, $wpdb->prefix for use in a plugin will be wp_x_.
$table_prefix is (supposedly) being deprecated, but with 1.2.5 the error I was getting with those plugins was similar to: table database.name.wp_tablename doesn't exist.
I wouldn't rely on that though. For any of my custom stuff with new tables, I'm going through sunrise.php because at that point $wpdb->prefix is still the original table prefix.
Hmm, i'd probably be better off using $wpmuBaseTablePrefix to get the base prefix. Do you know if there is a certain reason it hasn't been changed to something like $wpdb->base_prefix ?
Thanks,
Andrew
Get personal, comprehensive and timely support and assistance
from WordPress Experts
That would probably work.
As for why the other doesn't exist, maybe it just hasn't been thought of yet.
I'll post it on trac and see what Donncha says about it.
Done deal. Ticket 479.
Get personal, comprehensive and timely support and assistance
from WordPress Experts
Thanks for posting it to Trac. Donncha must be taking the day off because I haven't noticed him stirring about.
Thanks,
Andrew
Update on this...
It's fixed in this changeset:
http://trac.mu.wordpress.org/changeset/1134
Original ticket:
http://trac.mu.wordpress.org/ticket/479
Stupid question time: Do we need to change anything within the multidb plugin or with the original multidb code?
No.
Get personal, comprehensive and timely support and assistance
from WordPress Experts
@minusme,
Even I am trying to use 256 databases.
In the install.txt it is given that we need to move/copy the tables of first blog to the db specified in C (if we go for 16 databases). Can you let me to which database you moved the contents of the first blog. Thanks!
Well, blog #1 would be 'c4'. You may want to bookmark a md5 hash generator for reference. *chuckle* I know I have.
Luke, can you share what you use in sunrise to get the correct db and prefix? I'm finding that I have to manually correct multiple occurances in most plugins, and it's a killer...
Have you added the table names into wp-config.php for these plugins?
thanks mike!!! I actually had forgotten to add the tables there, OUCH!!
I would still be interested in how others are using sunrise for multiple db...
@drmike,
Thanks for the reply. Now I understand the logic behind it.
If I use 4096 databases then I have to place the first blog in "c4c" database.
If I use 65536 databases (at least in theory) then I have to place the first blog in "c4ca" database and so on.
Get personal, comprehensive and timely support and assistance
from WordPress Experts
Yes. The reasoning behind it is the system takes the $blog_id, md5s it into a hash and then takes the first few characters to determine which database to use. If you;re just doing 16 databases, it just takes the first character. If you're going 256 databases (ie 16 x 16), it takes the first 2 characters. If you're doing 4096 databases (ie 16 x 16 x 16) it's the first three characters. And so on.






Allows you to scale your standard Multisite install to allow for millions of blogs... also will vastly improve the performance of your site!