Este é meulogin.sql
SET sqlprompt "_user'@'_connect_identifier > "
SET sqlformat ansiconsole
SET serveroutput on
SET lines 3000
Como definir a sqlpromptcor vermelha para Prod (e a cor verde para teste)?
Versão
sql -version
SQLcl: Release 18.4.0.0 Production
Eu digito isso:
SQL> exec dbaspace.long_ops;
SID % Done Start Time Rem [s] Elapsed Message
==== ======= =================== ======= ======= ======================================================================================
There are currently no long running operations.
PL/SQL procedure successfully completed.
Eu pressiono a tecla SETA PARA CIMA para obter o último comando e o SQLcl modifica meu histórico assim:
SQL> BEGIN dbaspace.long_ops; END;;
Error starting at line : 1 in command -
BEGIN dbss.long_ops; END;;
Error report -
ORA-06550: line 1, column 26:
PLS-00103: Encountered the symbol ";"
06550. 00000 - "line %s, column %s:\n%s"
*Cause: Usually a PL/SQL compilation error.
*Action:
O comando de histórico reescrito não funciona
este é o nosso clássicotnsnames.ora
test1=
(DESCRIPTION=
(CONNECT_TIMEOUT=4)
(TRANSPORT_CONNECT_TIMEOUT=3)
(ENABLE=BROKEN)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=example1.example.com)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=example2.example.com)(PORT=1521))
)
(CONNECT_DATA=
(SERVER=DEDICATED)
(SERVICE_NAME=EXAMPLE.EXAMPLE.DBS)
)
)
Eu uso este comando SQLcl:
sql -nohistory -noupdates -S $username/$password@$hostname:$port/$servicename @$filename
Como especificar vários nomes de host? Não apenas um? É algum tipo de cluster passivo ativo (Exadata).
Edite após a primeira resposta:
Eu adicionei no script de shell (neste diretório tnsnames.ora):
TNS_ADMIN=/example/example
Eu ligo $sqlcl -nohistory -noupdates -S $username/$password@"MY-DB" @$filenamee recebo o erro:
./script.sh
USER = MY_USER
URL = jdbc:oracle:thin:@MY-DB
Error Message = IO Error: Unknown host specified
USER = MY_USER
URL = jdbc:oracle:thin:@MY-DB:1521/MY-DB
Error Message = IO Error: Invalid connection string format, a valid format is: "host:port:sid"
Encontrei uma pergunta semelhante para o SQL Server Management Studio . Mas eu uso o Azure Data Studio mais recente no macOS. Usamos o SQL Server local (não a nuvem do Azure).
Como posso usar o Azure Data Studio para gerar um ERD de um banco de dados existente?
Fiquei surpreso que xtrabackupsuporta backups incrementais. xtrabackupcopia os arquivos de dados e entende o formato dos arquivos de dados (pode dar uma olhada dentro)? O que é um LSN para manequins? Encontrei Qual é o número de seqüência de log? Como é usado no MySQL? .
Citação de Backup incremental
Um backup incremental copia cada página cujo LSN é mais recente que o LSN do backup incremental ou completo anterior. Existem dois algoritmos em uso para encontrar o conjunto de tais páginas a serem copiadas. A primeira, disponível com todos os tipos e versões de servidor, é verificar o LSN da página diretamente lendo todas as páginas de dados. A segunda, disponível com o Percona Server, é habilitar o recurso de rastreamento de página alterada no servidor, que observará as páginas conforme elas estão sendo alteradas. Esta informação será então escrita em um arquivo de bitmap separado e compacto. O binário xtrabackup usará esse arquivo para ler apenas as páginas de dados necessárias para o backup incremental, potencialmente salvando muitas solicitações de leitura. O último algoritmo é habilitado por padrão se o binário xtrabackup encontrar o arquivo de bitmap.
Ainda não entendi como isso funciona. Você usa xtrabackupBackup Incremental? Você recomenda xtrabackupBackup incremental?
Consulta:
SELECT Concat(t.table_schema, '.', t.table_name),
t.table_rows,
snu.non_unique,
smax.cardinality,
( t.table_rows / Ifnull(smax.cardinality, 1) ) AS
"medium distribution",
t.table_rows * ( t.table_rows / Ifnull(smax.cardinality, 1) ) AS
"replication row reads"
FROM information_schema.tables t
LEFT JOIN (SELECT table_schema,
table_name,
Max(cardinality) cardinality
FROM information_schema.statistics
GROUP BY table_schema,
table_name) AS smax
ON t.table_schema = smax.table_schema
AND t.table_name = smax.table_name
LEFT JOIN (SELECT table_schema,
table_name,
Min(non_unique) non_unique
FROM information_schema.statistics
GROUP BY table_schema,
table_name) AS snu
ON t.table_schema = snu.table_schema
AND t.table_name = snu.table_name
WHERE t.table_rows > 0
AND t.table_schema <> 'information_schema'
AND t.table_schema <> 'performance_schema'
AND t.table_schema <> 'mysql'
AND ( snu.non_unique IS NULL
OR snu.non_unique = 1 )
AND ( ( t.table_rows / Ifnull(smax.cardinality, 1) ) > 1.99 )
AND t.table_rows * ( t.table_rows / Ifnull(smax.cardinality, 1) ) >
100000
ORDER BY t.table_rows * ( t.table_rows / Ifnull(smax.cardinality, 1) ) DESC;
Versões:
(none)> show variables like '%version%';
+-------------------------+---------------------------+
| Variable_name | Value |
+-------------------------+---------------------------+
| innodb_version | 5.6.36-82.1 |
| protocol_version | 10 |
| slave_type_conversions | |
| version | 10.1.26-MariaDB |
| version_comment | Source distribution |
| version_compile_machine | x86_64 |
| version_compile_os | Linux |
| version_malloc_library | system |
| version_ssl_library | OpenSSL 1.0.1f 6 Jan 2014 |
| wsrep_patch_version | wsrep_25.19 |
+-------------------------+---------------------------+
10 rows in set
Time: 0.010s
Explique:
+----+-------------+------------+------+---------------+--------+---------+-------------------------------------------------------------------+--------+----------+--------------------------------------------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------+---------------+--------+---------+-------------------------------------------------------------------+--------+----------+--------------------------------------------------------------------------------------+
| 1 | PRIMARY | t | ALL | <null> | <null> | <null> | <null> | <null> | <null> | Using where; Open_full_table; Scanned all databases; Using temporary; Using filesort |
| 1 | PRIMARY | <derived2> | ref | key0 | key0 | 390 | information_schema.t.TABLE_SCHEMA,information_schema.t.TABLE_NAME | 2 | 100.0 | Using where |
| 1 | PRIMARY | <derived3> | ref | key0 | key0 | 390 | information_schema.t.TABLE_SCHEMA,information_schema.t.TABLE_NAME | 2 | 100.0 | Using where |
| 3 | DERIVED | statistics | ALL | <null> | <null> | <null> | <null> | <null> | <null> | Open_frm_only; Scanned all databases; Using temporary; Using filesort |
| 2 | DERIVED | statistics | ALL | <null> | <null> | <null> | <null> | <null> | <null> | Open_full_table; Scanned all databases; Using temporary; Using filesort |
+----+-------------+------------+------+---------------+--------+---------+-------------------------------------------------------------------+--------+----------+--------------------------------------------------------------------------------------+
5 rows in set
Time: 0.022s
Contar:
> select count('A') from information_schema.tables;
+------------+
| count('A') |
+------------+
| 7846 |
+------------+
1 row in set
Time: 0.069s
Parece que os indocumentados Open_full_table; Scanned all databases;demoram tanto assim? Como otimizar essa consulta ou essa duração é normal em um servidor ocupado?
Eu vi um novo recurso Colunas Invisíveis no MariaDB 10.3.x. Quais são os casos de uso práticos para DBA e desenvolvedor web? Quando usar esse recurso?
As colunas podem receber um
INVISIBLEatributo em uma instruçãoCREATE TABLEouALTER TABLE. Essas colunas não serão listadas nos resultados de umaSELECT *instrução, nem precisam receber um valor em umaINSERTinstrução, a menos queINSERTas mencione explicitamente pelo nome.Como
SELECT *não retorna as colunas invisíveis, novas tabelas ou visualizações criadas dessa maneira não terão vestígios das colunas invisíveis. Se especificamente referenciado naSELECTinstrução, as colunas serão trazidas para a visualização/nova tabela, mas oINVISIBLEatributo não.Colunas invisíveis podem ser declaradas como
NOT NULL, mas exigem umDEFAULTvalor
Encontrei um cara falando sobre semântica MDL em um relatório de bug Galera/XtraDB.
O que é MDL? O termo MDL também nos logs do Galera MDL conflict. Por favor, explique em detalhes.
2018-06-14 17:07:10 140112699321088 [Note] WSREP: cluster conflict due to certification failure for threads:
2018-06-14 17:07:10 140112699321088 [Note] WSREP: Victim thread:
2018-06-14 17:07:10 140112690834176 [Note] WSREP: cluster conflict due to high priority abort for threads:
2018-06-14 17:07:10 140112690834176 [Note] WSREP: Winning thread:
2018-06-14 17:07:10 140112690834176 [Note] WSREP: Victim thread:
2018-06-14 17:07:10 140112690834176 [Note] WSREP: MDL conflict db=APC_MYSQLMON_DB table=TABLE1 ticket=4 solved by abort
2018-06-14 17:07:10 140112695683840 [Note] WSREP: MDL conflict db=APC_MYSQLMON_DB table=TABLE1 ticket=8 solved by abort
2018-06-14 17:07:10 140112695683840 [Note] WSREP: cluster conflict due to certification failure for threads:
2018-06-14 17:07:10 140112695683840 [Note] WSREP: Victim thread:
2018-06-14 17:26:47 140112698108672 [Note] WSREP: cluster conflict due to certification failure for threads:
2018-06-14 17:26:47 140112698108672 [Note] WSREP: Victim thread:
2018-06-14 17:34:48 140087340817152 [Note] WSREP: cluster conflict due to certification failure for threads:
2018-06-14 17:34:48 140087340817152 [Note] WSREP: Victim thread:
2018-06-14 17:36:48 140076554697472 [Note] WSREP: cluster conflict due to high priority abort for threads:
2018-06-14 17:36:48 140076554697472 [Note] WSREP: Winning thread:
2018-06-14 17:36:48 140076554697472 [Note] WSREP: Victim thread:
2018-06-14 17:36:48 140076554697472 [Note] WSREP: MDL conflict db=APC_MYSQLMON_DB table=TABLE1 ticket=4 solved by abort
2018-06-14 17:36:48 140087340817152 [Note] WSREP: MDL conflict db=APC_MYSQLMON_DB table=TABLE1 ticket=8 solved by abort
2018-06-14 17:36:48 140087340817152 [Note] WSREP: cluster conflict due to certification failure for threads:
2018-06-14 17:36:48 140087340817152 [Note] WSREP: Victim thread:
2018-06-14 17:37:50 139917573339904 [Note] WSREP: cluster conflict due to certification failure for threads:
2018-06-14 17:37:50 139917573339904 [Note] WSREP: Victim thread:
2018-06-14 17:05:12 139927950939904 [Warning] WSREP: Failed to report last committed 1941199495, -4 (Interrupted system call)
2018-06-14 17:09:41 139900840323840 [Note] WSREP: cluster conflict due to high priority abort for threads:
2018-06-14 17:09:41 139900840323840 [Note] WSREP: Winning thread:
2018-06-14 17:09:41 139900840323840 [Note] WSREP: Victim thread:
Nossa configuração de VM (hospedada em VMware)
# cat /proc/cpuinfo |grep "cpu cores" | awk -F: '{ num+=$2 } END{ print "cpu cores", num }'
cpu cores 32
# free -h
total used free shared buffers cached
Mem: 62G 23G 39G 500K 349M 10G
-/+ buffers/cache: 12G 50G
Swap: 50G 0B 50G
Recebi do pt-variable-advisor um aviso sobre max_connections:
pt-variable-advisor h=localhost,u=root,p=Quule0juqu7aifohvo2Ahratit --socket /var/vcap/sys/run/mysql/mysqld.sock
(...)
# WARN max_connections: If the server ever really has more than a thousand threads running, then the system is likely to spend more time scheduling threads than really doing useful work.
(...)
Por quê? Algum detalhe?
Configuração em my.cnf
max_connections = 15360
configurações do cluster prd db (MariaDB 10.1.xe Galera)
MariaDB [(none)]> SHOW STATUS WHERE `variable_name` = 'Threads_connected';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_connected | 718 |
+-------------------+-------+
1 row in set (0.01 sec)
MariaDB [(none)]> SHOW STATUS WHERE `variable_name` = 'Max_used_connections';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Max_used_connections | 924 |
+----------------------+-------+
1 row in set (0.02 sec)
Encontrei um manual do MySQL e uma pergunta semelhante (muito) antiga .
O valor padrão é 151 para melhorar o desempenho
O número de conexões permitidas é controlado pela variável de sistema max_connections. O valor padrão é 151 para melhorar o desempenho quando o MySQL é usado com o servidor da Web Apache. (Anteriormente, o padrão era 100.) Se você precisar dar suporte a mais conexões, defina um valor maior para essa variável.
e
O número máximo de conexões que o MySQL suporta depende da qualidade da biblioteca de threads em uma determinada plataforma, da quantidade de RAM disponível, da quantidade de RAM usada para cada conexão, da carga de trabalho de cada conexão e do tempo de resposta desejado. Linux ou Solaris deve ser capaz de suportar pelo menos 500 a 1.000 conexões simultâneas rotineiramente e até 10.000 conexões
Atualmente temos 460 usuários e cada usuário pode fazer 100 max_connections. Este seria o valor máximo. O 100 max_connectionspor usuário e banco de dados é muito alto? Com o pool de conexões moderno, podemos definir isso para 20? Como devemos configurar para não correr o risco de sobrecarregar nosso servidor com troca de contexto? É possível que um aplicativo da Web use uma conexão (todas as instruções na mesma conexão)?
Eu corro pt-variable-advisore tenho uma nota sobre diferentes configurações para max_heap_table_sizee tmp_table_size.
Com uma pesquisa na web encontrei apenas artigos antigos (por volta de 2007).
pt-variable-advisor h=localhost,u=root,p=Quule0juqu7aifohvo2Ahratit --socket /var/vcap/sys/run/mysql/mysqld.sock
(...)
# NOTE tmp_table_size: The effective minimum size of in-memory implicit temporary tables used internally during query execution is min(tmp_table_size, max_heap_table_size), so max_heap_table_size should be at least as large as tmp_table_size.
(...)
Nossa configuração
max_heap_table_size = 16777216
tmp_table_size = 33554432
Nós não modificamos os padrões de cf-mysql-release . Vi que o MariaDB KB recomenda outros valores padrão.
cf_mysql.mysql.tmp_table_size:
description: 'The maximum size (in bytes) of internal in-memory temporary tables'
default: 33554432
cf_mysql.mysql.max_heap_table_size:
description: 'The maximum size (in rows) to which user-created MEMORY tables are permitted to grow'
default: 16777216
Encontrei também Optimize MySQL tmp_table_size e verifiquei nossos valores e a configuração:
MariaDB [(none)]> show global status like 'created_tmp_disk_tables';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Created_tmp_disk_tables | 12727901 |
+-------------------------+----------+
1 row in set (0.01 sec)
MariaDB [(none)]> show global status like 'created_tmp_tables';
+--------------------+-----------+
| Variable_name | Value |
+--------------------+-----------+
| Created_tmp_tables | 115714303 |
+--------------------+-----------+
1 row in set (0.01 sec)
MariaDB [(none)]> select (12727901*100)/(115714303 + 12727901) as "Created disk tmp tables ratio" from dual;
+-------------------------------+
| Created disk tmp tables ratio |
+-------------------------------+
| 9.9094 |
+-------------------------------+
1 row in set (0.00 sec)
Há algo errado com nossa configuração (padrão)? Não sabemos nossa carga de trabalho. Executamos cerca de 500 pequenos bancos de dados para pequenos aplicativos da web com diferentes padrões de uso.
Minhas versões instaladas do MariaDB e Percona Toolkit no MacBook:
brew info percona-toolkit
percona-toolkit: stable 3.0.10 (bottled), HEAD
Percona Toolkit for MySQL
https://www.percona.com/software/percona-toolkit/
/usr/local/Cellar/percona-toolkit/3.0.10 (244 files, 8.4MB) *
Poured from bottle on 2018-05-31 at 09:52:48
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/percona-toolkit.rb
==> Dependencies
Required: mysql ✔, openssl ✔
==> Options
--HEAD
Install HEAD version
Versões do servidor de banco de dados:
show global variables like '%version%';
+-------------------------+---------------------------+
| Variable_name | Value |
+-------------------------+---------------------------+
| innodb_version | 5.6.36-82.1 |
| protocol_version | 10 |
| slave_type_conversions | |
| version | 10.1.26-MariaDB |
| version_comment | Source distribution |
| version_compile_machine | x86_64 |
| version_compile_os | Linux |
| version_malloc_library | system |
| version_ssl_library | OpenSSL 1.0.1f 6 Jan 2014 |
| wsrep_patch_version | wsrep_25.19 |
+-------------------------+---------------------------+
10 rows in set (0.01 sec)
Engraçado é que para instalar o percona-toolkit eu tive que instalar o Oracle MySQL e depois mudar de volta para o MariaDB
brew install mariadb
brew unlink mariadb
brew install percona-toolkit
brew unlink mysql
brew link mariadb
Usamos o cluster Galera com replicação baseada em linha:
show global variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
1 row in set (0.00 sec)
Eu fiz um caso de uso simples:
mysqlbinlog mysql-bin.0013* > all.sql
pt-query-digest --type binlog all.sql
all.sql: 1% 37:37 remain
(...)
all.sql: 96% 01:23 remain
all.sql: 98% 00:30 remain
# 2417.5s user time, 51.4s system time, 89.16M rss, 4.24G vsz
# Current date: Fri Jun 1 07:42:57 2018
# Hostname: aukVivi0009
# Files: all.sql
# Overall: 0 total, 2.05k unique, 0 QPS, 0x concurrency __________________
# Time range: 2018-05-26 02:00:54 to 2018-05-31 08:05:28
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# Query size 10.68G 6 287.51k 492.88 833.10 1.92k 107.34
# Profile
# Rank Query ID Response time Calls R/Call V/M Item
# =========== =========== =========== =========== =========== ===== ======
por que a saída está vazia? Não pt-query-digesté compatível com MariaDB? Mudanças no formato de log binário? Alguma solução alternativa?
Durante o SST, meu diretório de dados se parece com isso (há um diretório oculto .sstcom xtrabackup):
-rw-rw---- 1 vcap vcap 113 Apr 16 08:13 grastate.dat
-rw-rw---- 1 vcap vcap 265 Apr 16 08:13 gvwstate.dat
-rw-rw---- 1 vcap vcap 0 Apr 16 08:13 sst_in_progress
-rw------- 1 vcap vcap 536872232 Apr 16 08:29 galera.cache
-rw------- 1 vcap vcap 134217728 Apr 16 08:32 gcache.page.000000
-rw------- 1 vcap vcap 134217728 Apr 16 08:36 gcache.page.000001
-rw------- 1 vcap vcap 134217728 Apr 16 08:40 gcache.page.000002
-rw------- 1 vcap vcap 134217728 Apr 16 08:44 gcache.page.000003
-rw------- 1 vcap vcap 134217728 Apr 16 08:48 gcache.page.000004
-rw------- 1 vcap vcap 134217728 Apr 16 08:52 gcache.page.000005
-rw------- 1 vcap vcap 134217728 Apr 16 08:56 gcache.page.000006
-rw------- 1 vcap vcap 134217728 Apr 16 09:00 gcache.page.000007
-rw------- 1 vcap vcap 134217728 Apr 16 09:03 gcache.page.000008
-rw------- 1 vcap vcap 134217728 Apr 16 09:07 gcache.page.000009
-rw------- 1 vcap vcap 134217728 Apr 16 09:11 gcache.page.000010
-rw------- 1 vcap vcap 134217728 Apr 16 09:15 gcache.page.000011
-rw------- 1 vcap vcap 134217728 Apr 16 09:19 gcache.page.000012
-rw-r----- 1 vcap vcap 366 Apr 16 09:20 mysql-bin.000021
-rw-rw---- 1 vcap vcap 19 Apr 16 09:20 mysql-bin.index
-rw------- 1 vcap vcap 134217728 Apr 16 09:23 gcache.page.000013
-rw------- 1 vcap vcap 134217728 Apr 16 09:27 gcache.page.000014
-rw------- 1 vcap vcap 134217728 Apr 16 09:30 gcache.page.000015
-rw------- 1 vcap vcap 134217728 Apr 16 09:32 gcache.page.000016
Pelo que entendi, as gravações durante o SST são armazenadas nos gcache.page.0000*arquivos. Isso está correto? Definimos o tamanho para max. 512 MB ( gcache.size). O que acontece se atingirmos o máximo? Se durante SST 2 GB inseridos?
2018-04-16 8:29:00 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000000 of size 134217728 bytes
2018-04-16 8:32:54 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000001 of size 134217728 bytes
2018-04-16 8:36:48 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000002 of size 134217728 bytes
2018-04-16 8:40:41 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000003 of size 134217728 bytes
2018-04-16 8:44:33 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000004 of size 134217728 bytes
2018-04-16 8:48:26 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000005 of size 134217728 bytes
2018-04-16 8:52:19 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000006 of size 134217728 bytes
2018-04-16 8:56:12 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000007 of size 134217728 bytes
2018-04-16 9:00:05 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000008 of size 134217728 bytes
2018-04-16 9:03:57 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000009 of size 134217728 bytes
2018-04-16 9:07:50 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000010 of size 134217728 bytes
2018-04-16 9:11:42 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000011 of size 134217728 bytes
2018-04-16 9:15:34 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000012 of size 134217728 bytes
2018-04-16 9:19:33 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000013 of size 134217728 bytes
2018-04-16 9:23:23 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000014 of size 134217728 bytes
2018-04-16 9:27:02 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000015 of size 134217728 bytes
2018-04-16 9:30:40 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000016 of size 134217728 bytes
2018-04-16 9:34:18 140448739440384 [Note] WSREP: Created page /var/vcap/store/mysql/gcache.page.000017 of size 134217728 bytes
2018-04-16 9:34:58 140449443399552 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2018-04-16 9:35:07 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000000
2018-04-16 9:35:08 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000001
2018-04-16 9:35:09 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000002
2018-04-16 9:35:11 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000003
2018-04-16 9:35:12 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000004
2018-04-16 9:35:13 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000005
2018-04-16 9:35:15 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000006
2018-04-16 9:35:16 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000007
2018-04-16 9:35:17 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000008
2018-04-16 9:35:19 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000009
2018-04-16 9:35:20 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000010
2018-04-16 9:35:21 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000011
2018-04-16 9:35:22 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000012
2018-04-16 9:35:32 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000013
2018-04-16 9:35:45 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000014
2018-04-16 9:35:59 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000015
2018-04-16 9:36:13 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000016
2018-04-16 9:36:16 140448383366912 [Note] WSREP: Deleted page /var/vcap/store/mysql/gcache.page.000017
2018-04-16 9:36:27 140436269124352 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool
2018-04-16 9:36:39 140588932401024 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2018-04-16 9:37:55 140579234867968 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool
Vejo em lotes de saída de SHOW FULL PROCESSLISTapenas COMMITou commit(mistura de letras minúsculas e maiúsculas). Quais são essas transações? Por que nenhuma instrução SQL? Estamos executando MariaDB 10.1.xe replicação Galera (3 nós).
Como interpretar essas transações?
> select COMMAND,TIME,STATE,INFO,TIME_MS,STAGE,MAX_STAGE,PROGRESS,MEMORY_USED,EXAMINED_ROWS,QUERY_ID,INFO_BINARY,TID from INFORMATION_SCHEMA.PROCESSLIST where INFO like '%commit%';
+---------+------+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+-------+-----------+----------+-------------+---------------+-----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------+
| COMMAND | TIME | STATE | INFO | TIME_MS | STAGE | MAX_STAGE | PROGRESS | MEMORY_USED | EXAMINED_ROWS | QUERY_ID | INFO_BINARY | TID |
+---------+------+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+-------+-----------+----------+-------------+---------------+-----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------+
| Query | 1 | init | COMMIT | 1267.015 | 0 | 0 | 0.000 | 67544 | 0 | 483610134 | COMMIT | 12241 |
| Query | 112 | init | COMMIT | 112442.763 | 0 | 0 | 0.000 | 67544 | 0 | 483594429 | COMMIT | 12003 |
| Query | 151 | init | COMMIT | 151914.251 | 0 | 0 | 0.000 | 67544 | 0 | 483588122 | COMMIT | 11972 |
| Query | 156 | init | COMMIT | 156962.716 | 0 | 0 | 0.000 | 141368 | 0 | 483587455 | COMMIT | 11962 |
| Query | 156 | init | COMMIT | 156961.757 | 0 | 0 | 0.000 | 141368 | 0 | 483587456 | COMMIT | 11960 |
| Query | 182 | init | commit | 182230.206 | 0 | 0 | 0.000 | 67544 | 0 | 483584325 | commit | 11801 |
| Query | 229 | init | COMMIT | 229144.061 | 0 | 0 | 0.000 | 67544 | 0 | 483578193 | COMMIT | 11529 |
| Query | 0 | Filling schema table | select COMMAND,TIME,STATE,INFO,TIME_MS,STAGE,MAX_STAGE,PROGRESS,MEMORY_USED,EXAMINED_ROWS,QUERY_ID,INFO_BINARY,TID from INFORMATION_SCHEMA.PROCESSLIST where INFO like '%commit%' | 0.346 | 0 | 0 | 0.000 | 104808 | 0 | 483610236 | select COMMAND,TIME,STATE,INFO,TIME_MS,STAGE,MAX_STAGE,PROGRESS,MEMORY_USED,EXAMINED_ROWS,QUERY_ID,INFO_BINARY,TID from INFORMATION_SCHEMA.PROCESSLIST where INFO like '%commit%' | 11359 |
| Query | 66 | init | commit | 66835.790 | 0 | 0 | 0.000 | 67544 | 0 | 483601099 | commit | 10917 |
| Query | 353 | init | commit | 353104.108 | 0 | 0 | 0.000 | 67544 | 0 | 483561401 | commit | 10807 |
| Query | 494 | init | COMMIT | 494696.772 | 0 | 0 | 0.000 | 338232 | 0 | 483540392 | COMMIT | 9997 |
Citação de openark-kit . O software parece não ser mantido (hospedado no Google Code e último commit de 2013).
oak-show-limits: mostra
AUTO_INCREMENT“espaço livre”.
O que é isto? Como ver AUTO_INCREMENT“espaço livre” sem esta ferramenta?
Criei um usuário com privilégios totais em seu próprio banco de dados ( dbOwner) e acesso somente leitura aos comandos administrativos ( clusterMonitor)
use customerdb
(mongod-3.4.7) customerdb> db.createUser( { user: "customer",
... pwd: "customerpw",
... roles: [ { role: "clusterMonitor", db: "admin" },
... { role: "dbOwner", db: "customerdb" }] },
... { w: "majority" , wtimeout: 5000 } )
Successfully added user: {
"user": "customer",
"roles": [
{
"role": "clusterMonitor",
"db": "admin"
},
{
"role": "dbOwner",
"db": "customerdb"
}
]
}
Autenticação habilitada e logada com o novo usuário. É uma instância única do MongoDB instalada no Homebrew com a versão mais recente.
$ mongo -u customer -p customerpw localhost --authenticationDatabase=customerdb
Por getRoles()que me mostra o enableShardingpapel? não encontrei explicação nos documentos
> db.getRoles(
... {
... rolesInfo: 1,
... showPrivileges:false,
... showBuiltinRoles: true
... }
... )
[
{
"role": "dbAdmin",
"db": "customerdb",
"isBuiltin": true,
"roles": [ ],
"inheritedRoles": [ ]
},
{
"role": "dbOwner",
"db": "customerdb",
"isBuiltin": true,
"roles": [ ],
"inheritedRoles": [ ]
},
{
"role": "enableSharding",
"db": "customerdb",
"isBuiltin": true,
"roles": [ ],
"inheritedRoles": [ ]
},
{
"role": "read",
"db": "customerdb",
"isBuiltin": true,
"roles": [ ],
"inheritedRoles": [ ]
},
{
"role": "readWrite",
"db": "customerdb",
"isBuiltin": true,
"roles": [ ],
"inheritedRoles": [ ]
},
{
"role": "userAdmin",
"db": "customerdb",
"isBuiltin": true,
"roles": [ ],
"inheritedRoles": [ ]
}
]
os privilégios da função enableSharding
{
"role": "enableSharding",
"db": "customerdb",
"isBuiltin": true,
"roles": [ ],
"inheritedRoles": [ ],
"privileges": [
{
"resource": {
"db": "",
"collection": ""
},
"actions": [
"enableSharding"
]
}
],
"inheritedPrivileges": [
{
"resource": {
"db": "",
"collection": ""
},
"actions": [
"enableSharding"
]
}
]
}
Eu testei isso em um cluster fragmentado em mongos com a versão:
MongoDB Enterprise mongos> db.version()
3.2.11
e também no MacBook com mongod único e versão 3.4.7
Acho que estou fazendo algo errado como crio usuários e concedo funções?
Testei rápido e sujo --no-autocommitvs. sem esta opção no MacBook (instalado com o Homebrew mais recente MariaDB). Eu restaurei para um MariaDB vazio um arquivo *.sql de 4,6 GB. O despejo feito sem --no-autocommitlevou 5m42.072s para restaurar e com --no-autocommitele demorou 1 minuto a mais.
Outras opções usadas para despejo são--max_allowed_packet=1G --flush-logs --single-transaction --all-databases
set autocommit=0;
INSERT INTO ...
UNLOCK TABLES;
commit;
Quando usar --no-autocommit? Em que caso de uso esta opção faz sentido?
mysqltuner.plme mostra resultado
[!!] 2 different collations for database ccdb
Eu não vejo dois diferentes COLLATEno nível de banco de dados. Isso é mesmo possível? Como verificar?
> show create database ccdb;
+----------+---------------------------------------------------------------------------------------+
| Database | Create Database |
+----------+---------------------------------------------------------------------------------------+
| ccdb | CREATE DATABASE `ccdb` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci */ |
+----------+---------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
> select * from information_schema.schemata where schema_name = 'ccdb';
+--------------+-------------+----------------------------+------------------------+----------+
| CATALOG_NAME | SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | SQL_PATH |
+--------------+-------------+----------------------------+------------------------+----------+
| def | ccdb | utf8 | utf8_unicode_ci | NULL |
+--------------+-------------+----------------------------+------------------------+----------+
1 row in set (0.00 sec)
Eu vejo diferente TABLE_COLLATION. Isso é um problema?
> SELECT count(*), TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA='ccdb' group by TABLE_COLLATION;
+----------+-----------------+
| count(*) | TABLE_COLLATION |
+----------+-----------------+
| 29 | utf8_bin |
| 26 | utf8_general_ci |
+----------+-----------------+
2 rows in set (0.00 sec)
> select version();
+-----------------+
| version() |
+-----------------+
| 10.1.20-MariaDB |
+-----------------+
1 row in set (0.00 sec)
Esta Consulta verifica apenas um documento e retorna apenas um documento. Mas isso é muito lento:
2017-05-22T07:13:24.548+0000 I COMMAND [conn40] query databasename.collectionname query: { _id: ObjectId('576d4ce3f2d62a001e84a9b8') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8009ms
2017-05-22T07:13:24.549+0000 I COMMAND [conn10] query databasename.collectionname query: { _id: ObjectId('576d4db35de5fa001ebdd77a') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8010ms
2017-05-22T07:13:24.553+0000 I COMMAND [conn47] query databasename.collectionname query: { _id: ObjectId('576d44b7ea8351001ea5fb22') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8014ms
2017-05-22T07:13:24.555+0000 I COMMAND [conn52] query databasename.collectionname query: { _id: ObjectId('576d457ceb82a0001e205bfa') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8015ms
2017-05-22T07:13:24.555+0000 I COMMAND [conn41] query databasename.collectionname query: { _id: ObjectId('576d457ec0697c001e1e1779') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8015ms
2017-05-22T07:13:24.555+0000 I COMMAND [conn39] query databasename.collectionname query: { _id: ObjectId('576d44b8ea8351001ea5fb27') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8015ms
2017-05-22T07:13:24.561+0000 I COMMAND [conn34] query databasename.collectionname query: { _id: ObjectId('576d44b55de5fa001ebdd31e') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8022ms
2017-05-22T07:13:24.564+0000 I COMMAND [conn32] query databasename.collectionname query: { _id: ObjectId('576d4df6d738a7001ef2a235') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8025ms
2017-05-22T07:13:24.564+0000 I COMMAND [conn51] query databasename.collectionname query: { _id: ObjectId('576d48165de5fa001ebdd55a') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8024ms
2017-05-22T07:13:24.564+0000 I COMMAND [conn17] query databasename.collectionname query: { _id: ObjectId('576d44c19f2382001e953717') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8025ms
2017-05-22T07:13:24.564+0000 I COMMAND [conn8] query databasename.collectionname query: { _id: ObjectId('576d45d256c22e001efdb382') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8025ms
2017-05-22T07:13:24.564+0000 I COMMAND [conn42] query databasename.collectionname query: { _id: ObjectId('576d44bd57c75e001e6e2302') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8025ms
2017-05-22T07:13:24.564+0000 I COMMAND [conn6] query databasename.collectionname query: { _id: ObjectId('576d44b394e731001e7cd530') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8025ms
2017-05-22T07:13:24.571+0000 I COMMAND [conn31] query databasename.collectionname query: { _id: ObjectId('576d4dbcb7289f001e64e32b') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8032ms
Isso parece uma E/S de disco muito lenta. O que planSummary: IDHACKsignifica? Mais alguma informação para IDHACK?
Preciso testar a restauração com o Ops Manager. Para isso, "clonei" o cluster fragmentado de produção. Crio VMs com o mesmo tamanho de produção e faço mongodump/mongorestore(Ops Manager Deployment). Meu teste (para restauração) não precisa ser uma cópia consistente, para mim não há problema se faltar cerca de 5 GB.
DATA SIZE: 573.6 GB
shard0
142.6 GB
shard1
145.94 GB
shard2
142.55 GB
shard3
142.52 GB
Por motivos de simplicidade, desejo pegar um mongodump e canalizá-lo para o mongorestore no arquivo mongos.
Encontrei um documento antigo (v3.0) Faça backup de um pequeno cluster fragmentado com mongodump . Esta documentação não existe mais nas novas versões do MongoDB.
Se o seu cluster fragmentado contém um pequeno conjunto de dados, você pode se conectar a um mongos usando o mongodump.
o que é um pequeno conjunto de dados em GB? Veja acima para minha implantação.
Se você usar o mongodump sem especificar um banco de dados ou uma coleção, o mongodump capturará os dados da coleção e os metadados do cluster dos servidores de configuração.
Eu não preciso fazer backup explicitamente config RS?
Ao restaurar dados para o cluster fragmentado, você deve implantar e configurar a fragmentação antes de restaurar os dados do backup. Consulte Implantar um cluster fragmentado para obter mais informações.
Significa em inglês claro que preciso definir o shard key (and enable sharding)antes da restauração?
Perco alguma etapa/coisa importante?
O que é um InnoDB Page checksumexatamente? Um Page checksumsó detecta problemas com armazenamento subjacente ao gravar ou ler em uma página/bloco?