amir jj's questions

Eu instalei os pacotes necessários do MySQL Cluster e agora estou usando o instalador automático para configurar os nós corretamente. quando tento iniciar o cluster em Deploy Configurationparte, todos os nós (1 nó de gerenciamento, 4 nós de dados) iniciam corretamente, exceto o nó SQL e recebo o erro abaixo.

Command `/usr/local/mysql/bin/mysqld --defaults-file=/home/debian/MySQL_Cluster/49/my.cnf', running on 192.168.120.107 exited with 1:
2016-04-03 16:32:49 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2016-04-03 16:32:49 0 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.6.28-ndb-7.4.10-cluster-gpl) starting as process 11472 ..

você vê que todos os nós são iniciados. Eu uso o comando recomendado com a --explicit_defaults_for_timestampopção abaixo.

 /usr/local/mysql/bin/mysqld --defaults-file=/home/debian/MySQL_Cluster/49/my.cnf  --explicit_defaults_for_timestamp 
2016-04-03 16:42:06 0 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.6.28-ndb-7.4.10-cluster-gpl) starting as process 11503 ...

você pode ver com a --explicit_defaults_for_timestamp opção de serviço iniciar corretamente, mas ainda assim, quando uso o nó de gerenciamento para ver o status, vejo que o cluster tem um problema, consulte o nó de gerenciamento:

ndb_mgm> show 
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 4 node(s)
id=1    @192.168.120.111  (mysql-5.6.28 ndb-7.4.10, Nodegroup: 0, *)
id=2    @192.168.120.117  (mysql-5.6.28 ndb-7.4.10, Nodegroup: 0)
id=3    @192.168.120.118  (mysql-5.6.28 ndb-7.4.10, Nodegroup: 1)
id=4    @192.168.120.76  (mysql-5.6.28 ndb-7.4.10, Nodegroup: 1)

[ndb_mgmd(MGM)] 1 node(s)
id=50   @192.168.120.79  (mysql-5.6.28 ndb-7.4.10)

[mysqld(API)]   1 node(s)
id=49 (not connected, accepting connect from 192.168.120.107)

como você pode ver, o nó SQL ainda não foi iniciado corretamente:

[mysqld(API)]   1 node(s)
id=49 (not connected, accepting connect from 192.168.120.107)

Eu não entendo o problema.

Estou tendo um MySQL dual-master Replicação do MySQL, cada um dos servidores tem 21 GB de memória, agora estou procurando uma solução de clustering para este projeto, é possível ter 6 servidores: dois deles com 20 GB de RAM e outros com 10 GB de RAM. na documentação do MySQL Cluster está escrito abaixo a fórmula para memória total e cada nó RAM, parece que preciso de muito mais RAM da minha replicação existente e é difícil fazer minha empresa concordar com esse tipo de requisito de RAM, além do objetivo de clustering é, em vez de fazer um servidor grande, usar servidores menores (em recursos) conectados uns aos outros, mas com esta fórmula cada nó de clustering é muito maior do que meus servidores existentes.

Se estiver projetando um banco de dados completamente novo, os seguintes cálculos podem ser usados ​​para ajudar a determinar os requisitos aproximados de dimensionamento de memória para os nós de dados:

• (na memória) Tamanho dos dados * Réplicas * 1,25 = Requisitos totais de memória do banco de dados Exemplo: 50 GB * 2 * 1,25 = 125 GB

• (Tamanho dos dados * Réplicas * 1,25)/Nós = RAM por nó Exemplo: (2 GB * 2 * 1,25)/4 = 31,25 GB

Nesta situação tenho algumas dúvidas:

• É necessário obedecer a essas fórmulas? posso usar menos RAM para nós?

Tenho dois banco de dados com uma tabela com utf8tabela, queria mudar a codificação de uma coluna, usei dois cenários mas aconteceu um problema comigo. a princípio a tabela era assim:

CREATE TABLE `spool` (
  `username` varchar(250) NOT NULL,
  `xml` text  NOT NULL,
  `seq` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  UNIQUE KEY `seq` (`seq`),
  KEY `i_despool` (`username`) USING BTREE,
  KEY `i_spool_created_at` (`created_at`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8

Primeiro cenário

no primeiro eu mudo a codificação da linha com o comando abaixo:

ALTER TABLE spool MODIFY xml TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL;

e então eu uso show create table spool;assim:

 CREATE TABLE `spool` (
  `username` varchar(250) NOT NULL,
  `xml` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `seq` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  UNIQUE KEY `seq` (`seq`),
  KEY `i_despool` (`username`) USING BTREE,
  KEY `i_spool_created_at` (`created_at`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8

segundo cenário

Na segunda tabela, alterei primeiro a codificação da tabela e depois alterei a xmlcodificação da coluna assim:

ALTER TABLE spool 
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

e então mudei a codificação da coluna como abaixo:

ALTER TABLE spool MODIFY xml TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL;

e então podemos ver a tabela como esta:

CREATE TABLE `spool` (
  `username` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL,
  `xml` text COLLATE utf8mb4_unicode_ci NOT NULL,
  `seq` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  UNIQUE KEY `seq` (`seq`),
  KEY `i_despool` (`username`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=30849368 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

como você pode ver no segundo cenário na frente do "texto `xml`" não vemos o CHARACTER SET utf8mb4e acho que causa erro para mim porque quando o Ejabberd deseja inserir uma consulta no segundo, vejo o erro abaixo, mas em a outra tabela não tenho esse erro:

HY000Incorrect string value: '\\xF0\\x9F\\x98\\x8F\\xF0\\x9F...' for column 'xml' at row 1"
** Stacktrace: [{ejabberd_odbc,sql_query_t,1,[{file,"src/ejabberd_odbc.erl"},{line,173}]},{lists,foreach,2,[{file,"lists.erl"},{line,1336}]},{ejabberd_odbc,outer_transaction,3,[{file,"src/ejabberd_odbc.erl"},{line,443}]},{ejabberd_odbc,run_sql_cmd,4,[{file,"src/ejabberd_odbc.erl"},{line,380}]},{p1_fsm,handle_msg,10,[{file,"src/p1_fsm.erl"},{line,582}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,237}]}]

no primeiro cenário não vemos este erro mas no segundo o erro existe. Como resolver este problema?

Eu tenho três servidores que quero instalar o cluster do Galera neles, segui este link para instalá-lo e configurá-lo. mas quando quero iniciar o primeiro servidor, recebo este erro:

root@node107:/home/debian# service mysql start --wsrep-new-clusterping 
Job for mysql.service failed. See 'systemctl status mysql.service' and 'journalctl -xn' for details.

e :

root@node107:/home/debian# journalctl -xn
-- Logs begin at Tue 2016-03-01 19:02:04 IRST, end at Tue 2016-03-01 19:39:32 IRST. --
Mar 01 19:39:31 node107 mysqld[5102]: 160301 19:39:31 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1379: Failed to open channel 'test_cluster' at 'gcomm://192.168.120.107,192.168.120.111,192.168.120.11
Mar 01 19:39:31 node107 mysqld[5102]: 160301 19:39:31 [ERROR] WSREP: gcs connect failed: Connection timed out
Mar 01 19:39:31 node107 mysqld[5102]: 160301 19:39:31 [ERROR] WSREP: wsrep::connect(gcomm://192.168.120.107,192.168.120.111,192.168.120.117) failed: 7
Mar 01 19:39:31 node107 mysqld[5102]: 160301 19:39:31 [ERROR] Aborting
Mar 01 19:39:31 node107 mysqld[5102]: 
Mar 01 19:39:31 node107 mysqld[5102]: 160301 19:39:31 [Note] WSREP: Service disconnected.
Mar 01 19:39:32 node107 mysqld[5102]: 160301 19:39:32 [Note] WSREP: Some threads may fail to exit.
Mar 01 19:39:32 node107 mysqld[5102]: 160301 19:39:32 [Note] /usr/sbin/mysqld: Shutdown complete
Mar 01 19:39:32 node107 mysqld[5102]: 
Mar 01 19:39:32 node107 mysqld_safe[5378]: mysqld from pid file /var/run/mysqld/mysqld.pid ended

estes são arquivos de configuração para os três servidores:

vim /etc/mysql/conf.d/cluster.cnf

Servidor1 :

[mysqld]
query_cache_size=0
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_type=0
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_provider=/usr/lib/galera/libgalera_smm.so
#wsrep_provider_options="gcache.size=32G"

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"
wsrep_cluster_address="gcomm://192.168.120.107,192.168.120.111,192.168.120.117"
#wsrep_cluster_address="gcomm://192.168.120.107"

# Galera Synchronization Congifuration
wsrep_sst_method=rsync
#wsrep_sst_auth=user:pass

# Galera Node Configuration
wsrep_node_address="192.168.120.107"
wsrep_node_name="node107"

Servidor 2:

[mysqld]
query_cache_size=0
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_type=0
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_provider=/usr/lib/galera/libgalera_smm.so
#wsrep_provider_options="gcache.size=32G"

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"
wsrep_cluster_address="gcomm://192.168.120.107"
#wsrep_cluster_address="gcomm://192.168.120.107,192.168.120.111,192.168.120.117"

# Galera Synchronization Congifuration
wsrep_sst_method=rsync
#wsrep_sst_auth=user:pass

# Galera Node Configuration
wsrep_node_address="192.168.120.111"
wsrep_node_name="node111"

servidor 3:

[mysqld]
query_cache_size=0
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_type=0
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_provider=/usr/lib/galera/libgalera_smm.so
#wsrep_provider_options="gcache.size=32G"

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"
wsrep_cluster_address="gcomm://192.168.120.107,192.168.120.111,192.168.120.117"

# Galera Synchronization Congifuration
wsrep_sst_method=rsync
#wsrep_sst_auth=user:pass

# Galera Node Configuration
wsrep_node_address="192.168.120.117"
wsrep_node_name="node117"

Não entendo o que perdi. O que devo fazer?

Eu tenho um banco de dados com latin1conjunto de caracteres, preciso alterar o conjunto de caracteres das tabelas para utf8, mas recebo um erro. o conjunto de caracteres atual é:

mysql> show variables like "%character%";
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

a tabela que quero alterar o conjunto de caracteres é:

mysql> describe spool;
+------------+---------------------+------+-----+-------------------+----------------+
| Field      | Type                | Null | Key | Default           | Extra          |
+------------+---------------------+------+-----+-------------------+----------------+
| username   | varchar(250)        | NO   | MUL | NULL              |                |
| xml        | text                | NO   |     | NULL              |                |
| seq        | bigint(20) unsigned | NO   | PRI | NULL              | auto_increment |
| created_at | timestamp           | NO   |     | CURRENT_TIMESTAMP |                |
+------------+---------------------+------+-----+-------------------+----------------+
4 rows in set (0.00 sec)

quando quero alterar o conjunto de caracteres, vejo o erro abaixo:

mysql> ALTER TABLE spool CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes

É um banco de dados em funcionamento da empresa e não quero atrapalhar a funcionalidade, portanto não quero alterar o tamanho do varchar(250)tipo, gostaria de saber se existe uma solução para alterar essa codificação.

mysql> show create table spool\G;
*************************** 1. row ***************************
       Table: spool
Create Table: CREATE TABLE `spool` (
  `username` varchar(250) NOT NULL,
  `xml` text NOT NULL,
  `seq` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  UNIQUE KEY `seq` (`seq`),
  KEY `i_despool` (`username`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=23490775 DEFAULT CHARSET=utf8

Tenho servidor MySQL 5.6 e utilizo teste de estresse para avaliar o desempenho do mesmo. após o teste o resultado mysqltuner.plfoi como abaixo:

root@master-1:/home/debian# perl mysqltuner.pl
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password:  >>  MySQLTuner 1.6.4 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.6.29-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM 
[--] Data in InnoDB tables: 34G (Tables: 29)
[!!] Total fragmented tables: 4

-------- Security Recommendations  -------------------------------------------
[OK] There are no anonymous accounts for any database users
[OK] All database users have passwords assigned
[!!] There is no basic password file list!

-------- CVE Security Recommendations  ---------------------------------------
[--] Skipped due to --cvefile option undefined

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1h 56m 26s (4M q [592.634 qps], 398 conn, TX: 8B, RX: 6B)
[--] Reads / Writes: 81% / 19%
[--] Binary logging is enabled (GTID MODE: OFF)
[--] Total buffers: 1.0G global + 1.1M per thread (8190 max threads)
[OK] Maximum reached memory usage: 1.1G (4.63% of installed RAM)
[OK] Maximum possible memory usage: 9.5G (40.45% of installed RAM)
[OK] Slow queries: 0% (0/4M)
[OK] Highest usage of available connections: 0% (44/8190)
[OK] Aborted connections: 0.75%  (3/398)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2 sorts)
[OK] Temporary tables created on disk: 0% (0 on disk / 27 total)
[OK] Thread cache hit rate: 84% (62 created / 398 connections)
[OK] Table cache hit rate: 75% (309 open / 408 opened)
[OK] Open file limit used: 0% (54/9K)
[OK] Table locks acquired immediately: 100% (4M immediate / 4M locks)
[OK] Binlog cache memory access: 100.00% ( 704225 Memory / 704225 Total)

-------- MyISAM Metrics ------------------------------------------------------
[!!] Key buffer used: 18.2% (3M used / 16M cache)
[OK] Key buffer size / total MyISAM indexes: 16.0M/95.0K
[!!] Read Key buffer hit rate: 80.0% (5 cached / 1 reads)

-------- InnoDB Metrics ------------------------------------------------------
[--] InnoDB is enabled.
[!!] InnoDB buffer pool / data size: 512.0M/34.2G
[!!] InnoDB buffer pool <= 1G and innodb_buffer_pool_instances(!=1).
[OK] InnoDB Used buffer: 96.95% (31769 used/ 32767 total)
[OK] InnoDB Read buffer efficiency: 99.83% (94182005 hits/ 94340114 total)
[!!] InnoDB Write buffer efficiency: 0.00% (0 hits/ 1 total)
[OK] InnoDB log waits: 0.00% (0 waits / 178758 writes)

-------- ThreadPool Metrics --------------------------------------------------
[--] ThreadPool stat is disabled.

-------- AriaDB Metrics ------------------------------------------------------
[--] AriaDB is disabled.

-------- TokuDB Metrics ------------------------------------------------------
[--] TokuDB is disabled.

-------- Galera Metrics ------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -------------------------------------------------
[--] This server is acting as master for 2 server(s).
[!!] This replication slave is running with the read_only option disabled.
[OK] This replication slave is up to date with master.

-------- Recommendations -----------------------------------------------------

então eu paro o script de teste de estresse e reconheço que a memória está quase cheia e o MySQL não libera (mesmo depois de um dia sem nenhuma consulta e depois de reiniciar o MySQL), algo como um vazamento de memória ou um bug. O my.cnftamanho do buffer era innodb_buffer_pool_size=512Me depois de alterá-lo para, 2Gmas nada de útil aconteceu. Neste tutorial, usei o comando abaixo e vejo algo ruim:

Consulta:

select
page_type as Page_Type,
sum(data_size)/1024/1024 as Size_in_MB
from information_schema.innodb_buffer_page
group by page_type
order by Size_in_MB desc;

Resultado:

+--------------------------------+------------+------------+------------+
| Table_Name                     | Index_Name | Page_Count | Size_in_MB |
+--------------------------------+------------+------------+------------+
| `SYS_COLUMNS`                  | CLUST_IND  |          1 | 0.01321316 |
| `SYS_INDEXES`                  | CLUST_IND  |          1 | 0.00615215 |
| `SYS_FIELDS`                   | CLUST_IND  |          1 | 0.00364017 |
| `SYS_TABLES`                   | CLUST_IND  |          1 | 0.00293446 |
| `SYS_FOREIGN`                  | FOR_IND    |          1 | 0.00023651 |
| `SYS_FOREIGN`                  | REF_IND    |          1 | 0.00022316 |
| NULL                           | NULL       |     131055 | 0.00000000 |
| `mysql`.`slave_relay_log_info` | PRIMARY    |          1 | 0.00000000 |
| `mysql`.`slave_master_info`    | PRIMARY    |          1 | 0.00000000 |
| `mysql`.`slave_worker_info`    | PRIMARY    |          1 | 0.00000000 |
+--------------------------------+------------+------------+------------+
10 rows in set (1.49 sec)

Como você pode ver, uma linha NULLtem 131055page_count. E o resultado dos tipos de página no buffer pool é como abaixo:

Consulta:

select
page_type as Page_Type,
sum(data_size)/1024/1024 as Size_in_MB
from information_schema.innodb_buffer_page
group by page_type
order by Size_in_MB desc;

Resultado:

+-------------------+------------+
| Page_Type         | Size_in_MB |
+-------------------+------------+
| INDEX             | 0.02639961 |
| IBUF_INDEX        | 0.00000000 |
| INODE             | 0.00000000 |
| IBUF_BITMAP       | 0.00000000 |
| SYSTEM            | 0.00000000 |
| UNKNOWN           | 0.00000000 |
| FILE_SPACE_HEADER | 0.00000000 |
| UNDO_LOG          | 0.00000000 |
| TRX_SYSTEM        | 0.00000000 |
+-------------------+------------+
9 rows in set (1.04 sec)

O resultado de htopé como abaixo:

Você pode ver o uso e os processos do tamanho do cache mysqldenquanto qualquer carga não estiver no servidor MySQL.

Não entendo porque a memória (cache) não é liberada ou me pergunto se isso é um bug.

então criei uma replicação multi-mestre com servidores abaixo dois para mestre e dois para escravo.

nome do host: master-1 ip: 192.168.120.107

nome do host: master-2 ip: 192.168.120.111

nome do host: slave-1 ip: 192.168.120.117

nome do host: slave-2 ip: 192.168.120.118

os dois mestres (mestre-1, mestre-2) são implantados como replicação ativo-ativo e funcionam bem e abaixo estão os arquivos de configuração /etc/mysql/my.cnf:

mestre-1:

[mysqld]
#
# * Basic Settings
#
server-id       = 1
user            = root
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
log-bin         = master-bin
log-bin-index   = master-bin.index
relay-log       = slave-relay-bin
relay-log-index = slave-relay-bin.index
skip-external-locking

mestre-2:

[mysqld]
#
# * Basic Settings
#
server-id       = 2
user            = root
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
log-bin         = master-bin
log-bin-index   = master-bin.index
relay-log       = relay-log-bin
relay-log-index = relay-log-bin.index
skip-external-locking

mestres funcionam bem. os dois escravos são conectados aos mestres assim: escravo-1 é o escravo do mestre-1 e escravo-2 é o escravo do mestre-2. e estes são os arquivos de configuração:

escravo-1:

[mysqld]
#
# * Basic Settings
#
server-id       = 3
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
relay-log       = slave-relay-bin
relay-log-index = slave-relay-bin.index
skip-external-locking

escravo-2:

[mysqld]
#
# * Basic Settings
#
server-id       = 4
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
relay-log       = slave-relay-bin
relay-log-index = slave-relay-bin.index
skip-external-locking

quando um mestre faz alterações no banco de dados, seus escravos alteram dois, isso significa que funciona bem, por exemplo, quando mestre-1 altera o banco de dados, as alterações serão replicadas para mestre-2 e escravo-1 e as alterações também serão feitas neles. meu problema é que preciso que as mudanças aconteçam em todos os escravos, por exemplo, quando mestre-1 altera o banco de dados, escravo-2 altera seu banco de dados como mestre-2 e escravo-1. como posso fazer isso acontecer?