Perguntas[connectivity](dba)

Um servidor Windows (2022) tem o MariaDB 10.4 em execução. Nos logs do Visualizador de Eventos para Windows > Aplicativo, há dois eventos que acontecem a cada minuto:

Aborted connection ### to db: 'unconnected' user: 'unauthenticated' host: 'localhost' (Esta conexão foi fechada normalmente sem autenticação) Aborted connection ### to db: 'unconnected' user: 'unauthenticated' host: 'localhost' (Ocorreu um erro ao ler os pacotes de comunicação)

Observe que '###' é um número que aumenta sequencialmente. De alguma forma, isso está relacionado ao serviço MariaDB porque os eventos não aparecem quando o serviço é interrompido.

Existe alguma maneira de suprimir esses eventos?

Obrigado

Ao analisar a configuração do Universal Data Link (UDL) da documentação (V2022/2019 e 2016), ela diz que posso usar um arquivo UDL para tentar um Active Directory - Universal with MFA support:login de tipo por meio do menu suspenso ( Seção 2 nas caixas de diálogo abaixo ).

Mas minha versão em uma VM Windows 10 e minha estação de trabalho Windows 11 não têm essa opção. O que eu tenho que fazer, para obter a opção?

À esquerda está (caixa de diálogo do Windows 10/11) À direita está a visualização da documentação.

1. Instalei o Db2 v11.5.7.0 no Linux/x86_64 dentro do meu PC virtual usando o VirtualBox no Windows 10.
2. Eu criei banco de dados com o nome TEST1
3. Eu me conectei ao banco de dados usando o soquete Unix: db2 connect to TEST1 e a conexão foi concluída com sucesso.
4. Verifique a configuração DB2COMM: db2set DB2COMM e a saída é DB2COMM=TCPIP
5. Apenas para garantir que a conexão TCP/IP funcione com o Db2, criei o nó local e o banco de dados do catálogo:

db2 catalog tcpip node loctcp remote localhost server 50000
db2 catalog database test1 as tcptest1 at node loctcp
db2 terminate
db2 connect to tcptest1 user db2inst1 using <password>

e a conexão foi concluída com sucesso.

6. Agora, no meu PC VirtualBox Windows 10 host, defino o encaminhamento de porta Host Port: 60127 e Guest Port: 50000.
7. No meu PC com Windows: netstat -an -p tcp | find ":60127" posso ver que a conexão está no estado LISTENING.
8. No meu PC com Windows:

db2 catalog tcpip node remtcp remote localhost server 60127
db2 catalog database test1 as tcptest1 at node remtcp
db2 terminate

9. No meu PC com Windows, conecte-se ao banco de dados

db2 connect to tcptest1 user db2inst1 using <password>

PROBLEMA: Parece que a conexão trava. Após alguns minutos, recebo erro no cliente Db2:

SQL30081N Foi detectado um erro de comunicação. Protocolo de comunicação utilizado: "TCP/IP". API de comunicação em uso: "SOCKETS". Local onde o erro foi detectado: "127.0.0.1". Função de comunicação detectando o erro: "recv". Código(s) de erro específico do protocolo: "10054", "*", "0". SQLSTATE=08001

10. Tentando entender o problema. No servidor Linux: a) Verifiquei o firewall e está desabilitado. b) IPv6 está desabilitado c) Db2 está escutando na porta 50000 usando IPv4
11. Wireshark no Windows ouvindo a porta 60127. a) A conexão TCP é estabelecida b) A conexão Db2 DRDA nunca aparece.
12. Tcpdump no servidor Linux capturando tráfego de rede de 50.000 portas. a) A conexão TCP é estabelecida b) A conexão Db2 DRDA nunca aparece.

Parece que algo está errado dentro da máquina virtual Linux, mas as etapas 4 e 5 devem estar bem com a conexão TCP/IP do Db2.

Alguma idéia do que mais para verificar por que a conexão do cliente Db2 não funciona?

PS Eu tenho exatamente a mesma instalação com Db2 v11.1 e conexão Db2 do meu PC está funcionando bem.

