Why MySQL Group Replication slave nodes have high delay with write node? - mysql

MySQL 5.7.17 MGR deploy in single-primary mode, 3 node all one one machine, the same configuration.
And then we test insert on the primary node and observe that the slave nodes have high delay with the write node, even primary node finish the insert test, slave node data is incresing!
Why MySQL Group Replication slave nodes have high delay with write node?
here is the my.cnf:
[mysqld]
datadir=/dba/mysql/data/s1
basedir=/dba/mysql/mysql-5.7/
port=24801
socket=/dba/mysql/data/s1/s1.sock
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24901"
loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off
loose-group_replication_single_primary_mode=true
loose-group_replication_enforce_update_everywhere_checks=false
slave_parallel_type=LOGICAL_CLOCK
slave_preserve_commit_order=1
slave_parallel_workers=4
and the MGR config :
mysql> show variables like '%group_replication%';
+----------------------------------------------------+-------------------------------------------------+
| Variable_name | Value |
+----------------------------------------------------+-------------------------------------------------+
| group_replication_allow_local_disjoint_gtids_join | OFF |
| group_replication_allow_local_lower_version_join | OFF |
| group_replication_auto_increment_increment | 7 |
| group_replication_bootstrap_group | OFF |
| group_replication_components_stop_timeout | 31536000 |
| group_replication_compression_threshold | 1000000 |
| group_replication_enforce_update_everywhere_checks | OFF |
| group_replication_flow_control_applier_threshold | 25000 |
| group_replication_flow_control_certifier_threshold | 25000 |
| group_replication_flow_control_mode | QUOTA |
| group_replication_force_members | |
| group_replication_group_name | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa |
| group_replication_group_seeds | 127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903 |
| group_replication_gtid_assignment_block_size | 1000000 |
| group_replication_ip_whitelist | AUTOMATIC |
| group_replication_local_address | 127.0.0.1:24901 |
| group_replication_poll_spin_loops | 0 |
| group_replication_recovery_complete_at | TRANSACTIONS_APPLIED |
| group_replication_recovery_reconnect_interval | 60 |
| group_replication_recovery_retry_count | 10 |
| group_replication_recovery_ssl_ca | |
| group_replication_recovery_ssl_capath | |
| group_replication_recovery_ssl_cert | |
| group_replication_recovery_ssl_cipher | |
| group_replication_recovery_ssl_crl | |
| group_replication_recovery_ssl_crlpath | |
| group_replication_recovery_ssl_key | |
| group_replication_recovery_ssl_verify_server_cert | OFF |
| group_replication_recovery_use_ssl | OFF |
| group_replication_single_primary_mode | ON |
| group_replication_ssl_mode | DISABLED |
| group_replication_start_on_boot | OFF |
+----------------------------------------------------+-------------------------------------------------+
32 rows in set (0.01 sec)

Related

How to determine and solve mysql high CPU usage?

