Puncte:0

Replicare MariaDB Conectare Master Slave Conectare Slave Interzisă

drapel cn
S.B

Bună ziua tuturor, Ca începător, îmi cer scuze dacă fac asta greșit.

Despre situație: Avem două servere fizice Ubuntu. Acestea sunt în aceeași rețea și acționează ca servere master/slave. Replicarea bazelor de date și, astfel, aprox. 300 GB funcționează cu succes. De asemenea, este posibilă o autentificare la master. Cu toate acestea, dacă utilizatorul care se poate conecta la master acum dorește să se autentifice la slave, el primește întotdeauna o conectare refuzată.

Dacă acum încerc să mă conectez la slave printr-un client MySQL, primesc următoarele mesaje:

2022-05-03 9:58:01 1161 [Avertisment] Conexiune întreruptă 1161 la db: utilizator „neconectat”: gazdă „neautentificată”: „XX” (Această conexiune s-a închis în mod normal fără autentificare)
    2022-05-03 9:58:11 1170 [Avertisment] Conexiune întreruptă 1170 la db: utilizator „neconectat”: gazdă „neautentificată”: „XX” (Această conexiune s-a închis în mod normal fără autentificare)
    2022-05-03 9:58:21 1179 [Avertisment] Conexiune întreruptă 1179 la db: utilizator „neconectat”: gazdă „neautentificată”: „XX” (Această conexiune s-a închis în mod normal fără autentificare)
    2022-05-03 9:58:31 1187 [Avertisment] Conexiune întreruptă 1187 la db: utilizator „neconectat”: gazdă „neautentificată”: „XX” (Această conexiune s-a închis în mod normal fără autentificare)
    2022-05-03 9:58:41 1196 [Avertisment] Conexiune întreruptă 1196 la db: utilizator „neconectat”: gazdă „neautentificată”: „XX” (Această conexiune s-a închis în mod normal fără autentificare)
Cu toate acestea, utilizatorul este disponibil și poate fi executat și de la distanță. Dacă încerc să mă conectez local direct pe CLI, primesc același model de eroare.

Trebuie remarcat faptul că aici lucrăm cu diferite versiuni de baze de date, deoarece masterul încă rulează pe o versiune veche MariaDB.

MySQL Master:

NAME="Ubuntu"
VERSION="16.04.7 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.7 LTS"
VERSION_ID="16.04"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
mariadb-server-10.1/now 10.1.44+maria-1~xenial amd64
mariadb-server-core-10.1/now 10.1.44+maria-1~xenial amd64

Slave MySQL:

  NAME="Ubuntu"
    VERSION="20.04.4 LTS (Focal Fossa)"
    ID=ubuntu
    ID_LIKE=debian
    PRETTY_NAME="Ubuntu 20.04.4 LTS"
    VERSION_ID="20.04"
    VERSION_CODENAME=focal
    UBUNTU_CODENAME=focal
    mariadb-server-10.5/necunoscut, acum 1:10.5.15+maria~focal amd64
    mariadb-server-core-10.5/necunoscut, acum 1:10.5.15+maria~focal amd64

Un netstat -tulpn |grep 3306 îmi arată că baza de date este și online.

Dacă acum întreb starea sclavului, totul arată bine și aici:

MariaDB [(niciunul)]> SHOW SLAVE STATUS\G;
**************************** 1. rând ******************** ******
                Slave_IO_State: Se așteaptă ca master să trimită evenimentul
                   Gazdă_master: XX.XX.XX.XX
                   Master_User: replicare
                   Master_Port: 3306
                 Connect_Retry: 60
               Master_Log_File: mariadb-bin.024024
           Read_Master_Log_Pos: 798994582
                Relay_Log_File: mysql-relay-bin.000008
                 Relay_Log_Pos: 798994879
         Fișier_Releu_Master_Log: mariadb-bin.024024
              Slave_IO_Running: Da
             Slave_SQL_Running: Da
               Replicate_Do_DB: numele_bază de date
           Replicate_Ignore_DB:
            Replicate_Do_Table:
        Replicate_Ignore_Table:
       Replicate_Wild_Do_Table:
   Replicate_Wild_Ignore_Table:
                    Ultima_eroare: 0
                    Ultima_eroare:
                  Skip_Counter: 0
           Exec_Master_Log_Pos: 798994582
               Relay_Log_Space: 798995229
               Până la_Condiție: Niciuna
                Până la_Log_File:
                 Până la_Log_Pos: 0
            Master_SSL_Allowed: Nu
            Master_SSL_CA_File:
            Master_SSL_CA_Path:
               Master_SSL_Cert:
             Master_SSL_Cipher:
                Master_SSL_Key:
         Secunde_În spatele_Maestrului: 0
 Master_SSL_Verify_Server_Cert: Nu
                 Ultima_IO_Errno: 0
                 Ultima_IO_Eroare:
                Last_SQL_Errno: 0
                Ultima_eroare_SQL:
   Replicate_Ignore_Server_Ids:
              Master_Server_Id: 2
                Master_SSL_Crl:
            Master_SSL_Crlpath:
                    Utilizând_Gtid: Nu
                   Gtid_IO_Pos:
       Replicate_Do_Domain_Ids:
   Replicate_Ignore_Domain_Ids:
                 Parallel_Mode: optimist
                     SQL_Delay: 0
           SQL_Remaining_Delay: NULL
       Slave_SQL_Running_State: Slave a citit toate jurnalele de releu; așteaptă mai multe actualizări
              Slave_DDL_Groups: 56
Slave_Non_Transactional_Groups: 0
    Slave_Transactional_Groups: 97448
1 rând în set (0.000 sec)

EROARE: Nu a fost specificată nicio interogare

Este cineva conștient de această problemă sau are o idee aproximativă despre ââcum să implementați o conectare pe slave pentru drepturi de citire?

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.