Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter castle9mm

    (@castle9mm)

    I AM the hosting provider. The mysql server is my own. The database user that WordPress uses has full privileges, include GRANT TRIGGER.

    I found this in the apache log files:
    “ERROR 1419 (HY000) at line #: You do not have the SUPER privilege and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable)“.

    I cannot grant the SUPER privilege as that would grant the user full access to the mysql server, not just it’s own database, which we can’t do due to security policies. I ended up running as query on mysql:

    set global log_bin_trust_function_creators = 1;

    Even though, i don’t use Amazon RDS, this article actually helped me rather than the unhelpful reply to ‘contact your hosting provider’

    Reference: https://techtavern.wordpress.com/2013/06/17/mysql-triggers-and-amazon-rds/

    @olaflexemo Yes i have multiple site using the same single redis container. You just define a different ‘WP_CACHE_KEY_SALT’ for each site in their wp-config.php That way they won’t be conflicts. I just use a “siteName1-somerandomstring” for my key salts.

    And yes, I have some sites that have multiple containers. As long as the salt is the same in each container, they’ll be able to share the same keys across the different containers.

    • This reply was modified 6 years, 7 months ago by castle9mm.

    @olaflexemo Sorry if I don’t understand. Are you asking if you need to have persistent storage with redis or are you telling me I should be using a persistent store?

    I’m not sure about best practices and I don’t have the best redis knowledge, but having persistent storage in Redis for WordPress isn’t mission critical in my case since I’m only using it to store the opcode cache. If the cache is wiped on container creation it’s not a huge loss for me. The sites will still function normally (albeit slower) and the cache will be built back up in a short amount of time.

    Redis is a memory store so it can ‘dump’ it’s memory to a time based snapshot so you have some data on a restart. https://redis.io/topics/persistence You could mount a host volume and have redis save it’s snapshot after a certain time or transaction to that volume and have it reload on spin up.

    If you’re wanting to add scalability with multiple redis containers, you can look into setting up a redis cluster. If I understand correctly they’ll sync over network so no need for a persistent shared data store in that case either. This is still on my to-do list but I haven’t need to outgrow the single container just yet.

    I hope that explains a little bit.

    • This reply was modified 6 years, 7 months ago by castle9mm.

    The plugin is “enabled” by copying the /wp-content/plugins/redis-cache/includes/object-cache.php file into you /wp-content/ directory. In my case I modified the “entryscript” used in my image to copy the file and change ownership on container creation. Not sure if it’s the best practice, but it worked in my case so the plugin is always enabled on container spin up. Depending on how you have your container built, you could also edit the ‘Dockerfile’ to just copy a local object-cache.php file into the image build as well but you’ll have to remember to update that local file if the plugin gets updated.

    
    # Enable Redis Object Cache Drop-in
    cp ./wp-content/plugins/redis-cache/includes/object-cache.php ./wp-content/
    chown www-data:www-data ./wp-content/object-cache.php
    • This reply was modified 6 years, 7 months ago by castle9mm.
    Thread Starter castle9mm

    (@castle9mm)

    I may have found the issue and solution. After greping the nginx cache keys and using curl from the multiple hosts, I found that nginx was creating different keys for the same URL when they should have been serving the already cached copy. After messing around a bit, I found the culprit was the VARY header causing each request to be slightly different on each host request. Anyway, modifying the cache_ignore_headers to include Vary, helped in my case. More testing to make sure it doesn’t causes other issues but thought I would drop it here in case someone else having the same issue as I.

    proxy_ignore_headers Cache-Control Expires Set-Cookie Vary;

    Same issue with me. Version 4.9.2 & WordPress 3.8. Strange thing, I only see *some* of the options when I click the “Insert Shortcode” button. There used to be a whole lot more and the ability to filter by category but those links are gone too.

Viewing 6 replies - 1 through 6 (of 6 total)