Menu

mysql

Липса на постове в блога

, , 1

Привет,

Не съм писал отдавна – сигурно си личи. Всичко е заради липсата ми на време – много бачкам 😀

От толкова работа даже не съм видял че имам проблем с блога – постовете в блога липсваха. Причината е спирането на сървъра където е блога онзи ден (Енерго про имаха проблем и нямаше няколко часа ток в сървърното ми). Поради тази причина ми се е бъгнала таблицата с постовете и изписваше : wp_posts is marked as crashed and last (automatic?) repair failed

Реших проблема си като спрях mariadb сървъра и поправих myisam таблиците чрез :
myisamchk -r *.MYI
в директорията на базата на блога. След това пуснах mariadb сървъра и всичко си беше ок.

Тук има хубава и лоша страна ; хубавата е че базата на блога е останала от едно време с таблици на MyISAM , а лошата е точно това , че използвам MyISAM вместо InnoDB 🙁 Може би някой ден ще си конвертирам таблиците и ще си реша проблеми завинаги, но това за в момента не ми е приоритет.

SASL LOGIN authentication failed: authentication failure

, , , , 0

SASL LOGIN authentication failed: authentication failureПривет,

Днес ще пиша за един проблем с който се занимавах по-рано сутринта, и който оправих с доста дебъгване.

Наложи се да местя един мейл сървър от стар физически debian 6 на нов виртуален ubuntu 12.04. Тестовете които проведох, показаха че всичко си му работи. След като го пуснах в действие обаче, видях че през мейл клиенти от рода на outlook и thunderbird изпращането на писма не работеше. През webmail всичко си беше 6.

В лога на postfix-а ми вадеше следното : SASL LOGIN authentication failed: authentication failure

като това по никакъв начин не ми помогна да разбера къде е проблема.

След като тествах какви ли не вариянти със saslauthd-а , накрая оправих проблема, който се оказа супер тъп и елементарен…

След като добавих в /etc/pam.d/smtp debug накрая на 2та реда:

auth required pam_mysql.so user=ispconfig passwd=mysqlpass host=127.0.0.1 db=dbispconfig table=mail_user usercolumn=login passwdcolumn=password crypt=1 debug
account sufficient pam_mysql.so user=ispconfig passwd=mysqlpass host=127.0.0.1 db=dbispconfig table=mail_user usercolumn=login passwdcolumn=password crypt=1 debug

и рестартирах postfix-a , видях следното:

Oct 25 14:15:31 bigmac saslauthd[11054]: PAM unable to dlopen(pam_mysql.so): /lib/security/pam_mysql.so: cannot open shared object file: No such file or directory

Мда… адски тъпо, липсваше ми пакета libpam-mysql =) и след като го инсталирах всичко си тръгна без проблеми..

Общо взето това е, отивам да пия винце, че баба зима дойде! Наздраве!

MySQL innodb crash

, , , , , 0

MySQL innodb crashПривет,

В допълнение на поста ми от 12.12.2013 за MySQL innodb crash-a, искам да споделя че, този проблем отново ми се случи на същия Ubuntu сървър. Оказа се че innodb е много фин сторидж енджин на MySQL-а и явно е много податлив на crash. Пример : счупи се единия хард диск и се наложи да преместя тази виртуалка на друг дял, и след като го сторих, MySQL-а не искаше да тръгва вече.

Проблемът:

Грешката отново беше следната:

Още..

WordPress w3tc_cdn_queue problem

, , , , 0

Wordpress w3tc_cdn_queue problemДобар ден,

Днес ще пиша за един проблем който мъчи блога ми от доста време. Става дума за страниците в блога където има много снимки – когато се отворят за първи път (преди varnish-a да е направил кеширан вариянт на страница) се отваря за около 2 минути!! Това е просто меко казано нелепо и трябваше да го оправя!

