Puncte:0

Replicare AWS EC2 MySQL: Configurare pentru a interoga Slave de la Master

drapel us

Am configurat cu succes o situație master-slave MySQL pe instanțe AWS EC2 separate. Sclavul rulează și replică cu succes masterul.

Până acum, bine.

Acum vreau să pot interoga slave (pentru analiză etc.) dar nu găsesc configurația potrivită pentru a putea trimite o interogare de la master la slave.

Erorile pe care le primesc (în funcție de setările profilului de securitate AWS) sunt fie „Conexiune refuzată”, fie „Conexiune expirată”

Pe slave am avut o alocație EC2 Security Group pentru blocul de IP master pe care să-l folosească pentru a se conecta la portul 3306 și am folosit adresa IP a sclavului în configurația conexiunii master-ului.

Asta a dus la eroarea „Conexiune refuzată” când am încercat să interog slave de la master.

Pe master, am rulat „afișează lista completă de procese” și am văzut că gazda slave era numele de gazdă AWS EC2, nu IP-ul, iar portul 44508 a fost conectat până la sfârșit, așa că am schimbat informațiile de conexiune pe master pentru a folosi gazda slave. nume în loc de adresa IP și setarea Grup de securitate pe slave pentru a permite traficul de la master pe portul 44508 în loc de 3306.

Aceasta a dus la eroarea „Conexiune expirată”.

Am încercat combinații de IP/nume de gazdă/port în grupul de securitate al sclavului, dar am primit una dintre acele 2 erori, cu orice combinație.

Poate cineva să ofere sfaturi despre cum să configurez lucrurile astfel încât să pot rula interogări (numai în citire) pe slave de la acea mașină principală și să returnez rezultatele înapoi la master? TIA.

Ambele sisteme sunt configurate la fel, cu excepția faptului că masterul rulează și Codeigniter4, care este locul unde stabilesc configurația conexiunii:

Ubuntu 20.04.3 LTS și MySQL 8.0.26-0

Puncte:1
drapel la

In such setup your clients (apps, software) should connect to the slave and run SELECT queries only (if you need to run write queries - they should be done on the master only).

You should check:

  1. If MySQL server listens on the network in the slave server.
  2. If security groups allow connecting to the slave server by your apps.
  3. The slave should be configured as read-only to prevent problems.
drapel us
Serverul slave se reproduce corect, cu datele transmise din jurnalul binar principal către slave. „Afișează starea slave” nu arată nicio eroare și actualizările privind masterul apar aproape imediat în slave.„Afișează lista completă de procese” de pe master arată slave. Grupul de securitate de pe master permite accesul de la și către slave. Grupul de securitate pe slave permite accesul la și de la master. Sclavul nu este configurat ca doar pentru citire, dar ar trebui să-l pot interoga, îmi imaginez. Vă mulțumim pentru atenție.
drapel us
Fără îndoială că acest lucru este legat de: pe serverul slave, nu mă pot conecta la slave ca utilizator „slave”. Tabelul „mysql.user” arată pluginul pentru utilizatorul „slave” ca „cached_sha2_password” în loc de „mysql_native_password”, ceea ce poate fi motivul pentru care nu mă pot autentifica ca utilizator (nici măcar ca „rădăcină”... Mă pot conecta cu 'sudo mysql')
drapel us
Nu mai încerc să mă conectez ca „slave”, la fel ca utilizatorul obișnuit pe care îl folosesc pe master. Cu siguranță mă pot conecta la slave db folosind acreditările normale ale utilizatorului. Cu toate acestea, nicio bucurie de conectare de la master, așa că am creat un nou utilizator pe master cu același nume și acreditări ca pe master, dar cu IP-ul gazdei slave și apoi cu IP-ul master-ului și apoi cu numele gazdei raportat de „afișați complet listă de procese” care le combină pe cele din șirul de conexiune db fie cu portul 3306, fie cu portul 44508 raportat de „afișează lista completă de procese”, dar tot nu este bucurie.
drapel la
Ar trebui să lansați toate comenzile care modifică datele numai pe master pentru a evita problemele și pentru a crea un utilizator cu localhost sau 127.0.0.1 ca gazdă, adică user@'127.0.0.1' dacă vă conectați la MySQL de pe serverul slave.
drapel us
Iti multumesc din nou. Da, emit toate comenzile pe master și le permit să gestioneze ceea ce se întâmplă cu slave. Nu există nicio problemă cu replicarea. Aceasta este o bază de date master destul de matură, cu toți utilizatorii localhost specificați și disponibili pentru utilizare pe master. Pur și simplu nu îmi pot da seama cum să rulez o interogare pe slave de la master. Încerc să mă conectez la slave de la master pentru a rula interogările mele și nu rulez nimic DE LA slave. Vreau să pot rula interogări pe slave DE LA master.
drapel la
Cum vă conectați de la serverul principal la serverul slave MySQL când încercați să rulați interogarea?
drapel us
Mulțumesc, din nou pentru atenție. Folosesc informații tipice de conectare MySQL... gazdă, utilizator, parolă. Apoi, pur și simplu verific dacă a fost realizată conexiunea la baza de date, dar în fiecare caz nu primesc niciun rezultat, cu excepția (a) conexiunea la baza de date a eșuat și (b) fie erorile „Conexiune refuzată”, fie „Conexiune expirată”. Am deschis complet firewall-ul serverului slave la orice trafic TCP din orice sursă folosind orice port și am primit eroarea „Conexiune expirată”. Am verificat că serverul MySQL rulează (și replică masterul), și chiar și cu totul deschis... sunt nedumerit.
drapel us
Când lansez „afișează replici” pe master, văd slave în rezultat, dar intrarea nu are valoare „gazdă”. Când emit „afișează lista completă de procese”, văd slave în rezultat cu o valoare completă a gazdei. Poate că asta înseamnă ceva?
drapel la
Afișați comanda exactă pe care o utilizați pentru a vă conecta și, de asemenea, puteți lipi my.cnf al sclavului
drapel us
connect_error) { die("Conexiune eșuată: " . $conn->connect_error); } echo „Conectat cu succes”; ?>
drapel us
Aveți o întrebare specifică despre configurația MySQL? server_id=2, de exemplu.
drapel la
Să [continuăm această discuție în chat](https://chat.stackexchange.com/rooms/129860/discussion-between-martynas-saint-and-james-butler).
Puncte:0
drapel us

SOLUȚIONAT: În /etc/mysql/mysql.conf.d/mysqld.cnf al sclavului, trebuia să comentez liniile „bind-address” și „mysqlx-bind-address”, să opresc slave, să repornesc mysqld și să pornesc slave.

Având „bind-address = 127.0.0.1” a împiedicat conexiunile de oriunde altundeva. Comentarea permite accesul din toate sursele, nu doar localhost. EC2 Security Group restricționează accesul la portul 3306 doar la serverul principal.

Funcționează grozav peste tot, acum. Mulțumesc, din nou, pentru atenție.

drapel la
deci practic acesta: ar trebui să verificați: Dacă serverul MySQL ascultă în rețea în serverul slave. ;:) ma bucur ca ti-ai rezolvat problema.

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.