rss ログイン
JJ1RLWのXOOPS Cube Siteにようこそ

メインメニュー

ログイン


ユーザー名:


パスワード:





パスワード紛失  |新規登録

オンライン状況

2 人のユーザが現在オンラインです。 (2 人のユーザが xpress ブログ を参照しています。)

登録ユーザ: 0
ゲスト: 2

もっと...

アーカイブ

カテゴリー

アクセスカウンタ

今日 : 5959
昨日 : 116116116
総計 : 230848230848230848230848230848230848

カレンダー

2017年11月
« 9月    
 1234
567891011
12131415161718
19202122232425
2627282930  

xpress ブログ » » DATABASE

  カテゴリー ‘DATABASE’ のアーカイブ
WordPress for XOOPS

MySQLからSQL Serverへのデータ移行

XOOPS2.6.0をSQL Serverで稼働させる為に、MySQLからSQL Serverへのデータ移行を行いました。
この時、SQL Server Management Studio (SSMS)を使ってデータ移行を行おうとしましたが、データインポートの途中でエラーとなり、上手く行きませんでした。

MySQLのテーブルは認識出来ている画面
MySQLのテーブルは認識出来ている画面

途中のエラー画面
途中のエラー画面

そこで、SSMSのリンクサーバを設定してテーブルのデータを表示して見ると問題無く表示されます。

リンクサーバへの問い合わせ画面
リンクサーバへの問い合わせ画面

仕方なく、MySQLのテーブルとデータをSQL文形式でエクスポートし、このSQL文をテキストエディタを使って、以下の様に編集してSQL Serverへ流し込みました。

