A topologia do exige um serviço único para emular o controle de lock de registro ISAM. Para ser possível escalar a aplicação para atender a mais conexões simultâneas, o
pode ser configurado para trabalhar em uma configuração distribuída, onde um serviço do
é configurado como Master, que terá a função de centralizar o controle de acessos mutuamente exclusivos (locks), e os demais serviços devem ser configurados como Slaves, e através deles serão realizadas as conexões e operações com o SGBD.
A configuração distribuída não é diretamente responsável por fazer distribuição da carga ou das conexões. Deste modo, cada serviço do deve ser explicitamente configurado para realizar as conexões de dados em um
"Slave", onde o balanceamento efetivo das conexões já foi realizado pelo engine de balanceamento do
, e cada
"Slave" é configurado para apontar para o "Master" para fazer as operações de lock.
Partindo de um ambiente hipotético com 3 servidores, nomeados SRVDB, SRVAPP1 e SRVAPP2, onde o servidor de banco de dados possui um banco MSSQL Server e um e os servidores APP1 e APP2 possuam cada um 4 serviços do
, configurados em modo de balanceamento de carga, neste cenário os serviços do
de todos os equipamentos apontam para um único
, instalando na máquina de banco (SRVDB), onde têm um ODBC configurado para o
. Nesse cenário, a seguinte topologia é sugerida:
Para implementar a configuração distribuída do , são necessários os seguintes passos:
Para configurar o para modo de conexão Master, deve-se abrir o arquivo de configuração (dbaccess.ini), do
, e na seção [General] inserir a chave Mode.
Mode=Master |
Para configurar os para modo Slave, deve-se abrir o arquivo de configuração (dbaccess.ini) e configurar as seguintes chaves:
Mode=SlaveMasterServer=<IP> MasterPort=<Port> |
Onde <IP> e <Port> correspondem ao IP e Porta do Master que será utilizado como servidor de locks para os demais
Slave.
Um Slave somente consegue estabelecer conexão com o banco de dados, se conseguir conectar primeiro com o
Master. Caso o
Master não esteja no ar ou esteja configurado de forma incorreta, o
retornará erro de conexão -43 (DBSERVER_INITERROR) ao
.
Devido ao Master centralizar o serviço de controle de locks, o Master não realiza conexão com os SGBDs, que retorna erro -35 (NO_DB_CONNECTION) ao tentar conectar com o SGBD e mostra em console a mensagem: Invalid TopClient Connection on DBACCESS MASTER.
O Master é uma aplicação crítica e deve estar sempre no ar. Se o
Master for derrubado durante a operação do sistema (ERP), as conexões dos Slaves serão derrubadas assim que qualquer recurso que dependa do Master (Lock de registro, controle de numeração de tabelas. virtual lock, table cache). Para o
, será retornado o erro -2 (NO_CONNECTION), indicando que a conexão entre o
e o
foi perdida, e nos logs do
será registrado que a causa do fechamento da conexão foi falha de comunicação como
Master.
Antes da build 19.2.1.0 do , a interface de monitoramento (
) somente têm acesso às informações e conexões processadas naquele serviço. Logo, para localizar uma conexão no ambiente mencioando, deve-se abrir um
para cada
Slave. Da mesma forma, os recursos de bloqueio de conexão e liberação de conexão ainda são individuais. Bloqueas novas conexões do
Master não bloqueia novas conexões do
Slave.
A partir da Build 19.2.1.0 do , foi implementado o mecanismo de monitoramento centralizado completo no
Master, permitindo visualizar todas as conexões estabelecidas em todos os
Slave(s) do ambiente, bem como rasterar e encerrar conexões. Para maiores informações sobre essa implementação, conslute a nota de release no link Implementação - DBMonitor passa a suportar as funcionalidades de visualização de Locks, Rastrear e Encerrar quando conectado ao DBAccess Master
Além disso, outro ponto importante, é a respeito das configurações: As configurações devem ser replicadas, de modo que cada esteja configurado apontando para uma configuração ODBC que aponte para o mesmo banco de dados, ou ainda apontar para o mesmo banco de dados um ou mais
configurados como Slaves e apontar também para o mesmo banco de dados um
configurado como StandAlone (Padrão sem distribuição). Discrepâncias desta natureza, não têm como serem detectadas pelo
, e caso sejam realizadas, podem causar comportamentos inesperados e fatalmente prejudiciais a aplicação.
O Master não precisa necessariamente ficar junto com a máquina de banco de dados. O
pode ser um serviço instalado em um servidor de aplicação, em uma porta diferente da 7890, e como o seu controle será exclusivamente para bloqueio de registros, seu consumo de memória será bem inferior aos serviços
Slaves. E, é possível configurar um
Master em uma plataforma diferente dos demais Slaves, por exemplo um Master em uma máquina Linux e os demais
Slaves em máquinas Windows. Além disso, podemos também colocar mais de um
Slave no mesmo equipamento, desde que configurado em outra porta.
Embora seja possível, não é recomendável que sejam utilizados Slaves para o mesmo banco de dados/ambiente em plataformas distintas, por exemplo um
Slave em Windows e outro em Linux.
A utilização do em modo distribuído requer uma build com release igual ou superior a 20100510.