Post: #1

The forum is about to get a new home on a dedicated server. The date for this upgrade is Friday, September 27. During the move...

1. The forum will be read-only. You can read existing threads but you can't reply or start new threads. It may also go down for stretches and be inaccessible.

2. Private messages will stay on, but if you send messages during the move, they will be lost forever once the move is complete. For example, if you send a private message on Friday from the old server, but the recipient doesn't check the forum until Monday (after the move), he will not know you sent him that message. Do not send any private messages while the move is in progress.

There will be an obvious notice at the top of the forum letting you know the move is taking place. I expect everything to be up and running for most of you within 48 hours of the move. You will be able to read updates on the forum Twitter account (https://twitter.com/rooshvforum ).

Post: #2

Any chance we could switch the related posts module back on?

Post: #3

Yes, and the forum search too.

Post: #4

The server isn't going to be housed in this building is it?

Post: #5

Latest crash:

Quote:130920 20:03:13 InnoDB: Initializing buffer pool, size = 512.0M
130920 20:03:13 InnoDB: Completed initialization of buffer pool
130920 20:03:13 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130920 20:03:13 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.

Post: #6

(09-20-2013 08:15 PM)Roosh Wrote:  Latest crash:

Quote:130920 20:03:13 InnoDB: Initializing buffer pool, size = 512.0M
130920 20:03:13 InnoDB: Completed initialization of buffer pool
130920 20:03:13 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130920 20:03:13 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.

Have the forum tables been switched to InnoDB? If not, I would actually disable it.

Post: #7

In Phpmyadmin, all the tables show MYISAM. One of the IT guys installed Percona mysql.

Post: #8

You could disable innodb by adding these two lines to my.cnf

innodb=OFF
default-storage-engine=MyISAM

and restarting mysqld. It would cause mysql to use less memory, since it would skip creating the buffer pool for indexes.

Post: #9

^^ Done!

Let's see what that does.

Post: #10

I also notice a lot of these errors (before the change I just made):

Quote:130920 20:29:15 [ERROR] /usr/sbin/mysqld: Table './cphulkd/brutes' is marked as crashed and should be repaired

Post: #11

So that table stores failed login attempts for cpanel, which eventually locks someone from attempting to login again. If it's crashed, you can repair it, but from what I've seen in these threads, looks a few tables have had this issue. This often comes from free space issues on the drive. You said you had a problem with free space involving the backups, correct? That could have crashed a few tables.

Post: #12

Latest developments:

I tried to do a full cpanel backup, but I got this error:


Then I re-enabled InnoDB and did the backup again. The result was successful:

Quote:Determining mysql dbs...Warning: Using unique option prefix pass instead of password is deprecated and will be removed in a future release. Please use the full name instead.
...mysql version: 5.5......mysqldump version: 5.5...Saving mysql privs...Done

But the successful backup crashed the mysql server and then corrupted the database:

Quote:130921 5:54:36 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130921 5:54:36 InnoDB: Database was not shut down normally!

So I had to repair it.

I'm thinking the best thing to do is return to a stock mysql database from Percona. What would this involve?

Post: #13

(09-21-2013 06:18 AM)Roosh Wrote:  Latest developments:

I tried to do a full cpanel backup, but I got this error:

Code:

Determining mysql dbs...DBD::mysql::db selectall_arrayref failed: Unknown storage engine 'InnoDB' at /usr/local/cpanel/bin/cpmysqladmin line 200.
DBD::mysql::db selectall_arrayref failed: Unknown storage engine 'InnoDB' at /usr/local/cpanel/bin/cpmysqladmin line 200.
...mysql version: 5.5......mysqldump version: 5.5...Saving mysql privs...Done

Then I re-enabled InnoDB and did the backup again. The result was successful:

Quote:Determining mysql dbs...Warning: Using unique option prefix pass instead of password is deprecated and will be removed in a future release. Please use the full name instead.
...mysql version: 5.5......mysqldump version: 5.5...Saving mysql privs...Done

But the successful backup crashed the mysql server and then corrupted the database:

Quote:130921 5:54:36 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130921 5:54:36 InnoDB: Database was not shut down normally!

So I had to repair it.

I'm thinking the best thing to do is return to a stock mysql database from Percona. What would this involve?

I haven't done that specifically, but it should be like any other move. You would disable any writes to it (like restarting in read-only mode), do the full backup, uninstall current mysql, install percona, reload, restart. Percona should be a drop-in replacement, I'm 99% sure it still uses the same default port. I've heard they make a great product, although they have focused more on the InnoDB engine.

Post: #14

Just found this:

http://www.percona.com/software/percona-xtrabackup

Probably better than the stuck mysqldump, which I believe cpanel uses. It's more involved, though, being a command line tool versus the nice interface cpanel provides for backups.

Post: #15

I'm just going to try to hold the fort until the move. The new server will be stock, instead of this jerry-rigged system I seem to have in place now.

Post: #16

Roosh, i cant quote in the mobile version. Is it my browser?

Post: #17

It would be nice if you could use the Like and Report features on your phone also.

Post: #18

I think I'm going to move up the server move a couple days. This shit is driving me crazy.

Post: #19

(09-20-2013 03:54 PM)Roosh Wrote:  (Continuance from this thread.. /thread-27558.html)

The forum is about to get a new home on a fast dedicated server. The tentative date for this upgrade is Friday, September 27. During the move...

was this prompted by the bluehost outage earlier this year?

Post: #20

^^ It's been prompted by the growing size of the forum and also a disastrous server upgrade that installed mysql software (percona) that keeps crashing. By moving to a dedicated server, we'll be hitting two birds with one stone. The forum will be faster and more features can be added.

Post: #21

(09-20-2013 03:54 PM)Roosh Wrote:  (Continuance from this thread.. /thread-27558.html)

The forum is about to get a new home on a fast dedicated server. The tentative date for this upgrade is Friday, September 27. During the move...

is that NYC time, GMT, or ...

Post: #22

Just a brief update that the forum will be moved starting tomorrow morning.

I don't think this will be a fast move, so the forum may be read-only or down for you probably until Sunday. Hopefully it will be faster, but be prepared for an entire weekend of limited functionality.

Once the move is complete, it will take an extra week to fine-tune the new server settings, so I will start a new thread for you to share any errors you see.

After that, the forum will be sitting on a server that is about 5 times stronger that what we got now.

Post: #23

Where is the new server located geographically? I suggest the American Northeast or Western Europe, that would give good latency (quick responses) to more of your users.

ryanf, I see your point about MyISAM using less RAM, but isn't MyISAM less robust than InnoDB? If the new server has plenty of memory, I suggest staying with InnoDB.

Post: #24

(09-26-2013 11:15 AM)William Windsor Wrote:  Where is the new server located geographically? I suggest the American Northeast or Western Europe, that would give good latency (quick responses) to more of your users.

ryanf, I see your point about MyISAM using less RAM, but isn't MyISAM less robust than InnoDB? If the new server has plenty of memory, I suggest staying with InnoDB.

If all of his tables are MyISAM, then he wouldn't have seen the benefits of innodb anyway.

Post: #25

(09-26-2013 11:15 AM)William Windsor Wrote:  Where is the new server located geographically?

Chicago. Current server is in Texas.