Para um projeto de faculdade, tenho que configurar uma instância RAC e um aplicativo, já consegui configurar meu laboratório RAC usando máquinas virtuais usando este vídeo guia , agora só preciso programar um aplicativo para conectar a minha instância RAC mas ... Eu não tenho certeza de como fazê-lo! Suponho que tenho que me conectar à rede SCAN? Mas eu tinha configurado como rede privada no adaptador de rede de cada máquina... Não configurei o DNS (fiquei travado por 4 dias e o vídeo guia não mostrava como configurar), então agora estou preso tentando se conectar a este banco de dados do DBeaver antes de programar meu aplicativo de nó.

Aqui estão algumas informações sobre o meu laboratório.

Eu tenho duas instâncias: node1 e node.

Status do serviço:

$ /crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Configuração de digitalização?

$ ./srvctl config scan
SCAN name: node-scan, Network: 1
Subnet IPv4: 192.168.24.0/255.255.255.0/enp0s3, static
Subnet IPv6: 
SCAN 1 IPv4 VIP: 192.168.24.41
SCAN VIP is enabled.
SCAN 2 IPv4 VIP: 192.168.24.42
SCAN VIP is enabled.
SCAN 3 IPv4 VIP: 192.168.24.43
SCAN VIP is enabled.

Ouvinte de varredura

$ ./srvctl config scan_listener
SCAN Listeners for network 1:
Registration invited nodes: 
Registration invited subnets: 
Endpoints: TCP:1521
SCAN Listener LISTENER_SCAN1 exists
SCAN Listener is enabled.
SCAN Listener LISTENER_SCAN2 exists
SCAN Listener is enabled.
SCAN Listener LISTENER_SCAN3 exists
SCAN Listener is enabled.

Como não há DNS, tive que configurar /etc/host assim para ambos os nós.

# Default

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
# Public
192.168.24.1 node1.localdomain node1
192.168.24.2 node2.localdomain node2
# Private
192.168.10.1 node-priv.localdomain node1-priv
192.168.10.2 node2-priv.localdomain node2-priv
# Virtual
192.168.24.31 node1-vip.localdomain node1-vip
192.168.24.32 node2-vip.localdomain node2-vip
# SCAN
192.168.24.41 node-scan.localdomain node-scan
192.168.24.42 node-scan.localdomain node-scan
192.168.24.43 node-scan.localdomain node-scan

Executando o MySql 5.7.33 em uma instância local do VirtualBox. Eu encaminhei a porta 3306 do servidor virtual para ser acessível localmente. No meu host virtual, tenho isso no meu arquivo /etc/mysql/my.cnf ...

[client]
#password = your_password
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld]
port = 3306
bind-address = 0.0.0.0
datadir = /var/lib/mysql
socket = /var/run/mysqld/mysqld.sock
pid-file = /var/run/mysqld/mysqld.pid

Da minha máquina local, posso me conectar à instância do MySql usando

mysql -h 127.0.0.1 -u my_user my_db -p

Mas uma vez que mudo para “localhost”, não consigo mais me conectar

$ mysql -h localhost -u my_user my_db -p
Enter password: 
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

Não tenho certeza qual é o problema. Da minha máquina local (ou seja, não do servidor virtual), isso é retornado para “localhost”…

$ host localhost
localhost has address 127.0.0.1
localhost has IPv6 address ::1

Estou procurando essa informação há anos, mas não consigo encontrá-la:

Existe alguma documentação disponível em learn.microsoft.com fornecendo uma tabela com todos os parâmetros de string de conexão válidos, seus valores de argumento válidos, seus valores padrão e suas implicações, para SQL Server e LocalDB?

Tudo o que encontro são alguns tutoriais e páginas de exemplo, mas nenhuma página de referência completa.

Estamos migrando duas instâncias do SQL Server 2008 em uma máquina Win7 para o SQL Server 2019 em um servidor Win10. O servidor antigo tinha duas instâncias: 123.123.123.123 e 123.123.123.123\ABC. Não tivemos problemas para conectar a ambas as instâncias de todos os nossos computadores em rede.

