I have an almost regular WordPress setup including a mySQL database (Server A). On March 1st 2018 this installation and mySQL database was copied to a new server (Server B). On the new server (B) a lot of things got improved and a new domain name was assigned. Also the prefix of the database has changed. Between March 1st and now this database (B) did not get any user registrations, however as said above it did get several updates and improvements for pages and general behaviour. I have successfully used phpmyadmin to export the database from the current installation (A) again (on May 5th) and import it into the new server (B) as a second database. What should happen now, is that the latest changes of (B) [March 1st + improvements etc.] should be merged together with the latest changes of (A) [March 1st + user registrations and user activities that happend on the current page between March 1st and May 5th]. 1. Can I merge the two databases as a whole (with one command), if the tables are the same (I have not really compared each of the tables and it's columns, but as I have not changed any plugins and all the table names are identical - no table has been added or deleted - I guess I can say the structure is identical?)? 2. Is there a way of using phpmyadmin to do that? 3. Should I be using "REPLACE" or "INSERT" or "INSERT ... ON DUPLICATE KEY UPDATE" or something completely different? I do not understand what would be correct here. 4. Once I have managed to mergen the data, what is a good way of updating all URL's to the new domain? In the new installation both databases (A) & (B) still have the wrong URL's. Many thanks for your help. On the new server (B) I'm running: - Server: Localhost via UNIX socket - Server-Typ: MySQL - Server-Version: 5.6.39 - MySQL Community Server (GPL) - Protokoll-Version: 10 - nginx/1.12.2 - Datenbank-Client Version: libmysql - mysqlnd 5.0.12-dev - 20150407 - $Id: b396954eeb2d1d9ed7902b8bae237b287f21ad9e $ - PHP-Erweiterung: mysqli curl mbstring - PHP-Version: 7.1.13

Thanks for reading! So I'm kind of banging my head against a wall but I firstly want to say that I think this is a DB setup problem rather than the code as even when stripped back to bare bones WC the queries are still slow so no interfering 3rd party code. Basically I have a WP/WooCommerce website that has quite a lot of data (11GB DB) and the WooCommerce core admin queries like listing orders on the orders page is taking 2 seconds plus other queries which totals to 9 seconds in DB queries. I really want to speed up these queries so query monitor plugin doesn't have any slow queries or at very least get much nearer to the 0.2s target but I have asked around and seem to be getting quite a few varied responses such as Redis, object cache and tools to add indexes but someone else fairly enough said that this will obviously add caching and speed up the queries but should the cache be cleared it will still be slow which doesn't (I guess) really solve the original issue? I'm not a DB admin expert by any means so I've previously just chucked memory at the VPS (48GB) and set the InnoDB pool size as high as mysqltuner told me to at 28GB but I get the feeling this is wrong as most google results suggest it should be 8GB or at very max be the same GB amount as the DB is big and the DB is back to being slow! Any ideas on what's going wrong? I've seen other things like increasing innodb_io_capacity (which is currently set to 200 but max is set to 2000 and the VPS is using an SSD) but mysqltuner has not mentioned these variables and I've not updated these values before. Would just like to know if I do just need to implement Redis etc or to start I do need more memory or I do need to change some variables or I need to do them all! Happy to provide what info I can. Thanks in advance, Brad

I had installed wordpress on ubuntu 20.04 on 2GB/2CPU and I have a problem with my MySQL server that keeps crashing. Everyday we are getting below error : error establishing a database connection and after refreshing the site, error gone but reappear after sometime.

`
2021-08-20T15:35:54.676626Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.26-0ubuntu0.20.04.2) starting as process 47806
2021-08-20T15:35:54.715129Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2021-08-20T15:35:55.518494Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2021-08-20T15:35:55.889880Z 0 [System] [MY-010229] [Server] Starting XA crash recovery...
2021-08-20T15:35:55.910933Z 0 [System] [MY-010232] [Server] XA crash recovery finished.
2021-08-20T15:35:55.968155Z 0 [Warning] [MY-013746] [Server] A deprecated TLS version TLSv1 is enabled for channel mysql_main
2021-08-20T15:35:55.968416Z 0 [Warning] [MY-013746] [Server] A deprecated TLS version TLSv1.1 is enabled for channel mysql_main
2021-08-20T15:35:55.972738Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2021-08-20T15:35:55.973735Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2021-08-20T15:35:56.049092Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '127.0.0.1' port: 33060, socket: /var/run/mysqld/mysqlx.sock
2021-08-20T15:35:56.049283Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.26-0ubuntu0.20.04.2'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu).
2021-08-20T15:35:56.358145Z 8 [ERROR] [MY-013134] [Server] Table './database_name/wprd_postmeta' is marked as crashed and should be repaired
2021-08-20T15:35:56.367954Z 8 [Warning] [MY-010756] [Server] Checking table:   './database_name/wprd_postmeta'
2021-08-20T15:35:56.396138Z 10 [ERROR] [MY-013134] [Server] Table './database_name/wprd_options' is marked as crashed and should be repaired
2021-08-20T15:35:56.397423Z 10 [Warning] [MY-010756] [Server] Checking table:   './database_name/wprd_options'
2021-08-20T15:35:56.759102Z 9 [ERROR] [MY-013134] [Server] Table './database_name/wprd_ahm_sessions' is marked as crashed and should be repaired
2021-08-20T15:35:56.759734Z 9 [Warning] [MY-010756] [Server] Checking table:   './database_name/wprd_ahm_sessions'
2021-08-20T15:35:57.341553Z 11 [ERROR] [MY-013134] [Server] Table './database_name/wprd_usermeta' is marked as crashed and should be repaired
2021-08-20T15:35:57.342417Z 11 [Warning] [MY-010756] [Server] Checking table:   './database_name/wprd_usermeta'
2021-08-20T15:36:05.715122Z 12 [ERROR] [MY-013134] [Server] Table './database_name/wprd_ahm_download_stats' is marked as crashed and should be repaired
2021-08-20T15:36:05.720212Z 12 [Warning] [MY-010756] [Server] Checking table:   './database_name/wprd_ahm_download_stats'

`` Database size is about 250MB

for the first time I am faced with such a problem that has puzzled everyone. I have all hosting busy (AWS lightsail) 78GB and after a few analyzes I realized that 90% of the memory is occupied in the mysql/data folder. My wordpress website is weight - 6GB and I removed all binary logs before the problem, so the problem is not connected with that. I can no longer log into *phpmyadmin*, because there is no free space left on the disk. But when I got there until the problem I saw that wp-option has a crazy amount of GB. No plugin was able to clear this and I decided to put it off. Now that everything is busy, most of the commands cannot be executed, especially the mysql commands. I am using SSH. Help if possible.

I am trying to install mysql-server on my Debian servers. I am following the documentation at dev.mysql.com. 1. I start in /tmp/. 2. I get wget https://dev.mysql.com/get/mysql-apt-config_0.8.30-1_all.deb . 3. I dpkg -i the file i just downloaded. 4. I do the config setting. 5. sudo apt update. The error:

Err:1 http://repo.mysql.com/apt/debian  buster InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B7B3B788A8D3785C
Reading package lists... Done
W: GPG error: http://repo.mysql.com/apt/debian  buster InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B7B3B788A8D3785C
E: The repository 'http://repo.mysql.com/apt/debian  buster InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

6. pro forma sudo apt install mysql-server, the error: No installation candidate. This must be the hundredth time I've done this in my life. Why is this suddenly not working?

Has anyone successfully deployed WordPress with TiDB in a production environment? Are there known compatibility issues (e.g., unsupported SQL syntax like SQL_CALC_FOUND_ROWS) that should be accounted for? There is no mention of TiDB at https://wordpress.org/about/stats/#mysql_versions nor at https://wordpress.org/about/requirements/ , and various websites/blogs seem like one-off tests.

SELECT object_id, term_taxonomy_id FROM wp_term_relationships INNER JOIN wp_posts ON object_id = ID WHERE term_taxonomy_id IN (525627,516360,525519,535782,517555,525186,517572,549564,1,517754,541497,541472,525476,549563,517633,524859,702393,541604,543483,524646,525001,550518,541516,525244,549565,517376,535783,524642,25,533395,533537,525475,2,705306,524684,525065,939122,541603,525523,533491,541590,702713,550724,525243,533634,525122,541498,549586,546982,21,524643,541478,525435,535784,541471,516611,535781,541638,516142,533416,546984,524999,533453,524682,704994,516579,516189,524644,517378,525185,541508,517634,705305,524858,517632,541637,517699,525064,517573,772367,516609,517375,525474,507436,524918,517635,541929,22,54,53,705119,524685,524683,516577,536343,191228,524915,524917,516298,541573,546983,515904,541601,56,517377,524645,517707,515905,516297,515903,517708,533635,516296,516578,517750,517554,516016,525123,533538,541625,525187,705307,55,191226,19,24,516299,541466,524916,772366,555654,516612,541503,191227,550302,991853,920642,191229,535829,525582,525524,524919,524720,525841,517636,541504,525184,525520,541562,525433,541563,516610) AND post_type IN ('post') AND post_status = 'publish' + _pad_term_counts() Theme 259514 2.0440 SELECT wp_posts.ID FROM wp_posts LEFT JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) WHERE 1=1 AND wp_posts.ID NOT IN (391534) AND ( wp_term_relationships.term_taxonomy_id IN (2,516296,517375,517376,517377,517378,517554,517555,517572,517573,517632,517633,517634,517635,517636,517699,517707,517708,517750,517754,524858,524859,524915,524916,524917,524918,524919,524999,525001,525064,525065,525185,525186,525187,525519,525520,525523,525524,525582,525841,533395,533416,533453,535782,535783,535784,535829,536343,549563,549564,549565,549586,550302,550518,550724,555654,702393,702713,704994,705119,705305,705306,705307,772366,772367,920642,939122,991853) ) AND wp_posts.post_type = 'post' AND ((wp_posts.post_status = 'publish')) GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 6 How can I improve this query ? I have many posts and they are taking like 2secs each. Thanks I also found this extra info that I think would help... > Why do you think modifying WordPress core table is a good idea? – > Krzysiek Dróżdż♦ Jun 12 '15 at 4:21 I really don't think it's a good > idea but a necessary one if running wordpress with the amount of posts > and combined with the limitations of mysql not having a descending > index function. Those file sorts caused by the order by operations are > a deal breaker for us in regards to site performance. – Ranknoodle Jun > 15 '15 at 2:34 But these operations are slow since you're doing it > wrong. In some projects we had similar issue, but came to very > different solution, that didn't modify core tables. We've created our > own table and used it as indexing/search table. So every slow query > was searching only based on this one table (no joins needed). (And we > had much more data, AFAIR) – Krzysiek Dróżdż♦ Jun 15 '15 at 5:06 Hi > KRZYSIEK can you explain a little more on indexing search tables that > you created? For example the slow query outline in the original > question, I would create a table to store the post > ID,reverse_post_id,post_type etc and only query against that? – > Ranknoodle Jun 15 '15 at 16:31 Send me an e-mail, I'll try to > elaborate on that method. – Krzysiek Dróżdż♦ Jun 15 '15 at 16:34 But no idea on the method he used.

i just did restarted services on my Bitnami/Nginx/SSL/WordPress server (was updating my certs). I suddenly got a disk space full, i found that my issue was Binlogs clogging up, which i promptly deleted and was good to turn it back on. However, now i have a permissions issue. The MYSQL logs show

2020-03-09T05:14:56.631119Z 0 [System] [MY-010910] [Server] /opt/bitnami/mysql/bin/mysqld.bin: Shutdown complete (mysqld 8.0.15) MySQL Community Server - GPL.
2020-03-09T05:16:56.071411Z 0 [System] [MY-010116] [Server] /opt/bitnami/mysql/bin/mysqld.bin (mysqld 8.0.15) starting as process 4893
2020-03-09T05:16:56.074734Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
2020-03-09T05:16:56.074743Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead.
2020-03-09T05:16:56.083922Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_actionscheduler_groups.ibd'
2020-03-09T05:16:56.083944Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_cleanup_optimizer_db_scheduler.ibd'
2020-03-09T05:16:56.083964Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_ac_abandoned_cart_history_lite.ibd'
2020-03-09T05:16:56.083984Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_auto_updates.ibd'
2020-03-09T05:16:56.084009Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_cleanup_optimizer_wp_scheduler.ibd'
2020-03-09T05:16:56.084032Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_tm_taskmeta.ibd'
2020-03-09T05:16:56.084053Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_wc_tax_rate_classes.ibd'
2020-03-09T05:16:56.084075Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_update_log.ibd'
2020-03-09T05:16:56.084097Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_actionscheduler_logs.ibd'
2020-03-09T05:16:56.084119Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_oses_emails.ibd'
2020-03-09T05:16:56.084151Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_cleanup_optimizer_login_log.ibd'
2020-03-09T05:16:56.084172Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_oses_clicks.ibd'
2020-03-09T05:16:56.084191Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_wfls_2fa_secrets.ibd'
2020-03-09T05:16:56.084212Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_ac_guest_abandoned_cart_history_lite.ibd'
2020-03-09T05:16:56.084234Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_ac_sent_history_lite.ibd'
2020-03-09T05:16:56.084255Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_wfls_settings.ibd'
2020-03-09T05:16:56.084275Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_cleanup_optimizer_block_single_ip.ibd'
2020-03-09T05:16:56.084296Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_cleanup_optimizer_plugin_settings.ibd'
2020-03-09T05:16:56.084317Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_cleanup_optimizer_block_range_ip.ibd'
2020-03-09T05:16:56.084338Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_wc_product_meta_lookup.ibd'
2020-03-09T05:16:56.084358Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_sbi_instagram_posts.ibd'
2020-03-09T05:16:56.084379Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_sbi_instagram_feeds_posts.ibd'
2020-03-09T05:16:56.084402Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_cleanup_optimizer_licensing.ibd'
2020-03-09T05:16:56.084423Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_ac_email_templates_lite.ibd'
2020-03-09T05:16:56.084442Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_actionscheduler_claims.ibd'
2020-03-09T05:16:56.084463Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_tm_tasks.ibd'
2020-03-09T05:16:56.084485Z 1 [Warning] [MY-012197] [InnoDB] Unable to open './bitnami_wordpress/wp_actionscheduler_actions.ibd'
2020-03-09T05:16:56.112313Z 1 [ERROR] [MY-012961] [InnoDB] Only one log file found
2020-03-09T05:16:56.112332Z 1 [ERROR] [MY-012930] [InnoDB] Plugin initialization aborted with error not found.
2020-03-09T05:16:56.713336Z 1 [ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
2020-03-09T05:16:56.713530Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2020-03-09T05:16:56.713868Z 0 [ERROR] [MY-010119] [Server] Aborting

Anyone know how i can fix permissions? I tried to CHOWN the mysql directory with no luck, i haven't ever seen the ./bitnami_wordpress issue and cannot seem to find a fix online at all.

I have made a Wordpress plugin that writes some data to a proprietary table. The query as shown in the log is: INSERT INTO berichten_devices (device_UUID, article_id) VALUES (%s, %s) If I take this line and enter it manually via adminer in the database, replacing the first %s with 'test' and the second %s with 1: INSERT INTO berichten_devices (device_UUID, article_id) VALUES ('test', 1) The this is stored in the database without a problem. There is also another table that is written to from the plugin which works fine. The php that is responsible for storing the data is as follows: function insert_artice_read($uuid, $article_id) { error_log('$uuid:'.$uuid, 0); error_log('$article_id:'.$article_id, 0); $query = "INSERT INTO berichten_devices (device_UUID, article_id) VALUES (%s, %s)"; error_log('$query', 0); error_log($query, 0); $query = $this->wpdb->prepare($uuid, $article_id); return $this->wpdb->query($query); } The parameter $this->wpdb is defined as $this->wpdb = $wpdb; The logging that is shown is this: dcr-wordpress | [Tue Jun 25 10:45:03.363771 2019] [php7:notice] [pid 1953] [client 192.168.224.1:43584] $uuid:ABCDEF01-2345-6789-ABCD-9876543210AA dcr-wordpress | [Tue Jun 25 10:45:03.363776 2019] [php7:notice] [pid 1953] [client 192.168.224.1:43584] $article_id:1 dcr-wordpress | [Tue Jun 25 10:45:03.363781 2019] [php7:notice] [pid 1953] [client 192.168.224.1:43584] $query dcr-wordpress | [Tue Jun 25 10:45:03.363785 2019] [php7:notice] [pid 1953] [client 192.168.224.1:43584] INSERT INTO berichten_devices (device_UUID, article_id) VALUES (%s, %s) dcr-wordpress | [Tue Jun 25 10:45:03.364844 2019] [php7:notice] [pid 1953] [client 192.168.224.1:43584] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ABCDEF01-2345-6789-ABCD-9876543210AA' at line 1 bij query ABCDEF01-2345-6789-ABCD-9876543210AA gemaakt door require('wp-blog-header.php'), wp, WP->main, WP->parse_request, do_action_ref_array('parse_request'), WP_Hook->do_action, WP_Hook->apply_filters, rest_api_loaded, WP_REST_Server->serve_request, WP_REST_Server->dispatch, Prop\\Inc\\Core\\RestController->article_retrieved, Prop\\Inc\\Common\\Repository->insert_artice_read dcr-wordpress | 192.168.224.1 - - [25/Jun/2019:10:45:03 +0000] "POST /wp/wp-json/prop/v1/berichten-devices HTTP/1.1" 200 802 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 12_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148" From this logging it is obvious that there is something wrong with the sql syntax, but this line seems weird to me: for the right syntax to use near 'ABCDEF01-2345-6789-ABCD-9876543210AA' This is data from the prepared statement parameters, I would expect to see something like for the right syntax to use near %s I tried to use %i instead of %s for the second parameter, just be sure, but there was no difference. This is the table definition: CREATE TABLE IF NOT EXISTS berichten_devices ( device_UUID VARCHAR(255) NOT NULL, article_id int(10) NOT NULL, date timestamp(4) NOT NULL DEFAULT CURRENT_TIMESTAMP(4), KEY dev_uuid (device_UUID) My question is basically: "What am I doing wrong?"

Recently my wordpress site is having troubles and is stopping from working due to heavy load in the mysql processes. I need to know what is causing all this traffic and how to narrow the issue so I can troubleshoot the error. I ran some commands and I am getting this results show status like '%onn%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | Aborted_connects | 143 | | Connections | 17736 | | Max_used_connections | 198 | | Ssl_client_connects | 0 | | Ssl_connect_renegotiates | 0 | | Ssl_finished_connects | 0 | | Threads_connected | 6 | +--------------------------+-------+ mysqladmin status Uptime: 3711 Threads: 3 Questions: 17872313 Slow queries: 13 Opens: 344 Flush tables: 1 Open tables: 335 Queries per second avg: 4816.036 and sometimes the cpu consumption by mysql reaches the 300%

When I visit the woocommerce orders page in WordPress, MySQL RDS CPU usage goes to 100% but the website is working perfectly fine. In 'active sessions' section, "wait/io/tables/sql/handler" is showing cpu usage to 99%. I looked at the performance insights of the database and saw this query: SELECT SQL_CALC_FOUND_ROWS hbm_posts.*, low_stock_amount_meta.meta_value AS low_stock_amount, MAX( product_lookup.date_created ) AS last_order_date FROM hbm_posts LEFT JOIN hbm_wc_product_meta_lookup wc_product_meta_lookup ON hbm_posts.ID = wc_product_meta_lookup.product_id LEFT JOIN hbm_postmeta AS low_stock_amount_meta ON hbm_posts.ID = low_stock_amount_meta.post_id AND low_stock_amount_meta.meta_key = '_low_stock_amount' LEFT JOIN hbm_wc_order_product_lookup product_lookup ON hbm_posts.ID = CASE WHEN hbm_posts.post_type = 'product' THEN product_lookup.product_id WHEN hbm_posts.post_type = 'product_variation' THEN product_lookup.variation_id END WHERE 1=1 AND hbm_posts.post_type IN ('product', 'product_variation') AND ((hbm_posts.post_status = 'publish')) AND wc_product_meta_lookup.stock_quantity IS NOT NULL AND wc_product_meta_lookup.stock_status IN('instock','outofstock') AND ( ( low_stock_amount_meta.meta_value > '' AND wc_product_meta_lookup.stock_quantity '' AND wc_product_meta_lookup.stock_quantity <= CAST(low_stock_amount_meta.meta_value AS SIGNED) ) OR ( ( low_stock_amount_meta.meta_value IS NULL OR low_stock_amount_meta.meta_value <= '' ) AND wc_product_meta_lookup.stock_quantity <= 2 ) ) GROUP BY hbm_posts.ID ORDER BY hbm_posts.post_date DESC, hbm_posts.ID DESC LIMIT 0, 1_posts.ID ORDER BY hbm_posts.post_date DESC, hbm_posts.ID DESC LIMIT 0, 1 I have tried tracing back the query in WordPress, but can't find it anywhere. I searched it with 'string locator', saw query logs in 'query monitor', tried disabling all plugins, and also tried "define('SAVEQUERIES', true);" as stated in this post: https://stackoverflow.com/questions/4660692/is-it-possible-to-print-a-log-of-all-database-queries-for-a-page-request-in-word What can I do to trace back this? Mysql version of server and client is 5.7.34

I am using Digital Ocean droplets for my WordPress Site. There are more than 60 binlog files in /var/lib/mysql. Most of the solutions say that I should purge them from MySQL. The storage is so full the Apache2 or MySQL are both off. How can I get rid of these binlog files in this case in a way that doesn't lose my data? Running this df -H --output=source,size,used,avail Returns Filesystem Size Used Avail tmpfs 412M 43M 370M /dev/vda1 63G 63G 0 tmpfs 2.1G 0 2.1G tmpfs 5.3M 0 5.3M /dev/vda15 110M 5.5M 104M tmpfs 412M 4.1k 412M

My mysql replication (master - slave) is failing with following error: >Last_SQL_Errno: 1062 >Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed > executing transaction 'ANONYMOUS' at source log mysql-bin.000115, > end_log_pos 468117420. See error log and/or > performance_schema.replication_applier_status_by_worker table for more > details about this failure or others, if any. I checked the bin log file and I see following > 2024-12-03T21:48:34.088063Z 7 [ERROR] [MY-010584] [Repl] Replica SQL > for channel '': Worker 1 failed executing transaction 'ANONYMOUS' at > source log mysql-bin.000123, end_log_pos 515; Could not execute > Write_rows event on table mydb.wp_options; Duplicate entry > '_transient_jetpack_update_remote_package_last_query' for key > 'wp_options.option_name', Error_code: 1062; handler error > HA_ERR_FOUND_DUPP_KEY; the event's source log mysql-bin.000123, > end_log_pos 515, Error_code: MY-001062 > 2024-12-03T21:48:34.088873Z 6 [ERROR] [MY-010586] [Repl] Error running query, replica SQL thread > aborted. Fix the problem, and restart the replica SQL thread with > "START REPLICA". We stopped at log 'mysql-bin.000123' position 157 The problematic database is a WordPress database. How do I fix it and also avoid this happening in the future as I've many wordPress databases and I'll have more in the future.

I have moderate experience in working with WordPress and WooCommerce sites but I'm now for the first time working on a site which is a bit bigger and I'm facing issues where the MariaDB process gets killed if I open up too many tabs too quickly for example browsing the admin side or sometimes it crashes when people are browsing the public site. I have done a temporary "fix" for keeping the site going with a cron job that runs every minute and it checks if MariaDB is running and restarts it if it's not. That seems to work but it still would be better to diagnose and fix the actual issue. My server is Ubuntu 22.04 with 4 cpu cores and 8GB of RAM I'm using Plesk Obsidian 18.0.60 to host my WordPress sites on the server. There's a couple other sites which barely get any traffic and then there is this one WooCommerce site which gets 95% of the traffic on the server. The RAM usage is around 2GB average constantly so there's plenty of room to use. I'm just not sure how to optimize the MariaDB settings for this large site. **kern.log** has this:

Apr 23 23:29:18 srv02 kernel: [561268.061478] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=init.scope,mems_allowed=0,global_oom,task_memcg=/system.slice/mariadb.service,task=mariadbd,pid=612094,uid=114
Apr 23 23:29:18 srv02 kernel: [561268.061534] Out of memory: Killed process 612094 (mariadbd) total-vm:2539808kB, anon-rss:703116kB, file-rss:0kB, shmem-rss:0kB, UID:114 pgtables:1692kB oom_score_adj:0

Not sure which variables I should list so here's all of them.

alter_algorithm DEFAULT
analyze_sample_percentage       100.000000
aria_block_size 8192
aria_checkpoint_interval        30
aria_checkpoint_log_activity    1048576
aria_encrypt_tables     OFF
aria_force_start_after_recovery_failures        0
aria_group_commit       none
aria_group_commit_interval      0
aria_log_dir_path       /var/lib/mysql/
aria_log_file_size      1073741824
aria_log_purge_type     immediate
aria_max_sort_file_size 9223372036853727232
aria_page_checksum      ON
aria_pagecache_age_threshold    300
aria_pagecache_buffer_size      134217728
aria_pagecache_division_limit   100
aria_pagecache_file_hash_size   512
aria_recover_options    BACKUP,QUICK
aria_repair_threads     1
aria_sort_buffer_size   268434432
aria_stats_method       nulls_unequal
aria_sync_log_dir       NEWFILE
aria_used_for_temp_tables       ON
auto_increment_increment        1
auto_increment_offset   1
autocommit      ON
automatic_sp_privileges ON
back_log        80
basedir /usr
big_tables      OFF
bind_address    127.0.0.1
binlog_annotate_row_events      ON
binlog_cache_size       32768
binlog_checksum CRC32
binlog_commit_wait_count        0
binlog_commit_wait_usec 100000
binlog_direct_non_transactional_updates OFF
binlog_expire_logs_seconds      864000
binlog_file_cache_size  16384
binlog_format   MIXED
binlog_optimize_thread_scheduling       ON
binlog_row_image        FULL
binlog_row_metadata     NO_LOG
binlog_stmt_cache_size  32768
bulk_insert_buffer_size 8388608
character_set_client    utf8mb3
character_set_connection        utf8mb3
character_set_database  utf8mb4
character_set_filesystem        binary
character_set_results   utf8mb3
character_set_server    utf8mb4
character_set_system    utf8mb3
character_sets_dir      /usr/share/mysql/charsets/
check_constraint_checks ON
collation_connection    utf8mb3_general_ci
collation_database      utf8mb4_general_ci
collation_server        utf8mb4_general_ci
column_compression_threshold    100
column_compression_zlib_level   6
column_compression_zlib_strategy        DEFAULT_STRATEGY
column_compression_zlib_wrap    OFF
completion_type NO_CHAIN
concurrent_insert       AUTO
connect_timeout 10
core_file       OFF
datadir /var/lib/mysql/
date_format     %Y-%m-%d
datetime_format %Y-%m-%d %H:%i:%s
deadlock_search_depth_long      15
deadlock_search_depth_short     4
deadlock_timeout_long   50000000
deadlock_timeout_short  10000
debug_no_thread_alarm   OFF
default_master_connection
default_password_lifetime       0
default_regex_flags
default_storage_engine  InnoDB
default_tmp_storage_engine
default_week_format     0
delay_key_write ON
delayed_insert_limit    100
delayed_insert_timeout  300
delayed_queue_size      1000
disconnect_on_expired_password  OFF
div_precision_increment 4
encrypt_binlog  OFF
encrypt_tmp_disk_tables OFF
encrypt_tmp_files       OFF
enforce_storage_engine
eq_range_index_dive_limit       200
error_count     0
event_scheduler OFF
expensive_subquery_limit        100
expire_logs_days        10.000000
explicit_defaults_for_timestamp OFF
external_user
extra_max_connections   1
extra_port      0
flush   OFF
flush_time      0
foreign_key_checks      ON
ft_boolean_syntax       + ->
optimizer_trace enabled=off
optimizer_trace_max_mem_size    1048576
optimizer_use_condition_selectivity     4
performance_schema      OFF
performance_schema_accounts_size        -1
performance_schema_digests_size -1
performance_schema_events_stages_history_long_size      -1
performance_schema_events_stages_history_size   -1
performance_schema_events_statements_history_long_size  -1
performance_schema_events_statements_history_size       -1
performance_schema_events_transactions_history_long_size        -1
performance_schema_events_transactions_history_size     -1
performance_schema_events_waits_history_long_size       -1
performance_schema_events_waits_history_size    -1
performance_schema_hosts_size   -1
performance_schema_max_cond_classes     90
performance_schema_max_cond_instances   -1
performance_schema_max_digest_length    1024
performance_schema_max_file_classes     80
performance_schema_max_file_handles     32768
performance_schema_max_file_instances   -1
performance_schema_max_index_stat       -1
performance_schema_max_memory_classes   320
performance_schema_max_metadata_locks   -1
performance_schema_max_mutex_classes    210
performance_schema_max_mutex_instances  -1
performance_schema_max_prepared_statements_instances    -1
performance_schema_max_program_instances        -1
performance_schema_max_rwlock_classes   50
performance_schema_max_rwlock_instances -1
performance_schema_max_socket_classes   10
performance_schema_max_socket_instances -1
performance_schema_max_sql_text_length  1024
performance_schema_max_stage_classes    160
performance_schema_max_statement_classes        222
performance_schema_max_statement_stack  10
performance_schema_max_table_handles    -1
performance_schema_max_table_instances  -1
performance_schema_max_table_lock_stat  -1
performance_schema_max_thread_classes   50
performance_schema_max_thread_instances -1
performance_schema_session_connect_attrs_size   -1
performance_schema_setup_actors_size    -1
performance_schema_setup_objects_size   -1
performance_schema_users_size   -1
pid_file        /run/mysqld/mysqld.pid
plugin_dir      /usr/lib/mysql/plugin/
plugin_maturity gamma
port    3306
preload_buffer_size     32768
profiling       OFF
profiling_history_size  15
progress_report_time    5
protocol_version        10
proxy_protocol_networks
proxy_user
pseudo_slave_mode       OFF
pseudo_thread_id        26517
query_alloc_block_size  16384
query_cache_limit       1048576
query_cache_min_res_unit        4096
query_cache_size        1048576
query_cache_strip_comments      OFF
query_cache_type        OFF
query_cache_wlock_invalidate    OFF
query_prealloc_size     24576
rand_seed1      979786629
rand_seed2      14782398
range_alloc_block_size  4096
read_binlog_speed_limit 0
read_buffer_size        131072
read_only       OFF
read_rnd_buffer_size    262144
relay_log
relay_log_basename
relay_log_index
relay_log_info_file     relay-log.info
relay_log_purge ON
relay_log_recovery      OFF
relay_log_space_limit   0
replicate_annotate_row_events   ON
replicate_do_db
replicate_do_table
replicate_events_marked_for_skip        REPLICATE
replicate_ignore_db
replicate_ignore_table
replicate_wild_do_table
replicate_wild_ignore_table
report_host
report_password
report_port     3306
report_user
require_secure_transport        OFF
rowid_merge_buff_size   8388608
rpl_semi_sync_master_enabled    OFF
rpl_semi_sync_master_timeout    10000
rpl_semi_sync_master_trace_level        32
rpl_semi_sync_master_wait_no_slave      ON
rpl_semi_sync_master_wait_point AFTER_COMMIT
rpl_semi_sync_slave_delay_master        OFF
rpl_semi_sync_slave_enabled     OFF
rpl_semi_sync_slave_kill_conn_timeout   5
rpl_semi_sync_slave_trace_level 32
secure_auth     ON
secure_file_priv
secure_timestamp        NO
server_id       1
session_track_schema    ON
session_track_state_change      OFF
session_track_system_variables  autocommit,character_set_client,character_set_connection,character_set_results,time_zone
session_track_transaction_info  OFF
skip_external_locking   ON
skip_name_resolve       OFF
skip_networking OFF
skip_parallel_replication       OFF
skip_replication        OFF
skip_show_database      OFF
slave_compressed_protocol       OFF
slave_ddl_exec_mode     IDEMPOTENT
slave_domain_parallel_threads   0
slave_exec_mode STRICT
slave_load_tmpdir       /tmp
slave_max_allowed_packet        1073741824
slave_net_timeout       60
slave_parallel_max_queued       131072
slave_parallel_mode     optimistic
slave_parallel_threads  0
slave_parallel_workers  0
slave_run_triggers_for_rbr      NO
slave_skip_errors       OFF
slave_sql_verify_checksum       ON
slave_transaction_retries       10
slave_transaction_retry_errors  1158,1159,1160,1161,1205,1213,1429,2013,12701
slave_transaction_retry_interval        0
slave_type_conversions
slow_launch_time        2
slow_query_log  OFF
slow_query_log_file     srv02-slow.log
socket  /run/mysqld/mysqld.sock
sort_buffer_size        2097152
sql_auto_is_null        OFF
sql_big_selects ON
sql_buffer_result       OFF
sql_if_exists   OFF
sql_log_bin     ON
sql_log_off     OFF
sql_mode        ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
sql_notes       ON
sql_quote_show_create   ON
sql_safe_updates        OFF
sql_select_limit        18446744073709551615
sql_slave_skip_counter  0
sql_warnings    OFF
ssl_ca
ssl_capath
ssl_cert
ssl_cipher
ssl_crl
ssl_crlpath
ssl_key
standard_compliant_cte  ON
storage_engine  InnoDB
stored_program_cache    256
strict_password_validation      ON
sync_binlog     0
sync_frm        ON
sync_master_info        10000
sync_relay_log  10000
sync_relay_log_info     10000
system_time_zone        EEST
system_versioning_alter_history ERROR
system_versioning_asof  DEFAULT
table_definition_cache  400
table_open_cache        2000
table_open_cache_instances      8
tcp_keepalive_interval  0
tcp_keepalive_probes    0
tcp_keepalive_time      0
tcp_nodelay     ON
thread_cache_size       151
thread_handling one-thread-per-connection
thread_pool_dedicated_listener  OFF
thread_pool_exact_stats OFF
thread_pool_idle_timeout        60
thread_pool_max_threads 65536
thread_pool_oversubscribe       3
thread_pool_prio_kickup_timer   1000
thread_pool_priority    auto
thread_pool_size        4
thread_pool_stall_limit 500
thread_stack    299008
time_format     %H:%i:%s
time_zone       SYSTEM
timestamp       1713944384.242827
tls_version     TLSv1.2,TLSv1.3
tmp_disk_table_size     18446744073709551615
tmp_memory_table_size   16777216
tmp_table_size  16777216
tmpdir  /tmp
transaction_alloc_block_size    8192
transaction_prealloc_size       4096
tx_isolation    REPEATABLE-READ
tx_read_only    OFF
unique_checks   ON
updatable_views_with_limit      YES
use_stat_tables PREFERABLY_FOR_QUERIES
userstat        OFF
version 10.6.16-MariaDB-0ubuntu0.22.04.1
version_comment Ubuntu 22.04
version_compile_machine x86_64
version_compile_os      debian-linux-gnu
version_malloc_library  system
version_source_revision
version_ssl_library     OpenSSL 3.0.2 15 Mar 2022
wait_timeout    28800
warning_count   0
wsrep_osu_method        TOI
wsrep_sr_store  table
wsrep_auto_increment_control    ON
wsrep_causal_reads      OFF
wsrep_certification_rules       strict
wsrep_certify_nonpk     ON
wsrep_cluster_address
wsrep_cluster_name      my_wsrep_cluster
wsrep_convert_lock_to_trx       OFF
wsrep_data_home_dir     /var/lib/mysql/
wsrep_dbug_option
wsrep_debug     NONE
wsrep_desync    OFF
wsrep_dirty_reads       OFF
wsrep_drupal_282555_workaround  OFF
wsrep_forced_binlog_format      NONE
wsrep_gtid_domain_id    0
wsrep_gtid_mode OFF
wsrep_gtid_seq_no       0
wsrep_ignore_apply_errors       7
wsrep_load_data_splitting       OFF
wsrep_log_conflicts     OFF
wsrep_max_ws_rows       0
wsrep_max_ws_size       2147483647
wsrep_mode
wsrep_mysql_replication_bundle  0
wsrep_node_address
wsrep_node_incoming_address     AUTO
wsrep_node_name srv02.xxx.xxx
wsrep_notify_cmd
wsrep_on        OFF
wsrep_patch_version     wsrep_26.22
wsrep_provider  none
wsrep_provider_options
wsrep_recover   OFF
wsrep_reject_queries    NONE
wsrep_replicate_myisam  OFF
wsrep_restart_slave     OFF
wsrep_retry_autocommit  1
wsrep_slave_fk_checks   ON
wsrep_slave_uk_checks   OFF
wsrep_slave_threads     1
wsrep_sst_auth
wsrep_sst_donor
wsrep_sst_donor_rejects_queries OFF
wsrep_sst_method        rsync
wsrep_sst_receive_address       AUTO
wsrep_start_position    00000000-0000-0000-0000-000000000000:-1
wsrep_strict_ddl        OFF
wsrep_sync_wait 0
wsrep_trx_fragment_size 0
wsrep_trx_fragment_unit bytes

What would be the first thing to look at for debugging this?

I'm having a similar issue as to what is described in this post which never received an answer. Essentially, I'm running bitnami and my server space is filling up over time on what is a very simple static website. I narrowed the cluprit down to the /opt/bitnami/mysql/data folder which seems to be increasing in size at a rate of about 158KB per minute (aka 230MB per day). Some potentially relevant (or irrelevant) info I noticed: Running sudo du -b yields the following > 10553149373 ./data but running ls -l yields the following > drwxr-x--- 7 mysql root 12288 Dec 25 06:25 data The size of the data folder is stationary in the case of the ls command as each time I run that I get the same output. But the du command shows that the size is growing. And note the size difference between the two (I understand that du shows allocated space and ls shows actual usage. Why would one be so much bigger than the other - and why does du show it growing while ls does not).

**Background** Two sites, both WordPress; one is public-facing, and the second is private with restrictive access. The public-facing site has a form on it, but I need to be able to access the information received from that form so that the private site can review it. The form is built through a WordPress plugin. Both databases live on the same server but are different instances and are managed through phpmyadmin. Once the business logic is handled on the form, I don't need to retain the information on the public site and prefer that it get deleted from the table. **Question** Does anyone have a recommendation on how I can share information/transfer information to the private site database without losing functionality on either site?

I have a MariaDB DB with three tables: 1. posts

ID | title         | content    | author_id | likes_count
--------------------------------------------------
1  | Abcd          | content_01 | 1         | 20
2  | BfeBB         | content_02 | 1         | 112
3  | ACFFDV        | content_03 | 3         | 0
4  | FVERVR        | content_04 | 2         | 8
5  | BGF           | content_05 | 2         | 3
6  | FGBFDG        | content_06 | 1         | 54
7  | BFD           | content_07 | 3         | 1
8  | FDBD          | content_08 | 1         | 1
9  | DFGBFG        | content_09 | 4         | 0

2. authors

ID | name          | email
----------------------------
1  | Author1       | content_01
2  | Author2       | content_02
3  | Author3       | content_03
4  | Author4       | content_04

3. comments

ID | title         | content     | post_id  | parent_comment_id
--------------------------------------------------------------
1  | Abcd          | comment_01  | 1        | NULL
2  | BfeBB         | comment_02  | 1        | 1
3  | ACFFDV        | comment_03  | 3        | 2
4  | FVERVR        | comment_04  | 2        | 1
5  | BGF           | comment_05  | 2        | NULL
6  | FGBFDG        | comment_06  | 1        | 2
7  | BFD           | comment_07  | 3        | 2
8  | FDBD          | comment_08  | 1        | 4
9  | DFGBFG        | comment_09  | 4        | NULL

Ny question is, what is the best way to get 10 posts of author #2 ordered by likes number as an array of objects where each object includes author name and an array of comments. For example, I want to get a result like this in PHP:

[
  {
    ID -> 2,
    title -> 'BfeBB',
    content -> 'content_02',
    author_id -> 1,
    likes_count -> 112,
    author_name -> Author1,
    comments -> [
                  {
                    ID -> 4,
                    title -> 'FVERVR',
                    content -> 'comment_04',
                    parent_comment_id -> 1,
                  },
                  {
                    ID -> 5,
                    title -> 'BGF',
                    content -> 'comment_05',
                    parent_comment_id -> NULL,
                  },
               ],
  },
  {
    ID -> 6,
    title -> 'FGBFDG',
    content -> 'content_06',
    author_id -> 1,
    likes_count -> 54,
    author_name -> Author1,
    comments -> []
  },
]

## UPDATE ## I have tried doing it via PHP by combining 2 MariaDB queries: 1. Get posts & author data in a LEFT JOIN statement and it worked as expected. 2. However, the second query for getting comments didn't work and returned this error Error in query (1235): This version of MariaDB doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery' because I added the LIMIt & ORDER BY in the subquery. ---------- I'm using MariaDB 10.4, PHP 8.1 and WordPress's $wpdb. Thanks in advance.

I'm not that experienced with linux or mysql so bear that in mind. I generated my website using the wordpress droplet on digital ocean and its been working fine, but today the website started saying Error establishing a database connection. So I power cycled the server and it didn't fix it. Next I went into the ssh console and used the command service mysql status It said: mysql.service - MySQL Community Server Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled) Active: deactivating (stop-sigterm) Process: 1790 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS) Main PID: 1809 (mysqld) Status: "Server startup in progress" Tasks: 25 (limit: 1131) Memory: 627.8M CGroup: /system.slice/mysql.service └─1809 /usr/sbin/mysqld Which I think means that it exited while trying to start up. The error log says: 2023-05-21T00:40:44.983416Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.33-0ubuntu0.20.04.2) (Ubuntu). 2023-05-21T00:40:45.837488Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.33-0ubuntu0.20.04.2) starting as process 3348299 2023-05-21T00:40:45.849124Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 2023-05-21T00:40:57.249705Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended. 2023-05-21T00:44:48.871761Z 4 [System] [MY-013381] [Server] Server upgrade from '80032' to '80033' started. 2023-05-21T00:49:24.748818Z 4 [ERROR] [MY-013178] [Server] Execution of server-side SQL statement 'ALTER TABLE user MODIFY ssl_type enum('','ANY','X509', 'SPECIFIED') NOT NULL; ' failed with error code = 3664, error > 2023-05-21T00:49:24.770070Z 0 [ERROR] [MY-013380] [Server] Failed to upgrade server. 2023-05-21T00:49:24.770938Z 0 [ERROR] [MY-010119] [Server] Aborting 2023-05-21T00:49:25.380870Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.33-0ubuntu0.20.04.2) (Ubuntu). 2023-05-21T00:49:26.329708Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.33-0ubuntu0.20.04.2) starting as process 3348366 2023-05-21T00:49:26.340737Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 2023-05-21T00:49:37.907861Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended. 2023-05-21T00:53:45.694567Z 4 [System] [MY-013381] [Server] Server upgrade from '80032' to '80033' started. So I assume that its trying to upgrade the server and failing every time. I tried to do it manually, but whenever I use service mysql stop. It just hangs there indefinitely. When I try to connect to the service with mysql -u root It says: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) I tried stopping the processes using: sudo pkill mysql sudo pkill mysql sudo killall mysql sudo killall mysqld But they still appear in the list when I use htop so I assume its not working. I tried using killall -9 -r "mysqld" and it may have worked. I also selected the mysql process in htop and pressed f9+enter to send the kill signal to that process. Next I used the command: ps aux | grep mysql Which returned: root 2555 0.0 0.0 8160 724 pts/1 S+ 09:57 0:00 grep --color=auto mysql Which makes me think all the mysql processes are now dead. When I try to start the service again with: sudo service mysql start --skip-grant-tables It hangs for over a minute and says: Job for mysql.service failed because the control process exited with error code. See "systemctl status mysql.service" and "journalctl -xe" for details. The /var/run/mysqld/mysqld.sock file does not exist, but /var/run/mysqld/mysqlx.sock and /var/run/mysqld/mysqlx.sock.lock does. Error log: 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.33-0ubuntu0.20.04.2) starting as process 2781 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended. 4 [System] [MY-013381] [Server] Server upgrade from '80032' to '80033' started. 4 [ERROR] [MY-013178] [Server] Execution of server-side SQL statement 'ALTER TABLE user MODIFY ssl_type enum('','ANY','X509', 'SPECIFIED') NOT NULL; ' failed with error code = 3664, error message = 'Failed to delete SDI 'mysql.user' in tablespace 'mysql'.'. 0 [ERROR] [MY-013380] [Server] Failed to upgrade server. 0 [ERROR] [MY-010119] [Server] Aborting How can I get mysql working again so my wordpress website can work?

After a migration to a new WooCommerce install, but we are experiencing very sow queries. Sometimes more than 1 minte. Currently this query is fired. This is fired in 0.7253s

EXPLAIN SELECT t.*, tt.*, tr.object_id
FROM btwc_terms AS t
INNER JOIN btwc_term_taxonomy AS tt
ON t.term_id = tt.term_id
INNER JOIN btwc_term_relationships AS tr
ON tr.term_taxonomy_id = tt.term_taxonomy_id
WHERE tt.taxonomy IN ('pwb-brand', 'product_type', 'product_visibility', 'product_cat', 'product_tag', 'product_shipping_class', 'pa_aangeraden-bedekking', 'pa_aantal-m2', 'pa_aantal-vakken-horizontaal', 'pa_aantal-vakken-verticaal', 'pa_accu-type', 'pa_accucapaciteit', 'pa_accuspanning', 'pa_achterkant', 'pa_afhalen', 'pa_afmeting', 'pa_afmeting-cm', 'pa_afwerking', 'pa_andere-namen', 'pa_anti-torsion', 'pa_antibacterieele-binnenvoerin', 'pa_antiperforatie', 'pa_antistatisch', 'pa_aswaarde', 'pa_behandeling', 'pa_bestandsdelen', 'pa_brandstof', 'pa_breedte', 'pa_breedte-achterzijde', 'pa_custom-html', 'pa_custom-stock-message', 'pa_diameter', 'pa_diepte', 'pa_draaggewicht', 'pa_eigenschappen', 'pa_elektrische-geleidbaarheid-e', 'pa_exclude-for-beslist', 'pa_extra-opties', 'pa_formaat-bodembedekker', 'pa_formaat-verpakking-lxbxh', 'pa_geslacht', 'pa_gestapeld', 'pa_gewicht', 'pa_google-gtin-aanwezig', 'pa_hoogte', 'pa_houtsoort', 'pa_inhoud', 'pa_inhoud-liters', 'pa_kabellengte', 'pa_keurmerk', 'pa_kies-uw-maat', 'pa_kies-uw-schoenmaat', 'pa_kleur', 'pa_kniptype', 'pa_korting-tekst', 'pa_kortingsfactor-10-staffelfac', 'pa_kwaliteit', 'pa_land-van-herkomst', 'pa_lengte', 'pa_lengte-buitenmaat', 'pa_lengte-links-buitenmaat', 'pa_lengte-rechts-buitenmaat', 'pa_levensduur', 'pa_leverancier', 'pa_levering', 'pa_levertijd', 'pa_maat', 'pa_marge-per-stap-marge-10', 'pa_materiaal', 'pa_meslengte', 'pa_nen-en-11772018', 'pa_oplaadtijd', 'pa_opvangbak-inhoud', 'pa_order-processing-time', 'pa_ovengedroogd', 'pa_ph-water-zone', 'pa_plaatdikte', 'pa_pre-order-text', 'pa_prijs-arbeidsloon', 'pa_prijs-excl-btw', 'pa_prijs-halve-vracht', 'pa_prijs-pallet', 'pa_prijs-per-kg', 'pa_prijs-transport-naar-winsum', 'pa_prijs-transportkosten-naar-k', 'pa_prijs-verpakking', 'pa_product-label', 'pa_productieprijs', 'pa_search-weight', 'pa_shipping-group', 'pa_shock-absorberend', 'pa_snijbreedte', 'pa_snijhoogte', 'pa_soort-laars', 'pa_soort-zool', 'pa_staffelfactor', 'pa_stamomtrek', 'pa_steel', 'pa_te-berekenen-productmarge', 'pa_toepassing', 'pa_type-houtpellets', 'pa_type-neus', 'pa_type-verpakking', 'pa_typenummer', 'pa_vanafprijs', 'pa_veiligheidsklasse', 'pa_vermogen', 'pa_verzenddatum-verbergen', 'pa_verzendeenheid', 'pa_verzendkosten', 'pa_verzendwijze', 'pa_vloeistof-dicht', 'pa_vochtpercentage-hout', 'pa_voeding', 'pa_voedingsstoffen', 'pa_voor-het-laatst-besteld', 'pa_voor-het-laatst-gecontroleer', 'pa_voorzien-van-reflecterende-e', 'pa_warehouse', 'pa_warmtewaarde', 'pa_werktijd', 'pa_wielen', 'pa_zitdiepte', 'pa_zithoogte')
AND tr.object_id IN (85865, 86033, 88961, 89108, 89585, 89602, 89638, 89657, 89688, 89767, 89813, 89832, 89846, 89869, 89903, 89940, 89996, 90034, 93044, 93056, 93070, 93084, 93115, 93127, 93141, 93153, 93278, 93329, 93341, 93427, 93667, 93693, 93712, 93731, 93966, 93981, 94022, 94051, 114762, 115589)
ORDER BY t.name ASC

And this is the trackback

require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('/plugins/woocommerce/templates/single-product.php'), wc_get_template_part, load_template, require('/plugins/woocommerce/templates/content-single-product.php'), do_action('woocommerce_after_single_product_summary'), WP_Hook->do_action, WP_Hook->apply_filters, woocommerce_output_related_products, woocommerce_related_products, array_map, wc_get_product, WC_Product_Factory->get_product, WC_Product->__construct, WC_Data_Store->read, WC_Product_Data_Store_CPT->read, WC_Product_Variable_Data_Store_CPT->read_attributes, wc_get_object_terms, get_the_terms, wp_get_object_terms, get_terms, WP_Term_Query->query, WP_Term_Query->get_terms

These are the EXPLAIN results

1	SIMPLE	t	ALL	PRIMARY	NULL	NULL	NULL	1	Using temporary; Using filesort	
1	SIMPLE	tt	ALL	PRIMARY,term_id_taxonomy,taxonomy	NULL	NULL	NULL	1	Using where; Using join buffer (flat, BNL join)	
1	SIMPLE	tr	range	PRIMARY,term_taxonomy_id	PRIMARY	8	NULL	1	Using where; Using index; Using join buffer (incre...

Quick summary. Wordpress community website, large userbase. Has caching for guests (WP Super Cache). Always operates around load of 1-2, or 5-6 at peak hours CPU. As of 4pm EST on Feb 15, the CPU load shot to 10 and ever since then has had a "resting" load of 7-8 and is at extreme levels during the day usually 12. **What was tried:** - Many reboots, it goes right back up to 12. - Blanked out the website for users, guests were served cache. Load stayed at 8 (weird?...) - Slow query log is useless, logging many non-normally-slow queries because entire server is slow. Here is a typical htop snapshot: The moment it happened: No plugin/code changes...Why? --- I sort of feel it's not just slow plugins/frontend queries and such, due to how it immediately jumps to 12 on reboot and how even with the site blanked out (not calling up posts, comments, sidebars, etc) it was still at a very high load. How can I determine what's going on?