Mudanças entre as edições de "Unilab no Linux"

Edição das 15h56min de 25 de maio de 2012

Atualmente é possível rodar o Banco de dados do Unilab no Linux.

Também é possível ter os executáveis e arquivos do Unilab no servidor Linux.

Política da Uniware

A política da Uniware em relação à servidores Linux com MySQL para o Unilab é a seguinte:

• Nós reconhecemos que o desempenho do MySQL no Linux é bastante superior e inclusive recomendamos para o laboratório que puder ter um servidor Linux.
• A Uniware não dá manutenção em servidores Linux.
• O Cliente Uniware que quiser utilizar uma máquina com Linux para o banco de dados tem que ter um técnico local que lhe dê total suporte no Linux.
• O técnico do cliente fica responsável por:
  • fazer a instalação do Linux, MySQL e qualquer outro software que se julgue necessário.
  • pelo sistema operacional Linux e qualquer manutenção que ele requira.
  • pelo banco de dados MySQL instalado no Linux.
  • por restaurar o backup do Unilab para implantar o banco de dados no Linux.
  • por implementar as rotinas de backup do banco de dados.
• A Uniware se compromete em passar os parâmetros de configuração do MySQL para uso com o Unilab conforme documentado abaixo.

MySQL no Linux

Para o Unilab funcionar corretamente, o MySQL no Linux deve ser configurado para:

• Trabalhar com a engine INNODB por padrão.
• Ter no mínimo 4 tablespaces de 4GB, ou uma tablespace de 16GB.
• Incluir na seção mysqld a opção lower_case_table_names = 1 isso faz com que o banco rode no linux de forma case insensitive, isto descarta a necessidade de converter nomes de tabelas para maiúsculo.
• Utilizar o charset latin1 por padrão.
• Tunar os parâmetros de tamanho de cache, memória, tabelas temporárias, para o INNODB. Afinal, geralmente o mysql do linux vem tunado para servidor web (MyISAM).
• Restaurar o backup do banco de dados do Unilab (por padrão o nome do banco de dados deve ser unilabw).
• Assim que o banco de dados estiver configurado e já tiver restaurado o backup do Unilab, a Uniware vai acessar remotamente uma máquina Windows da rede que rode o Unilab e vai fazer a última configuração para rodar o Unilab.

Exemplo de alterações para o my.cnf do Ubuntu

O exemplo abaixo não é um my.cnf completo. Ele apenas relaciona as linhas que são importantes para o Unilab.

Verifique o my.cnf do seu mysql, se alguma das linhas abaixo não existir, acrescente. Se já existir, modifique para deixar conforme abaixo.

As configurações de tunning podem ser diferentes do exemplo abaixo se você tiver uma máquina que suporta trabalhar com mais memória do que o especificado abaixo, entretanto, só altere estas configurações se você tiver certeza do que está fazendo.

[client]
default-character-set=latin1
#
[mysqld]
# The default character set that will be used when a new schema or table is
# created and no character set is defined
default-character-set=latin1
#
# The default storage engine that will be used when create new tables when
default-storage-engine=INNODB
#
# Set the SQL mode to strict
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
#
# isso faz com que o banco rode no linux de forma case insensitive, 
# descartando a necessidade de converter nomes de tabelas para maiúsculo.
lower_case_table_names = 1 
#
# Comentar a linha abaixo para que outras máquinas da rede possam acessar o mysql.
#bind-address		= 127.0.0.1
#
table_cache            = 256
query_cache_size        = 0
#
#
#*** INNODB Specific options ***
#
#
# Use this option if you have a MySQL server with InnoDB support enabled
# but you do not plan to use it. This will save memory and disk space
# and speed up some things.
#skip-innodb
#
# Additional memory pool that is used by InnoDB to store metadata
# information.  If InnoDB requires more memory for this purpose it will
# start to allocate it from the OS.  As this is fast enough on most
# recent operating systems, you normally do not need to change this
# value. SHOW INNODB STATUS will display the current amount used.
innodb_additional_mem_pool_size=10M
#
# If set to 1, InnoDB will flush (fsync) the transaction logs to the
# disk at each commit, which offers full ACID behavior. If you are
# willing to compromise this safety, and you are running small
# transactions, you may set this to 0 or 2 to reduce disk I/O to the
# logs. Value 0 means that the log is only written to the log file and
# the log file flushed to disk approximately once per second. Value 2
# means the log is written to the log file at each commit, but the log
# file is only flushed to disk approximately once per second.
innodb_flush_log_at_trx_commit=1
#
# The size of the buffer InnoDB uses for buffering log data. As soon as
# it is full, InnoDB will have to flush it to disk. As it is flushed
# once per second anyway, it does not make sense to have it very large
# (even with long transactions).
innodb_log_buffer_size=2M
#
# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and
# row data. The bigger you set this the less disk I/O is needed to
# access data in tables. On a dedicated database server you may set this
# parameter up to 80% of the machine physical memory size. Do not set it
# too large, though, because competition of the physical memory may
# cause paging in the operating system.  Note that on 32bit systems you
# might be limited to 2-3.5G of user level memory per process, so do not
# set it too high.
innodb_buffer_pool_size=1000M
#
# Size of each log file in a log group. You should set the combined size
# of log files to about 25%-100% of your buffer pool size to avoid
# unneeded buffer pool flush activity on log file overwrite. However,
# note that a larger logfile size will increase the time needed for the
# recovery process.
innodb_log_file_size=46M
#
# Number of threads allowed inside the InnoDB kernel. The optimal value
# depends highly on the application, hardware as well as the OS
# scheduler properties. A too high value may lead to thread thrashing.
innodb_thread_concurrency=8
#
#Paths to individual datafiles and their sizes.
innodb_data_file_path=ibdata1:4000M;ibdata2:4000M;ibdata3:4000M;ibdata4:4000M;

Não enviar este tópico para o cliente

Assim que o banco de dados estiver configurado e já tiver restaurado o backup do Unilab, a Uniware vai acessar remotamente uma máquina Windows da rede que rode o Unilab e vai fazer a última configuração para rodar o Unilab:

• Pagar com o técnico o ip da máquina do mysql, o nome do banco de dados, a porta onde o mysql está rodando e a senha do usuário root do banco de dados.
• Acessar o mysql dele com UnilabTools (você vai precisar da senha do usuário root dele) e rodar os 3 SQLs abaixo na sequência:

GRANT ALL ON *.* TO 'UNIWARE'@'localhost' IDENTIFIED BY 'DBUCFGS' WITH GRANT OPTION;
GRANT ALL ON *.* TO 'UNIWARE'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

• Configurar o ini do Unilab e entrar no Unilab;

Arquivos do Unilab no Linux

Na página Linux - Instalação Servidores está documentado como compartilhar arquivos com samba.