Plugin feedback is disabled как исправить

I installed MariaDB 10.2.10 on CentOS 7 but it stopped running. If I do:

If I do:

systemctl restart mariadb.service

I get:

mariadb.service: main process exited, code=killed, status=6/ABRT
Failed to start MariaDB 10.2.12 database server.
Unit mariadb.service entered failed state.

What’s weird is that it was running fine for more than a year and now suddenly, it won’t start. It’s a production server, so I have several databases there that I need; I can’t just reinstall it from scratch.

What can I do to get MariaDB back up and running without losing my databases?

/var/log/messages

systemd: mariadb.service: main process exited, code=killed, status=6/ABRT
Asystemd: Failed to start MariaDB 10.2.12 database server.
Asystemd: Unit mariadb.service entered failed state.
Asystemd: mariadb.service failed.
systemd: mariadb.service holdoff time over, scheduling restart.
systemd: Starting MariaDB 10.2.12 database server...
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] /usr/sbin/mysqld (mysqld 10.2.12-MariaDB) starting as process 24976 ...
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] InnoDB: Uses event mutexes
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] InnoDB: Compressed tables use zlib 1.2.7
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] InnoDB: Using Linux native AIO
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] InnoDB: Number of pools: 1
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] InnoDB: Using SSE2 crc32 instructions
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] InnoDB: Completed initialization of buffer pool
mysqld: 2018-04-24  7:06:38 140100781233920 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] InnoDB: Log sequence number at the start 1597389266 and the end 1597386521 do not match
mysqld: 2018-04-24  7:06:38 140101542774912 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace innodb_system page [page id: space=0, page number=5]. You may have to recover from a backup.
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] InnoDB: Uncompressed page, stored checksum in field1 2317626450, calculated checksums for field1: crc32 2317626450/1916606668, innodb 3858799490,  page type 7 == TRX_SYS.none 3735928559, stored checksum in field2 960005681, calculated checksums for field2: crc32 2317626450/1916606668, innodb 756644076, none 3735928559,  page LSN 0 1597389266, low 4 bytes of LSN at page end 1597386521, page number (if stored to page already) 5, space id (if created with >= MySQL-4.1.1 and stored already) 0
mysqld: InnoDB: Page may be a transaction system page
mysqld: 2018-04-24  7:06:38 140101542774912 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
mysqld: 2018-04-24  7:06:38 140101542774912 [ERROR] [FATAL] InnoDB: Aborting because of a corrupt database page.
mysqld: 180424  7:06:38 [ERROR] mysqld got signal 6 ;
mysqld: This could be because you hit a bug. It is also possible that this binary
mysqld: or one of the libraries it was linked against is corrupt, improperly built,
mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.
mysqld: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
mysqld: We will try our best to scrape up some info that will hopefully help
mysqld: diagnose the problem, but since we have already crashed,
mysqld: something is definitely wrong and this may fail.
mysqld: Server version: 10.2.12-MariaDB
mysqld: key_buffer_size=134217728
mysqld: read_buffer_size=131072
mysqld: max_used_connections=0
mysqld: max_threads=153
mysqld: thread_count=0
mysqld: It is possible that mysqld could use up to
mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467244 K  bytes of memory
mysqld: Hope that's ok; if not, decrease some variables in the equation.
mysqld: Thread pointer: 0x0
mysqld: Attempting backtrace. You can use the following information to find out
mysqld: where mysqld died. If you see no messages after this, something went
mysqld: terribly wrong...
mysqld: stack_bottom = 0x0 thread_stack 0x49000
mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x557c611fdc4e]
mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x355)[0x557c60c88825]
mysqld: /lib64/libpthread.so.0(+0xf5e0)[0x7f6bee7195e0]
mysqld: /lib64/libc.so.6(gsignal+0x37)[0x7f6becc261f7]
mysqld: /lib64/libc.so.6(abort+0x148)[0x7f6becc278e8]
mysqld: /usr/sbin/mysqld(+0x9a5643)[0x557c60fc2643]
mysqld: /usr/sbin/mysqld(+0x9e7289)[0x557c61004289]
mysqld: /usr/sbin/mysqld(+0xa0adfa)[0x557c61027dfa]
mysqld: /usr/sbin/mysqld(+0x9e8986)[0x557c61005986]
mysqld: /usr/sbin/mysqld(+0x9888af)[0x557c60fa58af]
mysqld: /usr/sbin/mysqld(+0x9575ab)[0x557c60f745ab]
mysqld: mysys/stacktrace.c:268(my_print_stacktrace)[0x557c60f76d87]
mysqld: buf/buf0buf.cc:6026(buf_page_io_complete(buf_page_t*, bool))[0x557c60e62cf9]
mysqld: buf/buf0rea.cc:227(buf_read_page(page_id_t const&, page_size_t const&))[0x557c60c8ace4]
mysqld: srv/srv0start.cc:896(srv_undo_tablespaces_init(bool))[0x557c60b0b3c0]
mysqld: /usr/sbin/mysqld(_Z11plugin_initPiPPci+0x9a2)[0x557c60b0cc72]
mysqld: handler/ha_innodb.cc:4381(innobase_init(void*))[0x557c60a66be8]
mysqld: sql/handler.cc:520(ha_initialize_handlerton(st_plugin_int*))[0x557c60a6b2d1]
mysqld: sql/sql_plugin.cc:1411(plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool))[0x7f6becc12c05]
mysqld: sql/mysqld.cc:5258(init_server_components())[0x557c60a5f51d]
mysqld: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
mysqld: information that should help you find out what is causing the crash.
systemd: mariadb.service: main process exited, code=killed, status=6/ABRT
systemd: Failed to start MariaDB 10.2.12 database server.
systemd: Unit mariadb.service entered failed state.
systemd: mariadb.service failed.

