MySQL Access Denied for User (1045) Hatası Nasıl Çözülür?

MySQL erişim reddedildi hatası, yani ERROR 1045 (28000): Access denied for user, muhtemelen bir veritabanıyla uğraşan herkesin gördüğü ilk ciddi hatadır. phpMyAdmin'e girmeye çalışırsınız, WordPress kurulumunun veritabanı adımında takılırsınız ya da masaüstündeki bir istemciden uzaktaki sunucuya bağlanmayı denersiniz; ekranda hep aynı cümle belirir. Ve hemen hemen herkesin ilk refleksi aynıdır: şifreyi yanlış yazmış olmalıyım. Şifreyi sıfırlarsınız, tekrar denersiniz, aynı hata. Bir daha sıfırlarsınız, aynı hata.

Bu yazının varlık sebebi tam olarak şu: MySQL 1045 hatası çoğu zaman şifreyle ilgili değildir. MySQL'de bir kullanıcının kimliği yalnızca kullanıcı adından değil, kullanıcı adı ile bağlandığı host'un çiftinden oluşur. mehmet@localhost ile mehmet@% iki ayrı kullanıcıdır, ayrı ayrı şifreleri ve ayrı ayrı yetkileri olabilir. Şifreniz doğruyken bile, yanlış host'tan bağlandığınız için 1045 alırsınız. Aşağıda hata mesajının içindeki host bilgisini nasıl okuyacağınızı, mysql.user tablosundan gerçekte hangi kullanıcıların tanımlı olduğunu nasıl göreceğinizi, SHOW GRANTS çıktısını nasıl yorumlayacağınızı ve hangi durumda hangi düzeltmeyi uygulayacağınızı sırayla anlatıyorum. Deneme yanılmayı bırakıp hatayı tek seferde teşhis edeceksiniz.

MySQL 1045 Hatası Tam Olarak Ne Anlama Gelir#

MySQL 1045 hatası, sunucunun sizi tanımadığını değil, sunduğunuz kullanıcı adı + host + şifre üçlüsüne uyan bir hesap bulamadığını söyler. Hata mesajının kendisi bunu zaten yazar ama okunmadığı için gözden kaçar:

ERROR 1045 (28000): Access denied for user 'wpuser'@'localhost' (using password: YES)

Bu tek satırda dört ayrı bilgi vardır ve her biri ayrı bir teşhis yolu açar:

Dikkat edilmesi gereken en önemli nokta şudur: bu hatayı aldıysanız TCP bağlantısı başarıyla kurulmuştur. Sunucuya ulaştınız, MySQL sizi karşıladı, el sıkışma yapıldı ve ardından reddedildiniz. Eğer sunucuya hiç ulaşamıyor olsaydınız 1045 değil, ERROR 2003 (HY000): Can't connect to MySQL server veya bağlantı seviyesinde bir ERR_CONNECTION_REFUSED hatası alırdınız. Yani 1045 gördüğünüz anda güvenlik duvarı, port, servis ayakta mı gibi soruları listeden çıkarabilirsiniz. Sorun kesinlikle yetkilendirme katmanındadır.

(using password: NO) ifadesini gördüğünüzde ise hikâye tamamen değişir. Bu, uygulamanızın şifre alanını boş gönderdiği anlamına gelir — genellikle yapılandırma dosyasındaki değişkenin okunamaması, ortam değişkeninin tanımsız olması ya da tırnak hatası yüzünden. Şifreyi sıfırlamak burada hiçbir işe yaramaz; şifrenin uygulamadan çıkmadığını çözmeniz gerekir.

MySQL Kullanıcı Kimliği Neden Kullanıcı Adı + Host Çiftidir#

MySQL'de kullanıcı hesabı 'kullanici'@'host' biçiminde saklanır ve bu iki parça birlikte birincil anahtarı oluşturur. Yani aynı kullanıcı adına sahip birden fazla hesap aynı anda var olabilir:

