MariaDB 10.1 から 10.4 にアップグレードする方法

MariaDB 10.1.40 から、MariaDB 10.4.6 にアップグレードした。

ひとつだけつまずいたが、簡単にできた。

 

日本語のutf8bm4の Collation で、MySQL 8.0.1 から使用できるようになったという、

utf8mb4_ja_0900_as_cs

utf8mb4_ja_0900_as_cs_ks

を、MySQL 8 と同等の、MariaDB 10.4 でも使用できるのかと思ってアップグレードしたのだが、結果としては、できなかった。

もうひと工夫必要なのかもしれない。

あとは、処理速度の改善が少しでもあればいいのだが。

 

 

 

環境の変化

CentOS Linux 7.6.1810

kusanagi-8.4.2-2 

nginx-1.17

MariaDB 10.1.40

MariaDB-server-10.1.40-1.el7.centos.x86_64
MariaDB-client-10.1.40-1.el7.centos.x86_64
mariadb-10.1-mroonga-9.03-1.el7.x86_64
MariaDB-common-10.1.38-1.el7.centos.x86_64
MariaDB-shared-10.1.38-1.el7.centos.x86_64
MariaDB-devel-10.1.38-1.el7.centos.x86_64

 

アップグレード後:

yum list installed | grep mariadb
MariaDB-client.x86_64                10.4.6-1.el7.centos            @mariadb
MariaDB-common.x86_64                10.4.6-1.el7.centos            @mariadb
MariaDB-compat.x86_64                10.4.6-1.el7.centos            @mariadb
MariaDB-devel.x86_64                 10.4.6-1.el7.centos            @mariadb
MariaDB-server.x86_64                10.4.6-1.el7.centos            @mariadb
MariaDB-shared.x86_64                10.4.6-1.el7.centos            @mariadb
galera-4.x86_64                      26.4.2-1.rhel7.el7.centos      @mariadb

アップグレードの手順

データーベースを使用するアプリを停止しておく。

 

systemctl stop postfix dovecot nginx

データベースのバックアップ

mkdir /mdbackup
mkdir /mdbackup/my.cnf.d

