Technical Suggestion to GFY for board problems
 

I'm not familar with the latest version of VB, but since it does use MySQL you might find less problems if you alter the tables (or atleast the huge ones affected by the 5 million+ posts) from INNODB to InnoDB.

InnoDB is better suited to handle millions of rows than INNODB is. From experience, usually after 1-2 million INNODB starts to choke and have corruption problems.

InnoDB seems to be fine for 10-15 million rows atleast.

Keith my dick gets hard when you talk about Mysql like that

I'll forward this to our tech guys.

Hehe wait until you hear my experience with the Purple Elephant baby (PostgreSQL) :1orglaugh

I once called the developer of it at his home and convinced him we had met at a show and he gave me this number if I ever had issues with PostgreSQL...I got him consulting and helping us with some performance issues for over a month for free :thumbsup

Cool, if that is indeed the problem (MYISAM table type for the size), this should fix it.

http://bo.gs/portfolio/print/charts/...#39;re-gay.jpg

:1orglaugh

I have a plan to find out the truth! I will implant two hot costa rican girls in his hotel room and see what they report :pimp

Hilarious.

Or Lensman could feed the hampsters more often?

Maybe they were over-fed and are too tired to run in the wheels powering the board :1orglaugh

Good stuff Various you sure know your stuff and can't wait to see your costarican honies at Internext...Better not be any Tranny surprise because I will do stuff but not be able to brag about it...:Graucho

No no....we'll thoroughly screen all attendees first-hand beforehand :Graucho

Err incase my gf reads this, I mean some guy at our office will test them beforehand :1orglaugh

row locking instead of table locking could add some benifits, i agree. As long as the overhead of transactions and foreign keys doesn't out weigh those benifits. With InnoDB you do take a preformance hit, but that hit depending on how your tables are done could be well worth it.

As far as INNODB, and 100 million rows plus (sorry 1-2 million) i haven't had any problems with corruption problems in some time. Only when some jackoff has kill -9 my server or when i had hardware failing on the machine. I don't think we have had a table corruption this year at all, however we used to have them all the time about 2 years ago when what we really needed was more servers to help with the load. Simple lookups are usually best handled with INNODB, something with high inserts and lookups InnoDB could be a much better solution.

If nothing else it's something that could be tried and if it didn't work move it back over. (if down time is an option, there could be a way of doing it w/out any down time) It is worth looking into.

Sorry it's late and i'm kinda rambling.

just have a question, have you ever ran into replication problems with InnoDB that you didn't get with INNODB?

Not as of yet, however I've had native mysql replication problems in the past using INNODB. I'm waiting to be able to use MySQL's new clustering software, that way I can have asynchronous replication.

In GFY's case, I assume they are doing massive inserts (every post), while tons of selects are being done on the same table, which is why I recommend trying InnoDB out.

Another option might be to run nightly optimizes on their tables if they don't already do so; I know when we had corruption problems, after having it run daily we had no more problems.

Yah an upgrade to 3.23.59 (replication fix in this 3 version) stoped or replication problems we used to have, since then we've upgraded had some problems on some earlier 4.0.x versions but 4.0.20 seems to be working fine.

I just didn't know if because of the way the binlogs for replication work and the differences in InnoDB and INNODB if you've seen any issue with this.

I do agree though if there are massive inserts on the same table all the selects are coming from (as we suspect) this could be a viable option.

I"m assuming these tables are keyed right :winkwink:

I have top secret footage from inside the adult.com offices of the server control station GFY is ran from....an agent lost his life to bring you these...enjoy...

http://www.cyberenigma.com/hamsterha...cs/compham.gif

I think most of my replication problems were in 4.0.13, we're now using 4.0.20 and it's been stable.

I'm using 4.1.5-gamma for our demo servers, for the new IwantU (so I can take advantage of subselects)....have yet to test if that one has any replication or innodb issues....hopefully not
:winkwink:

No idea, haven't had a look at VB's code/sql in years....but I'd definately hope so for their sake :1orglaugh

BTW, phpslave, are you experienced with references, constraints, multi-field indexes and such in MySQL?

I'm looking for someone to analyze my new DB structure, but so far people who told me they'd give me quotes haven't gotten me any yet......

If you're interested and qualified, hit me up on ICQ 38373031 or email [email protected]

I'll hit you up tomorrow I'm heading off to bed now, or you can hit me up tomorrow icq: 13792004

and we can see if I can help, no guarantees, if nothing else maybe you can help me :winkwink: