Verbindingsverbinding met MySQL-server bij ‘Reading Initial Communication Packet’, System Fout: 0

Ik krijg een foutmelding:

“Verloren verbinding met MySQL Server bij ‘LEADING INITIAL COMMUNICATION PAKET, SYSTEEM FOUT: 0”

Terwijl ik mijn db moet verbinden.

Als ik LocalHost gebruik, werkt alles goed.
Maar wanneer ik mijn live IP-adres zoals hieronder gebruik, krijgt het fout:

mysql_connect("202.131.xxx.106:xxxx", "xxxx", "xxxxx") or die(mysql_error());

Antwoord 1, Autoriteit 100%

Iemand Hier stelt voor dat het misschien een Firewall-probleem:

Ik heb net dit probleem gehad en vond dat het mijn firewall was. Ik gebruik PCTools Firewall Plus en het toestond geen volledige toegang tot MySQL. Toen ik eenmaal veranderde dat het goed was. Hoop dat dat helpt.

Zou dat het kunnen zijn?

Ook, iemand Hier suggereert dat het zou kunnen Omdat de MySQL-server is gebonden aan de Loop-Back IP (127.0.0.1 / localhost) die je effectief afsnijdt van het aansluiten van “Buiten”.

Als dit het geval is, moet u het script uploaden naar de webserver (die waarschijnlijk ook de MySQL-server uitvoert) en uw serverhost als ‘localhost’

behouden


Antwoord 2, Autoriteit 37%

Open MySQL-configuratiebestand met de naam My.CNF en probeer “BIND-ADRES” te vinden, hierna de instelling (127.0.0.1 of localhost) vervangen door uw Live Server IP (de IP die u gebruikt in MySQL_Connect-functie)

Hiermee wordt het probleem absoluut opgelost.

bedankt


Antwoord 3, Autoriteit 34%

1) Sta Remote Connect toe aan MySQL.
Bewerk bestand:

>sudo nano /etc/mysql/my.cnf

Reactieregel:

#bind-address       = 127.0.0.1

Herstart MySQL:

>sudo service mysql restart

2) Maak een gebruiker aan voor externe verbinding.

>mysql -uroot -p
CREATE USER 'developer'@'localhost' IDENTIFIED BY 'dev_password';
CREATE USER 'developer'@'%' IDENTIFIED BY 'dev_password';
GRANT ALL ON *.* TO 'developer'@'localhost';
GRANT ALL ON *.* TO 'developer'@'%';

3) In mijn geval moet ik op afstand verbinding maken van Windows naar VirtualBox-machine met Ubuntu. Dus ik moet poort 3306 toestaan in iptables:

>iptables -A INPUT -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT

Antwoord 4, autoriteit 13%

Heb dit probleem gehad bij het opzetten van een nieuwe slave-server. Gevonden dat het IP-adres van de slaveserver ontbrak in het bestand van de masterserver /etc/hosts.allow. Het IP-adres toegevoegd en ik kon verbinding maken met de hoofdserver.

Merk op dat ik hosts.allowen hosts.denygebruik om de toegang te regelen.


Antwoord 5, autoriteit 7%

Ik had dit probleem en het bleek dat de vorige sys-beheerder de poort waarop MySQL draaide, had gewijzigd. MySQL Workbench probeerde verbinding te maken met de standaard 3306, maar de server draaide op 20300.


Antwoord 6, autoriteit 5%

De fout betekent dat het geen reactie heeft ontvangen van de poort waarop het de server verwachtte te vinden. De oorzaken variëren van contact opnemen met de verkeerde machine (om een van de vele redenen) tot de server die niet op de verwachte poort staat.

Controleer aan welke poort uw server is gebonden in /etc/mysql/my.cnf. Komt dat overeen met wat er in uw connect-statement staat. Als ze overeenkomen, probeer dan verbinding te maken met mysql vanaf de server zelf en vanaf de opdrachtregel van de machine waarop u de client uitvoert. Als het op de ene plek wel werkt en niet op een andere, dan heb je mogelijk een probleem met de firewall/routerconfiguratie.


Antwoord 7, autoriteit 4%

Het probleem in mijn geval was dat MySQL alleen aan de lo op linux werd gebonden.
om het probleem op te lossen heb ik de my.cnf bewerkt (te vinden op /etc/mysql/my.cnf) door de regel bind-address=127.0.0.1 te verwijderen

hierdoor kan mysql zich binden aan elke netwerkinterface


Antwoord 8, autoriteit 4%

Deze fout is bij mij opgekomen toen ik verbinding probeerde te maken met de Google Cloud SQL met MySQL Workbench 6.3.

Na wat onderzoek ontdekte ik dat mijn IP-adres is gewijzigd door de internetprovider en dat hij niet was toegestaan in de Cloud SQL.

Ik heb het geautoriseerd en ben weer aan het werk gegaan.