The feedback plugin is designed to collect and, optionally, upload
configuration and usage information to MariaDB.org or to any other configured URL.

See the MariaDB User Feedback page on MariaDB.org to see collected MariaDB usage statistics.

The feedback plugin exists in all MariaDB versions.

MariaDB is distributed with this plugin included, but it is not enabled by default.
On Windows, this plugin is part of the server and has a special checkbox in the installer window. Either
way, you need to explicitly install and enable it in order for feedback data to be sent.

Installing the Plugin

Although the plugin’s shared library is distributed with MariaDB by default, the plugin is not actually installed by MariaDB by default. There are two methods that can be used to install the plugin with MariaDB.

The first method can be used to install the plugin without restarting the server. You can install the plugin dynamically by executing INSTALL SONAME or INSTALL PLUGIN. For example:

INSTALL SONAME 'feedback';

The second method can be used to tell the server to load the plugin when it starts up. The plugin can be installed this way by providing the --plugin-load or the --plugin-load-add options. This can be specified as a command-line argument to mysqld or it can be specified in a relevant server option group in an option file. For example:

[mariadb]
...
plugin_load_add = feedback

Uninstalling the Plugin

You can uninstall the plugin dynamically by executing UNINSTALL SONAME or UNINSTALL PLUGIN. For example:

UNINSTALL SONAME 'feedback';

If you installed the plugin by providing the --plugin-load or the --plugin-load-add options in a relevant server option group in an option file, then those options should be removed to prevent the plugin from being loaded the next time the server is restarted.

Enabling the Plugin

You can enable the plugin by setting the feedback option to ON in a relevant server option group in an option file. For example:

[mariadb]
...
feedback=ON

In Windows, the plugin can also be enabled during a new MSI installation. The MSI GUI installation provides the «Enable feedback plugin» checkbox to enable the plugin. The MSI command-line installation provides the FEEDBACK=1 command-line option to enable the plugin.