MySQLよりエクスポートしたSQL文
CREATE TABLE IF NOT EXISTS x174_avatars_avatar (
avatar_id int(10) unsigned NOT NULL AUTO_INCREMENT,
avatar_file varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ”,
avatar_name varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ”,
avatar_mimetype varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ”,
avatar_created int(11) NOT NULL DEFAULT ‘0’,
avatar_display tinyint(1) NOT NULL DEFAULT ‘0’,
avatar_weight smallint(5) unsigned NOT NULL DEFAULT ‘0’,
avatar_type char(1) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ”,
PRIMARY KEY (avatar_id),
KEY avatar_type (avatar_type,avatar_display)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

SQL Serverへ流し込むSQL文
CREATE TABLE “x174_avatars_avatar” (
“avatar_id” INT NOT NULL IDENTITY(1,1),
“avatar_file” varchar(30) NOT NULL DEFAULT ”,
“avatar_name” varchar(100) NOT NULL DEFAULT ”,
“avatar_mimetype” varchar(30) NOT NULL DEFAULT ”,
“avatar_created” INT NOT NULL DEFAULT ‘0’,
“avatar_display” TINYINT NOT NULL DEFAULT ‘0’,
“avatar_weight” SMALLINT NOT NULL DEFAULT ‘0’,
“avatar_type” char(1) NOT NULL DEFAULT ”,
PRIMARY KEY (“avatar_id”)
);
CREATE INDEX “avatar_type” ON “x174_avatars_avatar”(“avatar_type”,”avatar_display”);

ポイントは、AUTO_INCREMENTをIDENTITY(1,1)に、PRIMARY KEY以外のKEYをCREATE INDEXに置き換える、少々面倒でしたが色々と勉強になりました。

参考サイト
SQL ServerからMySQLのデータベースにアクセスしてみる。
SQL ServerからMySQLへリンクサーバを設定する

publisherのメンテナンス用SQL文を作って見た

XOOPS 2.6.0(本家版)のテストで、xpressのデータをpublisherに流し込むのに、Excelを利用した手作業が発生すので何とかならないかと思い、publisherのメンテナンス用SQL文を作って見ました。

publisherのitems、categoriesと2つの作業用テーブルの合計4つを用意して、XOOPSのコメントテーブルとxpressの各テーブルから抽出、集計してpublisher_items、publisher_categoriesのテーブルを完成させることをSQL文だけ行える様にしました。

それでも、MySQLからSQL Serverへのデータの流し込みには、テキストエディタでの置き換え処理が必要ですが、大幅な時間短縮となります。

MySQL(InnoDB)、utf8mb4環境で、indexの文字数制限

XOOPS 2.6.0をテストしていて、「Index column size too large. The maximum column size is 767 bytes.」とMySQLに叱られるので、MySQL 5.6.xだったので、取り敢えずindexにする文字数を191文字に指定して切り抜けました。
問題は、インデックスに指定したカラムの文字数が191文字を超えた場合、インデックスだけからはデータを特定出来ません。

どうも、MySQL 5.7.9以降なら、デフォルト設定でOK。
MySQL 5.6だとmy.ini(my.cnf)で、
innodb_large_prefix = ON
innodb_file_per_table
innodb_file_format = Barracuda
として、テーブル作成時にROW_FORMAT=DYNAMICを指定する。

参考サイト
MySQL(InnoDB) で charset を utf8mb4 にする注意点の現在
MySQL(InnoDB) で “Index column size too large. The maximum column size is 767 bytes.” いわれるときの対策

MySQL5.6と5.7の設定値

MySQL5.7を使っていて、5.6に較べてディスクアクセスに異常に時間が掛かる現象が見られ、MySQLでメインで使うバージョンを5.6系に変更していました。

そこで、MySQL5.6と5.7の設定値を比較した記事等を参考にシステム変数の一覧表示を行うSHOW VARIABLESの結果を比較して、MySQL5.6では、sync_binlogが0になっているが、5.7では、1になっている。
まさに、ログのディスクへの書き込み確認をその都度行っている様なので、MySQL5.6と同じ設定にして見ると、さほど気にならない程度になりました。

MySQLでメインで使うバージョンを5.7系に変更しました。

今回比較したのはMySQL5.6.37と5.7.19ですが、MySQL8.0.2でもsync_binlogが1になっていました。
※2017-08-20 一部加筆修正

Zen-Cart 1.5.6-alphaをテスト

Zen-Cart 1.5.6-alphaが公開されていたので、テストして見ました。
この版は、Zen-Cartの最新版1.5.5eの後継版だと思います。
以前から1.6.0もテストしていたのですが、まさか1.5.6が出てくるとは思いませんでした。

参考サイト
GitHub zencart/zencart

MySQL 8.0.2 dmrを試して

インストーラ版MySQL 8.0.2 dmrを試して見たが、アップグレード時にMySQL 8.0.1 dmrと同じで、サービスを起動できない。

ZIP版MySQL 8.0.2 dmrも試して見たら、サービスが正常に起動します。
どうも、Dataディレクトリの初期化から行うと問題ない様ですので、当然アップグレードは×です。

試しに、インストーラ版MySQL 8.0.2 dmrの新規インストールの前に、MySQL 8.0.0 dmrをアンインストールする時にDataディレクトリを削除してから新規インストールすると、サービスは正常に起動します。

環境は、Windows Server 2008R2

SQL Server 2017 on Ubuntu 16.04

SQL Server 2017 Community Technology Preview 2.0 をHyper-V上のUbuntu 16.04にインストールして見ました。

最初メモリ割当が512MBしか無かったので、「ERROR: This machine must have at least 3.25 gigabytes of memory to install Microsoft(R) SQL Server(R).」とのエラーとなり、メモリ割当を3328MBにして再インストール、問題無く稼働している様です。

SQL Server 2008のManagement StudioとHeidiSQLから接続して、システムテーブル類を確認して見ました。

ubuntu 16.04にSQL Serverをインストールした時の画面
ubuntu 16.04にSQL Serverをインストールした時の画面

参考サイト
SQL Server 2017 Community Technology Preview 2.0 now available
Install SQL Server on Ubuntu

データベース移行ツール

データベース移行ツールを使って見ました。

XOOPS 2.6.0をSQL Serverで動かすにあたり、XOOPS用のDBのインストールで不完全な部分が発生したため、MySQL用のSQLファイルをSQL Server用のSQLファイルに変換してくれる、Linux用の「SQL::Translator」と言うツールをHyper-V上のUbuntuで使いました。

不完全な部分は、AUTO INCREMENT、PRIMARY KEY以外のINDEXが設定されないなどですが、「SQL::Translator」を使うと、対応したSQL文に変換してくれました。
生成されたSQL文は完全では無いけど、手作業を軽減してくれます。

ほかにも俗に言う「SQLの方言」を見つけ出して、XOOPSのPHPで書かれたSQL文の中で、MySQL固有の部分をSQL Server用に書き換える作業は手作業になります。

以前に、PostgreSQLのデータをMySQL Workbenchのマイグレーション(Migration)機能で、MySQLにコピーした事があります。

まあ、有償のツールを使えば、こんなことしなくても良いと思いますし、SQL標準で書かれていれば、何の問題にもならないのですがね。

参考サイト
SQL::Translator
ベンダー毎の SQL の相互変換を SQL::Translator で

MySQL Workbench
MySQL Workbench(日本語)
Download MySQL Workbench

SSMA
SQL Server White Papers: Guides to Migration from MySQL, Oracle, Sybase, or Microsoft Access to Microsoft SQL Server 2005
Microsoft SQL Server Migration Assistant v7.3 for Access 2/17/2017
Microsoft SQL Server Migration Assistant 7.3 for MySQL 2/17/2017

Ubuntu 14.04 & 16.04のMariaDB Galera Clusterが起動できない

最近気付いたのですが、Ubuntu 14.04から16.04にアップグレードした環境で、MariaDB 10.1.x Galera Clusterが起動出来ない。
/etc/mysql/my.cnf(設定ファイル)を見直しても起動出来ません。
以前は、問題無く起動できていたのに、なぜ。?

そこで、MariaDB 10.1.x Galera Clusterを一旦削除し、再インストールしようとすると、スクリプトエラーでインストールも出来ません。
これは、インストーラーの動作に問題がありそうです。
そこで、Ubuntu 14.04 & 16.04でMariaDB Galera Clusterを構築すると、MariaDB Galera Clusterは問題無く起動出来ます。

Ubuntu 14.04と16.04のMariaDB Galera Clusterの構築を比較して見ると。

Ubuntu 14.04の場合

Ubuntu 16.04の場合

ubuntuのバージョンによる違いはあるが、新規インストールでは問題無い。

何気なく、syslogを眺めていると、

[日本語訳]

エラーで起動できない時は、
/var/lib/mysql/grastate.datのsafe_to_bootstrap: 1のクラスタを探して、最初に起動するクラスタとする。
または、safe_to_bootstrap: 1に変更してから起動する。
safe_to_bootstrap: 1とは、最後まで稼働していたクラスタにフラグが立っている。

たまたま、今まで気付かなかっただけの様です。

MySQL8.0.1のサービスが起動できない

MySQL 8.0.0から8.0.1にバージョンアップしたら、MySQL8.0.1のサービスが起動できない。

試しに、MySQL8.0.1を新規インストールして見たが、やはりMySQL8.0.1のサービスが起動できません。

インストールの過程を見ていると、システムDBのmysqlは作成されるが、information_schema、performance_schema、sysが作成されません。

そこで、mysql-8.0.1-dmr-winx64.zipを使って見ると、システムDBのmysql、information_schema、performance_schema、sysのすべてが問題無く作成されます。

mysql-installer-community-8.0.1.0-dmr.msiのインストーラーを使っているので設定は自動で、プログラムかインストーラーの不備だと思います。

取り敢えず、MySQL 8.0.0に戻して様子を見ます。


 

Powered by XOOPS Cube 2.2 © 2001-2016 XOOPS Cube Project Distributed by XOOPS Cube 2.2 Distribution Team.