This blog is about a very odd case of a Federated table error causing unable reach the remote MySQL server and causing to error. I’ll share the approach I tool to diagnose and resolve the issue.<\/p>\n\n\n\n
The Percona Server instance reported a replication error 1296 that was related to a Federated table, indicating a connection problem.
Here’s the error message:<\/p>\n\n\n\n
Last_SQL_Errno: 1296
Last_SQL_Error: Could not execute Write_rows event on table mysql_federated_db.federated_table_test; Got error 10000 'Error on remote system: 0: ' from FEDERATED, Error_code: 1296; handler error No Error!; the event's master log mysql-bin.000012, end_log_pos 26421<\/code><\/pre>\n\n\n\nError on remote system: 0<\/h2>\n\n\n\n
This error is replication error noting it failing to write “Could not execute Write_rows event” though the underlying error says “Got error 10000 ‘Error on remote system: 0: ‘ from FEDERATED”. The error denotes an error on Federated table suggesting that it is not able to reach!<\/p>\n\n\n\n
Investigation<\/h2>\n\n\n\n
I manually tried connecting and it worked:<\/p>\n\n\n\n
Reviewing mysql.servers table to check the configuration.\nmysql> select * from mysql.servers;\n+-------------------+--------------+---------------------+----------+----------+------+--------+---------+-------+\n| Server_name | Host | Db | Username | Password | Port | Socket | Wrapper | Owner |\n+-------------------+--------------+---------------------+----------+----------+------+--------+---------+-------+\n| ServerB | 192.168.0.10 | mysql_federated_db | usr | X | 3306 | | mysql | |\n+-------------------+--------------+---------------------+----------+----------+------+--------+---------+-------+<\/code><\/pre>\n\n\n\nTrying to connect remote server using above configured credentials:<\/p>\n\n\n\n
kedar@centos: ~ $ mysql -h192.168.0.10 -P3301 mysql_federated_db -p -uusr
\u2026
mysql> \\u mysql_federated_db
Database changed
mysql> select * from federated_table_test limit 1;
+---------+-------------+-----------------------------------+
| id | error | val |
+---------+-------------+-----------------------------------+
| 8582 | 1296 | MySQL Federated Table Error |
+---------+-------------+-----------------------------------+
1 row in set (0.00 sec)<\/code><\/pre>\n\n\n\nTried reviewing connectivity information, grants and max_connect_errors though that wasn’t an issue as and there were no hints regard such things in error log!
Also noted there are two tables in the database and querying second database works but first doesn’t.<\/p>\n\n\n\n
If you see below the exact error “ERROR 1430 (HY000): : 0 :<\/strong>” noted in replication shows up when manually executing:<\/p>\n\n\n\nmysql> use mysql_federated_db\n...\nmysql mysql_federated_db> show create table federated_table_test_OK\\G\n*************************** 1. row ***************************\n Table: federated_table_test_OK\nCreate Table: CREATE TABLE `federated_table_test_OK` (\n `id` int(11) NOT NULL AUTO_INCREMENT,\n `error` int(11) NOT NULL DEFAULT '0',\n `val` int(11) NOT NULL,\n PRIMARY KEY (`id`)\n) ENGINE=FEDERATED DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci CONNECTION='ServerB\/federated_table_test_OK'\n1 row in set (0.00 sec)\n\nmysql mysql_federated_db> select * from federated_table_test_OK limit 1;\n+---------+--------+---------------------------+\n| id | error | val |\n+---------+--------+---------------------------+\n| 1 | 1 | No Database Errors |\n+---------+--------+---------------------------+\n1 row in set (0.00 sec)\n\ncentos mysql_federated_db> select * from mysql_federated_db.federated_table_test limit 1;\nERROR 1430 (HY000): : 0 :<\/strong>\n<\/code><\/pre>\n\n\n\nI decided to try creating a new table with same definition to see if it can fetch the data as<\/p>\n\n\n\n
\n- connection to the remote server works<\/li>\n\n\n\n
- table is present on remote server<\/li>\n<\/ol>\n\n\n\n
centos mysql_federated_db> set sql_log_bin=0;\nQuery OK, 0 rows affected (0.00 sec)\n\ncentos mysql_federated_db> CREATE TABLE if not exists `_fed_test` (\n -> `id` int(11) NOT NULL AUTO_INCREMENT,\n -> `error` int(11) NOT NULL DEFAULT '0',\n -> `val` int(11) NOT NULL,\n -> PRIMARY KEY (`id`)\n -> ) ENGINE=FEDERATED DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci CONNECTION='ServerB\/federated_table_test';\nQuery OK, 0 rows affected (0.00 sec)\n\ncentos mysql_federated_db> select * from _fed_test limit 1;\n+---------+-------------+-----------------------------------+\n| id | error | val |\n+---------+-------------+-----------------------------------+\n| 8582 | 1296 | MySQL Federated Table Error |\n+---------+-------------+-----------------------------------+\n1 row in set (0.22 sec)<\/code><\/pre>\n\n\n\nWow!! The new table worked but the old didn’t! Something’s wrong with the table in the memory and hence I decided to “flush table”.<\/p>\n\n\n\n
centos mysql_federated_db> FLUSH TABLE federated_table_test;\n...\ncentos mysql_federated_db> select * from federated_table_test limit 1;\n+---------+-------------+-----------------------------------+\n| id | error | val |\n+---------+-------------+-----------------------------------+\n| 8582 | 1296 | MySQL Federated Table Error |\n+---------+-------------+-----------------------------------+<\/code><\/pre>\n\n\n\nWell, so I hit “START REPLICA” and replication caught-up in few mins. This looks like a bug but I couldn’t reproduce this yet and I welcome you to share with me if you already know the history.<\/p>\n\n\n\n
TL;DR<\/h2>\n\n\n\n
When “Error on remote system: 0:” for federated table, try FLUSH TABLE.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"This blog is about a very odd case of a Federated table error causing unable reach the remote MySQL server and causing to error. I’ll share the approach I tool…\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[869,8,377],"tags":[663,661,662,664,615],"class_list":{"0":"post-2975","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-mariadb","7":"category-mysql","8":"category-mysql-articles","9":"tag-error-1430-hy000-0","10":"tag-federated-table","11":"tag-flush-tables","12":"tag-mysql-replication-error","13":"tag-percona-server"},"aioseo_notices":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/posts\/2975","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/comments?post=2975"}],"version-history":[{"count":2,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/posts\/2975\/revisions"}],"predecessor-version":[{"id":2977,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/posts\/2975\/revisions\/2977"}],"wp:attachment":[{"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/media?parent=2975"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/categories?post=2975"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/tags?post=2975"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}