See the next section for how to verify the plugin is installed and active and (if needed) install the plugin.

Verifying the Plugin’s Status

To verify whether the feedback plugin is installed and enabled, execute the
SHOW PLUGINS statement or query the information_schema.plugins table. For example:

SELECT plugin_status FROM information_schema.plugins 
  WHERE plugin_name = 'feedback';

If that SELECT returns no rows, then you still need to install the plugin.

When the plugin is installed and enabled, you will see:

SELECT plugin_status FROM information_schema.plugins 
  WHERE plugin_name = 'feedback';
+---------------+
| plugin_status |
+---------------+
| ACTIVE        |
+---------------+

If you see DISABLED instead of ACTIVE, then you still need to enable the plugin.

Collecting Data

The feedback plugin will collect:

• Certain rows from SHOW STATUS and SHOW VARIABLES.
• All installed plugins and their versions.
• System information such as CPU count, memory, architecture, and OS/linux distribution.
• The feedback_server_uid, which is a SHA1 hash of the MAC address of the first network interface and the TCP port that the server listens on.

The feedback plugin creates the FEEDBACK table in the INFORMATION_SCHEMA database. To see the data that has been collected by the plugin, you can execute:

SELECT * FROM information_schema.feedback;

Only the contents of this table are sent to the feedback_url.

MariaDB stores collation usage statistics. Each collation that has been used by the server
will have a record in «SELECT * FROM information_schema.feedback» output, for example:

+----------------------------------------+---------------------+
| VARIABLE_NAME                          | VARIABLE_VALUE      |
+----------------------------------------+---------------------+
| Collation used utf8_unicode_ci         | 10                  |
| Collation used latin1_general_ci       | 20                  |
+----------------------------------------+---------------------+

Collations that have not been used will not be included into the result.

Sending Data

The feedback plugin sends the data using a POST request to any URL or a list of URLs
that you specify by setting the feedback_url system variable. By default, this is set to the following URL:

• https://mariadb.org/feedback_plugin/post

Both HTTP and HTTPS protocols are supported.

If HTTP traffic requires a proxy in your environment, then you can specify the proxy by setting the feedback_http_proxy system variable.

If the feedback_url system variable is not set to an empty string, then the
plugin will automatically send a report to all URLs in the list a few minutes after the server starts up and then once a week after that.

If the feedback_url system variable is set to an empty string, then the
plugin will not automatically send any data. This may be necessary if outbound HTTP communication from your database server is not permitted. In this case, you can still upload the data manually, if you’d like.

First, generate the report file with the MariaDB command-line mariadb client:

$ mariadb -e 'select * from information_schema.feedback' > report.txt

Then you can upload the generated report.txt here using your web browser.

Or you can do it from the command line with tools such as curl. For example:

$ curl -F data=@report.txt https://mariadb.org/feedback_plugin/post

Manual uploading allows you to be absolutely sure that we receive only the data shown in the INFORMATION_SCHEMA.FEEDBACK table and that no private or sensitive information is being sent.

Versions

System Variables

feedback_http_proxy

• Description: Proxy server for use when http calls cannot be made, such as in a firewall environment. The format is host:port.
• Commandline: --feedback-http=proxy=value
• Read-only: Yes
• Data Type: string
• Default Value: '' (empty)

feedback_send_retry_wait

• Description: Time in seconds before retrying if the plugin failed to send the data for any reason.
• Commandline: --feedback-send-retry-wait=#
• Scope: Global
• Dynamic: Yes
• Data Type: numeric
• Default Value: 60
• Valid Values: 1 to 86400

feedback_send_timeout

• Description: An attempt to send the data times out and fails after this many seconds.
• Commandline: --feedback-send-timeout=#
• Scope: Global
• Dynamic: Yes
• Data Type: numeric
• Default Value: 60
• Valid Values: 1 to 86400

feedback_server_uid

• Description: Automatically calculated server unique id hash.
• Scope: Global
• Dynamic: No
• Data Type: string

feedback_url

• Description: URL to which the data is sent. More than one URL, separated by spaces, can be specified. Set it to an empty string to disable data sending.
• Commandline: --feedback-url=url
• Scope: Global
• Dynamic: No
• Data Type: string
• Default Value: https://mariadb.org/feedback_plugin/post

feedback_user_info

• Description: The value of this option is not used by the plugin, but it is included in the feedback data. It can be used to add any user-specified string to the report. This could be used to help to identify it. For example, a support contract number, or a computer name (if you collect reports internally by specifying your own feedback-url).
• Commandline: --feedback-user-info=string
• Scope: Global
• Dynamic: No
• Data Type: string
• Default Value: Empty string

Options

feedback

• Description: Controls how the server should treat the plugin when the server starts up.
  • Valid values are:
    • OFF — Disables the plugin without removing it from the mysql.plugins table.
    • ON — Enables the plugin. If the plugin cannot be initialized, then the server will still continue starting up, but the plugin will be disabled.
    • FORCE — Enables the plugin. If the plugin cannot be initialized, then the server will fail to start with an error.
    • FORCE_PLUS_PERMANENT — Enables the plugin. If the plugin cannot be initialized, then the server will fail to start with an error. In addition, the plugin cannot be uninstalled with UNINSTALL SONAME or UNINSTALL PLUGIN while the server is running.
  • See Plugin Overview: Configuring Plugin Activation at Server Startup for more information.
• Commandline: --feedback=value
• Data Type: enumerated
• Default Value: ON
• Valid Values: OFF, ON, FORCE, FORCE_PLUS_PERMANENT

The InnoDB memory heap is disabled or Plugin ‘FEEDBACK’ is disabled

Error:
The InnoDB memory heap is disabled
 Solved:
 Add "innodb_use_sys_malloc = 1" under [mysqld], that is, use the system to automatically allocate memory.

 Error:
Plugin 'FEEDBACK' is disabled
 Solved:
 Add "feedback=ON" under [mysqld] to open it.



[mysqld]
innodb_use_sys_malloc = 1
feedback=ON

Intelligent Recommendation

More Recommendation

Start MySQL after installing XAMPP, find that the startup failed does not have any prompts, by viewing the mysql_error log, description:

2021-08-11 18:56:53 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2021-08-11 18:56:53 0 [Note] InnoDB: Uses event mutexes
2021-08-11 18:56:53 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-08-11 18:56:53 0 [Note] InnoDB: Number of pools: 1
2021-08-11 18:56:53 0 [Note] InnoDB: Using SSE2 crc32 instructions
2021-08-11 18:56:53 0 [Note] InnoDB: Initializing buffer pool, total size = 16M, instances = 1, chunk size = 16M
2021-08-11 18:56:53 0 [Note] InnoDB: Completed initialization of buffer pool
2021-08-11 18:56:53 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2021-08-11 18:56:53 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2021-08-11 18:56:53 0 [Note] InnoDB: Setting file 'E:xamppmysqldataibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2021-08-11 18:56:53 0 [Note] InnoDB: File 'E:xamppmysqldataibtmp1' size is now 12 MB.
2021-08-11 18:56:53 0 [Note] InnoDB: Waiting for purge to start
2021-08-11 18:56:53 0 [Note] InnoDB: 10.4.20 started; log sequence number 300369; transaction id 170
2021-08-11 18:56:53 0 [Note] InnoDB: Loading buffer pool(s) from E:xamppmysqldataib_buffer_pool
2021-08-11 18:56:53 0 [Note] Plugin 'FEEDBACK' is disabled.
2021-08-11 18:56:53 0 [Note] Server socket created on IP: '::'.

Solution:
will /xampp/mysql/backup/All files are copied and overwritten/xampp/mysql/data/All files, restart XAMPP, start mysql, success!