sql >> Database teknologi >  >> RDS >> Mysql

MySQL-forbindelsen virker ikke

Her er en hurtig hurtig tjekliste til aktivering af fjernforbindelser til MySQL, men læs (6) først. Hvis jeg er gået glip af noget, er du velkommen til at redigere.

1) Din fjernbruger opretter forbindelse via en konto, der er oprettet med passende bruger, vært indgange (se på output fra vælg bruger, vært fra mysql.user rækkefølge efter 1,2 ). Hvis ikke, så kig ind i OPRET BRUGER og/eller GRANT kommandoer. Undersøg output fra VIS TILSKUD for brugeren.

2) Du har foretaget flush-privilegier; (Nogle siger det er unødvendigt, andre siger det er det).

3a) Find din mysql-konfigurationsfil, der henvises til i 3b) nedenfor ved at gennemgå info i Dette dokument (eller for Windows, sandsynligvis nede i C:\ProgramData\MySQL\MySQL Server 5.NNN sti). Det varierer efter distro for Linux.

3b) Du har ændret og gemt my.ini (Windows) eller my.cnf (Linux) og ændret bind-adresse væk fra 127.0.0.1 eller localhost , til fordel for 0.0.0.0 . Og du har oprettet og rem'd ud af følgende linje:#skip-netværk . Det vil ligne dette:

[mysqld]
bind-address=0.0.0.0
#skip-networking

4) Genstart mysql-dæmonen. Hvordan man gør dette varierer efter distro.

5) Firewall problemer. Sørg for, at porten er 3306 som standard , er åben for omverdenen (som måske i virkeligheden bare er dit intranet). Dette inkluderer alle andre lag af firewalls, såsom AWS EC2 Security Groups eller lignende, hvis nogen.

6) Forstå, at der er en sikkerhedsrisiko forbundet med dette. Medmindre du har viden om at udsætte din mysql-server for fjernforbindelser, skal du ikke udføre dette.

7) Kør hyppige sikkerhedsvurderinger med select erklæring, der er angivet i 1. ovenfor, herunder gennemgang af SHOW GRANTS for disse brugere. Overgiv ikke brugere med jokertegn unødigt. Giv i stedet brugerne de minimale privilegier, som de kan få deres arbejde gjort.

8) Undersøg ofte mislykkede forbindelsesforsøg via den generelle log og fejlloggen som kort introduceret nedenfor.

For indgående kan du se den generelle forespørgselslog.

select @@general_log; -- a 1 indicates it is turned on for capture
select @@general_log_file; -- the file that it logs to

Så alle forespørgsler kan være logget på Generel forespørgselslog hvis indstillingen er slået til. Undersøg loggen for "connect", men især for Adgang nægtet for bruger at se mislykkede forsøg. Gør dette regelmæssigt (ikke hvert par år). Jeg gør det mindst to gange om dagen. Bemærk, du kan naturligvis automatisere rapporteringen gennem et eksternt program. Omverdenen kommer til at banke din server for at komme ind som billedet nedenfor. Det er en realitet; forbered dig på det.

Tjek manualsiden for Fejlloggen også bemærke advarselsniveauer og detaljeringsindstillinger baseret på din version.

Jeg vil anbefale, at man laver en sikkerhedskopi efter dato (navngivet som sådan) og sletter logfilerne efter sikkerhedskopieringen for at starte på en frisk efter sikkerhedskopieringen. Logfilerne kan hurtigt vokse sig store i størrelse, især den generelle log. Glem ikke, om du har slået indstillingen til eller fra for logning.

Du kan bruge de to logfiler til at bestemme, om dit forbindelsesforsøg kom forbi firewallen under trinene her.




  1. Gruppér efter klausul i mySQL og postgreSQL, hvorfor fejlen i postgreSQL?

  2. Sådan overføres parametre til mysql-forespørgselstilbagekald i nodejs

  3. Langsom bulk indsats til bord med mange indekser

  4. xampp mysql Kunne ikke initialisere multimasterstrukturer