Menu

mysql

WordPress и MySQL 8

, , , 0

Wordpress и MySQL 8Здравейте,

Фен съм на новите технологии и много обичам ъпдейтите ;))

Поради тази причина от днес root.bg вече работи на MySQL 8!

В този пост ще споделя особенностите при пускането на версия 8 и какво е нужно да проработи нашия wordpress – особенно ако базата му е голяма, стара и с различни типове charset и collation-и. Да подчертая че мигрирах от MariaDB 10.2 и за целта си вдигнах нов MySQL сървър – не съм правил mysql_upgrade, а dump и restore на базата!

Повече подробности за новостите в MySQL 8 може да се намерят в официалния им сайт.

Това което е важно за wordpress специално е именно това :

  • Character set support.  The default character set has changed from latin1 to utf8mb4. The utf8mb4 character set has several new collations, including utf8mb4_ja_0900_as_cs, the first Japanese language-specific collation available for Unicode in MySQL. For more information, see Section 10.10.1, “Unicode Character Sets”.

Или именно проблемът с който се сблъсках след като налях базата на root.bg на новия mysql сървър.  Ето така изглеждаха всичките публикации написани на кирилица :

 

Причината за това е именно енкодинга в MySQL.

Този проблем може да се реши по два начина – чрез настройка в самия сървър или в конфигурационния файл на нашия wordpress.

Ето и двата начина:

В MySQL:

character-set-server=latin1

За да направим проверка в mysql конзолата пишем :

SHOW VARIABLES LIKE 'character\_set\_%';

и трябва да видим следния резултат :

+--------------------------+---------+
| Variable_name | Value |
+--------------------------+---------+
| character_set_client | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8mb4 |
| character_set_server | latin1 |
| character_set_system | utf8 |
+--------------------------+---------+
7 rows in set (0.00 sec)

В wordpress:

В конфигурационният файл на wordpress – wp-config.php добавяме следния ред :

define('DB_CHARSET', 'latin1');

И така вече имаме работещ wordpress на MySQL 8!

ПС
root.bg живее върху :
ubuntu 18.04.1
nginx 1.14.0
php 7.2.11
mysql 8.0.13
memcached 1.5.6

Това е!

MySQL delayed replication

, , , 0

Привет,

Днес ще споделя как лесно се слага MySQL delayed replication (закъсняла репликация).

Идеята е проста – имаме слейв сървър който е винаги изостанал от мастъра си. Това се прави с цел, той да седи като онлайн бекъп, и ако без да искаме изтрием нещо от главния сървър като таблица или база (или пък някой кадърен девелопър е truncate-нал таблица но вместо на дев го е направил на лайв – случвало ми се е!! 🙂 ), да можем бързо да вземем информацията от този изостанал слейв.

Да подчерая, че тази функция я има във версия на MySQL 5.6 и нагоре.

Ето и как се прави това :

Още..

MyISAM repair all tables in all databases

, , 0

MyISAM repair all tables in all databasesЗдравейте,

Както вече обещах в предния си пост, чапочвам отново да пиша по-активно в блога!

Днес ще споделя за проблем с хостинг сървър на който има около 500 акаунта и на много от тях MyISAM таблиците в MySQL им бяха счупени.
По принцип най-добрия вариянт за справене с този проблем е чрез командата myisamchk :

 

myisamchk -r *.MYI

Така се оправят таблиците на една база, но днес ми се наложи да правя това на 500 акаунта.

За целта използвах find като преди това свалих MySQL сървъра:

find ./ -name "*.MYI" -exec myisamchk -r {} \;

Стартирах MySQL процеса след успешната поправка и всичко си тръгна нормално!

Това е!

MySQL split dump to table

, , 0

Здравейте,

В продължение на поста MySQL split dump to different databases

от миналата година, днес ще споделя как бързо и лесно можем да извадим определена таблица от dump-a на MySQL базата ни. Разбира се ако базата ние малка можем да отворим този dump и да си копираме съдържанието на таблицата в текстов редактор, но когато базата ни е 100гб това няма да е възможно.

 

Тук идва на помощ sed и решението е :

sed -n -e '/CREATE TABLE.*`fc_company`/,/CREATE TABLE/p' 201709140001-db-CRM.sql > fc_company.sql

Тук нещата изглеждат напълно ясни, но да обесня :

  1. fc_company е таблицата която искаме да извадим
  2. 201709140001-db-CRM.sql е името на dump-а ни
  3. fc_company.sql е името на новият dump съдържащ само таблицата ни

Хубаво е да се прегледа след това самия fc_company.sql файл, тъй като sed понякога хваща и началото на други таблици и ги дропи 🙂 Такъв пример е ако имаме таблица fc_compay_new примерно.

Това е!

MariaDB Galera Cluster Split Brain

, , , , 0

Здравейте,

Днес ми се случи отпадане на един MySQL сървър, и в резултат на това се получи така наречения MariaDB Galera Cluster Split Brain.

MariaDB Galera Cluster Split Brain

Тъй като използвам 2 нода, което не е препоръчително за Galera Cluster, сутринта работещия нод връщаше следната грешка:

WSREP has not yet prepared node for application use

След като оправих проблемния нод (достатъчен беше един рестарт), реших да се справя и с този Split Brain.

Идеята като цяло беше, да добавя трети нод в клъстера, или да включа арбитър.

Първоначалната ситуация изглеждаше така :

mysql> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 2 |
+--------------------+-------+
1 row in set (0.01 sec)

За да увелича размера на клъстера до 3, инсталирах и конфигурирах galera arbitrator на трета машина с минимални ресурси.

apt-get install galera-arbitrator-3

Тъй като клъстера ми използва SSL сертификати, се наложи да ги копирам и на тази машина, за да мога да стартирам garbd демона.

Конфигурационният му файл (/etc/default/garb) изглежда така :

# Copyright (C) 2012 Codership Oy
# This config file is to be sourced by garb service script.

# A comma-separated list of node addresses (address[:port]) in the cluster
GALERA_NODES="192.168.168.1:4567 192.168.168.16:4567"

# Galera cluster name, should be the same as on the rest of the nodes.
GALERA_GROUP="cbz_cluster"

# Optional Galera internal options string (e.g. SSL settings)
# see http://galeracluster.com/documentation-webpages/galeraparameters.html
GALERA_OPTIONS="socket.ssl_key=/etc/mysql/ssl/server-key.pem;socket.ssl_cert=/etc/mysql/ssl/server-cert.pem;socket.ssl_ca=/etc/mysql/ssl/ca-cert.pem;socket.ssl_cipher=AES128-SHA"

# Log file for garbd. Optional, by default logs to syslog
# LOG_FILE="/var/log/garbd.log"

Последна стъпка – стартиране на процеса :

web-root:~# /etc/init.d/garb restart . ok [ ok ] Starting /usr/bin/garbd: :.

И wsrep_cluster_size вече беше 3.

mysql> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+
1 row in set (0.00 sec)

Така при отпадане на един от нодовете, другия ще продължи да работи нормално.

Това е!

Load More