Apache Ошибка 500 после обновления PHP

При обновлении PHP до версии 5.4 вы можете столкнуться с ошибкой 500, из-за использования устаревших функций, например — session_register.
Она используется, в Tiger CMS.

Для поиска и замены всех строк вызывающих данную функцию можно использовать следующую команду:

find . -type f -exec sed -i 's/session_register/\/\/session_register/g' {} \;

Шаги для выяснения причин ошибки 500 в веб-сервере Apache:

1. Проверьте лог-файл error.log
/var/log/apache2/error.log

2. Включите показ ошибок PHP в etc/php.ini (/etc/php5/apache2/php.ini)

error_reporting(E_ALL);

3. Создайте файл info.php для получения информации о PHP и его модулях:

<?php phpinfo; ?>

Если тестовый файл работает, далее нужно смотреть конкретную страницу выдающую ошибку.

Удачи!

Как улучшить производительность MySQL сервера

Ниже приведены минимально необходимые параметры конфигурации MySQL сервера, улучшающие его производительность:

1. innodb_buffer_pool_size — Количество памяти выделяемое серверу для таблиц InnoDB
Оптимально ~80% RAM памяти, если сервер используется только для MySQL. Пример для сервера с 32Гб ОЗУ

innodb_buffer_pool_size=24G

2. innodb_flush_log_at_trx_commit = 2 — Запись логов происходит раз в секунду, вместо каждого коммита. Улучшает производительность при медленной дисковой подсистемы.

innodb_flush_log_at_trx_commit = 2

3. innodb_log_file_size — Увеличение лога уменьшает нагрузку на диск, улучшая I/O.

innodb_log_file_size = 512M

Изменение параметра вступает в силу только после рестарта MySQL. Старые лог файлы /var/lib/mysql/ib_logfile* необходимо удалить/переместить, так как они будут созданы заново.

4. innodb_log_buffer_size — позволяет производить более крупные операции, без записи лога на диск, увеличивая производительность дисковой подсистемы. По умолчанию = 1MB.

innodb_log_buffer_size = 8M

5. innodb_file_per_table — Не влияющий на производительность, однако очень полезный параметр, который трудно будет поменять после записи даннных.

В пежиме file-per-table каждая новая таблица будет иметь отдельный файл данных, что позволяет освобождать место на диске при удалении данных в таблице, а также имеет другие преимущества.

Итог:

innodb_buffer_pool_size=24G
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 512M
innodb_log_buffer_size = 8M
innodb_file_per_table

Настройка репликации базы MySQL