SELECT user, host, plugin FROM mysql.user ORDER BY user, host;

Tipik bir çıktı şuna benzer:

+------------------+-----------+-----------------------+
| user             | host      | plugin                |
+------------------+-----------+-----------------------+
| wpuser           | localhost | caching_sha2_password |
| wpuser           | 10.0.0.%  | caching_sha2_password |
| raporlama        | %         | mysql_native_password |
| root             | localhost | auth_socket           |
+------------------+-----------+-----------------------+

Buradaki wpuser iki kez geçiyor ve bunlar iki ayrı hesaptır. localhost olanın şifresi farklı olabilir, yetkileri farklı olabilir, hatta biri aktif diğeri kilitli olabilir. Web sunucusu ile MySQL aynı makinedeyse birincisi kullanılır; uygulama başka bir sunucudan 10.0.0.14 üzerinden bağlanıyorsa ikincisi devreye girer. Uygulamayı ayrı bir sunucuya taşıdığınız gün, şifreye hiç dokunmadığınız hâlde 1045 almanızın sebebi budur.

Host alanında kullanılabilecek değerler ve anlamları:

localhost ile 127.0.0.1 ayrımı en çok tuzağa düşüren yerdir. MySQL istemcisi -h localhost verildiğinde Linux'ta TCP değil, Unix soket dosyasını kullanır (/var/run/mysqld/mysqld.sock). -h 127.0.0.1 verdiğinizde ise TCP'ye geçer. Sunucu bu iki yolu farklı host değerleriyle eşler. Yani 'app'@'localhost' hesabı varken mysql -h 127.0.0.1 -u app -p komutu 1045 verir — ve şifre kesinlikle doğrudur.

Hata Mesajındaki Host Bilgisini Nasıl Okursunuz#

Hatanın içindeki @ işaretinden sonraki değer, MySQL sunucusunun sizi nereden geliyor gördüğüdür; sizin nereden geldiğinizi sandığınız yer değil. Bu ayrım teşhisin kalbidir.

Diyelim ki uygulama sunucunuzun IP'si 10.0.0.14 ve şu hatayı alıyorsunuz:

ERROR 1045 (28000): Access denied for user 'app'@'10.0.0.14' (using password: YES)

Bu mesaj size şunu söyler: sunucuda 'app'@'10.0.0.14' ya da bu IP'yi kapsayan bir joker ('app'@'10.0.0.%' veya 'app'@'%') hesabı yoktur, ya da vardır ama şifresi tutmamıştır. Kontrolü tek sorguyla yapabilirsiniz:

SELECT user, host FROM mysql.user WHERE user = 'app';

Çıktıda yalnızca app | localhost görüyorsanız teşhis tamamdır: hesap var, ama yalnızca yerel bağlantılar için tanımlı. Şifreyi yüz kere sıfırlasanız da bu bağlantı açılmaz.

Bir de NAT ve konteyner senaryosu vardır. Docker içinden bağlanıyorsanız MySQL sizi konteynerin köprü ağındaki adresiyle (172.17.0.x) görür, sizin bildiğiniz host IP'siyle değil. Cloud ortamlarda ise özel IP yerine NAT gateway adresi görünebilir. Bu yüzden hesabı oluştururken IP'yi tahmin etmeyin; hata mesajının size söylediği adresi baz alın. Mesaj zaten doğru cevabı içeriyor.

Sunucunun sizi hangi adresle gördüğünü bağımsız olarak doğrulamak isterseniz, başarılı bir bağlantı içinde şu sorgu yeterlidir:

SELECT CURRENT_USER(), USER();

USER() sizin bağlanmaya çalıştığınız kimliği, CURRENT_USER() ise MySQL'in sizi eşlediği hesabı gösterir. Bu ikisi farklıysa — örneğin [email protected] ve app@% — bağlantınız joker hesap üzerinden kabul edilmiş demektir ve yetkileri o hesaptan alırsınız.

Şifre Doğruyken 1045 Almanın En Sık Beş Sebebi#

Şifre doğru olmasına rağmen 1045 alınmasının nedeni neredeyse her zaman aşağıdaki beş maddeden biridir.

1. Hesap yanlış host için tanımlı. En yaygın senaryo. Yukarıda anlattığım localhost / % ayrımı.
2. Uygulama, şifreyi yapılandırma dosyasından okuyamıyor. (using password: NO) bunun imzasıdır. WordPress'te wp-config.php dosyasındaki DB_PASSWORD satırında tırnak hatası, ortam değişkeni kullanılan kurulumlarda değişkenin tanımsız kalması buna yol açar. Bu durumda şifreyi sıfırlamak değil, değerin uygulamadan gerçekten çıkıp çıkmadığını doğrulamak gerekir.
3. Şifrede kabuk tarafından yorumlanan karakter var. Komut satırında -p'Se$$1z!' yazdığınızda kabuk $$ ifadesini kendi süreç numarasıyla değiştirir. Tek tırnak kullanmak ve şifreyi doğrudan komuta yazmamak doğru davranıştır.
4. Kimlik doğrulama eklentisi uyumsuz. MySQL 8 varsayılan olarak caching_sha2_password kullanır; eski PHP veya eski istemci kütüphaneleri bunu konuşamayabilir. Sunucu bunu da 1045 olarak raporlar.
5. Kullanıcı adında görünmeyen boşluk var. Panelden kopyalanan kullanıcı adının sonunda boşluk kalması sanılandan çok daha sık görülür. Hata mesajındaki tırnak içine dikkatle bakın: 'wpuser ' gibi bir çıktı sorunu anında ele verir.

Şifrenin doğru olup olmadığını izole biçimde sınamanın en temiz yolu, uygulamayı tamamen aradan çıkarıp doğrudan istemciyle bağlanmaktır:

mysql -h 127.0.0.1 -P 3306 -u app -p --protocol=TCP

--protocol=TCP bayrağı soket kısayolunu devre dışı bırakır ve gerçekten TCP üzerinden bağlanmanızı garanti eder. Bu komut çalışıyor ama uygulamanız çalışmıyorsa sorun MySQL'de değil, uygulamanın yapılandırmasındadır.

GRANT Satırını Doğrulama ve Yetki Kontrolü#

Kimlik doğrulaması geçtikten sonra ikinci bir engel daha vardır: yetkiler. Hesap doğru host için tanımlıysa ve şifre tutuyorsa bağlantı kurulur, ama veritabanına erişemezsiniz. Bu durumda hata numarası değişir — 1045 değil, 1044 (Access denied for user ... to database ...) alırsınız. İkisini karıştırmayın:

Bir hesabın gerçekte neye yetkili olduğunu görmenin tek doğru yolu SHOW GRANTS kullanmaktır:

SHOW GRANTS FOR 'app'@'10.0.0.%';

Tipik bir çıktı:

+---------------------------------------------------------------------+
| Grants for [email protected].%                                             |
+---------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `app`@`10.0.0.%`                              |
| GRANT SELECT, INSERT, UPDATE, DELETE ON `magaza`.* TO `app`@`10.0.0.%` |
+---------------------------------------------------------------------+

Burada GRANT USAGE ON *.* satırı sizi yanıltmasın: USAGE "hiçbir yetkisi yok ama hesap var" anlamına gelir. Yalnızca bu satırı görüyorsanız kullanıcı bağlanabilir fakat hiçbir veritabanını göremez. Bu, phpMyAdmin'e girip boş bir liste görmenin klasik sebebidir.

Bu hesap ilgili host için hiç yoksa SHOW GRANTS şu hatayı verir:

ERROR 1141 (42000): There is no such grant defined for user 'app' on host '10.0.0.%'

