New to the community? Start here

Further Info Needed

Hi, im going to try out the multi db thing, however im not sure i understand this part.

4) Copy blog tables (and related plugin tables) to the new blog databases. Blogs are assigned to databases based on an md5 hash of the blog id. You then take the first character for 16 databases, 2 for 256, and 3 for 4096.

how would i decide which id goes where?

would blog id 256 go into database 2? if so why would blog id 4096 go into databse 3?

Wed, 11 Jul 2007 10:19:08
  • Andrew
    • Champion of Loops

    Hi,

    You grab an md5 hash of the blog id. You can use this:

    http://calc.wpmudev.org/md5.php

    so if I put blog id “1002” into that form it gives you:

    fba9d88164f3e2d9109ee770223212a0

    If you’re using 16 database then it goes into db “f”, if you’re using 256 dbs it goes into db “fb”, and if you’re using 4096 dbs it goes into “fba”.

    As a general note, the Multi-DB code is considered “Beta” right now because it’s not very user friendly.

    Basically I want to get all the kinks ironed out then put out a new release with detailed instructions.

    Hope this helps,

    Andrew

  • Andrew
    • Champion of Loops

    Also unless you’re planning on millions of users i’d just go with 16 databases.

    Here’s the breakdown:

    16 databases – supports roughly 512,000 blogs

    256 databases – supports roughly 8,192,000 blogs

    4096 databases – supports roughly 131,072,000 blogs

    Those are simply estimates. Based on your OS and hardware, those numbers could go up or down slightly (most likely down by a few K).

  • Andrew
    • Champion of Loops

    Actually I do but i’m hesitant to release it because i’m not in the mood to answer questions such as “This doesn’t work on a particular distro with my particular setup”.

    If I were to release it, i’d only support it on CentOS which is the distro i’m most familiar with.

  • Andrew
    • Champion of Loops

    No. If you look inside of wp-config.php and find the database array you’ll see section that looks like this:

    $db_list = ‘YOUR_DB_NAME’;

    $db_list = ‘USER’;

    $db_list = ‘PASSWORD’;

    $db_list = ‘localhost’;

    You put the blog with the md5 hash 8e98d81f8217304975ccb23337bb5761 in the db that you have filled in the section of code above.

    Thanks,

    Andrew

  • Luke
    • The Crimson Coder

    Andrew: “If I were to release it, i’d only support it on CentOS which is the distro i’m most familiar with.”

    With “proper” permissions, a user should be able to execute a create database query.

    I won’t say it wouldn’t be a detailed process, but in theory a form could take in a special username/password for the creation of the DB (probably the mysql root user), and be able to execute the query efficiently.

    Then, even perhaps be able to write all the required data to the config file, or maybe an include file instead. Something where they could pick how many different users they want to access databases overall, the form spits out all the fields, the writes a modification to the config file to include say… wp-includes/multiple-db-settings.php, which is what the plugin would write all the settings to.

    Then again, that might not work, but there are some install programs out there that can create a DB if the db user is allowed to do so.

    Where this wouldn’t work, is probably on a shared host, but since this plugin isn’t intended for someting like that (obviously), then it might not be an issue.

  • Luke
    • The Crimson Coder

    Oh, as a note…

    Something I’ve observed before is that an md5 isn’t always the same across all platforms.

    I put together a class one time, that took a pre-installed md5 hash and compared it to a hash of the current values of two combined variables on the users site. While it was only an issue in maybe 10% of users, it was still an issue. I can’t say specifically what caused it, as what was hashed on their site matched exactly what was used to generate the original hash, but it ended up getting coded so that the hash was generated on their site, then added to a settings table.

    It wasn’t any one specific thing that narrowed it down to a certain distro or anything. It was very weird.

  • Luke
    • The Crimson Coder

    Andrew: “If I were to release it, i’d only support it on CentOS which is the distro i’m most familiar with.”

    With “proper” permissions, a user should be able to execute a create database query.

    I won’t say it wouldn’t be a detailed process, but in theory a form could take in a special username/password for the creation of the DB (probably the mysql root user), and be able to execute the query efficiently.

    Then, even perhaps be able to write all the required data to the config file, or maybe an include file instead. Something where they could pick how many different users they want to access databases overall, the form spits out all the fields, the writes a modification to the config file to include say… wp-includes/multiple-db-settings.php, which is what the plugin would write all the settings to.

    Then again, that might not work, but there are some install programs out there that can create a DB if the db user is allowed to do so.

    Where this wouldn’t work, is probably on a shared host, but since this plugin isn’t intended for someting like that (obviously), then it might not be an issue.

  • Andrew
    • Champion of Loops

    Hi Luke,

    I researched this exact issue at length before deciding to go with md5. DO you remember which distros they were using? Also, what version of PHP was this with? There were some issues with this on earlier version but was supposedly fixed sometime in 2005.

    I’ll comment on you other post in a bit – off to grab food now.

    Thanks,

    Andrew

  • Luke
    • The Crimson Coder

    This was late 2005 and early 2006, and there wasn’t anything specific enough to narrow it down. Nothing that matched up in terms of OS, PHP version, or anything. It was a nightmare, really.

    The only reason I mention this, is from the calc on the site here. It should be fine for most people, but might not be for 100%.

    As for using md5 for the keys in the script, then I wouldn’t see it having an effect. 1 still equals 1, after all.

    I’ll dig through my notes to see if I have anything from that time period on it, but I’m “pretty sure” I trashed em all after that project went down the toilet.

  • Andrew
    • Champion of Loops

    Since it was late 2005/early 2006 they might have been using an older version of PHP. Kinda like 85% of servers are running PHP 4.x.x even though PHP 5.x.x has been out for over two years now.

    If you do happen to find your notes though, i’d greatly appreciate you sending them :slight_smile:

    Thanks,

    Andrew

  • Luke
    • The Crimson Coder

    So far, I haven’t found anything locally. And anything I posted on the web to a certain forum, is behind locked doors which I no longer can access.

    I’ll be talking to Chris later tonight or tomorrow, and I’ll see if he remembers anything about it.

    Again, this would only affect the calc here, and not the actual plugin. If the plugin is running locally, and moving tables from the main db to one of the multiple, it wouldn’t be an issue.

    I will note though, as an example, that RHEL comes stock with PHP 4.3.9, although it can (obviously) be upgraded.

    RHEL 5 is due out shortly (a month or two +/-), and it’s going to be a big leap forward. And I thought someone mentioned something about Debian having older versions of either mysql or php a few months ago, but can’t recall specifically.

    Either way, we’re still only talking about the calc, and not the plugin being affected.

  • Luke
    • The Crimson Coder

    So far, I haven’t found anything locally. And anything I posted on the web to a certain forum, is behind locked doors which I no longer can access.

    I’ll be talking to Chris later tonight or tomorrow, and I’ll see if he remembers anything about it.

    Again, this would only affect the calc here, and not the actual plugin. If the plugin is running locally, and moving tables from the main db to one of the multiple, it wouldn’t be an issue.

    I will note though, as an example, that RHEL comes stock with PHP 4.3.9, although it can (obviously) be upgraded.

    RHEL 5 is due out shortly (a month or two +/-), and it’s going to be a big leap forward. And I thought someone mentioned something about Debian having older versions of either mysql or php a few months ago, but can’t recall specifically.

    Either way, we’re still only talking about the calc, and not the plugin being affected.

  • Luke
    • The Crimson Coder

    So far, I haven’t found anything locally. And anything I posted on the web to a certain forum, is behind locked doors which I no longer can access.

    I’ll be talking to Chris later tonight or tomorrow, and I’ll see if he remembers anything about it.

    Again, this would only affect the calc here, and not the actual plugin. If the plugin is running locally, and moving tables from the main db to one of the multiple, it wouldn’t be an issue.

    I will note though, as an example, that RHEL comes stock with PHP 4.3.9, although it can (obviously) be upgraded.

    RHEL 5 is due out shortly (a month or two +/-), and it’s going to be a big leap forward. And I thought someone mentioned something about Debian having older versions of either mysql or php a few months ago, but can’t recall specifically.

    Either way, we’re still only talking about the calc, and not the plugin being affected.

  • Andrew
    • Champion of Loops

    The next release will have some “db scripts” and including in those will be a version of the calc. That should solve that issue :slight_smile:

    However, I am going to make a note that users might want to consult their sys admin before moving to a different distro/platform.

    Thanks,

    Andrew

  • Luke
    • The Crimson Coder

    That sounds pretty reasonable.

    A quick check on their end (by just hashing a couple numbers to see if they match up between systems) should be good on their end.

    Other than that, you “would think” that if someone was expanding out boxes, they would be pretty much the same thing in terms of OS and packages and such. Never know though, I guess.

  • Andrew
    • Champion of Loops

    Well you see, that’s what i’m worried about. The multi-db code is meant for people who know what they’re doing. Not for the average Joe who thinks “hey, maybe i’ll try this myself”.

    For this reason i’m really having a hard time deciding whether or not I should create a step by step “how to”.

    At the moment i’m leaning towards providing some general instructions along with some db scripts that might make things go a bit faster. However if I go this route, there won’t be a “now click here” set of instructions.

    I’d love some feedback on this from anyone who might be interested.

    Thanks,

    Andrew

  • Luke
    • The Crimson Coder

    That makes sense to me, really.

    Then again, would that increase your load here in the forums, as you know someone that is clueless (er, less knowledgeable) will stick it right on their live site and try to do it. If you don’t have a problem telling them they shouldn’t be running it, or their site doesn’t need it, cool.

    However, considering the target audience for that particular script, as long as you warn them up front then they can’t really complain.