Репликация позволяет синхронизировать все изменения базы данных на первичном сервера со вторичным.

  • Первичный сервер
  • Редактируем файл /etc/my.cnf

    server-id=1
    log_bin=/var/log/mysql/mysql-bin.log
    

    В файл log_bin будут записываться изменения базы.
    Параметром binlog_do_db=database возможно контролировать названия баз, для которых изменения будут записываться в файл, однако делать это не рекоммендуется (смотри ссылку)

    Сохраняем изменения и перезагружаем сервер MySQL:

    service mysql restart

    Теперь нужно определить пользователя, который будет выкачивать данные об изменениях.
    Для этого заходим в консоль MySQL:

    mysql -u root -p

    И выполняем команду

    GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'pass';
    FLUSH PRIVILEGES;

    Отлично! Теперь осталось только сделать дамп базы и перенести на другой сервер.
    Предварительно блокируем запись в базу.
    В консоли MySQL:

    FLUSH TABLES READ LOCK;

    Далее нам нужно узнать позицию, с которой начнется репликация.

    SHOW MASTER STATUS;

    Запоминаем значение поля Position.

    Теперь можно делать дамп.
    Для этого нужно открыть новое окно, иначе, если произвести какое-либо действие,
    база разблокируется автоматически. В новом окне выполняем команду:

    mysqldump -u root -p -f db1 > db1.sql

    где db1 — название базы, которую надо перенести

    Разблокируем базу:
    В консоли MySQL:

    UNLOCK TABLES;

    Готово. Теперь пришло время для второго сервера, на который надо реплицировать данные.

  • Вторичный сервер
  • На втором сервере создаем базу, аналогичную первому серверу — db1.
    Для этого в консоли MySQL:

    CREATE DATABASE db1;

    Теперь нужно залить в нее дамп с первого сервера
    (Вы ведь уже перенесли файл db1.sql на этот сервер?)

    mysql -u root -p -f db1 < db1.sql

    Готово! Теперь у нас есть копия базы на втором сервере.

    Редактируем конфиг MySQL /etc/my.cnf и выполняем аналогичные первому серверу действия:

    server-id=2
    relay-log=/var/log/mysql/mysql-relay-bin.log
    log_bin=/var/log/mysql/mysql-bin.log
    

    Теперь сервер нужно перезагрузить:

    service mysql restart

    Сервер сконфигурирован и готов к репликации!

    Остался один шаг, а именно указание основного сервера.
    Для этого нам надо зайти в консоль MySQL и выполнить команду:

    CHANGE MASTER TO
    MASTER_HOST='IP-адрес основного сервера',
    MASTER_USER='slave_user',
    MASTER_PASSWORD='pass',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=XXX;

    Вспоминаем поле Position из «SHOW MASTER STATUS» и вписываем его на место XXX.
    И запускаем репликацию:

    START SLAVE;

    Смотрим состояние:

    SHOW SLAVE STATUS\G

    Slave_IO_State: Waiting for master to send event

    Чтобы остановить репликацию

    STOP SLAVE

    Готово. Теперь данные будут дублироваться между серверами!

    PS: Не забываем, что для передачи используется TCP порт 3306, поэтому не забывайте про фаерволы.

    Zabbix не работает icmpping cnt=0 rcv=0

    После установки zabbix-proxy на CentOS 6, все icmpping / icmppingsec элементы возвращали нулевые зеачения.

    После включения DEBUG режма, лог Zabbix показал следующее:

    
    

    31790:20140611:073610.004 In process_ping() hosts_count:1
    31790:20140611:073610.004 /tmp/zabbix_proxy_31790.pinger
    31790:20140611:073610.004 10.20.2.20
    31790:20140611:073610.004 /usr/sbin/fping -C5 -p200 -b1024 -t1000 2>&1 Проблема оказалась в SELinux, однако audit.log не показывал никаких блокирующих записей пока не была запущена следующая комманда:

    yum install -y policycoreutils-python
    /usr/sbin/semodule -DB
    
    Опция -D отключает dontaudit; -B пересоздает правила.
    type=SYSCALL msg=audit(1402473587.551:550371): arch=c000003e syscall=5 success=no exit=-13 a0=0 a1=7fff2c862c70 a2=7fff2c862c70 a3=238 items=0 ppid=16064 pid=16065 auid=0 uid=500 gid=500 euid=500 suid=0 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=87526 comm="fping" exe="/usr/sbin/fping" subj=unconfined_u:system_r:ping_t:s0 key=(null)
    type=AVC msg=audit(1402473588.556:550372): avc:  denied  { getattr } for  pid=16067 comm="fping" path="/tmp/zabbix_proxy_31776.pinger" dev=dm-0 ino=784936 scontext=unconfined_u:system_r:ping_t:s0 tcontext=unconfined_u:object_r:initrc_tmp_t:s0 tclass=file
    
    Для добавление правила SELinux для zabbix-а выполните следующие комманды:
    grep fping /var/log/audit/audit.log | audit2allow -M zabbix_fping
    semodule -i zabbix_fping.pp
    
    После этого проверка хостов с помощью элементов icmpping / icmppingsec должна выполнятся успешно, что подтверждается логом:
    29940:20140611:071726.366 In process_ping() hosts_count:1
     29940:20140611:071726.366 /tmp/zabbix_proxy_29940.pinger
     29940:20140611:071726.366     10.20.2.20
     29940:20140611:071726.366 /usr/sbin/fping -C5 -p200 -b24 -t900 2>&1 
    

    Компиляция PHP для интерфейса Zabbix 2.2

    Для компиляции PHP для интерфейся Zabbix 2.2+ необходимо использовать следующие параметры:

    ./configure --enable-mbstring --enable-sockets --with-mysql --with-mysqli --with-ldap --enable-fpm --enable-bcmath  --with-gettext --with-xmlrpc --with-openssl --with-mcrypt --with-gd --with-zlib --with-freetype-dir=/usr/include/freetype2 --with-jpeg-dir=/usr/lib 
    

    Минимальные параметры в файле php.ini :

     memory_limit = 128M
     post_max_size = 16M
     upload_max_filesize = 2M
     max_execution_time = 300
     max_input_time = 300
     session.auto_start = 0