Yani sorgunun kendisi de bir teşhis aracıdır. Yetki modelini derinlemesine kurmak isterseniz MySQL kullanıcı yetkileri yazısı yetki türlerini tek tek açıklıyor.

Erişimi Doğru Biçimde Açma: Adım Adım Komutlar#

Teşhis tamamlandıysa düzeltme kısa sürer. MySQL 8 ve MariaDB 10.4+ için doğru sıra kullanıcı oluşturmak, sonra yetki vermektir; eski sürümlerdeki GRANT ... IDENTIFIED BY tek satırı artık önerilmez.

1. Yönetici olarak bağlanın:

sudo mysql -u root

2. Hangi hesapların gerçekten var olduğunu görün:

SELECT user, host, plugin, account_locked FROM mysql.user WHERE user = 'app';

3. Eksik host için hesabı oluşturun. Hata mesajındaki adresi birebir kullanın:

CREATE USER 'app'@'10.0.0.14' IDENTIFIED BY 'gucluBirSifre';

Tek bir IP yerine ağ bloğu vermek istiyorsanız:

CREATE USER 'app'@'10.0.0.%' IDENTIFIED BY 'gucluBirSifre';

4. Yalnızca ihtiyaç duyulan yetkileri verin. ALL PRIVILEGES vermek pratik görünür ama uygulama hesabının tablo silme yetkisine ihtiyacı yoktur:

GRANT SELECT, INSERT, UPDATE, DELETE ON magaza.* TO 'app'@'10.0.0.%';
FLUSH PRIVILEGES;

5. Var olan bir hesabın şifresini değiştirmeniz gerekiyorsa, host'u da belirterek yapın. Host yazmazsanız MySQL varsayılan olarak % varsayar ve yanlış hesabın şifresini değiştirirsiniz:

ALTER USER 'app'@'10.0.0.%' IDENTIFIED BY 'yeniSifre';

6. Eski bir istemci kütüphanesi kullanıyorsanız kimlik doğrulama eklentisini değiştirin:

ALTER USER 'app'@'10.0.0.%' IDENTIFIED WITH mysql_native_password BY 'yeniSifre';

7. Değişikliği hemen doğrulayın; uygulamayı yeniden başlatmadan önce istemciyle test edin:

mysql -h 10.0.0.5 -u app -p -e "SELECT CURRENT_USER();"

Sunucunun uzaktan bağlantı kabul edip etmediğini de kontrol etmeyi unutmayın. bind-address değeri 127.0.0.1 ise, hesabı % için açsanız bile dışarıdan gelen paket MySQL'e hiç ulaşmaz — bu durumda 1045 değil bağlantı hatası alırsınız:

grep -R "bind-address" /etc/mysql/

Uzaktan erişimi güvenli biçimde kurgulamak istiyorsanız uzaktan MySQL bağlantısı yazısında SSH tüneli üzerinden çalışan alternatifi de bulacaksınız — çoğu durumda 3306 portunu internete açmaktan çok daha doğru bir yaklaşımdır.

phpMyAdmin ve cPanel Ortamında 1045 Hatası#

Paylaşımlı hosting üzerinde 1045 hatasının sebebi neredeyse her zaman kullanıcı adı ön ekidir. cPanel, oluşturduğunuz her veritabanı ve kullanıcı adının başına hesap adınızı ekler. Panelde magaza yazarsınız, gerçek isim hesapadi_magaza olur. Uygulamanın yapılandırma dosyasına ön eksiz adı yazarsanız kimlik doğrulaması başarısız olur.

Sık karşılaşılan ikinci sebep, kullanıcının veritabanına atanmamış olmasıdır. cPanel'de kullanıcı oluşturmak ve veritabanı oluşturmak iki ayrı adımdır; üçüncü bir adımda "Kullanıcıyı Veritabanına Ekle" ekranından ikisini eşleştirmeniz gerekir. Bu adım atlandığında kullanıcı vardır, şifre doğrudur, fakat hiçbir veritabanına yetkisi yoktur.

Kontrol listesi olarak şu sırayı izleyin:

1. cPanel → MySQL Veritabanları ekranında kullanıcının tam adını (ön ekiyle birlikte) not edin.
2. Aynı ekranın alt kısmında kullanıcının hangi veritabanına atandığını doğrulayın.
3. Şifreyi panelden yeniden belirleyin ve panonun kopyaladığı değeri doğrudan yapıştırın; elle yazmayın.
4. Uygulamanın yapılandırma dosyasında host değerinin localhost olduğundan emin olun. Paylaşımlı hostingde bu neredeyse her zaman localhost'tur; sunucunun genel IP'sini yazmak dışarıdan bağlantı olarak sayılır ve reddedilir.
5. phpMyAdmin'e panel üzerinden girin. Doğrudan phpMyAdmin giriş ekranından deniyorsanız ve orada 1045 alıyorsanız, kullanıcı adı ön ekini yine kaçırmış olabilirsiniz.

Hosting hesabınızda hata kaydını görmek için cPanel hata kayıtları ekranını kullanabilirsiniz; PHP tarafındaki mysqli_connect(): (HY000/1045) satırı hangi kullanıcı adının gerçekten gönderildiğini gösterir ve tahmin yürütmeyi bitirir.

Root Şifresini Unuttuysanız: Güvenli Kurtarma#

Root şifresini kaybettiyseniz kurtarma mümkündür ama sunucuya fiziksel ya da SSH erişiminiz olmalıdır. İşlem sırasında MySQL bir süre yetki kontrolü olmadan çalışacağı için, bu adımları yalnızca erişimi kısıtlanmış bir ortamda ve mümkün olduğunca hızlı uygulayın.

sudo systemctl stop mysql
sudo mkdir -p /var/run/mysqld && sudo chown mysql:mysql /var/run/mysqld
sudo mysqld_safe --skip-grant-tables --skip-networking &

--skip-networking bayrağı burada kritik: yetki kontrolü kapalıyken sunucunun ağdan erişilebilir olmasını engeller. Ardından şifresiz bağlanıp değişikliği yapın:

FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'yeniRootSifresi';

FLUSH PRIVILEGES satırını ALTER USER öncesinde çalıştırmak zorunludur; yetki tabloları yüklenmeden ALTER USER komutu çalışmaz ve "Unknown command" benzeri kafa karıştırıcı bir hata alırsınız. İşlem bittiğinde geçici süreci sonlandırıp servisi normal biçimde başlatın:

sudo pkill mysqld_safe
sudo systemctl start mysql

Modern Ubuntu kurulumlarında root@localhost hesabı auth_socket eklentisiyle gelir; yani şifre değil, işletim sistemi kullanıcısı üzerinden doğrulanır. sudo mysql çalışıyor ama mysql -u root -p 1045 veriyorsa durum tam olarak budur ve bu bir arıza değildir. Şifreyle giriş isterseniz eklentiyi bilinçli olarak değiştirmeniz gerekir. Benzer bir "anahtar var ama kabul edilmiyor" mantığını SSH permission denied publickey hatası yazısında da göreceksiniz — iki hata farklı servislerde çıkar ama teşhis mantığı aynıdır: sunucu sizi hangi kimlikle eşliyor?

Tekrar Yaşamamak İçin Kalıcı Düzen#

1045 hatasının tekrar tekrar dönmesinin sebebi genellikle disiplinsiz kullanıcı yönetimidir. Birkaç alışkanlık bu döngüyü kapatır.

Her uygulama için ayrı hesap açın. Tek bir admin hesabını beş uygulamada paylaşmak, şifre değiştiğinde beş yerin birden düşmesi demektir. Ayrıca bir uygulamanın açığı diğerlerinin verisine erişim vermez.

Host'u mümkün olduğunca dar tutun. % pratiktir ama internete açık bir MySQL için ciddi risktir. Uygulama sunucunuzun IP'si ya da özel ağ bloğu yeterlidir.

Hesapları belgeleyin. Küçük bir dosyada hangi kullanıcının hangi host için hangi veritabanına yetkili olduğunu tutmak, altı ay sonra hatırlamaya çalışmaktan çok daha ucuzdur. Bunu otomatikleştirmek isterseniz mysql.user tablosunu düzenli olarak döken küçük bir kabuk betiği yeterlidir.

Yetki değişikliklerini denetleyin. Aşağıdaki sorgu, sunucudaki tüm hesapların özetini tek ekrana sığdırır ve düzenli olarak bakmaya değer:

SELECT user, host,
       IF(account_locked='Y','KİLİTLİ','aktif') AS durum,
       plugin
FROM mysql.user
ORDER BY user, host;

Bağlantı sayısını izleyin. Yetki sorunu çözüldükten sonra sıradaki tipik arıza bağlantı havuzunun dolmasıdır; SHOW STATUS LIKE 'Threads_connected'; sorgusunu düzenli olarak çalıştırmak erken uyarı verir.

Sıkça Sorulan Sorular#

MySQL 1045 hatası her zaman şifre yanlış demek mi#

Hayır, çoğu zaman şifreyle ilgili değildir. MySQL'de kimlik kullanıcı adı ile host çiftinden oluştuğu için, doğru şifreyle bile yanlış host'tan bağlandığınızda 1045 alırsınız. Hata mesajındaki @ işaretinden sonraki değer sunucunun sizi nereden geliyor gördüğünü söyler; mysql.user tablosunda o host için bir hesap yoksa şifre hiç değerlendirilmez bile. Şifreyi sıfırlamadan önce mutlaka SELECT user, host FROM mysql.user WHERE user='kullanici'; sorgusunu çalıştırın.

localhost ile 127.0.0.1 arasındaki fark nedir#

Linux'ta localhost Unix soket dosyası üzerinden, 127.0.0.1 ise TCP üzerinden bağlanır ve MySQL bunları farklı host değerleriyle eşler. Yani 'app'@'localhost' hesabı varken -h 127.0.0.1 ile bağlanmak 1045 verir. İki yolun da çalışmasını istiyorsanız iki ayrı hesap tanımlamanız veya bağlantı dizesinde tutarlı bir tercih yapmanız gerekir. Test ederken --protocol=TCP bayrağı hangi yolun kullanıldığını netleştirir.

using password NO ifadesi ne anlama geliyor#

Bu ifade, sunucuya hiç şifre gönderilmediğini gösterir. Sorun MySQL'de değil, bağlanan uygulamadadır: yapılandırma dosyasındaki şifre değişkeni boş kalmış, ortam değişkeni tanımsız kalmış veya tırnak hatası yüzünden okunamamıştır. WordPress'te wp-config.php içindeki DB_PASSWORD satırı, çerçevelerde .env dosyası ilk bakılacak yerdir. Şifreyi sıfırlamak bu durumda hiçbir şeyi değiştirmez.

GRANT USAGE ne demek ve neden hiçbir tabloyu göremiyorum#

GRANT USAGE ON *.* satırı, hesabın var olduğunu ama hiçbir yetkiye sahip olmadığını gösterir. Bağlantı kurulur, giriş başarılı görünür fakat veritabanı listesi boş gelir. Bu durumda ilgili veritabanı için açıkça GRANT SELECT, INSERT, UPDATE, DELETE ON veritabani.* TO 'kullanici'@'host'; çalıştırmanız gerekir. SHOW GRANTS FOR 'kullanici'@'host'; çıktısında yalnızca USAGE satırı görünüyorsa teşhis kesindir.

cPanel üzerinde 1045 alıyorum, ne kontrol etmeliyim#

Önce kullanıcı adının ön ekini kontrol edin; cPanel tüm veritabanı ve kullanıcı adlarının başına hesap adınızı ekler, yani gerçek ad hesapadi_kullanici biçimindedir. Ardından kullanıcının veritabanına atanıp atanmadığına bakın, çünkü kullanıcı oluşturmak ile onu veritabanına eklemek ayrı adımlardır. Host değeri paylaşımlı hostingde daima localhost olmalıdır; sunucunun genel IP'sini yazmak bağlantıyı dışarıdan gelmiş gibi gösterir ve reddedilir.

MySQL 8 ile eski PHP sürümü arasında uyumsuzluk 1045 üretir mi#

Evet, MySQL 8 varsayılan olarak caching_sha2_password kimlik doğrulama eklentisini kullanır ve eski istemci kütüphaneleri bu yöntemi konuşamaz. Sunucu bu durumu da erişim reddi olarak raporladığı için sorun şifre hatasına benzer görünür. Hesabı ALTER USER 'kullanici'@'host' IDENTIFIED WITH mysql_native_password BY 'sifre'; komutuyla eski yönteme geçirmek çözümdür. Uzun vadede istemci tarafını güncellemek daha doğru bir yaklaşımdır.

1045 ile 1044 hataları arasındaki fark ne#

1045 kimlik doğrulamanın başarısız olduğunu, 1044 ise kimliğin doğrulandığını ama belirtilen veritabanına erişim yetkisi olmadığını gösterir. Yani 1044 aldıysanız kullanıcı adınız, host'unuz ve şifreniz doğrudur; eksik olan yalnızca GRANT satırıdır. Bu ayrım teşhis süresini ciddi biçimde kısaltır çünkü hangi komutu çalıştıracağınızı doğrudan söyler. Tablo bazlı bir yetki eksikliğinde ise 1142 hatasıyla karşılaşırsınız.

Root şifresini sıfırlarken sunucu risk altında mı#

Evet, --skip-grant-tables ile başlatılan bir MySQL sunucusunda yetki kontrolü tamamen devre dışıdır ve bağlanan herkes tam yetkiyle çalışır. Bu yüzden komutu mutlaka --skip-networking bayrağıyla birlikte kullanın; böylece sunucu yalnızca yerel soketten erişilebilir olur. İşlemi olabildiğince kısa tutun ve şifre değişikliği biter bitmez servisi normal modda yeniden başlatın. Mümkünse bu işlemi bakım penceresi içinde yapın.

Kapanış#

MySQL 1045 hatasında teşhisin tamamı tek bir soruya bakar: sunucu sizi hangi kullanıcı ve hangi host olarak görüyor? Hata mesajı bu iki bilgiyi zaten yazar, mysql.user tablosu gerçekte hangi hesapların tanımlı olduğunu gösterir, SHOW GRANTS ise o hesabın neye yetkili olduğunu söyler. Bu üç kaynağı sırayla okuduğunuzda şifre sıfırlama döngüsünden tamamen çıkarsınız; çünkü çoğu vakada şifre en baştan doğruydu. localhost ile 127.0.0.1 ayrımını, cPanel'in kullanıcı adı ön ekini ve USAGE yetkisinin aslında "yetki yok" anlamına geldiğini bilmek, bu hatanın yüzde doksanını dakikalar içinde kapatır.

Veritabanı kullanıcı yönetimini panel üzerinden kolayca yapmak istiyorsanız cPanel'li web hosting paketleri kullanıcı, veritabanı ve yetki eşleştirmesini tek ekranda toplar. Uzaktan bağlantı, kendi MySQL sürümünüzü seçme ve bind-address gibi ayarlara ihtiyaç duyuyorsanız kök erişimli bir VDS sunucu çok daha rahat çalışmanızı sağlar. Kurulum, sıkılaştırma ve yedekleme tarafını kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmeti bu işleri devralır ve kullanıcı yetkilendirmesini de kapsar.