Mysql 5.7 mysqldump bug

Mysql 5.7 ye terfi ettikten sonra backup sistemimde aşırı bir yavaşlık meydana geldi.

Nedenini araştırdığımda şunu buldum :

https://bugs.launchpad.net/percona-server/+bug/1589334

mysqldump komutuna –no-tablespaces parametresini girdiğimizde ise her şey eskisi gibi güzel oldu.

 

konsoldan mysql root sifresini sifirlamak

Özet olarak bu işlem için, konsoldan mysql şifresini sıfırlamamız icap ettiğinde mysqli yetkisiz bir şekilde başlatıp, işlemlerimizi yapıp sonra tekrar başlatarak işlemlerimizi tamamlamış olacağız.

İzlenmesi gereken adımlar :

Mysql’i durdurun.

/etc/init.d/mysqld stop

Şimdi, skip-grant özelliği ile tekrar başlatıyoruz:

mysqld_safe --skip-grant-tables

Şimdi Mysql’e passwordsüz bağlanacağız. (ayrı bir konsolda)

mysql -u root

Aşağıdaki komutları sırası ile verelim ve yeni şifremizi belirleyelim.

mysql> use mysql;
mysql> update user set password=PASSWORD("yeni_sifremiz") where User='root';
mysql> flush privileges;
mysql> quit;

Mysql’i yeniden durduralım

/etc/init.d/mysqld stop

Şimdi de normal bir şekilde başlatalım

/etc/init.d/mysqld start

İşlem tamamdır 🙂

Mac OS X Nginx PHP 5.3 ve percona-server (mysql) kurulumu

Bu yazıda Mac OS X üzerine Nginx ve PHP5.3 (özellikle php5.3, daha yenisi değil) kurmayı anlatmaya çalışacağım.

İnternetteki dökümanlar genelde konu güncel iken yazıldığı için, siz bir yazılım dilinin daha önceki versiyonlarına ait kurulumlar yapmak istediğinizde, varsayılan paket yöneticisi tarafından hep en son sürümü kurulmakta, ve bu da bizim o anki ihtiyaçlarımızı karşılamamaktadır.

Ben de birkaç tane projedeki php 5.3 gereksinimim sebebiyle böyle bir şey yapmak durumunda kaldım. (aslında vagrant daha güzel bir çözüm tabi ki dileyen araştırabilir.)

