We have a 3 node percona xtradb cluster and two slaves attached to it. One of the slaves we want to use it for taking backups. We have GTID based replication setup between the slave and the Xtradb cluster. My question is if we are adding a new node to the xtradb cluster can we use the backups from the slave and restore on the new node. Also would we be able to avoid SST and do IST instead. I am not sure how that part works since the backups are from a slave. Any help will be appreciated.

I'm running a Percona-Server instance off an Ubuntu server install. I'm using an application that needs to access this database, and its having VERY poor performance. Once the database has been established, the application goes in (upon install) and creates the schema. It defaults everything to MyISAM, however I have converted the table engines back to InnoDB. The issue that I'm having is VERY poor insert performance. This application is very write-heavy, and it seems as though its writing each row 1 at a time to disk, not using any sort of buffers, however I'm unsure how to check or verify this. Even a select(*) from one of the tables will take 2.4 seconds, and there is only 163,000 rows. I'm kind of at a loss as to what else I can do. Server has 8GB of ram, and CPU is almost entirely idle while this is occurring. my.cnf: [mysql] # CLIENT # port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld] # GENERAL # user = mysql default_storage_engine = InnoDB socket = /var/run/mysqld/mysqld.sock pid_file = /var/run/mysqld/mysqld.pid # MyISAM # key_buffer_size = 32M myisam_recover = FORCE,BACKUP # SAFETY # max_allowed_packet = 16M max_connect_errors = 1000000 skip_name_resolve sql_mode = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY sysdate_is_now = 1 innodb = FORCE innodb_strict_mode = 1 # DATA STORAGE # datadir = /mnt/Storage/mysql/ # BINARY LOGGING # log_bin = /mnt/Storage/mysql/mysql-bin expire_logs_days = 14 sync_binlog = 1 # CACHES AND LIMITS # tmp_table_size = 32M max_heap_table_size = 32M query_cache_type = 0 query_cache_size = 0 max_connections = 500 thread_cache_size = 50 open_files_limit = 65535 table_definition_cache = 1024 table_open_cache = 2048 # INNODB # innodb_flush_method = O_DIRECT innodb_log_files_in_group = 2 innodb_log_file_size = 512M innodb_flush_log_at_trx_commit = 0 innodb_file_per_table = 1 innodb_buffer_pool_size = 6144M innodb_buffer_pool_instances = 1 innodb_read_io_threads = 64 innodb_write_io_threads = 64 innodb_io_capacity = 10000 # LOGGING # log_error = /mnt/Storage/mysql/mysql-error.log log_queries_not_using_indexes = 1 slow_query_log = 1 slow_query_log_file = /mnt/Storage/mysql/mysql-slow.log desc of one table that is having poor insert performance: mysql> desc parts; +------------+---------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+---------------------+------+-----+---------+----------------+ | ID | bigint(20) unsigned | NO | PRI | NULL | auto_increment | | binaryID | int(11) unsigned | NO | MUL | 0 | | | messageID | varchar(255) | NO | | | | | number | bigint(20) unsigned | NO | MUL | 0 | | | partnumber | int(10) unsigned | NO | | 0 | | | size | bigint(20) unsigned | NO | | 0 | | | dateadded | datetime | YES | MUL | NULL | | +------------+---------------------+------+-----+---------+----------------+ 7 rows in set (0.00 sec)

**Can we create a table in MariaDB 10.2 with XtraDB engine?** I have installed MariaDB **10.2** and I am trying to create a table with storage engine XtraDB and I am getting error *mysql> CREATE TABLE T1(ID smallint(6),NAME varchar(30)) ENGINE=XtraDB; *ERROR 1286 (42000): **Unknown storage engine** 'XtraDB'* If I lists the engines of MariaDB here, there are no XtraDB engine type available. Part of show engines output:

I'm trying to understand why Percona and xtradb InnoDB/MySQL behaves the way it does and if there's anything I can change in the configuration to fix it. I've a InnoDB database with only one table with about 10 rows. ID INT(11) UNSIGNED NOT NULL AUTO_INCREMENT, randomnumber INT(11) NULL DEFAULT NULL, PRIMARY KEY (ID) When I insert a single row, about 1-2 seconds after commit the mysql process causes 30-40% CPU usage for about one second. INSERT INTO status.statustest (randomnumber) VALUES ('1111111'); But when inserting one row every 500ms for 10 seconds (so in total 20 rows), the CPU spikes only after the last commit. I found a similar question , but there was no answer to it: I see this behaviour only with Percona and XtraDB, not with MariaDB. My system:
2GB RAM
2CPU Cores
20GB SSD
Debian 9.9 x64
mysqld Ver 5.7.26-29 for debian-linux-gnu on x86_64 (Percona Server (GPL), Release '29', Revision '11ad961') Has anyone found a solution as how to get rid of those CPU spikes and what causes them?

Title says it all. However i have to enter at least 30 characters.

I have three nodes that I want to setup into a Percona XtraDB Cluster (PXC). I have bootstrapped the first node and joined the second node, but cannot somehow join the third node. All configuration is the same as I just did copy and paste: [mysqld] # Galera wsrep_cluster_address = gcomm://10.1.5.100,10.1.5.101,10.1.5.102 wsrep_cluster_name = db-test wsrep_provider = /usr/lib/libgalera_smm.so wsrep_provider=/usr/lib64/galera3/libgalera_smm.so wsrep_provider_options = "gcache.size=256M" wsrep_slave_threads = 16 # 2~3 times with CPU wsrep_sst_auth = "sstuser:sstPwd#123" wsrep_sst_method = xtrabackup-v2 I am running the nodes on CentOS 7.x. Below is the status of the two PXC nodes already up and running: | wsrep_ist_receive_seqno_end | 0 | | wsrep_incoming_addresses | 10.1.5.100:3306,10.1.5.101:3306 | | wsrep_cluster_weight | 2 | | wsrep_desync_count | 0 | | wsrep_evs_delayed | | | wsrep_evs_evict_list | | | wsrep_evs_repl_latency | 0/0/0/0/0 | | wsrep_evs_state | OPERATIONAL | | wsrep_gcomm_uuid | 8d59ca0f-cd35-11e8-863c-d79869fa6d80 | | wsrep_cluster_conf_id | 4 | | wsrep_cluster_size | 2 | | wsrep_cluster_state_uuid | ac97f711-cad5-11e8-8f39-be9d0594cdb9 | | wsrep_cluster_status | Primary | | wsrep_connected | ON | | wsrep_local_bf_aborts | 0 | | wsrep_local_index | 0 | | wsrep_provider_name | Galera | | wsrep_provider_vendor | Codership Oy | | wsrep_provider_version | 3.31(rf216443) | | wsrep_ready | ON | +----------------------------------+-----------------------------------------+ 71 rows in set (0.01 sec) Below is the error from the error log of the third node failing to join: backup-v2|10.1.5.102:4444/xtrabackup_sst//1 2018-10-11T09:20:03.278884-00:00 2 [Note] WSREP: Auto Increment Offset/Increment re-align with cluster membership change (Offset: 1 -> 2) (Increment: 1 -> 3) 2018-10-11T09:20:03.278997-00:00 2 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 2018-10-11T09:20:03.279155-00:00 2 [Note] WSREP: Assign initial position for certification: 69, protocol version: 4 2018-10-11T09:20:03.279626-00:00 0 [Note] WSREP: Service thread queue flushed. 2018-10-11T09:20:03.280052-00:00 2 [Note] WSREP: Check if state gap can be serviced using IST 2018-10-11T09:20:03.280145-00:00 2 [Note] WSREP: Local state seqno is undefined (-1) 2018-10-11T09:20:03.280445-00:00 2 [Note] WSREP: State gap can't be serviced using IST. Switching to SST 2018-10-11T09:20:03.280510-00:00 2 [Note] WSREP: Failed to prepare for incremental state transfer: Local state seqno is undefined: 1 (Operation not permitted) at galera/src/replicator_str.cpp:prepare_for_IST():549. IST will be unavailable. 2018-10-11T09:20:03.287673-00:00 0 [Note] WSREP: Member 1.0 (db-test-3.pd.local) requested state transfer from '*any*'. Selected 0.0 (db-test-2.pd.local)(SYNCED) as donor. 2018-10-11T09:20:03.287850-00:00 0 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 69) 2018-10-11T09:20:03.288073-00:00 2 [Note] WSREP: Requesting state transfer: success, donor: 0 2018-10-11T09:20:03.288225-00:00 2 [Note] WSREP: GCache history reset: ac97f711-cad5-11e8-8f39-be9d0594cdb9:0 -> ac97f711-cad5-11e8-8f39-be9d0594cdb9:69 2018-10-11T09:20:38.988120-00:00 0 [Warning] WSREP: 0.0 (db-test-2.pd.local): State transfer to 1.0 (db-test-3.pd.local) failed: -32 (Broken pipe) 2018-10-11T09:20:38.988274-00:00 0 [ERROR] WSREP: gcs/src/gcs_group.cpp:gcs_group_handle_join_msg():766: Will never receive state. Need to abort. 2018-10-11T09:20:38.988366-00:00 0 [Note] WSREP: gcomm: terminating thread 2018-10-11T09:20:38.988493-00:00 0 [Note] WSREP: gcomm: joining thread 2018-10-11T09:20:38.988942-00:00 0 [Note] WSREP: gcomm: closing backend 2018-10-11T09:20:38.995070-00:00 0 [Note] WSREP: Current view of cluster as seen by this node view (view_id(NON_PRIM,8d59ca0f,3) memb { d3167260,0 } joined { } left { } partitioned { 8d59ca0f,0 e3def063,0 } ) 2018-10-11T09:20:38.995334-00:00 0 [Note] WSREP: Current view of cluster as seen by this node view ((empty)) 2018-10-11T09:20:38.996612-00:00 0 [Note] WSREP: gcomm: closed 2018-10-11T09:20:38.996837-00:00 0 [Note] WSREP: /usr/sbin/mysqld: Terminated. Terminated 2018-10-11T09:20:47.767946+00:00 WSREP_SST: [ERROR] Removing /var/lib/mysql//xtrabackup_galera_info file due to signal 2018-10-11T09:20:47.788109+00:00 WSREP_SST: [ERROR] Removing file due to signal 2018-10-11T09:20:47.808425+00:00 WSREP_SST: [ERROR] ******************* FATAL ERROR ********************** 2018-10-11T09:20:47.818240+00:00 WSREP_SST: [ERROR] Error while getting data from donor node: exit codes: 143 143 2018-10-11T09:20:47.828411+00:00 WSREP_SST: [ERROR] ****************************************************** 2018-10-11T09:20:47.840006+00:00 WSREP_SST: [ERROR] Cleanup after exit with status:32 And below is the error from the node that was chosen as the donor: 2018/10/11 09:20:38 socat E connect(5, AF=2 10.1.5.102:4444, 16): No route to host 2018-10-11T09:20:38.805798+00:00 WSREP_SST: [ERROR] ******************* FATAL ERROR ********************** 2018-10-11T09:20:38.818683+00:00 WSREP_SST: [ERROR] Error while sending data to joiner node: exit codes: 0 1 2018-10-11T09:20:38.832059+00:00 WSREP_SST: [ERROR] ****************************************************** 2018-10-11T09:20:38.846813+00:00 WSREP_SST: [ERROR] Cleanup after exit with status:32 2018-10-11T09:20:38.985060-00:00 0 [ERROR] WSREP: Process completed with error: wsrep_sst_xtrabackup-v2 --role 'donor' --address '10.1.5.102:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix '' --mysqld-version '5.7.23-23-57' --binlog 'db-test-2-bin' --gtid 'ac97f711-cad5-11e8-8f39-be9d0594cdb9:69' : 32 (Broken pipe) 2018-10-11T09:20:38.985552-00:00 0 [ERROR] WSREP: Command did not run: wsrep_sst_xtrabackup-v2 --role 'donor' --address '10.1.5.102:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix '' --mysqld-version '5.7.23-23-57' --binlog 'db-test-2-bin' --gtid 'ac97f711-cad5-11e8-8f39-be9d0594cdb9:69' 2018-10-11T09:20:38.990613-00:00 0 [Warning] WSREP: 0.0 (db-test-2.pd.local): State transfer to 1.0 (db-test-3.pd.local) failed: -32 (Broken pipe) 2018-10-11T09:20:38.990815-00:00 0 [Note] WSREP: Shifting DONOR/DESYNCED -> JOINED (TO: 69) 2018-10-11T09:20:38.997784-00:00 0 [Note] WSREP: declaring e3def063 at tcp://10.1.5.100:4567 stable 2018-10-11T09:20:38.997807-00:00 0 [Note] WSREP: Member 0.0 (db-test-2.pd.local) synced with group. 2018-10-11T09:20:38.998230-00:00 0 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 69) 2018-10-11T09:20:38.998277-00:00 0 [Note] WSREP: forgetting d3167260 (tcp://10.1.5.102:4567) 2018-10-11T09:20:38.998806-00:00 13 [Note] WSREP: Synchronized with group, ready for connections 2018-10-11T09:20:38.999112-00:00 13 [Note] WSREP: Setting wsrep_ready to true 2018-10-11T09:20:38.999198-00:00 13 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 2018-10-11T09:20:39.003491-00:00 0 [Note] WSREP: Node 8d59ca0f state primary 2018-10-11T09:20:39.005025-00:00 0 [Note] WSREP: Current view of cluster as seen by this node view (view_id(PRIM,8d59ca0f,4) memb { 8d59ca0f,0 e3def063,0 } joined { } left { } partitioned { d3167260,0 } ) 2018-10-11T09:20:39.005270-00:00 0 [Note] WSREP: Save the discovered primary-component to disk 2018-10-11T09:20:39.009691-00:00 0 [Note] WSREP: forgetting d3167260 (tcp://10.1.5.102:4567) 2018-10-11T09:20:39.010097-00:00 0 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 2 2018-10-11T09:20:39.011037-00:00 0 [Note] WSREP: STATE_EXCHANGE: sent state UUID: eb0b1f21-cd36-11e8-8ac8-c60fb82759c9 2018-10-11T09:20:39.019171-00:00 0 [Note] WSREP: STATE EXCHANGE: sent state msg: eb0b1f21-cd36-11e8-8ac8-c60fb82759c9 2018-10-11T09:20:39.021665-00:00 0 [Note] WSREP: STATE EXCHANGE: got state msg: eb0b1f21-cd36-11e8-8ac8-c60fb82759c9 from 0 (db-test-2.pd.local) 2018-10-11T09:20:39.021786-00:00 0 [Note] WSREP: STATE EXCHANGE: got state msg: eb0b1f21-cd36-11e8-8ac8-c60fb82759c9 from 1 (db-test-1.pd.local) 2018-10-11T09:20:39.021861-00:00 0 [Note] WSREP: Quorum results: version = 4, component = PRIMARY, conf_id = 3, members = 2/2 (primary/total), act_id = 69, last_appl. = 0, protocols = 0/9/3 (gcs/repl/appl), group UUID = ac97f711-cad5-11e8-8f39-be9d0594cdb9 2018-10-11T09:20:39.021999-00:00 0 [Note] WSREP: Flow-control interval: [141, 141] 2018-10-11T09:20:39.022058-00:00 0 [Note] WSREP: Trying to continue unpaused monitor 2018-10-11T09:20:39.022774-00:00 17 [Note] WSREP: REPL Protocols: 9 (4, 2) 2018-10-11T09:20:39.023163-00:00 17 [Note] WSREP: New cluster view: global state: ac97f711-cad5-11e8-8f39-be9d0594cdb9:69, view# 4: Primary, number of nodes: 2, my index: 0, protocol version 3 2018-10-11T09:20:39.023209-00:00 17 [Note] WSREP: Setting wsrep_ready to true 2018-10-11T09:20:39.023256-00:00 17 [Note] WSREP: Auto Increment Offset/Increment re-align with cluster membership change (Offset: 1 -> 1) (Increment: 3 -> 2) 2018-10-11T09:20:39.023373-00:00 17 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 2018-10-11T09:20:39.023540-00:00 17 [Note] WSREP: Assign initial position for certification: 69, protocol version: 4 2018-10-11T09:20:39.023832-00:00 0 [Note] WSREP: Service thread queue flushed. 2018-10-11T09:20:44.480289-00:00 0 [Note] WSREP: cleaning up d3167260 (tcp://10.1.5.102:4567) When I bootstrap the third not to be its own cluster, it runs just fine. But when I try to stop the first two nodes in the other cluster and attempt to have them join the new cluster, they fail to join. I can ping and telnet the first two clusters nodes from the third node and vice versa. I even tried stopping all nodes and bootstrapped the cluster from scratch, and that did not help. What is really going on here?

I have installed MySQL 5.7 community edition installed. Can we use Percona xtradb backup tool for backup DB for banking site databases for OLTP?

After seeing the following in the error log on the second node: 121003 7:16:06 [Note] WSREP: Member 0 (joiner) synced with group. 121003 7:16:06 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 0) 121003 7:16:06 [Note] WSREP: Synchronized with group, ready for connections 121003 7:16:06 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 121003 7:17:08 [Note] WSREP: Skipping empty log_xid: COMMIT 121003 7:17:08 [Note] WSREP: ignoring DDL failure: 0 ALTER TABLE bigdata_queue_campaigns DISABLE KEYS 121003 7:17:08 [Note] WSREP: Skipping empty log_xid: COMMIT 121003 7:17:08 [Note] WSREP: ignoring DDL failure: 0 ALTER TABLE bigdata_queue_campaigns ENABLE KEYS ... 121003 7:31:33 [ERROR] Slave SQL: Error 'Table 'reportingdb.norep_zonebannertmp_bk' doesn't exist' on query. Default database: 'reportingdb'. Query: 'TRUNCATE TABLE norep_zonebannertmp_bk', Error_code: 1146 121003 7:31:33 [Warning] WSREP: RBR event 1 Query apply warning: 1, 1141 121003 7:31:33 [Warning] WSREP: Ignoring error for TO isolated action: source: 84dcb35c-0ce4-11e2-0800-4568aec9a7f3 version: 2 local: 0 state: APPLYING flags: 65 conn_id: 1106 trx_id: -1 seqnos (l: 1196, g: 1141, s: 1140, d: 1140, ts: 1349224295344525000) I cannot login to the first node mysql -u root -p hangs. I don't see any interesting in the error log on this node. I'm using Percona-XtraDB-Cluster-server-5.5.27-23.6.356.rhel5. Let me know if you need further information.

I believe that innodb has a single read thread. However, with MariaDB you can set multiple read threads. I'm unsure what the recommended value would be. Questions - Does anyone have any experience with MariaDB and performance tuning? - Can you think of any features within MariaDB that XtraDB uses that MySQL does not? - Are there any similar settings that can I can use to fully exploit XtraDB and Maria's enhanced functionality?

Is there a way to skip State Snapshot Transfer (SST) at startup on Percona XtraDB Cluster Server? wsrep_sst_mode=skip doesn't work: 121003 6:49:55 Percona XtraDB (http://www.percona.com) 1.1.8-rel28.1 started; log sequence number 82208067084 121003 6:49:55 [ERROR] /usr/sbin/mysqld: unknown variable 'wsrep_sst_mode=skip' 121003 6:49:55 [ERROR] Aborting I'm using Percona-XtraDB-Cluster-server-5.5.27-23.6.356.rhel5.

We have a situation where we would like to have synchronous replication in our main data center, but replicate asynchronously to another region. Our second data center is 3,000 miles away (Site B) and we use it as a warm backup in case we need to failover our primary data center (Site A) due to a data center failure. We are not storing any financial or transactionally sensitive data. Our data is important, of course, but it is not critical to that degree, it consists primarily of updates to website content from content editors. We are interested in using either Percona XtraDB or Galera Cluster in Site A mixed with something like MySQL, MariaDB or Percona Server for Site B, but don't know if this is even possible or how we might implement such a solution. Can we have a synchronous replication scheme in Site A with an asynchronous backup to the Site B servers? Would we be able to maintain a multi-master implementation in Site A with replicas in Site B? If it is possible, I assume it would require multiple technologies. What technologies or configurations are feasible solutions?

