この連載では、
オープンソースカンファレンス（OSC）東京での「多様性時代のDB選択」の開催中止
今回の
［MySQL］2020年2月の主な出来事
2020年2月の製品リリースはありませんでした。1月の原稿締め切り後、
MySQL InnoDB ReplicaSetの登場
マイナーバージョンアップでもどんどん新機能を追加してくるMySQL 8.
InnoDB ReplicaSetは、
下記はMySQL Shellからレプリケーション環境を構築した例です。事前にMySQLサーバー
$ mysqlsh
# 3つのインスタンス作成 出力略
MySQL JS > dba.deploySandboxInstance(3310)
MySQL JS > dba.deploySandboxInstance(3320)
MySQL JS > dba.deploySandboxInstance(3330)
# マスターになる端末に接続
MySQL JS > \c root@localhost:3310
# レプリカセットの作成
MySQL localhost:3310 ssl JS > dba.createReplicaSet("repl1")
A new replicaset with instance '127.0.0.1:3310' will be created.
* Checking MySQL instance at 127.0.0.1:3310
This instance reports its own address as 127.0.0.1:3310
127.0.0.1:3310: Instance configuration is suitable.
* Updating metadata...
ReplicaSet object successfully created for 127.0.0.1:3310.
Use rs.addInstance() to add more asynchronously replicated instances to this replicaset and rs.status() to check its status.
<ReplicaSet:repl1>
# レプリカセットへスレーブとなるノードの追加
MySQL localhost:3310 ssl JS > dba.getReplicaSet().addInstance("root@localhost:3320")
You are connected to a member of replicaset 'repl1'.
Adding instance to the replicaset...
* Performing validation checks
This instance reports its own address as 127.0.0.1:3320
127.0.0.1:3320: Instance configuration is suitable.
* Checking async replication topology...
* Checking transaction state of the instance...
〈略〉
Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone): C
* Updating topology
Waiting for clone process of the new member to complete. Press ^C to abort the operation.
* Waiting for clone to finish...
NOTE: 127.0.0.1:3320 is being cloned from 127.0.0.1:3310
** Stage DROP DATA: Completed
** Clone Transfer
FILE COPY #################################################### 100% Compl
PAGE COPY #################################################### 100% Compl
REDO COPY ################################################## 100% In Progress
NOTE: 127.0.0.1:3320 is shutting down...
* Waiting for server restart... ready
* 127.0.0.1:3320 has restarted, waiting for clone to finish...
** Stage RESTART: Completed
* Clone process has finished: 61.11 MB transferred in about 1 second (~inf TB/s)
** Configuring 127.0.0.1:3320 to replicate from 127.0.0.1:3310
** Waiting for new instance to synchronize with PRIMARY...
The instance '127.0.0.1:3320' was added to the replicaset and is replicating from 127.0.0.1:3310.
MySQL localhost:3310 ssl JS > dba.getReplicaSet().addInstance("root@localhost:3320")
〈略〉
途中で追加するノードへのデータのコピーをクローンプラグインを利用するか、
MySQL localhost:3310 ssl JS > dba.getReplicaSet().status()
You are connected to a member of replicaset 'repl1'.
{
"replicaSet": {
"name": "repl1",
"primary": "127.0.0.1:3310",
"status": "AVAILABLE",
"statusText": "All instances available.",
"topology": {
"127.0.0.1:3310": {
"address": "127.0.0.1:3310",
"instanceRole": "PRIMARY",
"mode": "R/W",
"status": "ONLINE"
},
"127.0.0.1:3320": {
"address": "127.0.0.1:3320",
"instanceRole": "SECONDARY",
"mode": "R/O",
"replication": {
"applierStatus": "APPLIED_ALL",
"applierThreadState": "Slave has read all relay log; waiting for more updates",
"receiverStatus": "ON",
"receiverThreadState": "Waiting for master to send event",
"replicationLag": null
},
"status": "ONLINE"
},
"127.0.0.1:3330": {
〈略〉
}
}
レプリケーションの遅延はこの出力のreplicationLagで確認できるほか、
登場から20年近く経つ定番機能のレプリケーションにも構築運用の新しい仕組みが加わり進化を続けています。ぜひお試しください。
［PostgreSQL］2020年2月の主な出来事
2月は中止になるセミナーやイベントが多くあった中で、
PostgreSQLエンタープライズ・コンソーシアム／活用事例セミナー
みんな大好き！
このセミナーの発表資料は、
- 事例1：PLMパッケージのPostgreSQL対応
- PLM
（product lifecycle management） は、 製品のライフサイクルを管理するために製品情報を包括的に管理して企業戦略に活用するための情報システムです。ポイントは、 今回の対象システムが一般的なビジネスアプリケーションと同じ構成になっていることでしょう。つまり、 Web UIから実行されるアプリケーションの下にデータベース層が位置づけられる構成です。この発表ではPLMシステムを、 異種DBMSからPostgreSQLへの移行を計画し実行していった経験談が語られました。アプリケーションへの影響を考慮して極力避けつつ、 PostgreSQL移行を検討する際には、 PLM分野に限らずその他のビジネスビジネスアプリケーションでも参考になる発表です。移行元とPostgreSQLとで非互換な点や対応が必要だった作業について、 具体的な対応例も提示されていますので、 同様の移行案件を担当する際のノウハウになるでしょう。たとえば、 C/ C++言語での埋め込みSQLの移行方法、 非互換なSQLで影響があったもの、 トランザクション途中でのエラー発生の場合の挙動の違いなど、 技術TIPSとしても有益な内容を含んでいます。 - 事例2：PostgreSQL 8.
3からAmazon Aurora PostgreSQLへの移行事例 - IaaS上のDBからマネージドサービスのDBへの移行という、
今風のホットな移行事例です。また同時に、 PostgreSQLのバージョンが8. 3から10. 7に大きく変わることになり、 これによる移行の難しさと、 性能や機能の改善への期待という両面を持っていた点も興味深いところです。さらに、 採用事例がインターネットでの一般消費者向けサービスであり、 使える移行時間が短い点も気になります。これらの課題を解決するための、 移行手段の選択や、 制限時間内に移行を完了させるための検証などについて、 実際の測定値などまで提示して説明されました。 - 事例3：大規模監視でPostgreSQLを利用した場合の運用ノウハウ
- 1000台以上のIT機器を監視するZabbix環境の事例です。Zabbixに限らず、
監視対象が多くなると運用監視環境には高い負荷が掛かります。その様なZabbix環境を支えるデータベースにPostgreSQLを採用し、 ファイルシステムや、 クラスタ構成などで様々な工夫を繰り返してこられた実績が紹介されました。この事例は企業内のプライベートクラウド環境のインフラ運用部隊でのものであり、 データベースの専門家がいるわけではありません。その様な制約の中でも、 増大するデータ量を受け入れ、 厳しい性能要求に応えないといけないという課題は、 多くの現場にも共通する事情ではないでしょうか。また技術ノウハウとして、 Zabbix用のPostgreSQLがデータを置くファイルシステムにZFSを採用した （OSはCentOS） ことが紹介されました。ファイルシステムの管理 （追加など） をしやすくして性能も良いとのことです。 - 事例4：Amazon.
comにおけるPostgreSQLへの移行 - AWS
（Amazon Web Service） ではなくて、 物販サービスAmazon. comを実現するITインフラのデータベースを、 PostgreSQLに切り替えていった事例です。2017年時点でOLTP用として7500のDB、 データ量75PB、 数千種類のアプリケーションがあり、 これらのほとんどをAmazon RDSやAuroraのPostgreSQLに移行していったとのこと。紹介された内容には、 意外なほど具体的な数値や方法論などが含まれています。移行前のDBMSのスペシャリストを再教育する話には日本的な親近感も感じました。それだけ大人数のスペシャリストが携わっているということでしょう。ただ、 いろいろと規模が大きすぎて、 どこを参考にしたらいいのかが悩ましいところです。言い換えれば、 それほど貴重な事例紹介でもあります。なお、 講演時間にまったく収まらないために発表時には割愛されましたが、 「PostgreSQLへ移行する場合の技術的なポイント」 として40ページほどの資料も一緒に公開されています。
PostgreSQL 12.2、11.7、10.12、9.6.17、9.5.21、9.4.26がリリース
2月14日にPostgreSQLのマイナーバージョンアップ12.
なお、
Pgpool-II 4.1.1、4.0.8、3.7.13、3.6.20、3.5.24、pgpoolAdmin 4.1.0がリリース
Pgpool-IIは、
2020年3月以降開催予定のセミナーやイベント、ユーザ会の活動
本稿は2月25日時点の公開情報に基づいて記載をしていますが、
オープンソースカンファレンス 2020浜名湖／名古屋／北海道
| 日程 | 浜名湖 2020年4月11日 名古屋 2020年5月16日 北海道 2020年6月27日 |
|---|---|
| 場所 | 浜名湖 浜松市市民協働センター 2F ギャラリー 名古屋 名古屋市中小企業振興会館 北海道 ACU札幌 |
| 内容 | オープンソースカンファレンスは、 |
| 主催 | オープンソースカンファレンス実行委員会 |