Antwoord 9, autoriteit 3%

Nog een reden…

Ik kwam een Ubuntu-server tegen waar alles was aangepast en kon vanwege diezelfde fout geen verbinding maken.

Deze instelling stond in /etc/ssh/sshd_config

PermitTunnel no

Na het veranderen in

PermitTunnel yes

Ik kon op afstand verbinding maken met mijn MySQL DB


Antwoord 10, autoriteit 3%

Ik liep deze exact dezelfde fout in bij het aansluiten van MySQL Workbench. Hier is hoe ik het heb gerepareerd. Mijn /etc/my.cnf-configuratiebestand had de bindadres-waarde ingesteld op het IP-adres van de server. Dit moest worden gedaan om replicatie in te stellen. Hoe dan ook, ik heb het opgelost door twee dingen te doen:

  1. Maak een gebruiker die kan worden gebruikt om verbinding te maken met het bindadres in het bestand My.cnf

b.g.

CREATE USER 'username'@'bind-address' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON schemaname.* TO 'username'@'bind-address';
FLUSH PRIVILEGES;
  1. Wijzig de MySQL-hostnaamwaarde in de aansluitgegevens in MySQL Workbench om overeen te komen met het bindadres

Antwoord 11, Autoriteit 2%

Het probleem voor mij was dat DNS-query’s werden geblokkeerd door de FW in het subnet. De oplossing was om DNS-lookups binnen MySQL uit te schakelen.


Antwoord 12, Autoriteit 2%

Ik heb gewoon MySQL opgezet in een Windows-doos. Ik heb de fout van het OP bij het proberen om verbinding te maken met de Navicat MySQL-client in dezelfde doos. Ik moest 127.0.0.1 specificeren als de gastheer, en dat heeft het.

localhost, of het daadwerkelijke IP-adres van de servers werkte beiden niet.


Antwoord 13, Autoriteit 2%

Voor mij is het configuratiebestand gevonden “/etc/mysql/mysql.conf.d/mysqld.cnf” commenting out bindadres heeft de truc.

Zoals we hier kunnen zien:
in plaats van Skip-Networking De standaard is nu om alleen te luisteren
localhost die compatibel is en niet minder veilig is.


Antwoord 14, Autoriteit 2%

In mijn geval had ik alles: alles in hosts.Den. Dit aan iedereen wijzigen: Paranoïde heeft mijn probleem opgelost bij het verbinden van SSH


Antwoord 15, Autoriteit 2%

Het probleem was behoorlijk stom voor mij.

Ik kreeg hetzelfde probleem op de AWS EC2 Ubuntu-machine (MariaDB is voorlopig lokaal geïnstalleerd), dus ik probeerde SSH-tunneling te maken en had hetzelfde probleem. Dus ik probeerde de tunnel over terminal te ssh-en:

ssh -L13306:127.0.0.1:3306 [email protected] -i my/private/key.pem

En het vertelde me dit:

Log in als gebruiker “ubuntu” in plaats van als gebruiker “root”.

Ik heb de ssh-gebruiker gewijzigd van root in ubuntu, net als mijn ssh-configuratie, en het maakte prima verbinding.

Controleer dus uw SSH-verbindingsgebruiker.

Ik heb hier toezicht op gehouden, dus ook dit een half uur van mijn tijd, dus ik hoop dat dit nuttig voor je zal zijn.


Antwoord 16, autoriteit 2%

Loop tegen hetzelfde probleem aan, Bind Addressheen en weer tevergeefs. De oplossing voor mij was voorrechten doorspoelen.

mysql> FLUSH PRIVILEGES;

Antwoord 17, autoriteit 2%

Ik probeer mijn db docker-containeraan te sluiten op Ubuntu 18.04, hetzelfde probleem.

Controleer eerst uw apparaat door nmcli devuit te voeren om te controleren of apparaat docker0is aangesloten.

Als het niet is aangesloten, probeer dan de docker-service opnieuw te starten:

sudo service docker restart


Antwoord 18

Voor mij werkte het instellen van bind-address = 0.0.0.0in mysql/my.cnf. Het luistert dan in principe naar alle adressen (maar nog steeds één poort).

En vergeet niet je server opnieuw op te starten: systemctl restart mysql


Antwoord 19

Ik had net hetzelfde probleem, maar in mijn geval heb ik het opgelost met

service mysqld start


Antwoord 20

Ik had hetzelfde probleem. Ik heb het gecontroleerd en geprobeerd om AllowTcpForwarding Jain te stellen, maar het ontbrak in mijn sshd_config, dus geen hulp. Ik heb sshd_config of my.cnf niet gewijzigd. Zorg ervoor dat de ssh-hostnaam NIEThetzelfde is als de mysql-hostnaam (gebruik localhost).