No novo servidor as instâncias são: CMP0123456 e CMP0123456\ABC. Podemos nos conectar à instância sem a barra, mas não podemos nos conectar à instância com a barra. O erro é SQL Error 17: Servidor não existe ou acesso negado.

O ping CMP0123456 funciona para computadores remotos.

Verifiquei se o gerenciador de configuração e os serviços do SQL Server e do SQL Server Agent estão em execução para ambas as instâncias. O navegador também está em execução. Ambas as instâncias usam os protocolos TCP/IP e de memória compartilhada. Pipes nomeados estão desabilitados.

Posso acessar ambas as instâncias por meio do SSMS local.

Eu não sou um DBA. Não configurei o servidor antigo ou o SQL Server 2008. Estou apenas vagamente familiarizado com problemas de rede. Verifiquei o firewall no novo servidor e ambas as portas 1433 e 1434 estão habilitadas/abertas. 1433 usa TCP e 1434 usa UDP.

Por alguma razão, o PolyBase tem as portas 1433 e 1434. Instalei o PolyBase, mas não acho que realmente precise dele. Se esse for o problema, existe uma maneira de associar as portas 1433 e 1434 diretamente ao SQL Server 2019?

Ou há alguma outra configuração no SQL Server e/ou no Firewall/Networking/DNS que preciso alterar para que os computadores remotos vejam a instância \ABC?

O artigo BOL de compatibilidade de versão do SQL informa que a versão mínima do driver JDBC compatível para SQL Server 2019 é 7.4.

Um driver JDBC mais antigo ainda pode se conectar ao SQL Server 2019? Ou apenas as versões de driver listadas como compatíveis podem se conectar às versões especificadas do SQL Server?

Aqui está o meu código:

mongoose.connect(consts.database, {
    useNewUrlParser: true,
    useUnifiedTopology: true,
    sslCA: consts.databaseCert,
});
//...
const user = await db.userModel.findOne({
    username: usernameLowerCase
}).exec();

Aqui está minha string de conexão do banco de dados (anônima):

mongodb://myUser:[email protected]:27017,SG-staging-43334.servers.mongodirector.com:27017?replicaSet=RS-staging-0&ssl=true&authSource=stagingDB

Estou recebendo este erro:

MongoError: not authorized on test to execute command {
    find: "users",
    filter: {
        username: "bob"
    },
    projection: {},
    limit: 1,
    singleBatch: true,
    batchSize: 1,
    returnKey: false,
    showRecordId: false,
    lsid: {
        id: UUID("0a9400e3-83e3-429c-b8c9-92ade2ff210e")
    },
    $clusterTime: {
        clusterTime: Timestamp(1613200171, 1),
        signature: {
            hash: BinData(0, FED473B580D13E7E5073756DB5140981AADB2985),
            keyId: 6928615819992774977
        }
    },
    $db: "test"
}

Informações do usuário do banco de dados:

myUser  [{"role":"readWrite","db":"stagingDB"}]

Não tenho ideia de por que estou recebendo esse erro not authorized on test to execute commande, na string de retorno $db: "test", nem tenho um banco de dados chamado test. O que eu poderia estar fazendo de errado? Eu adicionei recentemente este novo usuário myUser, mas agora estou recebendo este erro. Este erro significa que o usuário não está autorizado a "testar" comandos? Ou significa que estou tentando (de alguma forma) me conectar a um banco de dados chamado "teste"?

Embora possa parecer relacionado a esta questão , não é, porque estou interessado no uso de soquetes unix em vez de TCP/IP.

No entanto, não consigo me conectar a um banco de dados PostgreSQL remoto usando soquetes unix e um túnel ssh com pgAdmin4. O pgAdmin sempre reivindica uma conexão recusada pelo servidor e pede uma senha, o que me faz pensar. Ao fazer o sshing no servidor e usar o psql, uma conexão pode ser feita perfeitamente usando o soquete unix (/var/run/postgresql). Existe algo especial que precisa ser definido para permitir tal configuração, ou isso pode até ser um bug no próprio pgAdmin? Eu apreciaria quaisquer idéias para resolver este problema sem ter que recorrer a conexões TCP/IP no lado remoto.

Também posto algumas telas da minha configuração atual: