Archive

Archive for İ

MySQL 5.6.10 yeniliklər-mysql_config_editor

Terminaldan root və yaxud da digər user-lə connect olmaq lazım olur…Lakin hər dəfə root password yazmağa əringənlik yaranır, password yazarkən zillənən gözlər narahat edir və.s 😉
Ən əsası da təhlükəsizlik cəhətdən hər dəfə əllə password yazarkən process-ləri oxuya bilən birisi çox asandca sizin password-ü götürə bilər.
MySQL 5.6.6-dan etibarən mysql_config_editor utility təklif olunur. Bu utility bizə imkan verir ki authentication credential-ları encprypt olunmuş mylogin.cnf faylında saxlayaq…
Çox sadə istifadəsi var:

[root@localhost ~]# mysql_config_editor set --login-path=local  --host=localhost --user=root --password
Enter password: 
WARNING : 'local' path already exists and will be overwritten. 
 Continue? (Press y|Y for Yes, any other key for No) : y

Əgər remote connect oluruqsa, –login-path=remote qeyd edirik.

Daha sonra qoşulmaq istədikdə sadəcə yazırıq:

[root@localhost ~]# mysql --login-path=local
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.6.10-log MySQL Community Server (GPL)

Hə sual ola bilər ki, parolu filan hər hansı fayla yazmaq düzgündür mü? Təbii ki buna dəhşətli şüphəli yanaşmaq da olar.
Amma ən azından faylı oxuduqda belə heç bir password görsənmir:

[root@localhost ~]# mysql_config_editor print --all
[local]
user = root
password = *****
host = localhost

Hələ geniş istifadə olunmayıb məhz bu səbəbdən google-da bu utility-yə qarşı dəhşətli bir gedişata rast gəlmədim 😉
Təşəkkürlər 😉

MySQL 5.6.10 yeniliklər-sha256_password,validate_password plugins

MySQL 5.6.6-dan etibarən “SHA-256 password hashing” parollar üçün daha secure encrypting support-u əlavə olunmuşdur.
Plugin şəklində gələn bu support sadə şəkildə aktiv olunur. Onu da qeyd etmək lazımdır ki , built-in plugin olduğu heç bir install və yaxud path göstərmək lazım deyil.
SHA-256 Authentication Plugin

Plugin-i aktiv etmək üçün my.cnf faylında
[mysqld] kataloqunun altında:

default-authentication-plugin=sha256_password

Yazmaq kifayətdir. MySQL restart etdikdən sonra adi qaydada hər hanıs bir user yaradaq:

mysql> create user 'donuzcuq'@'localhost' identified by '12345';
Query OK, 0 rows affected (0.09 sec)

və connect olmağa çalışaq:

[sh@localhost ~]$ mysql -u donuzcuq -p
Enter password: 
ERROR 2061 (HY000): Authentication plugin 'sha256_password' reported error: Authentication requires SSL encryption

Bunu mən bir bug kimi artıq report etmişəm. Report səbəbim isə çox sadədir: mən hansı əsasa görə məcburən SSL istifadə etməliyəm? Həm də bu məcburiyyət haqqında dokumentasiyada heç bir şey bildirilməyib.
Bəli çox təəssüf ki bu plugin-dən istifadə edə bilmədik keçirik digərinə 😉

validate_password
plugini MySQL 5.6.6-dan etibarən təklif olunur. bu plugin yeni user yaradarkən düzgün parolun qoyulub qoyulmadığını müəyyən edir. Daha doğrusu plugin aktiv olunduqdan sonra məcburən secure parol fikirləşməli olacıq.

Plugin-dən istifadə etmək üçün yenə my.cnf faylına:

[mysqld]
plugin-load=validate_password.so
validate-password=FORCE_PLUS_PERMANENT

Əlavə edirik və MySQL restart.
Dokumentasiya bildirir ki, Daha sonra root olaraq qoşuluruq və:

INSTALL PLUGIN validate_password SONAME 'validate_password.so';
ERROR 1125 (HY000): Function 'validate_password' already exists

Lakin son anda ortaya çıxır ki dokumentasiya səhv deyir. Error-dan da göründüyü kimi yuxarıdakı prosedur kifayət edir.
Və indi parolu 12345 olan bir user yaratmağa çalışaq:

mysql> create user 'donuzcuq'@'localhost' identified by '12345';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

Və hətta siz plugin-nin vasitəsilə qoymaq istədiyiniz password-u da yoxlaya bilərsiniz:

mysql> select VALIDATE_PASSWORD_STRENGTH('abc');
+-----------------------------------+
| VALIDATE_PASSWORD_STRENGTH('abc') |
+-----------------------------------+
|                                 0 |
+-----------------------------------+
1 row in set (0.00 sec)


mysql> select VALIDATE_PASSWORD_STRENGTH('12345');
+-------------------------------------+
| VALIDATE_PASSWORD_STRENGTH('12345') |
+-------------------------------------+
|                                  25 |
+-------------------------------------+
1 row in set (0.00 sec)

mysql> select VALIDATE_PASSWORD_STRENGTH('donuzcuq54');
+------------------------------------------+
| VALIDATE_PASSWORD_STRENGTH('donuzcuq54') |
+------------------------------------------+
|                                       50 |
+------------------------------------------+


mysql> select VALIDATE_PASSWORD_STRENGTH('Donuzcuq545&');
+--------------------------------------------+
| VALIDATE_PASSWORD_STRENGTH('Donuzcuq545&') |
+--------------------------------------------+
|                                        100 |
+--------------------------------------------+
1 row in set (0.00 sec)

Bu plugin mənim şəxsən çox xoşuma gəldi…
Təşəkkürlər 😉

max_connections vs. max_user_connections

Mövcud məhşur error-lardan biri:
ERROR 1203 (42000): User user_name already has more than ‘max_user_connections’ active connections
Bəs bur error hansı səbəbə çıxır? İlk öncə max_connectionsmax_user_connections-u fərqləndirək.


max_connections: Ümumiyyətlə MySQL-ə simultane qoşulma sayını müəyyən edir. Ümumiyyətlə.
max_user_connections: 1 user-in neçə dəfə simultane qoşula biləcəyini göstərir.

Sınayaq. my.cnf-ə [mysqld] kataloqunun altına yazırıq:

max_connections = 10
max_user_connections = 5

Teorik olaraq deyə bilərik ki, bizim 10 connect olmaq hüququmuz var. Lakin root user ilə 5 connection-dan sonra dəhşətli error-umuzu yenə gördük:

Və həqiqətən də 5 dəfə connect olmuşuq:

Bunun səbəbi max_user_connections-un 5 olmasıdır. Həqiqətən də tərifdən göründüyü kimi 1 user yalnız 5 dəfə simultane connect ola bilər.

İndi isə dəyişənlərin qiymətini dəyişək:
max_connections = 3
max_user_connections = 0

indiki halda bizim max_user_connections limitsizdir yani =0-dır.
Onu da qeyd etmək lazımdır ki max_connections=3 olsa da MySQL max_connections+1 qədər qoşulmaya icazə verəcək. Yani teorik olaraq biz yalnız və yalnız 4 dəfə qoşula biləcik baxmayaraq ki max_user_connections limitsizdir 😉
Sınadıq və gördük ki 4-dən çox connection olduqda:

Həqiqətən də 4 connection-umuz var:

Əgər yuxarıda göstərilən 2 ERROR-dan biri ilə qarşılaşsanız error-lardan başa düşəcəksiniz ki problem max_connections-dadır ya max_user_connections-da. Və müvafiq dəyişənlərin qiymətini artıra bilərsiniz.
Bu dəyişənlər GLOBAL-dır və qiymətlərini dəyişmək üçün SUPER privilege lazımdır. bu da yalnız root və yaxud root-a bənzər user-lərdə olur 😉

Təşəkkürlər.

Kateqoriyalar: MySQL, MySQL administration

Installing MySQL 5.6.10 on CentOS 6.3

İnternetdə bu haqda çoxlu resurs var lakin onlardan istifadə etdikdə çoxlu çətinlik çıxdı ki o haqda yazmırlar.
Deməli ilk öncə onu deməliyəm ki müvəqqəti olaraq MariaDB 5.5.29 yazmışdım 3 saatlıq 😉
Onu Silmək üçün ardıcıllıqla:

yum remove MariaDB-client
yum remove MariaDB-server
yum remove MariaDB-devel
yum remove mysql-libs

Təbii ki silməmişdən əvvəl data backup və my.cnf backup almaq lazım idi.
Lakin əgər config fayllara və data directory-yə baxsaq görərik ki,

[root@localhost ~]# cd /etc

Data directory:

[root@localhost ~]# cd /var/lib

Dolayısı ilə əgər bunları silmədən yeni install-a başlasaq conflict verəcək.

[root@localhost ~]# cd /etc
[root@localhost etc]# rm my.cnf
rm: remove regular file `my.cnf'? y
[root@localhost etc]# rm -rf my.cnf.d

[root@localhost ~]# cd /var/lib
[root@localhost lib]# rm -rf mysql

Yalnız indi yeni MySQL-i install etmək olar:

wget http://dev.mysql.com/get/Downloads/MySQL-5.6/MySQL-server-5.6.10-1.el6.x86_64.rpm/from/http://cdn.mysql.com/
wget http://dev.mysql.com/get/Downloads/MySQL-5.6/MySQL-client-5.6.10-1.el6.x86_64.rpm/from/http://cdn.mysql.com/
wget http://dev.mysql.com/get/Downloads/MySQL-5.6/MySQL-devel-5.6.10-1.el6.x86_64.rpm/from/http://cdn.mysql.com/

İnstalling:

[root@localhost ~]# rpm -ivh MySQL-server-5.6.10-1.el6.x86_64.rpm
Preparing...                ########################################### [100%]
   1:MySQL-server           ########################################### [100%]

[root@localhost ~]# rpm -ivh MySQL-client-5.6.10-1.el6.x86_64.rpm
Preparing...                ########################################### [100%]
   1:MySQL-client           ########################################### [100%]

[root@localhost ~]# rpm -ivh MySQL-devel-5.6.10-1.el6.x86_64.rpm
Preparing...                ########################################### [100%]
   1:MySQL-devel            ########################################### [100%]

Daha sonra start edirik…MySQL 5.5-dən fərqli olaraq MySQL 5.6-da /etc/init.d/mysqld start işləmir.
Onun əvəzinə:

[root@localhost ~]# service mysql start
Starting MySQL. SUCCESS!

Daha sonra mysql_secure_installation script-ini işlədirik. Bu production server-lər üçün çox vacib məsələlərdən sayılır.

[root@localhost ~]# /usr/bin/mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQL
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!
.
.
.

Daha sonra belə bir yazı görəcəksiniz:

Enter current password for root (enter for none): 
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

MySQL 5.5-də fresh install-dan sonra root user-in heç bir parolu olmurdur. Və sadəcə enter-i sıxıb keçirdik digər mərhələyə. Lakin MySQL 5.6-da daha bir yenilik ondan ibarətdir ki, fresh install zamanı default root parol da bizə təqdim olunur. Həmin password-u /root/.mysql_secret-də tapa bilərik:
# The random password set for the root user at Wed Feb 20 18:39:52 2013 (local time): lU3gnECq

Və bunu copy edib MySQL-ə connect oluruq :

[root@localhost ~]# mysql -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.6.10

Daha bir yenilik ondan ibarətdir ki, MySQL 5.6.10-a default password ilə yenicə connect olduqdan sonra hər hansı əməliyyata icazə verilmiyəcək:

mysql> select @datadir;
ERROR 1820 (HY000): You must SET PASSWORD before executing this statement

Yalnız default parolu dəyişdikdən sonra nəsə edə bilərik:

mysql> set password for 'root'@'localhost'=password('12345');
Query OK, 0 rows affected (0.00 sec)

MySQL 5.5-dən daha bir fərqliliyi bundan ibarətdir ki daha MySQL 5.6-da anonymous user-lər yoxdur.

mysql> select user from mysql.user;
+------+
| user |
+------+
| root |
| root |
| root |
| root |
+------+
4 rows in set (0.00 sec)

Test etdim data directory, base directory, query cache, slow query log, binary log MySQL 5.5-dəki kimidir:

mysql> select @@datadir;
+-----------------+
| @@datadir       |
+-----------------+
| /var/lib/mysql/ |
+-----------------+
1 row in set (0.00 sec)

mysql> select @@basedir;
+-----------+
| @@basedir |
+-----------+
| /usr      |
+-----------+
1 row in set (0.00 sec)

mysql> select @@log_bin;
+-----------+
| @@log_bin |
+-----------+
|         0 |
+-----------+
1 row in set (0.00 sec)

mysql> select @@query_cache_type;
+--------------------+
| @@query_cache_type |
+--------------------+
| OFF                |
+--------------------+
1 row in set (0.00 sec)

mysql> select @@slow_query_log;
+------------------+
| @@slow_query_log |
+------------------+
|                0 |
+------------------+
1 row in set (0.00 sec)

Lakin daha bir fərqlilik ondan ibarətdir ki, my.cnf faylı artıq /etc-də yox məhz /usr-dədir.

Təşəkkürlər 😉

[Warning] Could not increase number of max_open_files to more than 1024

Fevral 13, 2013 2 şərh

Error log-a baxarkən [Warning] Could not increase number of max_open_files to more than 1024 – ə rast gəldim dəhşətli dərəcədə pis təsir elədi araşdırdım və aşkarladım ki, Linux-da open-files-limit default olaraq 1024-dür və MySQL-dən nə istiyirsən yaz xeyri yoxdur bundan yuxarı qalxmaz.
Qeyd edim ki, my.cnf-də mən dəyişiklik etmişəm:
open-files-limit=65535
Lakin buna baxmayaraq 1024-dən yuxarı həqiqətən də qalxmır.

mysql> select @@global.open_files_limit;
+---------------------------+
| @@global.open_files_limit |
+---------------------------+
|                      1024 |
+---------------------------+
1 row in set (0.00 sec)

Çarəsi:

[root@localhost ~]# vi /etc/security/limits.conf

Və aşağıdakıları yazıb save edirik:

mysql soft nofile 65535
mysql hard nofile 65535

Və yoxlayırıq:

[sh@localhost ~]$ su - mysql
Password: 
-bash-4.1$ ulimit -Hn
65535
-bash-4.1$ ulimit -Sn
65535

Daha sonra mysql-ə start veririk və yoxlayırıq:

mysql> select @@global.open_files_limit;
+---------------------------+
| @@global.open_files_limit |
+---------------------------+
|                     65535 |
+---------------------------+
1 row in set (0.00 sec)

Vəssalam 😉 Təşəkkürlər 😉

MySQL database normalization

Database design-da advance mövzulardan biri də normalization və denormalization-dur.
Bu 2 teknik bir-birinə ziddir və hər birinin öz tərəfdarları var. Məsələn MySQL Users Group Azerbaijan-da olan bir fikir mübadiləsində
Wordpress-sin database arxitekturu haqqında danışıldı. Və gəlinən nəticəyə əsasən WordPress redundant data-larla dolu olan denormalize cədvəllərdən istifadə edir. Onlar çox böyük ehtimal ki bunu öz sistemlərinə uyğun hesab ediblər və ona uyğun öz spesifik optimization-larını aparıblar. Facebook məsələn normalize cədvəllərdən istifadə edir Facebook Database Schema
Bunu deməkdə məqsədim o idi ki, mütləq şəkildə normalization aparmaq deyə bir şey yoxdur. Özümüzə necə lazımdırsa elə də etməliyik.Hansı design bizə daha uyğundur ya yox onu artıq test etmək lazımdır.

İnternetdə bir sıra qaynaqlar var normalization-la bağlı mən terminlərə və.s girişmirəm. Bu yazının məqsədi sadə yolla bir cədvəli necə normalize etmək olar o haqdadır.
Nümunə cədvəlimiz belədir:

Puppy_number — id.
Puppy_name — ad.
Kennel_Code — yerləşdirildiyi yetişdirmə yurdu id-si.
Kennel_Name — yerləşdirildiyi yetişdirmə yurdu adı.
Kennel_location — yerləşdirildiyi yetişdirmə yurdu adresi.
Trick_ID — bacardığı tryuklar(Azərbaycanca bilmirəm nə deyim buna).
Trick_Name — tryuk adı.
Trick_Where_Learned — harda öyrənib.
Skill_Level — bacarıq dərəcəsi.

Normalization-nun 3 mərhələli şəkildə etmək məsləhət görülsə də mən şəxsən tapa bilmirəm ki konrket nə vaxt bilim ki 1NF(1 normal form) bitdi və yaxud 2NF hələ tam yerinə yetirilməyib və.s 😉

Mənim ümumi oxuduqlarıma əsasən normalization sadəcə 1 cədvəli ona dəxlisi olmayan məlumatlardan azad etməkdir vəssəlam 😉 Yəni cədvəli single-theme etmək…Yalnız bir-birilə sıx əlaqəli olan məlumatları orda saxlamaq

Əyani olaraq diqqət edək bizim cədvəl 4 ayrı hissələrdən ibarət görünür:

1.
Puppy_number
Puppy_name

2.
Kennel_Code
Kennel_Name
Kennel_location

3.
Trick_ID
Trick_Name

4.
Trick_Where_Learned
Skill_Level

Sübut: həqiqətən də puppy-nin yetişdirmə yurduna= kennel-ə, trick növlərinin də harda öyrənilməsinə dəxlisi yoxdur.

Denormalize cədvəlimiz:

create table puppies_trick(
p_id int not null, 
p_name varchar(25) not null,
k_code int not null,
k_name varchar(25) not null,
t_id int not null,
t_name varchar(25) not null,
t_where_learned varchar(25) not null,
skill_level int not null,
primary key(p_id,k_code,t_id)       
);

Və içindəki məlumat:

insert into puppies_trick() values(1,'Tibetian Mastiff',1,'Tibet Mastiff Success',1,'Catching Wolf','Tibet Mastiff Success',9);

Normalize edilmiş cədvəlimiz 4 hissəyə bölünüb:

create table puppies(
p_id int not null auto_increment,
p_name varchar(25) not null,
k_code int not null,
primary key(p_id),
index(k_code),
foreign key (k_code) references kennels(k_code) ON DELETE cascade ON UPDATE cascade
);


create table kennels(
k_code int not null auto_increment,
k_name varchar(25) not null,
k_location varchar(25) not null,
primary key(k_code),
index(k_location),
index(k_name)
);

create table tricks(
t_id int not null auto_increment,
t_name varchar(25) not null,
primary key(t_id,t_name)
);


create table puppy_tricks(
p_id int not null,
t_id int not null,
k_name varchar(25) not null,
skill_level int not null,
primary key(p_id),
index(t_id),
foreign key(p_id) references puppies(p_id) ON DELETE cascade ON UPDATE cascade,
foreign key(t_id) references tricks(t_id) ON DELETE cascade ON UPDATE cascade,
foreign key(k_name) references kennels(k_name) ON DELETE cascade ON UPDATE cascade
);

Və bu cədvəllərdə yerləşən məlumatlar:

insert into puppies() values(1,'Tibetian Mastiff',1);
insert into kennels() values(1,'Tibet Mastiff Success','Tibet');
insert into tricks() values(1,'Catching Wolf');
insert into puppy_tricks() values(1i,1,'Tibet Mastiff Success',9);

Məntiqlə belə düşünmək olar ki, əgər 1 ümumi və ona bərabər 4 cədvəl varsa select verdikdə eyni məlumatları almalıyıq. Bəli elədir:

-- Denormalize cədvəldən:
mysql> select p_name,k_name,t_name,skill_level from puppies_trick;
+------------------+-----------------------+---------------+-------------+
| p_name           | k_name                | t_name        | skill_level |
+------------------+-----------------------+---------------+-------------+
| Tibetian Mastiff | Tibet Mastiff Success | Catching Wolf |           9 |
+------------------+-----------------------+---------------+-------------+
1 row in set (0.00 sec)

-- Normalize cədvəllərdən:

mysql> select puppies.p_name,puppy_tricks.k_name,tricks.t_name,puppy_tricks.skill_level from puppy_tricks,tricks,puppies where puppy_tricks.t_id=tricks.t_id and puppy_tricks.p_id=puppies.p_id;
+------------------+-----------------------+---------------+-------------+
| p_name           | k_name                | t_name        | skill_level |
+------------------+-----------------------+---------------+-------------+
| Tibetian Mastiff | Tibet Mastiff Success | Catching Wolf |           9 |
+------------------+-----------------------+---------------+-------------+
1 row in set (0.00 sec)

Təbii ki bu bir elmi məqalə deyil və mən yazı üçün bir şeylər uyğunlaşdırıb yazdım. Sözsüz ki hansı cədvəlin performance cəhətdən özünü daha gözəl göstərəcəyini yalnız heavy load-da anlamaq olar.

Normalization haqqında ətraflı oxumaq üçün:
Overview of Normalization

Steps in Normalization

Təşəkürlər 😉

lower_case_table_names system variable

Database və table adları-nın case sensitive olub-olmaması vacib məsələrdən biridir. Yəni məntiqlə City ilə city arasında heç bir fərq olmamalıdır.
Lakin Unix\Linux-da bu case sesnsitivity mövcuddur. Yəni əgər create table və yaxud create database zamanı biz city əvəzinə City yazsaq bu elə bu cür də saxlanılacaq. Lakin Windows və Mac OS X-da bu belə deyil.
Hər halda bizə daha uyğun olar ki bütün sistemlərdə lower_case istifadə olunsun. Bunu əldə edə bilməyimiz üçün
lower_case_table_names system dəyişənindən istifadə etməliyik. Bu dəyişən 3 qiymət alır.

From Documentation:
0—Table and database names are stored on disk using the lettercase specified in the CREATE TABLE or CREATE DATABASE statement. Name comparisons are case sensitive. You should not set this variable to 0 if you are running MySQL on a system that has case-insensitive file names (such as Windows or Mac OS X). If you force this variable to 0 with –lower-case-table-names=0 on a case-insensitive file system and access MyISAM tablenames using different lettercases, index corruption may result.

1—Table names are stored in lowercase on disk and name comparisons are not case sensitive. MySQL converts all table names to lowercase on storage and lookup. This behavior also applies to database names and table aliases.

2—Table and database names are stored on disk using the lettercase specified in the CREATE TABLE or CREATE DATABASE statement, but MySQL converts them to lowercase on lookup. Name comparisons are not case sensitive. This works only on file systems that are not case sensitive! InnoDB table names are stored in lowercase, as for lower_case_table_names=1.

Default olaraq UNİX\Linux-da bu dəyişənin qiyməti 0-dır.

mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        0 |
+--------------------------+
1 row in set (0.00 sec)

Windows-da default 1 və Mac OS X-da isə 2-dir.

Bütün sistemlər üçün 1 qiymətinin qoyulması məsləhət görülür
Mən də elə etdim amma maraqlı hadisələr baş verdi necə deyərlər sürpriz 😉
Əvvəlcədən world database-imdə 3 cədvəlim var idi hamısı da case sensitive:

mysql> show tables;
+-----------------+
| Tables_in_world |
+-----------------+
| City            |
| Country         |
| CountryLanguage |
+-----------------+
3 rows in set (0.00 sec)

lower_case_table_names=1 etdim:

mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        1 |
+--------------------------+
1 row in set (0.00 sec)

Və daha sonra əlimdə olan bu 3 cədvəldən birini drop etmək istədim:

mysql> drop table city;
ERROR 1051 (42S02): Unknown table 'city'

mysql> drop table City;
ERROR 1051 (42S02): Unknown table 'city'

Həm kiçik hərflə, həm də böyük hərflə yazmağıma baxmayaraq belə bir cədvəlin olmadığını iddia edir 😉
Halbuki show tables hələ də 3 cədvəlin mövcudluğundan xəbər verir:

mysql> show tables;
+-----------------+
| Tables_in_world |
+-----------------+
| City            |
| Country         |
| CountryLanguage |
+-----------------+
3 rows in set (0.00 sec)

Daha sonra isə world database-ni drop etmək istədim:

mysql> drop database world;
ERROR 1010 (HY000): Error dropping database (can't rmdir './world', errno: 39

errno 39:

[root@localhost ~]# perror 39
OS error code  39:  Directory not empty

Əslində bunun heç dəxlisi də olmamalıdır söhbətə 1ci dəfə deyil ki database drop edirik…
Düşündüm və lower_case_table_names-i yenidən =0 etdim.

mysql> drop database world;
Query OK, 3 rows affected (0.11 sec)

Və yalnız bundan sonra drop getdi. Bunun səbəbi nədir bilmirəm lakin təhlükəli bir şey olduğu açıq-aşkar görünür.
Düşünürəm ki MySQL-i fresh install etdikdən dərhal sonra lower_case_table_names-i dəyişmək daha doğru olacaq. İçində məlumatlar ola-ola bu dəyişənə toxunmaq məsləhət deyil.

Təşəkkürlər 😉