I am quite new in MariaDB and I use SQLyog Community Edition as the frontend GUI. Whenever I create a new table, on the **Engine** dropdown, there is no XtraDB option. Is there any additional steps I am missing? As I've read, XtraDB is the InnoDB improved. How can I set my table to have that engine? Here is my SHOW ENGINES result: MariaDB [(none)]> SHOW ENGINES; +--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+ | Engine | Support | Comment | Transactions | XA | Savepoints | +--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+ | MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO | | CSV | YES | CSV storage engine | NO | NO | NO | | PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO | | BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO | | MyISAM | YES | MyISAM storage engine | NO | NO | NO | | MRG_MyISAM | YES | Collection of identical MyISAM tables | NO | NO | NO | | ARCHIVE | YES | Archive storage engine | NO | NO | NO | | FEDERATED | YES | FederatedX pluggable storage engine | YES | NO | YES | | InnoDB | DEFAULT | Percona-XtraDB, Supports transactions, row-level locking, and foreign keys | YES | YES | YES | | Aria | YES | Crash-safe tables with MyISAM heritage | NO | NO | NO | +--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+

I noticed that WordPress runs quite a bit faster when I use XtraDB (MariaDB's InnoDB replacement) instead of TokuDB. This is strange, because TokuDB is advertised as being 20x faster. However, I noticed that YOURLS stat pages are a tiny bit faster when I use TokuDB for the gigantic (~22,000 rows) log table. So the question is: What situations will TokuDB be a higher-performance database engine than others, such as XtraDB/InnoDB?

In my vps, I thought of switching from MySQL to MariaDB (using Monty's repository for Debian Squeeze). Copying over my.cnf from MySQL to MariaDB, I saw that the new config file (the one from the MariaDB package) does not mention any plugins commands like the old one from MySQL, where I loaded the InnoDB plugin. Now, I understand that XtraDB has become the default ACID storage engine in MariaDB, in place of InnoDB. Since I find MariaDB site's documentation lacking in this area, do I need to put something extra in the new my.cnf to activate XtraDB or is it active by default? show plugins returns this: MariaDB [(none)]> show plugins; +--------------------------------+--------+--------------------+---------+---------+ | Name | Status | Type | Library | License | +--------------------------------+--------+--------------------+---------+---------+ | binlog | ACTIVE | STORAGE ENGINE | NULL | GPL | | mysql_native_password | ACTIVE | AUTHENTICATION | NULL | GPL | | mysql_old_password | ACTIVE | AUTHENTICATION | NULL | GPL | | MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL | | partition | ACTIVE | STORAGE ENGINE | NULL | GPL | | ARCHIVE | ACTIVE | STORAGE ENGINE | NULL | GPL | | BLACKHOLE | ACTIVE | STORAGE ENGINE | NULL | GPL | | CSV | ACTIVE | STORAGE ENGINE | NULL | GPL | | FEDERATED | ACTIVE | STORAGE ENGINE | NULL | GPL | | MEMORY | ACTIVE | STORAGE ENGINE | NULL | GPL | | Aria | ACTIVE | STORAGE ENGINE | NULL | GPL | | MRG_MYISAM | ACTIVE | STORAGE ENGINE | NULL | GPL | | PBXT | ACTIVE | STORAGE ENGINE | NULL | GPL | | PBXT_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | InnoDB | ACTIVE | STORAGE ENGINE | NULL | GPL | | INNODB_RSEG | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_POOL_PAGES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_POOL_PAGES_INDEX | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_POOL_PAGES_BLOB | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_TRX | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_LOCKS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_LOCK_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMPMEM | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMPMEM_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_TABLE_STATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_INDEX_STATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | XTRADB_ADMIN_COMMAND | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_TABLES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_INDEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_STATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | XTRADB_ENHANCEMENTS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | +--------------------------------+--------+--------------------+---------+---------+ 33 rows in set (0.00 sec) What do I understand from the output above? That InnoDB=XtraDB?

I have old db with myisam tables, using mariadb and want try move to xtradb for row-level locking. Each table have 27 columns, primary index and other 11 indexes. Columns with indexes have many selects with where, group and order. I make some test and I'm little confused. Table with about 6M rows - disk space (data + keys): myisam - 915MiB innodb (xtradb) - 2011MiB On innodb(xtradb) I try large select with many where, group and order on indexed columns and it takes 63s, but if I delete all other indexes - only primary stay, then it takes 21s. It looks like if I don't use transaction, foreign keys, joins, etc...on this tables, that primary key is fine and all others is useless. But I think this is very strange :-/ I don't have hardware for better test, are you guys think it's good idea to convert all tables to inno(xtra) and drop all indexes except primary in production environment?

I installed mariadb 5.5.36 on a win32 system. Everything runs fine except innodb requests are 2 x slower than an identical MySQL installation. So I want to switch back to original innodb plugin to test the performance with it. In my.ini I put under [mysqld] the following: ignore_builtin_innodb plugin-load=innodb=ha_innodb.dll The plugin is located in BASEDIR/lib/plugin. But when I start the service I get the following in the error log: 140315 18:03:04 [Note] Plugin 'FEEDBACK' is disabled. 140315 18:03:04 [ERROR] Plugin 'InnoDB' init function returned error. 140315 18:03:04 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 140315 18:03:04 [ERROR] Unknown/unsupported storage engine: InnoDB 140315 18:03:04 [ERROR] Aborting If I comment both lines out then everything runs fine. Even when I try to run a plain MariaDB data dir (without the log files ...) the error occurs. Is there someone who have a hint for me?

I'm researching database configuration for MySQL/MariaDB. I've been reading the configuration chapter in "High Performance MySQL". In there, it suggests that innodb_lazy_drop_table can be used to avoid server stalls when dropping tables if innodb_file_per_table is set, to stop an immediate scan of the buffer pool to invalidate pages that refer to the dropped table. However, I also found that innodb_lazy_drop_table has now been removed from XtraDB. Does that mean the original issue is fixed, and I no longer have to worry about performance issues when dropping InnoDB/XtraDB tables? Or perhaps the lazy invalidation of pages has been enabled by default and the configuration option is all that's been removed?

I have two mariadb servers in cluster that is working galera and xtradb. it is my primary server configuration: [mysqld] datadir=/var/lib/mysql query_cache_size=0 binlog_format=ROW default_storage_engine=innodb innodb_autoinc_lock_mode=2 wsrep_provider=/usr/lib/galera/libgalera_smm.so wsrep_cluster_address=gcomm:// wsrep_cluster_name='cluster1' wsrep_node_address='172.16.41.34' wsrep_node_name='node1' wsrep_sst_method=xtrabackup wsrep_sst_auth="test:test1234" log-error=/var/log/mysql.log Slave configuration : [mysqld] datadir=/var/lib/mysql query_cache_size=0 binlog_format=ROW default_storage_engine=innodb innodb_autoinc_lock_mode=2 wsrep_provider=/usr/lib/galera/libgalera_smm.so wsrep_cluster_address=gcomm://172.16.41.34 wsrep_cluster_name='cluster1' wsrep_node_address='172.16.41.36' wsrep_node_name='node2' wsrep_sst_method=xtrabackup wsrep_sst_auth="sstuser:s3cretPass" log-error=/var/log/mysql.log After deliberately changed the user in wsrep_sst_auth, I noticed that the servers no problem to connect and synchronize with different user and password . Do you think that is this a bug in galera? Is it possible to compromise the cluster? And also want to ask the traffic between two web server in the cluster that is encrypted? Thanks :)

I'm replicating from one node of a three-member Percona XtraDB cluster to a separate slave, using regular MySQL replication. The node is set to write binlog in ROW mode, with log_slave_updates=true specifically for this. Replication seems to work fine. Still I wonder, given that XtraDB is an extension of InnoDB which the slave is using, is there a risk of some updates not replicating? Is it worth it to replicate into an XtraDB slave, and how would that need to be configured? I want the native async replication to the slave as it is an analytics DB and the goal is to offload the production Percona cluster from analytics queries, so it should not be just a regular cluster member.

Why should I use InnoDB and MySql instead of XtraDB and MariaDB, except that InnoDB and Mysql happen to be installed by default on my servers? Why isn't MariaDB and XtraDB installed by default everywhere?