'top' gives:
top - 13:07:35 up 827 days, 8:18, 2 users, load average: 5,26, 5,38, 5,45
KiB Mem: 32848512 total, 32265240 used, 583272 free, 261908 buffers
KiB Swap: 1046520 total, 313784 used, 732736 free, 28190744 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23927 mysql 20 0 917m 243m 8152 S 553,7 0,8 65:09.27 mysqld
mysql> SHOW FULL PROCESSLIST;
+------+--------+-----------------+-------------+---------+------+--------------+--------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+--------+-----------------+-------------+---------+------+--------------+--------------------------------------------------------------------+
| 600 | oneill | localhost | NULL | Query | 0 | NULL | SHOW FULL PROCESSLIST |
| 956 | oneill | 127.0.0.1:42219 | FoxPoker | Sleep | 0 | | NULL |
| 1318 | oneill | 127.0.0.1:44207 | FoxPoker | Sleep | 0 | | NULL |
| 1319 | oneill | 127.0.0.1:44210 | FoxPoker | Sleep | 0 | | NULL |
| 1321 | oneill | 127.0.0.1:44215 | FoxPoker | Sleep | 0 | | NULL |
| 1489 | oneill | 127.0.0.1:45218 | FoxPoker | Sleep | 0 | | NULL |
| 1490 | oneill | 127.0.0.1:45217 | FoxPoker | Sleep | 0 | | NULL |
| 1700 | oneill | 127.0.0.1:46246 | FoxPoker | Sleep | 0 | | NULL |
| 1701 | oneill | 127.0.0.1:46248 | FoxPoker | Sleep | 0 | | NULL |
| 2203 | oneill | 127.0.0.1:49218 | FoxPoker | Sleep | 0 | | NULL |
| 3262 | oneill | 127.0.0.1:54855 | FoxPoker | Sleep | 0 | | NULL |
| 3263 | oneill | 127.0.0.1:54858 | FoxPokerDev | Sleep | 0 | | NULL |
| 3462 | oneill | 127.0.0.1:56029 | FoxPoker | Sleep | 0 | | NULL |
| 4269 | oneill | 127.0.0.1:60551 | FoxPoker | Sleep | 0 | | NULL |
| 4945 | oneill | 127.0.0.1:36032 | FoxPoker | Query | 3 | Sending data | SELECT COUNT(deviceId) FROM devices WHERE BINARY deviceId="pMGmpY" |
| 4950 | oneill | 127.0.0.1:36073 | FoxPoker | Query | 1 | Sending data | SELECT COUNT(deviceId) FROM devices WHERE BINARY deviceId="tAf994" |
| 4952 | oneill | 127.0.0.1:36083 | FoxPoker | Query | 1 | Sending data | SELECT COUNT(deviceId) FROM devices WHERE BINARY deviceId="ea6Kv2" |
| 4954 | oneill | 127.0.0.1:36097 | FoxPoker | Query | 1 | Sending data | SELECT COUNT(deviceId) FROM devices WHERE BINARY deviceId="yFYvur" |
| 4955 | oneill | 127.0.0.1:36098 | FoxPoker | Query | 1 | Sending data | SELECT COUNT(deviceId) FROM devices WHERE BINARY deviceId="73qTcv" |
| 4956 | oneill | 127.0.0.1:36099 | FoxPoker | Query | 1 | Sending data | SELECT COUNT(deviceId) FROM devices WHERE BINARY deviceId="q64MfG" |
+------+--------+-----------------+-------------+---------+------+--------------+--------------------------------------------------------------------+
mysql> show status like '%onn%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| Aborted_connects | 1 |
| Connections | 5528 |
| Max_used_connections | 25 |
| Ssl_client_connects | 0 |
| Ssl_connect_renegotiates | 0 |
| Ssl_finished_connects | 0 |
| Threads_connected | 19 |
+--------------------------+-------+
7 rows in set (0.00 sec)
(Connections keep on growing.)
mysqladmin status -h localhost -u -p
Uptime: 924 Threads: 21 Questions: 92803 Slow queries: 1677 Opens: 1025 Flush tables: 1 Open tables: 265 Queries per second avg: 100.436
I restared mysql, optimized all tables and nothing changed.
Any idea ?
Login to MySQL and check for expensive queries using:
SHOW FULL PROCESSLIST;
Find the offending sql that's causing the 1600 slow queries and performance tune it.
You can also look to enable slow query logging via the below documentation.
https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html

MariaDB Galera Cluster is not syncing

