SHOW PROCESSLISTmostra a lista de processos apenas para o usuário e a sessão atuais.
Existe uma maneira de o usuário atual listar todos os seus processos para todas as sessões atualmente abertas?
Eu tenho uma pergunta sobre a ALTER TABLE ... ADD COLUMNinstrução DDL .
Em uma instância do Amazon RDS com MariaDB v10.2, notei que INSERTas instruções são concluídas e as linhas são inseridas corretamente na tabela (conforme verificado via SELECT) antes que um ALTER TABLE ... ADD COLUMNna tabela seja concluído.
Nenhuma instrução DML que executa uma gravação deve ser enfileirada até que a ALTER TABLEoperação termine?
Estou postando esta pergunta porque me pediram para realizar alguns testes para verificar se é possível executar ALTER TABLE ... ADD COLUMNem um banco de dados de produção ativo em horário comercial, em um banco de dados muito usado, em tabelas com vários milhões de linhas - o que eu achar muito desaconselhável. Mesmo que ALTER TABLEnão coloque um bloqueio na tabela, terá que esperar até que alguma conexão não esteja mais usando a tabela (devido à conexão colocar um bloqueio de metadados ), o que pode acontecer muito mais tarde.
EDIT: Aparentemente esta avaliação foi muito pessimista. Eu tenho feito vários testes mysqlslaprealizando operações pesadas na tabela ( INSERT, UPDATE, DELETEdeclarações e SELECTdeclarações comLIKEpara evitar o uso de índices) em 150 conexões simultâneas simuladas durante a ALTER TABLE ... ADD COLUMNexecução; a criação de perfil mostra bloqueios de metadados, mas com tempos de espera curtos (1 segundo cada), e a alteração da tabela é concluída em cerca de 30 minutos, em comparação com 10 minutos sem nenhuma instrução SQL em execução. Embora isso seja satisfatório, por outro lado, gostaria de saber se é seguro assumir que as instruções DDL não são bloqueantes.
(Provavelmente vale a pena notar que existe um recurso Instant ADD COLUMNno InnoDB , que permite a adição instantânea de uma coluna à tabela (sob restrições específicas), mas não está disponível antes da v10.3.2.)
Aqui está um trecho da saída da ferramenta Percona pt-duplicate-key-checkerque procura por índices redundantes:
# Key myidx ends with a prefix of the clustered index
# Key definitions:
# KEY `myidx` (`bar`,`foo`)
# PRIMARY KEY (`foo`),
# Column types:
# `bar` mediumint(8) unsigned not null default '0'
# `foo` mediumint(8) unsigned not null auto_increment
# To shorten this duplicate clustered index, execute:
ALTER TABLE `mydb`.`mytable` DROP INDEX `myidx`, ADD INDEX `myidx` (`bar`);
Por que a ferramenta sugere isso? O índice composto original não pode ser útil?
Pelo que entendi, um índice em barvaleria a pena ser apagado dado um PK (bar,foo), mas não é o caso aqui.
Estou auditando o esquema de um banco de dados MySQL usado por um aplicativo de comércio eletrônico pronto para uso e encontrei isso como saída de SHOW CREATE TABLE thistable:
CREATE TABLE `thistable`
(
`case_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`company_id` int(11) NOT NULL DEFAULT '0',
(...)
`timestamp` int(11) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`case_id`),
KEY `idx_case_id` (`case_id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=21688281 DEFAULT CHARSET=utf8
Ele adiciona explicitamente um índice em uma chave primária.
Isso é um erro do designer de banco de dados ou existe realmente uma razão para isso?
Vale a pena notar que esta tabela era de origem MyISAM.
Em um servidor MySQL 5.6, a mysql.usertabela contém um usuário com um nome de host vazio ( 'jdoe'@''). O que isso significa?
Estou gerenciando um site de comércio eletrônico que usa um popular software de carrinho de compras on-line executado no MySQL 5.6. Ontem notei que SHOW PROCESSLISTrelata que 990 de 1000 consultas estão aguardando um bloqueio de cache de consulta:
mysql> show processlist;
+----------+------------+---------------------+-------------+---------+------+--------------------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----------+------------+---------------------+-------------+---------+------+--------------------------------+------------------------------------------------------------------------------------------------------+
| 12224065 | sqluser | 10.13.13.13:21716 | mydatabase | Query | 0 | Waiting for query cache lock | SELECT `data` FROM mytable WHERE `foo` = 'bar' |
(...)
No entanto, o tempo é sempre 0 e os IDs do processo mudam o tempo todo. Meu entendimento é que a consulta aguarda um bloqueio de tabela, mas o bloqueio é liberado em menos de um segundo.
Este é um comportamento normal/aceitável ou vale a pena fazer alguns ajustes no cache de consulta, talvez removê-lo completamente?
Como você obtém o tamanho (em bytes) do resultado de uma consulta SQL, no MySQL 5.6?
EXPLAINretornará o número de linhas buscadas, mas não seu tamanho.
Meu objetivo é avaliar consultas comuns para saber um valor de limite inferior para query_cache_limitque possam ser atendidas pelo Query Cache.
Esta tabela MySQL me deixou perplexo por um momento:
mysql> desc quux;
+---------------------------+-----------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------+-----------------------+------+-----+---------+----------------+
| foobar | int(11) | NO | | NULL | |
(...)
mysql> show create table quux;
(...)
`foobar` int(11) NOT NULL,
(...)
Como o foobarcampo nunca foi criado com uma cláusula DEFAULT, ele é automaticamente atribuído a DEFAULT NULL. No entanto, à primeira vista, isso parece contradizer o fato de que também foi definido como NOT NULL.
Então percebi que esse esquema visa forçar a inserção de um valor (e não NULL) foobarao adicionar um novo registro.
Essa é uma maneira aceitável de fazer isso ou há maneiras melhores?
Precisamos restaurar um banco de dados de um arquivo mysqldump de 7 Gb para uma instância RDS Amazon. A restauração completa leva entre 3 e 4 horas (provavelmente devido à latência da rede, já que o despejo deve residir em um EC2) e é muito longo para nós. Para referência, uma restauração para um mysqld local levaria menos de 30 minutos.
Existe uma solução relacionada à Amazon que nos permita reduzir o tempo de importação?
Perguntas sobre como otimizar um tempo de restauração do mysqldump foram feitas antes, como:
- Acelerando mysqldump / recarregar
- MySQL alguma maneira de importar um dump sql enorme (32 GB) mais rápido?
- Tempos razoáveis para uma restauração do mysqldump?
- Configurações do MySQL úteis para acelerar uma importação mysqldump
No entanto, esta questão é diferente porque se refere a uma instância RDS, então:
- Restrições adicionais são aplicadas, por exemplo, algumas variáveis do MySQL (por exemplo
innodb_doublewrite) não podem ser alteradas para melhorar o desempenho - Pode haver alguma solução ou produto nativo da Amazon que resolveria esse problema de maneira fácil e agradável
Recentemente, tive que importar um arquivo dump MySQL de 7 Gb para um servidor MySQL 5.6. A importação levou cerca de 7 horas em uma CPU mono-core com 1 Gb de RAM.
Outra pessoa testou a importação em um servidor MySQL que possui, entre outras, as seguintes configurações:
innodb_buffer_pool_size = 8G
query_cache_size = 300M
Estou um pouco cético sobre a relevância dessas configurações (e sim, até acho que definir um cache de consulta tão grande é ruim ). Faria diferença? Essas configurações não são usadas apenas ao consultar o banco de dados e, portanto, irrelevantes para uma importação?
Se sim, quais configurações devem ser definidas para acelerar a importação de um grande arquivo dump?
De acordo com a documentação oficial, esses valores devem ser definidos temporariamente:
unique_checks = 0
foreign_key_checks = 0
Eu li aqui que deve ser definido também
innodb_flush_log_at_trx_commit = 2
mas não acho que ajudaria, porque o modo de confirmação automática (liberação de logs no disco para cada inserção) já está desabilitado por padrão no comando mysqldump ( --optopção).
O MySQL permite o uso de curingas para nomes de bancos de dados, a fim de permitir que um usuário opere apenas em um subconjunto de bancos de dados:
GRANT ALL PRIVILEGES ON `foobar%`.* TO 'user'@'%' IDENTIFIED BY 'somepassword';
Existe uma maneira de fazer o mesmo para a concessão CREATE, para permitir (cf. o exemplo acima) criaruser apenas bancos de dados cujo nome começa com ?foobar
Dito de outra forma: a concessão CREATE é global (ou seja, um usuário com esse privilégio pode criar qualquer banco de dados, sem limitações) ou pode ser limitado de alguma forma?
Estou utilizando um sistema de monitoramento de banco de dados que, entre outros dados, mostra os seguintes valores para consultas SELECT:
- número de junções que usam intervalos na primeira tabela
- número de junções que fazem uma varredura completa da primeira tabela
- número de junções sem chaves que verificam o uso da chave após cada linha
- número de junções que executam varreduras de tabela porque não usam índices
- número de junções que usam uma pesquisa de intervalo em uma tabela de referência
Dessas consultas, quais são as de menor desempenho e, portanto, devem ser otimizadas primeiro? Eu diria os números 2 e 4 em ordem de importância, mas também gostaria de ouvir comentários sobre os outros tipos.
Esse sistema de monitoramento mostra também o número total de consultas SELECT como a soma desses cinco valores. Esses são todos os casos possíveis e mutuamente exclusivos para um SELECT?
Não estou falando de uma consulta específica (que posso encontrar no log de consultas lentas); Estou mais interessado no tipo de consulta entre esses 5 listados acima. Por exemplo, varreduras completas de tabelas geralmente são ruins (a menos que estejamos trabalhando em tabelas pequenas, caso em que não nos importaremos com a otimização).
Minha outra dúvida era se esses tipos podem estar se sobrepondo, pois o sistema de monitoramento mostra um 6º valor que é a soma desses cinco, e isso não faz sentido se os tipos não forem mutuamente exclusivos (como suspeitamos).
Esta consulta imprime o tamanho (em termos de dados e índices) das tabelas em mydatabase :
SELECT table_name "Table name",
round(((data_length)/1024/1024),2) "Data size",
round(((index_length)/1024/1024),2) "Index size"
FROM information_schema.TABLES
WHERE table_schema="mydatabase" AND data_length>1000000
order by table_name INTO OUTFILE '/tmp/mydatabase_values'
FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';
Os tamanhos são impressos em Mb, sendo consideradas apenas tabelas maiores que 1Mb. As tabelas são listadas em ordem alfabética e a saída é salva em um arquivo CSV.
A execução dessa consulta em diferentes pontos no tempo mostrou - obviamente - resultados diferentes à medida que os dados foram alterados no banco de dados. No entanto, apenas nas últimas semanas a consulta produziu resultados idênticos. Isso significa que o tamanho do banco de dados não mudou muito (como você pode ver, o arredondamento é feito no limite de 10Kb) ou há algo que realmente estou perdendo? A pergunta pode parecer absurda, mas as visualizações INFORMATION_SCHEMAsempre mantêm metadados atualizados?
Observação: não, não estou lendo todas as vezes o mesmo arquivo CSV por engano.
Editar: todas as tabelas são InnoDB e innodb_file_per_table=1.
Em um cluster MySQL, faz sentido armazenar arquivos de banco de dados MySQL e binlogs em diferentes partições?
(Trata-se de partições no mesmo disco físico. Se estivessem em discos físicos diferentes, a resposta seria sim - para permitir leituras e gravações paralelas.)
Pode-se pensar que, ao separar datadir e binlog dir em diferentes partições, se um for preenchido, o outro continua a ter espaço livre. Mas, na verdade, isso não importa, pois qualquer um desses dois eventos interromperia a replicação ou o servidor MySQL. Por outro lado, uma única partição para datadir e binlogs permitiria que eles compartilhassem o espaço livre disponível e, portanto, oferecessem mais espaço para expansão.
Por esse motivo, não parece haver nenhuma desvantagem em compartilhar uma partição, embora possa haver algumas vantagens. Há mais alguma coisa a ter em consideração?
Tenho em minhas mãos um cluster Percona XtraDB de 3 nós onde, de acordo com mysqlcheck, algumas tabelas estão corrompidas (alguns índices contêm o número errado de entradas):
mydb.mytable
Warning : InnoDB: Index 'foo' contains 1393929 entries, should be 1393918.
Warning : InnoDB: Index 'bar' contains 1393921 entries, should be 1393918.
error : Corrupt
Qual é a melhor prática para executar OPTIMIZE TABLEem um cluster?
Fiz alguns experimentos em um ambiente de teste sem usuários e parece que um OPTIMIZE TABLEem um nó não propaga automaticamente seu efeito para os outros nós. Isso é consistente com o fato de que este comando modifica os índices e o espaço de armazenamento da tabela, não seu conteúdo ou sua definição.
Quais poderiam ser as desvantagens de executar o comando em um ambiente de produção em cada nó, deixando-o completo antes de executá-lo no nó seguinte?
Qual seria o efeito sobre os usuários, considerando que o MySQL (e o Percona XtraDB Cluster, até onde eu sei) não suporta bloqueios de tabelas distribuídas? Isso deixaria o cluster em um estado inconsistente?
Eu gerencio um Percona XtraDB Cluster que usa um armazenamento de rede com uma conexão oscilante. Periodicamente, experimentamos um alto iowait com travamentos e remontagem do fs em somente leitura. Substituir o armazenamento, infelizmente, não é uma opção por enquanto.
Recentemente, notei que quando mysqldump ou mysqlcheck são executados, eles travam o servidor MySQL no nó, com um erromysqlcheck: Got error: 2013: Lost connection to MySQL server during query when executing 'CHECK TABLE ... '
Aqui está o conteúdo de mysqld.logdurante o acidente:
InnoDB: Error in pages 9479 and 9480 of index "PRIMARY" of table "foobar"."quux"
InnoDB: broken FIL_PAGE_NEXT or FIL_PAGE_PREV links
2015-09-28 14:39:45 7f015813b700 InnoDB: Page dump in ascii and hex (16384 bytes):
(...)
InnoDB: End of page dump
2015-09-28 14:39:45 7f015813b700 InnoDB: uncompressed page, stored checksum in field1 4038097986, calculated checksums for field1: crc32 2787032309, innodb 4038097986, none 3735928559, stored checksum in field2 1190336748, calculated checksums for field2: crc32 2787032309, innodb 1190336748, none 3735928559, page LSN 4 3652646491, low 4 bytes of LSN at page end 3652646491, page number (if stored to page already) 9479, space id (if created with >= MySQL-4.1.1 and stored already) 18
InnoDB: Page may be an index page where index id is 67
InnoDB: (index "PRIMARY" of table "foobar"."quux")
2015-09-28 14:39:45 7f015813b700 InnoDB: Page dump in ascii and hex (16384 bytes):
(...)
InnoDB: End of page dump
2015-09-28 14:39:46 7f015813b700 InnoDB: uncompressed page, stored checksum in field1 554678569, calculated checksums for field1: crc32 2178598661, innodb 554678569, none 3735928559, stored checksum in field2 1065260512, calculated checksums for field2: crc32 2178598661, innodb 1065260512, none 3735928559, page LSN 10 202985777, low 4 bytes of LSN at page end 202985777, page number (if stored to page already) 6792, space id (if created with >= MySQL-4.1.1 and stored already) 18
InnoDB: Page may be an index page where index id is 67
InnoDB: (index "PRIMARY" of table "foobar"."quux")
InnoDB: Corruption of an index tree: table "foobar"."quux", index "PRIMARY",
InnoDB: father ptr page no 55234, child page no 9479
PHYSICAL RECORD: n_fields 14; compact format; info bits 0
0: len 30; hex 34616434393538322d353232372d653863302d326466662d353461663639; asc 4ad49582-5227-e8c0-2dff-54af69; (total 36 bytes);
1: len 6; hex 000000000dd7; asc ;;
2: len 7; hex c8000001741ea1; asc t ;;
3: len 5; hex 99951259cb; asc Y ;;
4: len 5; hex 99951259cb; asc Y ;;
5: len 30; hex 62633965323864352d383865382d343466322d393337322d353339303931; asc bc9e28d5-88e8-44f2-9372-539091; (total 36 bytes);
6: len 30; hex 62633965323864352d383865382d343466322d393337322d353339303931; asc bc9e28d5-88e8-44f2-9372-539091; (total 36 bytes);
7: len 1; hex 80; asc ;;
8: len 30; hex 64356664666538352d656431652d346465362d383363612d616439663164; asc d5fdfe85-ed1e-4de6-83ca-ad9f1d; (total 36 bytes);
9: len 8; hex 436f6e7461637473; asc Contacts;;
10: len 4; hex 6c696e6b; asc link;;
11: len 30; hex 7b226f626a656374223a7b226e616d65223a224d72204a6f7264616e204e; asc {"object":{"name":"Mr John Hacker; (total 343 bytes);
12: len 4; hex 80000000; asc ;;
13: len 30; hex 7b226e616d65223a22222c22646f635f6f776e6572223a22222c22757365; asc {"name":"","doc_owner":"","use; (total 72 bytes);
n_owned: 0; heap_no: 2; next rec: 751
PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 30; hex 34616435616262302d303535662d333939612d613038652d353439396461; asc 4ad5abb0-055f-399a-a08e-5499da; (total 36 bytes);
1: len 4; hex 0000d7c2; asc ;;
n_owned: 0; heap_no: 277; next rec: 4688
InnoDB: You should dump + drop + reimport the table to fix the
InnoDB: corruption. If the crash happens at the database startup, see
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html about
InnoDB: forcing recovery. Then dump + drop + reimport.
2015-09-28 14:39:46 7f015813b700 InnoDB: Assertion failure in thread 139643749381888 in file btr0btr.cc line 1492
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:39:46 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Please help us make Percona XtraDB Cluster better by reporting any
bugs at https://bugs.launchpad.net/percona-xtradb-cluster
key_buffer_size=25165824
read_buffer_size=131072
max_used_connections=7
max_threads=202
thread_count=10
connection_count=5
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 105204 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0xf4de780
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f015813ad38 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8fa965]
/usr/sbin/mysqld(handle_fatal_signal+0x4b4)[0x665644]
/lib64/libpthread.so.0(+0xf710)[0x7f0185a25710]
/lib64/libc.so.6(gsignal+0x35)[0x7f0183e6b625]
/lib64/libc.so.6(abort+0x175)[0x7f0183e6ce05]
/usr/sbin/mysqld[0xa10d84]
/usr/sbin/mysqld[0xa16cc8]
/usr/sbin/mysqld[0x917920]
/usr/sbin/mysqld(_ZN7handler8ha_checkEP3THDP15st_ha_check_opt+0x6a)[0x5a422a]
/usr/sbin/mysqld[0x835fc3]
/usr/sbin/mysqld(_ZN19Sql_cmd_check_table7executeEP3THD+0xc2)[0x836cd2]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x33d5)[0x6ed235]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x658)[0x6f0958]
/usr/sbin/mysqld[0x6f0acd]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d5)[0x6f2de5]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x22b)[0x6f42cb]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x17f)[0x6bc52f]
/usr/sbin/mysqld(handle_one_connection+0x47)[0x6bc717]
/usr/sbin/mysqld(pfs_spawn_thread+0x12a)[0xaf611a]
/lib64/libpthread.so.0(+0x79d1)[0x7f0185a1d9d1]
/lib64/libc.so.6(clone+0x6d)[0x7f0183f218fd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7efebc091d30): is an invalid pointer
Connection ID (thread ID): 2336
Status: NOT_KILLED
É claro que a mesa foobar.quuxestá muito danificada. O aplicativo que usa o banco de dados ainda funciona (embora com desempenho reduzido), assim como as SELECTinstruções.
A ferramenta mysqlcheck não pode ser usada para corrigi-lo, portanto, a solução que conheço é fazer um SELECT * FROM quux INTO OUTFILE, descartar a tabela e fazer um LOAD DATA INFILEdurante a próxima janela de manutenção. Existem inconvenientes com esta forma de proceder e existem outras opções para consertar a mesa?
EDIT: reiniciei o servidor MySQL com valores crescentes de innodb_force_recovery1 a 4, e o resultado é sempre o mesmo:
mysqldump falha com um erro
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table quux at row: 156915um comando MySQL
SELECT * FROM quux INTO OUTFILE '/root/quux.sql';falha logo depois com um erroERROR 2013 (HY000): Lost connection to MySQL server during query
Devo tentar innodb_force_recovery=5e innodb_force_recovery=6? Quais poderiam ser as desvantagens?
Quais bancos de dados estão incluídos no dump gerado por mysqldump --all-databases?
Pela minha experiência, devem ser todos os bancos de dados criados pelo usuário, mais o mysqlbanco de dados. O backup do banco de dados information_schemaé feito apenas se explicitamente mencionado e performance_schemanunca é feito backup. Isso está correto?
Em uma arquitetura de replicação mestre-escravo do MySQL, como você detecta se houve (erroneamente, já que isso nunca deveria acontecer!) Gravações diretas no escravo?
Por enquanto, estou executando este comando no escravo:
tcpdump tcp port 3306 and not host my_master_IP -A | grep -i -e INSERT -e UPDATE -e DELETE
cuja saída, se houver, significa que escreve no escravo, o que é ruim.
Há um método melhor?
Executei o MySQLTuner para verificar a configuração de um banco de dados MySQL e ele relatou este problema:
[!!] Maximum possible memory usage: 40.9G (1022% of installed RAM)
Esses números vêm da computação max_connectionsmultiplicada por read_buffer_size+ sort_buffer_size+ join_buffer_sizeno my.cnfarquivo, o que efetivamente dá 40Gb.
No entanto, o servidor possui 128 Gb de RAM. Parece que o MySQL vê apenas 4Gb.
A princípio, pensei que isso acontecia porque um binário MySQL de 32 bits em um sistema operacional de 64 bits pode acessar efetivamente apenas 4 Gb de RAM . No entanto, tanto o binário do MySQL quanto o sistema operacional são de 64 bits:
root@box# isainfo -v
64-bit amd64 applications
pclmulqdq aes sse4.2 sse4.1 ssse3 popcnt tscp ahf cx16 sse3 sse2 sse
fxsr mmx cmov amd_sysc cx8 tsc fpu
32-bit i386 applications
pclmulqdq aes sse4.2 sse4.1 ssse3 popcnt tscp ahf cx16 sse3 sse2 sse
fxsr mmx cmov sep cx8 tsc fpu
root@box# uname -a
SunOS box 5.11 11.2 i86pc i386 i86pc
root@box# file /usr/local/bin/mysql
/usr/local/bin/mysql: ELF 64-bit LSB executable AMD64 Version 1 [SSE2 SSE FXSR CMOV FPU], dynamically linked, not stripped
e não há limite de quanta memória um processo pode acessar:
root@box# ulimit -a
address space limit (kbytes) (-M) unlimited
core file size (blocks) (-c) unlimited
cpu time (seconds) (-t) unlimited
data size (kbytes) (-d) unlimited
file size (blocks) (-f) unlimited
locks (-x) not supported
locked address space (kbytes) (-l) not supported
message queue size (kbytes) (-q) not supported
nice (-e) not supported
nofile (-n) 256
nproc (-u) 29995
pipe buffer size (bytes) (-p) 5120
max memory size (kbytes) (-m) not supported
rtprio (-r) not supported
socket buffer size (bytes) (-b) 5120
sigpend (-i) 128
stack size (kbytes) (-s) 8192
swap size (kbytes) (-w) not supported
threads (-T) not supported
process size (kbytes) (-v) unlimited
Existe outra maneira de ver quanta memória o MySQL está usando efetivamente?
(Caso você pergunte, shell é tcsh; não posso marcar a postagem "tcsh" devido a privilégios insuficientes.)
Eu precisava de um usuário para poder fazer login em nosso servidor MySQL 5.6 da máquina foobarhost, IP 10.11.12.13.
Portanto, criei um usuário 'joe'@'foobarhost', mas ele não conseguiu fazer login. Tive que criar um usuário 'joe'@'10.11.12.13'e desta vez funcionou bem.
Minha pergunta : como o MySQL lida com nomes de host versus endereços IP em relação aos usuários?
O MySQL classifica a tabela de usuários antes de verificar uma correspondência , usando endereços IP e nomes de host como os valores mais específicos para correspondência. No entanto, os documentos não especificam o que tem precedência - nome do host ou IP. O MySQL tenta uma resolução de nome de host e, se falhar, executa uma verificação no IP?
Qual é o uso recomendado para a tabela de usuários: especifique apenas endereços IP, nomes de host ou ambos (como fiz no exemplo acima)?