You can still read archived posts. It would look like this: https://boards.straightdope.com/sdmb/archive/index.php/t-160851.html
~Max
That’s not a true archive. That’s a read-only dialup/search engine friendly mode. Back in the day, many message boards would block search engines from crawling, except for /archive URLs, to conserve then-expensive bandwidth.
businesses routinely archive old data so it’s funny that some people here think it’s an awful thing to archive data.
Yes, but if there were a true archive, I would expect it to look just like that.
~Max
No one thinks it’s an awful thing.
We’re not physically able to do it in this software. If we could have we would have been doing this all along.
Jenny
your humble TubaDiva
Administrator
you can’t setup a new table called archive and copy old data into it? Find that very odd to say the least. Is the DB limited to just one table ?
I’m sure it’s possible to to make a new table or tables in whatever db is running this board. The question is, does this version of vbulletin have a way to interact with those tables to do what you’re envisioning. Sounds like the answer from people who do have familiarity is no.
What about master/slave for write/read operations, respectively? If search and indexing (eg: User CP subscription lists) is triggering table-level locks while other users are trying to post messages, would that help?
~Max
There’s mention of master-slave configuration in the manual: https://www.vbulletin.com/docs/html/main/config.php?manualversion=30807606?
~Max
FFS. Is everybody that attached to vBulletin 3, that they’d rather see the Reader spend thousands of dollars and several months coding some archive function that will have no benefit whatsoever, instead of a couple hundred dollars and a long weekend on new message board software that works?
I’ll use the car analogy again. You have a 2004 Pontiac Sunfire with more rust than intact body. You can’t go faster than 10 MPH without stalling. You’re driving with a passenger in the front seat. The car won’t go any faster if you ask the passenger to move to the back. Why? BECAUSE YOU’RE BOTH IN THE SAME BROKE-ASS BEATER CAR THAT STALLS AT 10 MPH. (That’s a little bit more than 16 EuroMiles/EuroHour.)
And, even if it did make a difference, which it won’t, it’s not as easy as “just make a new table”. The table structure for a message board system is a lot more complicated than you think. vBulletin 3 was written to work with a very specific MySQL database structure. (Use a text editor to look at the .sql file.) There’s close to 100 tables in the database of a stock vBulletin 3.* installation.
So, let’s say all that’s needed to fix the SDMB is a “new table”, because we live in a world where magic is real, Hillary Clinton is running for her second term in office, Pit Bulls poop Jolly Ranchers, and Jeffrey Epstein really killed himself. (A new table won’t do JACK SQUAT, but let’s just pretend it does.) What kind of structure would the archive table have? What kind of relationship would there be between that archive table and the information in other tables? What kind of PHP scripts would you need to populate the archive table? What about to generate dynamic Web pages that can display pages from the archive table, or search through them? What new fields would you need to add to other tables? The amount of modding it would require – again, to an obsolete message board system, for absolutely no benefit whatsoever – would be insane. Also, the outcome would be a database that would be very, very difficult to convert to another message board system when the time comes, because its table structure would be much different than what the conversion scripts would expect.
Or, you could buy a new message board system that works just fine on sites with hundreds of millions of posts for less than $200, convert the old vBulletin database by filling out a few things on a conversion script, make sure web server and MySQL default settings are optimized, and be good for the next 10 years.
I’m convinced. Some folks really want this relic of a message board script forever. I know the collective SDMB community is adverse to change, but … c’mon.
In vBulletin, a master and slave database both have the same information. Write queries go to the master server. Read queries go to the salve server. Writes to the master database are replicated to the slave database.
Not a techie, but from what I understand, it’s write queries that will lock the database when it’s overloaded. (I get more errors when I post or edit, than when I read.) That won’t change. If you post or edit a message, you’ll still get errors. Reading a post, I don’t know. It might work better, but it’ll still be slow. You can still lock a table with a search, which would affect the slave. It won’t help reduce CPU load or bandwidth consumption. Also, copying from the master to the slave database will burn through more CPU cycles. There might be a small bump in speed, but you really need several slave databases to make a noticeable difference in performance.
There’s also slave lag, which I have no clue about, but it doesn’t sound good. And, outside the context of BDSM, that’s enough “problematic” language for me today.
But, hey, there’s another option. The Reader could buy a new message board system that wasn’t coded all the way back when ALL YOUR BASE ARE BELONG TO US and Peanut Butter Jelly Time were a thing, and John Kerry was the Democratic Party nominee for president. Something that can deal with hundreds of millions of posts, for less than $200. They could then spend a nice long weekend converting the old vBulletin database over to the new system, tweaking things, and end up with a message board that works. But that’s too easy. Deconstructing an elderly version of vBulletin to see how it ticks, writing scripts to implement an archive function, and implementing master-slave databases on an already underpowered Google Sites account is the way to go, because vBulletin 3 rules, and change is bad.
It looks like the software cost is trivial for an upgrade. The real cost would be paying someone to install and test it. You need to test it under real conditions meaning having regular users use it for a week or so. I don’t care what software they use or what version as long as it works. I’m amazed that a table locking system did not slow down years ago.
Huge developer cost because all the conversion needed of the current database. This has been a problem for a whole lot of years now; previous owners weren’t willing to do this.
I was informed a long time ago that going to a new install of vBulletin will approximately quadruple the size of the existing database; this is the chief reason we’ve been on this version for so long. The techs we had in the past actively argued against upgrade for that reason, in fact; their limited budgets could not absorb the technician hours necessary to make this happen.
For the record, we have had this system thrashing thing for a while tbut not to this extent. (I had forgotten it, spend 24 years on a site, you forget a lot.) What happened in the past is that when it got unbearable TPTB would buy a new server. Whereupon we would eat up all the capacity in a relatively short time – at one point we got a bigger server and three months later we were looking at ANOTHER server – at that point we were on two servers.
The locking table problem was known back then too. IRRC this came to light when TSD was one of the assets acquired by a venture capital company that had loaned money to Creative Loafing to buy a stack of alternative papers, including the Reader. Then we had a recession and CL could not make the payments and the venture guys took over the company when it was forced into bankruptcy. They held this investment for four years before they sold the assets; during that period they did nothing besides the most basic maintenance. Keep in mind we’re talking like 12 years ago.
The venture capitalists hung on to TSD and didn’t manage to sell it until 2012. Again IIRC they did only the barest maintenance and didn’t invest much in anything … they may have upgraded us a little further down the 3.7 line but I think that was it. The next guys did a little something something and held on to TSD until purchase by the Sun-Times two years ago. The Sun-Times is finally able to get to us; they had to stabilize the main paper and that took them way longer than any of us thought.
Our time is soon arriving.
As I have said multiple times here, betterment is coming. It’s obviously not coming on the timetable we all want, but it is happening. We are asking for a lot from you to be patient. It is the situation that prevails right now.
Jenny
your humble TubaDiva
Administrator
Thanks again, Tuba. I really appreciate how you’ve been upfront about all of this.
Is there any way to get capacity on an additional server during the transition? Even though it would just be a temporary solution, it would help avoid any loss of membership because of the 5xx errors.
new software makes the DB 4x bigger? That’s bad, what about other software? Or another DB besides MySQL? Postgres is free and widely used. Since google hosts the site has anybody asked them about what software to run?
I’m pretty sure it’s support for more granular locking that makes the database bigger.
~Max
I can see row locking support making the software bigger but not sure why it would make the actual data bigger? Of course being free software it’s not like they are too worried about making things really efficient. Maybe the indexes are bigger.
Padding, I would assume. Gotta have the individual rows padded so you can lock them.
I also noticed some extra spaces in your post, coincidence?
~Max
If you’re looking for a DBA who can quickly fix performance problems with large databases, I’ve heard great things about Robert’); DROP TABLE Students;. 