mysqldump -u root -p --all-databases > /mdbackup/all_db_backup.sql
cp -af /etc/my.cnf /mdbackup/my.cnf
cp -af /etc/my.cnf.d/* /mdbackup/my.cnf.d/

systemctl stop mariadb

MariaDB-server 10.1 だけの削除

MariaDBを普通に削除しようとすると、依存関係で削除しなくていいものまで削除される仕組みになっているのであとあと面倒になる。

それで、 --nodeps -ev を付けて、依存関係無視してアンイストールする。

# MariaDB-server 10.1 のアンイストール
rpm --nodeps -ev MariaDB-server

rpm -qa | grep -i '^mariadb-'

MariaDB 10.4 のリポジトリ設定

MariaDB の10.1ではなく、 10.4 をインストールできるようにする。

cd /etc/yum.repos.d/
cp -af MariaDB.repo MariaDB.repo.10.1
nano MariaDB.repo

# 以下の内容に書き換える。
# MariaDB 10.4 CentOS repository list - created 2019-07-01 01:50 UTC
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.4/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

 

MariaDB 10.4 のインストール

yum -y install MariaDB-devel MariaDB-common MariaDB-client MariaDB-server MariaDB-shared

# 確認する
rpm -qa | grep -i '^mariadb-'

# MariaDBを起動する。
systemctl start mariadb
systemctl enable mariadb

MariaDB 10.4 の設定ファイルを編集

/etc/my.cnf.d/server.cnf.rpmsave

として、元の server.cnf が自動バックアップされているので、それをそのままコピーすると良い。

cp -af server.cnf.rpmsave server.cnf

# 再起動する。
systemctl restart mariadb

エラー発生! 起動しない

ここでこんなエラーが出て、起動しなくなった。

● mariadb.service - MariaDB 10.4.6 database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/mariadb.service.d
           mqmigrated-from-my.cnf-settings.conf
   Active: failed (Result: exit-code) since 月 2019-07-01 11:36:20 +07; 37s ago
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
  Process: 7532 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 8657 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=7)
  Process: 8580 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
  Process: 8577 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
 Main PID: 8657 (code=exited, status=7)
   Status: "MariaDB server is down"

 7月 01 11:36:17 my.server systemd[1]: Stopped MariaDB 10.4.6 database server.
 7月 01 11:36:17 my.server systemd[1]: Starting MariaDB 10.4.6 database server...
 7月 01 11:36:18 my.server mysqld[8657]: 2019-07-01 11:36:18 0 [Note] /usr/sbin/mysqld (mysqld 10.4.6-MariaDB) starting as process 8657 ...
 7月 01 11:36:20 my.server systemd[1]: mariadb.service: main process exited, code=exited, status=7/NOTRUNNING
 7月 01 11:36:20 my.server systemd[1]: Failed to start MariaDB 10.4.6 database server.
 7月 01 11:36:20 my.server systemd[1]: Unit mariadb.service entered failed state.
 7月 01 11:36:20 my.server systemd[1]: mariadb.service failed.

 

原因は、server.cnf  内の、

innodb_use_sys_malloc = 1

の設定項目が廃止無効になっていたから。

これをコメントアウト、削除すればよい。

他にも時代遅れになった設定項目があるかもしれない。

# server.cnf の内容
[server] character_set_server = utf8mb4 max_connections = 900 thread_cache_size = 300 table_cache = 256 max_allowed_packet = 16M query_cache_size = 128M tmp_table_size = 32M max_heap_table_size = 32M thread_stack = 512K key_buffer_size = 32M sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 1M join_buffer_size = 1M myisam_sort_buffer_size = 1M bulk_insert_buffer_size = 1M innodb_buffer_pool_size = 384M innodb_log_file_size = 32M #innodb_use_sys_malloc = 1 innodb_thread_concurrency = 8 log-error = /var/log/mysql/mysqld.log log-warnings = 1 # this is only for the mysqld standalone daemon [mysqld]

 

起動する。

systemctl start mariadb

アップグレード後のデータベースの整合性をチェックする。

 mysql_upgrade -u root -p

停止していたアプリ、サービスを起動する。

systemctl start postfix dovecot nginx

# 又はサーバーの再起動
reboot

 

ダウンタイムは2時間だった。

 

/etc/my.cnf.d/server.cnf の設定を見直して、以下のようにした。

[server]
character_set_server = utf8mb4
max_connections = 30
thread_cache_size = 30
table_cache = 64
max_allowed_packet = 16M
query_cache_size = 512M
tmp_table_size = 32M
max_heap_table_size = 32M
thread_stack = 512K

key_buffer_size = 32M
sort_buffer_size = 4M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
join_buffer_size = 1M

myisam_sort_buffer_size = 1M
bulk_insert_buffer_size = 1M

innodb_buffer_pool_size = 1000M
innodb_log_file_size = 32M
#innodb_use_sys_malloc = 1
innodb_thread_concurrency = 8

log-error = /var/log/mysql/mysqld.log
log-warnings = 1

# this is only for the mysqld standalone daemon
[mysqld]

[galera]
[embedded]
[mariadb]
[mariadb-10.4]

未使用のテーブルを削除するには Plugins Garbage Collector

この際、削除したプラグインやテーマが作成したデーターベースのテーブルで、未使用のテーブルを削除したい。

「Plugins Garbage Collector」が便利。

 

 

  • またまたこのサイトのSSL証明書が期限切れになった。 Kusanagi の自動更新ができていない。 それで手動であれこれしてみても、こんなエラーが出る。# kusanagi update cert Challenge failed for domain makotoiwasaki.com Challenge failed for domain www.makotoiwasaki.com Attempting to renew cert (makotoiwasaki.com) from /etc/letsencrypt/renewal/makotoiwasaki.com.conf produced an unexpected error: Some challenges hav...
  • Google の Indexing API を使うと、新しい投稿記事を瞬時にGoogleの検索エンジンに登録できる。 WordPress のプラグインとしてインデックスAPIが利用できる。使い方は英語だが、この通り: ⏱️ Get Google To Index Your Website Instantly Using the Indexing API ⚡Take a look at how you can use Google's new indexing API & to get your website's pages and content crawled instantly instead of waiting for Google to...
  • Yoast SEO を停止して、Rank Math SEO プラグインを使ってみたらGoogle の検索結果に表示される記事抜粋スニペットの文字数が短過ぎに見えてびっくりした。#1 Yoast Alternative You Deserve - Rank Math SEO vs. Yoast SEORank Math SEO plugin for WordPress is hands down the best Yoast alternative WordPress plugin. And the best thing is, Rank Math is completely FREE!Rank Math
  • WP_CRON を停止して、Linux の crontab に移行する設定をこれまでに何度も試みたがうまくいかなかった。 毎日バックアップされるはずの、UpdraftPlus プラグインのクロンが動いていない。やっと成功した設定方法を記録しておく。wp-config.php に次の行を追加する。define('DISABLE_WP_CRON', true);/var/spool/cron  に、  httpd という名前のファイルを作成し、次の1行を追加する。 所有者を httpd.www など、httpd nginx サーバーの稼働ユーザー名と同じにする。nginx.conf に書いてある。root@s4:/v...
  • Kusanagi WordPress プラットフォームでは Fcache とBcache がある。 Fcache とはNginx ヱブサーバーのキャッシュ機能であり、Kusanagi の独自機能ではない。Nginx のアクセスログを眺めていると、  BYPASS MISS EXPIRED のみで、HITが殆どない。 トップ頁、アーカイブリストの頁ではHIT、 個別投稿頁では、BYPASS MISS EXPIRED ばかりでHITがない。Kusanagi fcache on とすると、fcache は有効になったかのように思えるが、本当にキャッシュが効いているのかどうかはログで確認しないとわからない。まず、Wordpressの編集画面にログインし...
  • 目次1 HTTPD アクセスログの日本語化2 Logwatch も日本語化 HTTPD アクセスログの日本語化 Nginx,  Apache ヱブサーバーのアクセスログを見ると、日本語URLはエンコードされていて読めない。 そこで、デコードして表示させる。 ログのファイル名が ssl_access.log だとすると、tail -f ssl_access.log| perl -ne 'use URI::Escape; print uri_unescape($_);' tail -f access.log | php -R 'echo urldecode($argn)."\n";'で、日本語URlが読める状態で出力される。 Apa...
  • ヱブサイトの再構築中には、スタイルシート、style.css を頻繁に調整更新する。 CSSを追加、編集する度に再読み込みを繰り返して、変更の反映を確認していた。 これで編集者は反映を確認できるのだが、一般閲覧者はわざわざ再読み込みしたり、キャッシュを削除したりするはずはないので、変更が反映されていない崩れたデザインを見ているかもしれない。わざわざリロードしたりキャッシュを削除したりしなくても変更が確実に反映されるような設定方法を発見した。wp_enqueue_scripts で CSS、JS の読み込みを管理している場合には、次のようにfunctions.php に記述する。// 子テーマのstyle.cssを最後に読み込む add_acti...
  • 2679年8月25日

    頁カウンターの比較 WordPress

    WordPressで使える頁カウンターをいくつか同時に使ってカウントの仕方の違いを比べてみた。WP-PostViews    長期常用中 Post Views Counter  新規インストール Google Analytics Post Pageviews Pjaxblog の付属カウンター機能WP-PostViews は他のカウンターよりもカウントが多くなりがちなことに気づいた。一度のアクセスなのに2回カウントされることもあるようだ。ロボットクローラー Bots のリスト数も不十分に少ないような気がする。それで数が多くなりやすいのではないか。 それで Post Views Counter に乗り換えることにした。Post Views Cou...

WordPress カテゴリ人気記事 Views most

WordPress カテゴリ人気記事 月間

タグ関連記事

閲覧履歴

    //cookieが無い場合の処理