Kies in workbench + om een nieuwe verbinding toe te voegen en stel het volgende in:

  • verbindingsmethode: standaard TCP/IP via SSH
  • SSH-hostnaam: 192.168.0.50:22(vervang het IP-adres en de poort van de externe SSH-server (optioneel))
  • SSH-gebruikersnaam: sshuser
  • U kunt een wachtwoord instellen of toevoegen bij de prompt
  • MYSQL-hostnaam: localhost of 127.0.0.1
  • MYSQL-serverpoort:3306
  • U kunt een wachtwoord instellen of toevoegen bij de prompt

Test verbinding. Het zou succesvol moeten zijn en druk dan op OK.Viola!


Antwoord 21

In mijn geval was het de wifi-blokkeringspoort 3306 van de universiteit. Ik kon verbinding maken via een mobiele hotspot.

Verander naar een mobiele hotspot of een ander netwerk, en als het daar werkt, weet je dat het oorspronkelijke netwerk poort 3306 blokkeert. Als je dezelfde fout op meer dan 1 netwerk krijgt, weet je dat het specifiek is voor jouw machine.


Antwoord 22

Firewalldblokkeert het IP-adres. dus om toegang te geven, gebruik je deze commando’s:

firewall-cmd –permanent –zone=trusted –add-source=YOUR_IP/32

firewall-cmd –permanent –zone=trusted –add-port=3306/tcp

firewall-cmd –reload


Antwoord 23

Ik heb geprobeerd een telnette maken via een externe server op poort 3306.
De foutmelding is duidelijk

Host 'x.x.x.x' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'Connection closed by foreign host.

Als rootOP SERVER mysqladmin flush-hostsWERKT ALL!


Antwoord 24

Ik had dezelfde fout bij het gebruik van localhost. Ik herstart de MySQL-service en het werkte prima.


Antwoord 25

Bij aansluiting op MySQL op afstand, kreeg ik de fout.
Ik had deze waarschuwing in /var/log/mysqld.log:

[Warning] IP address 'X.X.X.X' could not be resolved: Temporary failure in name resolution

Ik heb deze regel gewoon toegevoegd aan /etc/hostsbestand:

X.X.X.X some_name

Probleem opgelost! Niet gebruiken skip-name-resolveVeroorzaakt enkele fouten in mijn lokale app bij het aansluiten op MySQL.


Antwoord 26

Ik had identiek probleem. Om het te repareren, veranderde ik gewoon van host van localhost: 3306 tot gewoon localhost. Dus fout kan Acour Acour wanneer u oneprroper poort voor verbinding dient. Het is beter om het standaard te verlaten.


Antwoord 27

Databasedirectory lees-schrijf toestemming ook een probleem dat ik heb gevonden.
Zorg ervoor dat uw applicatie kan RW-bestanden op DB-locatie. Probeer chmod 777 voor testen.


Antwoord 28

Als bindadres niet aanwezig is in uw configuratiebestand en MySQL wordt gehost op AWS-exemplaar, controleer dan uw beveiligingsgroep. In de ideale omstandigheden moeten de inkomende regels alle aansluiting aanvaarden van de haven 3306 en de uitgaande regel moeten reageren op alle geldige IPS.


Antwoord 29

Ik had een vergelijkbare fout (verbonden met MySQL op AWS via MySQL Workbench). Ik verbond vroeger voor en plotseling stopte het met werken en zou gewoon niet meer werken). Mijn verbinding was via SSH beschermd door KeyFile.

Blijkbaar had ik een time-out. Dus ik verhoogde de time-out van de SQL-verbinding tot 30 seconden (van standaard 10) en was goed om weer te gaan. dingen die u kunt proberen (als u zich in een vergelijkbare configuratie bevindt)

  1. Kun je rechtstreeks van terminal naar de server ssh’en (detecteert problemen met sleutelbestandsrechten, enz.)?
  2. Kun je dan via terminal verbinding maken met MySQL met dezelfde gebruiker/pwd met iets als mysql -u [username] -p [database]? Hiermee wordt gecontroleerd op problemen met gebruikersrechten, enz.
  3. als beide werken, dan zijn je parameters niet het probleem en misschien hetzelfde time-outprobleem als ik (behalve dat er nooit een time-outfout is genoemd, maar eerder gevraagd om te controleren op toestemmingen, enz.)

Antwoord 30

Beperkte schijfruimte kan deze fout veroorzaken.

Controleer uw schijfruimte

$ df -h

Probeer de ruimte te vergroten als er 100% gebruikte schijven zijn.

In mijn geval: ik heb een Vagrant (8.0.1) box (Ubuntu 16.04) Mijn mysql-schijfcapaciteit was 10 GB, ik heb deze verhoogd naar 20 GB

$ sudo lvextend -L20G -r /dev/mapper/homestead--vg-mysql--master

Herstart mysql vervolgens

$ sudo service mysql restart

Other episodes