Öncelikle Mac’inizde homebrew (http://brew.sh/) yüklü değilse, bunu yüklememiz gerekiyor. Bunun için konsolunuzda

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

komutunu çalıştırmanız gerekiyor.

Nginx kurulumu

brew install nginx

Bu kadar basit 🙂
Nginxi başlatmak için

nginx

komutunu yazmanız yeterli. (Evet konsola sadece nginx yazacağız, ubuntu gibi değil) Ancak sudo olarak çalıştırmanız gerekebilir.
Php kurulumu

php yi Nginx ile iletişim kurabilmesi için 2 şekilde kurabiliriz. 1. yöntem cgi ile. 2. yöntem ise, php-fpm ile. php-fpm ile kurmak daha mantıklı, çünkü fcgi process manager ile yönetilmeyen bir cgi kullanımı aynı anda çok fazla processi handle etmenizi yani stress test vb toolları çalıştırdığınız kısımlarda size problem çıkartabilir. Ben de bu ve birkaç sebepten dolayı php-fpm ile kurmayı anlatacağım. Ancak cgi ile kurmak isteyen için de sadece 1 parametre değişiyor 🙂

brew install php53 --with-mysql --with-suhosin --with-intl --with-imap --with-fpm

sondaki —with-fpm kısmı yerine –with-cgi yazarsanız da cgi ile kurmuş olursunuz.

Mac OS X içerisinde PHP, Ruby, Python gibi dillerin CLI (konsol üzerinden çalıştırılabilir) versiyonları ile birlikte geldiği için şu anda halen konsolda php -v yazdığınızda php 5.4.24 veya benzeri başka bir versiyonu görürsünüz. Ancak web arayüzünden (Yani browserdan nginx ile) girdiğinizde ilgili php 5.3 sürümünü çalıştırmış olacağız.

Eğer siz konsoldan da php 5.3 çalıştırmak istiyorsanız,

export PATH=/usr/local/Cellar/php53/5.3.28/bin:$PATH

şeklinde komut çalıştırmanız gerekiyor. (sudo ile çalıştırmanız icap edebilir).
Ancak bu şekilde yaparsanız da bilgisayarınızı yeniden açtığınızda (ya da konsoldaki oturumu kapattığınızda) bu ayar kaybolacaktır. Bunu kaybetmemek için bu komutu /usr/local/Cellar/php53/5.3.28/bin i sudo ile /etc/paths e yazmalısın.

Mac OS X üzerinde php-fpm ubuntudaki gibi /etc/init.d/php-fpm start stop, vb.. şeklinde kullanılamıyor. Bu yüzden kullanımı biraz farklı.
Php-fpm yi hemen başlatmak için

launchctl load ~/Library/LaunchAgents/homebrew.mxcl.php53.plist

Bilgisayarınız her açıldığında otomatik başlasın istiyorsanız da

ln -sfv /usr/local/opt/php53/*.plist ~/Library/LaunchAgents

şeklinde işlem yapmanız gerekiyor.

Şimdi sıra php-fpm.conf dosyasını bulup, buradaki ayarlardaki loglara veya dosyalara izin vermek kısmında.
php-fpm.confu bulup ilgili pid ve log dosyasını ve access log dosyasını yazabilmesi için yetki vb verip o gerekli klasörleri oluşturursan gerisi tamamdır. (Yine ubuntunun aksine, /var/run/php-fpm.pid yerine phpnin kendi klasörüne yapmanız daha mantıklı olacak ben bu şekilde yaptım. Log için de aynı yeri belirttim.)

 

percona-server kurulumu

Nginx kadar basit aslında.

brew install percona-server

Percona server’i hemen başlatmak için

launchctl load ~/Library/LaunchAgents/homebrew.mxcl.percona-server.plist

Bilgisayar her başladığında başlatmak için ise,

ln -sfv /usr/local/opt/percona-server/*.plist ~/Library/LaunchAgents

komutlarını çalıştırmanız gerekiyor.

Bu yazı nginx ayarları, php ayarları ve mysql ayarlarının nasıl yapıldığı ile ilgili olmadığı için o detayları burada paylaşmıyorum. Ancak ihtiyacı olan tabi ki danışabilir.

Umarım yararlı olur.

Sayısal Veri İçeren Karakter Alanlar

Oracle veri tabanında, sayısal veri içermesi beklenen karakter tipinde (CHAR,VARCHAR) alanlar sorun yaşamak için birebirdir. Örneğin müşteri numarası tutulan bir alana, servis ve grafik arayüz seviyesinde yeterli kontroller yapılmazsa müşteri adı, soyadı..vs gibi bilgiler yazılıyor olabilir 🙂 Bu alanda to_number() kullanarak bir sorgu yazdığınızda ve ya tabloyu bu alan üzerinden başka bir tablodaki nümerik bir alana bağlamak istediğinizde ORA-01722 hatası alırsınız.

Alanın yer aldığı tablodaki satırları düzeltmek için hangisinde hata olduğu bulmak da ayrı bir sorundur. Bunun için UPPER () ve LOWER () metotlarını kullanabilirsiniz. UPPER () ve LOWER () metotları numerik değerler için aynı, karakter değerleri için farklı sonucu vereceğinden, hatalı satırlara ulaşabilirsiniz. Diyelim ki tablomuzun adı MUSTERI, alanın adı MUSTERINO olsun:


CREATE TABLE MUSTERI
(
RECORDOID NUMBER(16) NOT NULL,
MUSTERINO VARCHAR(10) NOT NULL,
MUSTERIADI VARCHAR(10) NOT NULL
);

Tabloya bazı kayıtlar atalım:


Insert into MUSTERI
(RECORDOID, MUSTERINO, MUSTERIADI)
Values
(4, '!', 'aslan');
Insert into MUSTERI
(RECORDOID, MUSTERINO, MUSTERIADI)
Values
(3, '-', 'aslan');
Insert into MUSTERI
(RECORDOID, MUSTERINO, MUSTERIADI)
Values
(2, 'bogac', 'aslan');
Insert into MUSTERI
(RECORDOID, MUSTERINO, MUSTERIADI)
Values
(1, '100', 'bogac');
COMMIT;

Tabloyu yarattıktan sonra geçersiz değerler içeren satırları bulalım:


SELECT *
FROM MUSTERI M
WHERE UPPER(M.MUSTERINO) != LOWER(M.MUSTERINO)

Bu çözüm UPPER ve LOWER metotlarında aynı sonucu veren bazı diğer karakterler (“!”,”-” gibi) için yeterli olmayabilir, sadece bu karakterleri içeren satırlar olduğundan şüpheleniyorsanız ek sorgular yazmak gerekebilir. Sorunla Oracle veri tabanında karşılaşmış olsam da, diğer veri tabanı sistemleri için de çözüm olacağını düşünüyorum.

Kolay gelsin 🙂

mysql_real_escape_string DBAL dengi (equivalent)

Benim gibi projenizde bir altyapı değişikliği yapıyorsanız, muhtemelen yeniden ele aldığınız kısımlardan biri de veritabanı bağlantısı ile ilgili kısımlar oluyor. Biz de bu noktada Doctrine DBAL kullanmaya karar verdik. Henüz ORM implemente etmek için yolumuz var. O yüzden sadece DBAL katmanını kullanacağız. Ancak burada mysql_real_escape_string vasıtası ile escape ettiğimiz verileri, artık DBAL tarafına geçerken birsürü yerde replace işlemi yapmak istemiyorsanız birkaç önerim olacak.

mysql_Real_Escape artık projenizde düzgün çalışmayacaktır diye tahmin ediyorum. Çünkü artık classlar üzerinden çalışıyorsunuz, ve buradaki mysql doğru connectionı bulamayabilir. (özellikle master slave ilişkili çift veya daha fazla db mimarisinde)

Tabi ki işin doğrusu statement->prepare metodu üzerinden bindParam veya bindValue ile ilerlemek. Ancak bunları için oldukça uzun bir vakit gerekebilir.

Biz de mysql_real_escape_string’in karşılığı olarak bir metod bulduk. Connection nesnesi üzerinde bulunan quote metodu.

 

$conn->quote(”) dediğimiz metod tam da istediğimiz şekilde çalışıyor. Hatta connection objesindeki ekstra parametreler kısmına ATTR_EMULATE_PREPARES=> true verirseniz, bu metod bildiğiniz mysql_Real_escape işlemini yapıyor. bu parametredeki tek handikap, çoklu querylerin tek seferde çalıştırılamaz hale gelmesi oluyor.

quote’un mysql_Real escape’ten tek farkı başına ve sonuna bir tırnak koyuyor. siz bunları substr ile çıkartırsanız birebir aynı olacaktır.

 

dikkat etmeniz gereken bir şey de şu ki, mysql server’ınızın encoding’i ile (server encodinginizin mysql e bağlanıp show variables like ‘%char%’ seklindeki degisklenlerden gorebilirsiniz) connection (DBAL ayarlarından verilen encoding) aynı olması gerkeiyor ki güvenli bir escape işlemi yapılabilsin.