Днес открих че проблема е от една заявка която прави w3-total-cache плугина когато се използва CDN. Ако спазваме внимателно указанията за инсталация на този плугин трябва да напишем следната заявка:

DROP TABLE IF EXISTS `wp2_w3tc_cdn_queue`; 
CREATE TABLE IF NOT EXISTS `wp2_w3tc_cdn_queue` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `local_path` varchar(500) NOT NULL DEFAULT '', `remote_path` varchar(500) NOT NULL DEFAULT '', `command` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '1 - Upload, 2 - Delete, 3 - Purge', `last_error` varchar(150) NOT NULL DEFAULT '', `date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', PRIMARY KEY (`id`), KEY `date` (`date`) ) ;

Ами хубаво ама не правете това! Днес открих че MySQL-a ми товареше на 160% CPU като отворя сайта на Ани и след като отворих mysql.log видях следното:

2057 Query SELECT remote_path FROM wp2_w3tc_cdn_queue WHERE remote_path = 'wp-includes/js/jquery/jquery.js'
2057 Query SELECT remote_path FROM wp2_w3tc_cdn_queue WHERE remote_path = 'wp-includes/js/jquery/jquery-migrate.min.js'
2057 Query SELECT remote_path FROM wp2_w3tc_cdn_queue WHERE remote_path = 'wp-includes/wlwmanifest.xml'
2057 Query SELECT remote_path FROM wp2_w3tc_cdn_queue WHERE remote_path = 'wp-includes/js/comment-reply.min.js'
2057 Query SELECT remote_path FROM wp2_w3tc_cdn_queue WHERE remote_path = 'wp-content/themes/postline/js/audio-player.js'

И ето защо страниците със снимките се отварят така мега бавно! Дропнах таблицата и си реших проблема завинаги!

MariaDB [jbblog]> DROP TABLE IF EXISTS `wp2_w3tc_cdn_queue`; Query OK, 0 rows affected (0.04 sec)

Синхронизиране на два ISPConfig сървъра чрез lsyncd

, , , , 0

Идеята е следната:

Имам 2 сървъра на които върви ISPConfig и искам единия да е огледален на другия. За целта ISPConfig ми позволява да включа като опция единия да е “mirror” на другия, но това не ми помага като цяло.

За целта направих следната комбинация:

1. Направих MySQL master-master репликация  за да мога да имам базите от единия на другия през цялото време.

2. Инсталирах lsyncd – супер лек демон който ми синхронизира /var/www и /var/vmail от главния на втория сървър.

За целта използвах и следния конфиг за lsyncd:

 

settings {
logfile = "/var/log/lsyncd/lsyncd.log",
statusFile = "/var/log/lsyncd/lsyncd-status.log",
statusInterval = 20
}
sync {
default.rsync,
source="/var/www/",
target="192.168.1.2:/var/www/",

rsync = {
compress = true,
acls = true,
verbose = true,
owner = true,
group = true,
perms = true,
rsh = "/usr/bin/ssh -p 22 -o StrictHostKeyChecking=no"
}
}

sync {
default.rsync,
source="/var/vmail/",
target="192.168.1.2:/var/vmail/",

rsync = {
compress = true,
acls = true,
verbose = true,
owner = true,
group = true,
perms = true,
rsh = "/usr/bin/ssh -p 22 -o StrictHostKeyChecking=no"
}
}

Като предварително бях направил SSH ключове към 192.168.1.2.
Идеята на lsyncd като цяло е копирането само на нови фаилове от мастър-а към слейва, като прави постоянни проверки за обновления през няколко секунди, и като открие такива фаилове ги прехвърля чрез rsync.

Така реално имам огледално копие на главния ISPConfig сървър + базите му и датата. Нещото което трябва ръчно да се прехвърля обаче са nginx/apache конфигурационните фаилове + php*-тата.
Надявам се пичовете от ISPConfig да измислят нещо автоматизирано за тази цел, но до тогава ще използвам тази схема 🙂

Това е..

Load More