I have deployed MariaDB Cluster before, and this problem only comes out recently (I don't have this problem before and I don't know why).
I have server 1, 2 and 3. I executed an INSERT command at server 3, however, the tables at server 1 and 2 remains unchanged.
3 servers are at different parts of the world. After the INSERT command, the state uuid remains the same.
Here is the status of server 1:
MariaDB [mysql]> show status like 'wsrep_%';
+------------------------------+----------------------------------------------------------+
| Variable_name | Value |
+------------------------------+----------------------------------------------------------+
| wsrep_local_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_protocol_version | 7 |
| wsrep_last_committed | 205 |
| wsrep_replicated | 170 |
| wsrep_replicated_bytes | 160481 |
| wsrep_repl_keys | 664 |
| wsrep_repl_keys_bytes | 9222 |
| wsrep_repl_data_bytes | 140379 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 46 |
| wsrep_received_bytes | 26150 |
| wsrep_local_commits | 170 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 1 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 1 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.000000 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 1 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 0.000000 |
| wsrep_local_cached_downto | 1 |
| wsrep_flow_control_paused_ns | 0 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_cert_deps_distance | 7.482927 |
| wsrep_apply_oooe | 0.009756 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 1.009756 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 1.000000 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 28 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 0.009756 |
| wsrep_incoming_addresses | server1:3306,server2:3306,server3:3306 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0.200155/0.201113/0.201752/0.000614937/4 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | c4f91b4f-fee1-11e5-8c4f-6e451c332f79 |
| wsrep_cluster_conf_id | 3 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 6 |
| wsrep_local_index | 0 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info#codership.com> |
| wsrep_provider_version | 25.3.14(r3560) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+------------------------------+----------------------------------------------------------+
Status of server 2:
MariaDB [(none)]> show status like 'wsrep_%';
+------------------------------+----------------------------------------------------------+
| Variable_name | Value |
+------------------------------+----------------------------------------------------------+
| wsrep_local_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_protocol_version | 7 |
| wsrep_last_committed | 225 |
| wsrep_replicated | 35 |
| wsrep_replicated_bytes | 25700 |
| wsrep_repl_keys | 119 |
| wsrep_repl_keys_bytes | 1757 |
| wsrep_repl_data_bytes | 21703 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 187 |
| wsrep_received_bytes | 177793 |
| wsrep_local_commits | 35 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 1 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 1 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.000000 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 4 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 0.032086 |
| wsrep_local_cached_downto | 9 |
| wsrep_flow_control_paused_ns | 0 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_cert_deps_distance | 7.193548 |
| wsrep_apply_oooe | 0.004630 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 1.004630 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 1.000000 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 28 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 0.009217 |
| wsrep_incoming_addresses | server1:3306,server2:3306,server3:3306 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0.200138/0.201917/0.203696/0.00177914/2 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | d562e272-fee1-11e5-b2a2-d3a6b5579aab |
| wsrep_cluster_conf_id | 3 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 1 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info#codership.com> |
| wsrep_provider_version | 25.3.14(r3560) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+------------------------------+----------------------------------------------------------+
57 rows in set (0.01 sec)
Status of server3 (As you can see, the latency shows all 0 but I don't know why)
MariaDB [(none)]> show status like 'wsrep_%';
+------------------------------+----------------------------------------------------------+
| Variable_name | Value |
+------------------------------+----------------------------------------------------------+
| wsrep_local_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_protocol_version | 7 |
| wsrep_last_committed | 245 |
| wsrep_replicated | 5 |
| wsrep_replicated_bytes | 4350 |
| wsrep_repl_keys | 11 |
| wsrep_repl_keys_bytes | 203 |
| wsrep_repl_data_bytes | 3827 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 226 |
| wsrep_received_bytes | 208559 |
| wsrep_local_commits | 1 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 0 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 1 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.000000 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 1 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 0.000000 |
| wsrep_local_cached_downto | 19 |
| wsrep_flow_control_paused_ns | 0 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_cert_deps_distance | 7.022026 |
| wsrep_apply_oooe | 0.000000 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 1.000000 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 1.000000 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 28 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 0.008811 |
| wsrep_incoming_addresses | server1:3306,server2:3306,server3:3306 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0/0/0/0/0 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | fd022144-fee1-11e5-a7a3-f23274fef9c3 |
| wsrep_cluster_conf_id | 3 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 2 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info#codership.com> |
| wsrep_provider_version | 25.3.14(r3560) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+------------------------------+----------------------------------------------------------+
57 rows in set (0.00 sec)
iptables at all three servers are set to ACCEPT all input and output traffics.
The log shows that all servers have joined and synced with the cluster.
Does anyone know why? Thanks.
I finally found that is is the app's problem that use MyISAM as storage engine, which causes the error. There is no error after change back to InnoDB.
I suggest you to check the table engines, Because the Galera cluster support InnoDB engine not MyISAM.
So here is a easy way how to migrate Mysql database with MyISAM tables into Galera and InnoDB:
Make sure your db schema doesn't contain FULLTEXT indexes or any other constructions, which are not supported by InnoDB engine
Dump schema of your database
replace in the dump string "MYISAM" with "INNODB"
Dump data
Prepare db user in Galera Cluster (mysql.user table is not replicated across cluster, so you have to insert db user into each of your mariadb servers)
Import schema (with innodb engine)
Import data
Cleanup dump files
Thanks from https://support.qualityunit.com/718375-Migrate-MySQL-Database-with-Myisam-engine-to-MariaDB-Galera-Cluster

Unable to view all the hive metastore tables in mysql setup

I have apache Hive - 0.12.0 and hadoop - 1.2.1 version on my machine.
and used mysql for hive metastore.
Now when i fire show tables for metastore test, it only shows 20 rows/tables.
// My Environment
mysql> use metastore_db
Database changed
mysql> show tables;
+---------------------------+
| Tables_in_metastore_db |
+---------------------------+
| BUCKETING_COLS |
| CDS |
| COLUMNS_V2 |
| DATABASE_PARAMS |
| DBS |
| PARTITION_KEYS |
| SDS |
| SD_PARAMS |
| SEQUENCE_TABLE |
| SERDES |
| SERDE_PARAMS |
| SKEWED_COL_NAMES |
| SKEWED_COL_VALUE_LOC_MAP |
| SKEWED_STRING_LIST |
| SKEWED_STRING_LIST_VALUES |
| SKEWED_VALUES |
| SORT_COLS |
| TABLE_PARAMS |
| TBLS |
| VERSION |
+---------------------------+
20 rows in set (0.06 sec)
Why am not able to see all the tables like below one. Do i need to use any other hive version for this ? Please suggest.
// Need to see all these tables
mysql> show tables;
+ --------------------------- +
| Tables_in_hive_demo |
+ --------------------------- +
| BUCKETING_COLS |
| CDS |
| COLUMNS_V2 |
| DATABASE_PARAMS |
| DBS |
| DB_PRIVS |
| GLOBAL_PRIVS |
| IDXS |
| INDEX_PARAMS |
| NUCLEUS_TABLES |
| PARTITIONS |
| PARTITION_EVENTS |
| PARTITION_KEYS |
| PARTITION_KEY_VALS |
| PARTITION_PARAMS |
| PART_COL_PRIVS |
| PART_COL_STATS |
| PART_PRIVS |
| ROLES |
| ROLE_MAP |
| SDS |
| SD_PARAMS |
| SEQUENCE_TABLE |
| SERDES |
| SERDE_PARAMS |
| SKEWED_COL_NAMES |
| SKEWED_COL_VALUE_LOC_MAP |
| SKEWED_STRING_LIST |
| SKEWED_STRING_LIST_VALUES |
| SKEWED_VALUES |
| SORT_COLS |
| TABLE_PARAMS |
| TAB_COL_STATS |
| TBLS |
| TBL_COL_PRIVS |
| TBL_PRIVS |
| TYPES |
| TYPE_FIELDS |
| VERSION |
+ --------------------------- +
39 rowsinset (0.00 sec)
Try to upgrade the hive schema by the available sql script (mysql in your case).
mysql> use metastore_db
Database changed
mysql> SOURCE $HIVE_HOME/scripts/metastore/upgrade/mysql/hive-schema-0.12.0.mysql.sql;
mysql> CREATE USER 'dbuser'#'%' IDENTIFIED BY 'dbpassword';
mysql> GRANT all on *.* to 'dbuser'#localhost identified by 'dbpassword';
mysql> flush privileges;
Now requery your tables. It should show all the tables now.
mysql> show tables;

Get all tables from information_schema, MySQL

I just dont understand one thing. When I type:
SELECT table_name FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE';
I get:
+----------------------------------------------+
| table_name |
+----------------------------------------------+
| columns_priv |
| db |
| event |
| func |
| general_log |
| help_category |
| help_keyword |
| help_relation |
| help_topic |
| host |
| ndb_binlog_index |
| plugin |
| proc |
| procs_priv |
| proxies_priv |
| servers |
| slow_log |
| tables_priv |
| time_zone |
| time_zone_leap_second |
| time_zone_name |
| time_zone_transition |
| time_zone_transition_type |
| user |
| cond_instances |
| events_waits_current |
| events_waits_history |
| events_waits_history_long |
| events_waits_summary_by_instance |
| events_waits_summary_by_thread_by_event_name |
| events_waits_summary_global_by_event_name |
| file_instances |
| file_summary_by_event_name |
| file_summary_by_instance |
| mutex_instances |
| performance_timers |
| rwlock_instances |
| setup_consumers |
| setup_instruments |
| setup_timers |
| threads |
+----------------------------------------------+
41 rows in set (0.23 sec)
but selecting seems not to work at all:
mysql> select * from db;
ERROR 1109 (42S02): Unknown table 'db' in information_schema
mysql>
How is that possible? I mean, SELECT table_name FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE'; showed that there IS a table named 'db' ...
Secondly, when I type: SELECT table_name FROM INFORMATION_SCHEMA.TABLES; it gives me :
+----------------------------------------------+
| table_name |
+----------------------------------------------+
| CHARACTER_SETS |
| COLLATIONS |
| COLLATION_CHARACTER_SET_APPLICABILITY |
| COLUMNS |
| COLUMN_PRIVILEGES |
| ENGINES |
| EVENTS |
| FILES |
| GLOBAL_STATUS |
| GLOBAL_VARIABLES |
| KEY_COLUMN_USAGE |
| PARAMETERS |
| PARTITIONS |
| PLUGINS |
| PROCESSLIST |
| PROFILING |
| REFERENTIAL_CONSTRAINTS |
| ROUTINES |
| SCHEMATA |
| SCHEMA_PRIVILEGES |
| SESSION_STATUS |
| SESSION_VARIABLES |
| STATISTICS |
| TABLES |
| TABLESPACES |
| TABLE_CONSTRAINTS |
| TABLE_PRIVILEGES |
| TRIGGERS |
| USER_PRIVILEGES |
| VIEWS |
| INNODB_BUFFER_PAGE |
| INNODB_TRX |
| INNODB_BUFFER_POOL_STATS |
| INNODB_LOCK_WAITS |
| INNODB_CMPMEM |
| INNODB_CMP |
| INNODB_LOCKS |
| INNODB_CMPMEM_RESET |
| INNODB_CMP_RESET |
| INNODB_BUFFER_PAGE_LRU |
| columns_priv |
| db |
| event |
| func |
| general_log |
| help_category |
| help_keyword |
| help_relation |
| help_topic |
| host |
| ndb_binlog_index |
| plugin |
| proc |
| procs_priv |
| proxies_priv |
| servers |
| slow_log |
| tables_priv |
| time_zone |
| time_zone_leap_second |
| time_zone_name |
| time_zone_transition |
| time_zone_transition_type |
| user |
| cond_instances |
| events_waits_current |
| events_waits_history |
| events_waits_history_long |
| events_waits_summary_by_instance |
| events_waits_summary_by_thread_by_event_name |
| events_waits_summary_global_by_event_name |
| file_instances |
| file_summary_by_event_name |
| file_summary_by_instance |
| mutex_instances |
| performance_timers |
| rwlock_instances |
| setup_consumers |
| setup_instruments |
| setup_timers |
| threads |
+----------------------------------------------+
81 rows in set (0.00 sec)
and Im able to do: mysql> select * from events; and Im getting some results. Why is that? Why can I do select only on upper-case-names? And further, how can I select from information_schema tables given only in uppercase? Cheers
If it matters: Im logged as root to my db.
You select only table_name, but what about table_schema:
MariaDB [(none)]> SELECT table_name, table_schema FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_TYPE = 'BASE TABLE';
+----------------------------------------------+--------------------+
| table_name | table_schema |
+----------------------------------------------+--------------------+
| columns_priv | mysql |
| db | mysql |
| event | mysql |
| func | mysql |
| general_log | mysql |
| help_category | mysql |
| help_keyword | mysql |
| help_relation | mysql |
| help_topic | mysql |
| host | mysql |
| ndb_binlog_index | mysql |
| plugin | mysql |
| proc | mysql |
| procs_priv | mysql |
| proxies_priv | mysql |
| servers | mysql |
| slow_log | mysql |
| tables_priv | mysql |
| time_zone | mysql |
| time_zone_leap_second | mysql |
| time_zone_name | mysql |
| time_zone_transition | mysql |
| time_zone_transition_type | mysql |
| user | mysql |
| cond_instances | performance_schema |
| events_waits_current | performance_schema |
| events_waits_history | performance_schema |
| events_waits_history_long | performance_schema |
| events_waits_summary_by_instance | performance_schema |
| events_waits_summary_by_thread_by_event_name | performance_schema |
| events_waits_summary_global_by_event_name | performance_schema |
| file_instances | performance_schema |
| file_summary_by_event_name | performance_schema |
| file_summary_by_instance | performance_schema |
| mutex_instances | performance_schema |
| performance_timers | performance_schema |
| rwlock_instances | performance_schema |
| setup_consumers | performance_schema |
| setup_instruments | performance_schema |
| setup_timers | performance_schema |
| threads | performance_schema |
+----------------------------------------------+--------------------+
And you get:
MariaDB [(none)]> select * from mysql.db;
Empty set (0.00 sec)
'information_schema' has ONLY SERVICE INFORMATION. It has info about table 'db' is exist, but it table IS NOT IN 'information_schema' DATABASE -- somewhere, but not in 'information_schema'.
Info about database which has needed table saved in TABLE_SCHEMA field

Nova boot error Devstack

I uploaded an image to glance, an Ubuntu server 12.04 in a vhd format and when i'm trying to boot that image with nova boot i receive this:
+-------------------------------------+--------------------------------------+
| Property | Value |
+-------------------------------------+--------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-SRV-ATTR:host | None |
| OS-EXT-SRV-ATTR:hypervisor_hostname | None |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
| OS-EXT-STS:power_state | 0 |
| OS-EXT-STS:task_state | scheduling |
| OS-EXT-STS:vm_state | building |
| accessIPv4 | |
| accessIPv6 | |
| adminPass | PK2mwUZ7SJEH |
| config_drive | |
| created | 2012-12-19T17:21:48Z |
| flavor | m1.tiny |
| hostId | |
| id | 716c9276-648c-4f90-9e67-43b8f41feb91 |
| image | Ubuntu |
| key_name | key1 |
| metadata | {} |
| name | vm1 |
| progress | 0 |
| security_groups | [{u'name': u'default'}] |
| status | BUILD |
| tenant_id | 73e54a9f1ddc46fa9bd0a99d5e2a1cda |
| updated | 2012-12-19T17:21:54Z |
| user_id | dc9c0376d5604467b3898082fd270b1c |
+-------------------------------------+--------------------------------------+
ubuntu#ubuntu:~/vmware-tools-distrib$ cd /
ubuntu#ubuntu:/$ cd /home/ubuntu/devstack/
ubuntu#ubuntu:~/devstack$ nova list
+--------------------------------------+------+--------+----------+
| ID | Name | Status | Networks |
+--------------------------------------+------+--------+----------+
| 716c9276-648c-4f90-9e67-43b8f41feb91 | vm1 | ERROR | |
| 77aa0d77-2dae-4d18-a827-f08d0fb2f71a | vm1 | ERROR | |
+--------------------------------------+------+--------+----------+
So, what may be the problem??
Thanks!
you can access the database to get the detail reason if there is no obvious information in log file, query nova.instance_faults table will give you more information about why this instance became error status.
look at the nova-network.log if there is an error which is related dhcpbridge file, add that line to nova.conf
dhcpbridge = /usr/bin/nova-dhcpbridge
hint: if there is a builted image(nova list) delete it and then restart all nova-* services