Wordpress on Vultr 768

scottalanmiller

@fuznutz04 said in Wordpress on Vultr 768:

@scottalanmiller Yeah, that didn't fix it. I'll just start over. I recall discussion on here previously that the "one click" installs of Wordpress on Vultr are not recommended. I couldn't remember (or find the discussion) why this was the opinion...

That's correct, those are never recommended. Use the OS, not a third party system.

momurda

@fuznutz04
I think there should be a bit more lines in that file.
What size files are the recreated innodb files?
What is the contents of /var/log/mariadb/mariadb.log

AdamF

@momurda said in Wordpress on Vultr 768:

@fuznutz04
I think there should be a bit more lines in that file.
What size files are the recreated innodb files?
What is the contents of /var/log/mariadb/mariadb.log

5242880 bytes is the size of the new files.

Seems like I'm in a time warp, as it is warning me that my sequence numbers are in the future!

161107 12:17:20  InnoDB: Waiting for the background threads to start
161107 12:17:20  InnoDB: Error: page 348 log sequence number 133743653
InnoDB: is in the future! Current system log sequence number 107618964.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.
161107 12:17:21 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended

So following the directions to force innodb into recovery mode, the DB starts, but then the logs say this:

InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
161107 12:34:37 mysqld_safe Number of processes running now: 0
161107 12:34:37 mysqld_safe mysqld restarted
161107 12:34:40 [Note] /usr/libexec/mysqld (mysqld 5.5.50-MariaDB) starting as process 11049 ...
161107 12:34:40 InnoDB: The InnoDB memory heap is disabled
161107 12:34:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
161107 12:34:40 InnoDB: Compressed tables use zlib 1.2.7
161107 12:34:40 InnoDB: Using Linux native AIO
161107 12:34:40 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137756672 bytes) failed; errno 12
161107 12:34:40 InnoDB: Completed initialization of buffer pool
161107 12:34:40 InnoDB: Fatal error: cannot allocate memory for the buffer pool
161107 12:34:40 [ERROR] Plugin 'InnoDB' init function returned error.
161107 12:34:40 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
161107 12:34:40 [ERROR] mysqld: Out of memory (Needed 128917504 bytes)
161107 12:34:40 [Note] Plugin 'FEEDBACK' is disabled.
161107 12:34:40 [ERROR] Unknown/unsupported storage engine: InnoDB
161107 12:34:40 [ERROR] Aborting

momurda

Just a bit of browsing I find this. You do actually seem to be out of memory, try adding

performance_schema = off

to the [mysqld] section of my.cnf

AdamF

@momurda said in Wordpress on Vultr 768:

Just a bit of browsing I find this. You do actually seem to be out of memory, try adding

performance_schema = off

to the [mysqld] section of my.cnf

No go. Same result, same errors

AdamF

Oh look, I fixed it!
(throws hands up and reinstalls.)

dafyre

Just don't forget to feed it... water it... say nurturing things to it.

momurda

Ah I forgot you put it in recovery mode. Turning that off might have fixed it, but if youre going to NIFO then that is ok too. Also when doing the reinstall make sure your permissions are right.

scottalanmiller

Wait, it works now? Or you reinstalled? Or both?

coliver

@scottalanmiller said in Wordpress on Vultr 768:

Wait, it works now? Or you reinstalled? Or both?

Sounds like both.

momurda

Think he means he fixed it by 'throwing hands up' and reinstalling. DOes the reinstall work though?

AdamF

I "fixed it" by reinstalling. Now I'm in the process of setting up LAMP and then Wordpress again.

scottalanmiller

@fuznutz04 said in Wordpress on Vultr 768:

I "fixed it" by reinstalling. Now I'm in the process of setting up LAMP and then Wordpress again.

Gotcha

dafyre

It's the old "Take that!" & nuke it from orbit ploy. Works every time.

AdamF

@dafyre Exactly. Didn't want to waste any more time on it, especially since it was still in testing/setup stages.

scottalanmiller

@fuznutz04 said in Wordpress on Vultr 768:

@dafyre Exactly. Didn't want to waste any more time on it, especially since it was still in testing/setup stages.

Makes sense.

thwr

@scottalanmiller said in Wordpress on Vultr 768:

@thwr said in Wordpress on Vultr 768:

Most Wordpress sites only have like 128 MB, maybe 256 MB.

I doubt that most do, as it's effectively impossible for many years to even get VPS that small. Rackspace minimum is 512MB and DO/Vultr is like 768MB.

I wasn't sure what he got at that point. Wordpress runs "fine" on 128MB, but that does not take into account what the operating system, Apache/Nginx and MySQL need.

A VM with Wordpress and a full webserver/database server stack should probably have like 512 MB at least.

scottalanmiller

@thwr said in Wordpress on Vultr 768:

I wasn't sure what he got at that point. Wordpress runs "fine" on 128MB, but that does not take into account what the operating system, Apache/Nginx and MySQL need.

It should run fine on 16MB then

scottalanmiller

@thwr said in Wordpress on Vultr 768:

A VM with Wordpress and a full webserver/database server stack should probably have like 512 MB at least.

For any real use, yeah. We have it working on 256MB, but it sucks.

thwr

@scottalanmiller said in Wordpress on Vultr 768:

@thwr said in Wordpress on Vultr 768:

A VM with Wordpress and a full webserver/database server stack should probably have like 512 MB at least.

For any real use, yeah. We have it working on 256MB, but it sucks.

Probably due to Wordpress. Someone once said: "That's the most frustrating piece of code I've ever seen". Don't have the link anymore...