1965 件中 461 - 470 件を表示
« 前の 10 件 | 次の 10 件 »
Displaying posts with tag: MySQL (reset)
個性的なcsvからデータを取り出した話

コンピュータシステム周辺に関わっているとCSVファイルとのお付き合いは避けて通れないものと言えるでしょう。みなさんはどんなCSVとお付き合いしたことがありますか。
 セパレータが明確でない(というか明確なのだけど例外例外の積み重ねが意外とややこしい)のがcsvとのお付き合いで気を使うところですよね。

[さらに読む]
Geospatial Hackers Program に参加して優秀な成績を収めた話

 少し前の話になるのですが、Geospatial Hackers Program (GHP)というイベントに参加して来ました。実は、ハッカソンなるものに参加するのは初めてのことで、勝手も分からずに緊張していたのですが、素敵な仲間たちと出会い、心地よく参加させていただくことができました。

Geospatial Hackers Program とは

 公式サイトによると「多方面で注目を集める高需要スキル 「G空間技術」 をイチから学び、エンジニアの方ももそうでない方も、地域課題の解決や新規ビジネス創出に活かせる力を手にいれる2日間の集中プログラムです。 …

[さらに読む]
MySQL 8.0のデュアルパスワードを使った記念メモ

TL;DR

  • デュアルパスワードの情報は mysql.user.User_attributes カラムにJSONで入ってくるのでその辺で確認できる
    • SHOW CREATE USER には入ってこないのでここで確認するしかない?
  • SELECTステートメントでデュアルパスワード持ってるアカウントだけを引っ張るなら mysql.user.user_attributesadditional_password って要素を持ってるかどうかで判定ができる
mysql80 7> SELECT user, host FROM mysql.user WHERE user_attributes->>'$.additional_password' IS NOT NULL;
+----------+------+
| user | host |
+----------+------+
| yoku0825 | % |
+----------+------+
1 row in set (0.00 sec)

[さらに読む]
MySQLのゾンビプロセスの話

エビデンス的なものを貼り付けてもイマイチ伝わらないので、文字通り雑記レベルで。

複数セッション用意してタイミングに依存した実験の結果を伝える時、難しいよね、ってことで、ダラっとした解説になってしまいます。



MySQLのサーバーに重いクエリを投げつけたりしたとき、
クライアント自身を強制終了(mysqlクライアントを「kill -9」とか)すると、サーバー側では処理が続きます。

「SHOW FULL PROCESSLIST」を見るとわかります。

再接続してクエリを投げると、別セッションなのでSHOW FULL …

[さらに読む]
MySQL&Dockers ...簡単なセットアップ

MySQL&Dockers ...は新しい概念ではなく、人々はしばらくの間Dockersに移行しています。 開発のためにこれに移行しようとしている人にとっては、いくつかのハードルがあります。

MySQLはローカルで正常に動作しますが、MySQLの異なるバージョン間でコードをテストする場合は、いくつかのバージョンを簡単に入手できると便利です。

長年の選択肢の1つは、もちろんGiuseppe Maxiaによるhttps://mysqlsandbox.net/です。 これは、複数のインスタンスを起動し、レプリケーションなどをテストできる非常に有効なソリューションです。

[さらに読む]
わざと件数をズラしたグループレプリケーションで、「遅延中」の動きを観察する

日々の覚書: シングルプライマリーモードだろうとInnoDB Cluster内のデータをズラす方法 の続き。 件数をズラした上で OPTIMIZE TABLE をかけるといくらでもセカンダリーが遅延した状況が作り出せる、というとことまでは良いとして。 node3のグループレプリケーションを一旦止める。

### node3
mysql> STOP GROUP_REPLICATION;
Query OK, 0 rows affected (4.49 sec)

またnode1から OPTIMIZE TABLE を5発くらい叩き込んでついでに更新SQLを入れておく。

### node1
mysql> OPTIMIZE TABLE sbtest.sbtest1; -- これを5回くらい

mysql> INSERT INTO d1.t1 VALUES (4, 'four');
Query OK, 1 row affected (0.01 sec)

mysql> SELECT * FROM d1.t1; …
[さらに読む]
シングルプライマリーモードだろうとInnoDB Cluster内のデータをズラす方法

TL;DR

  • 単にプライマリーノードで SET sql_log_bin = 0 で効くんだからびっくりだ

動作確認用にd1.t1テーブルを作って2行くらい入れておく。

### node1
mysql> CREATE DATABASE d1;
Query OK, 1 row affected (0.01 sec)

mysql> CREATE TABLE d1.t1 (num SERIAL, val VARCHAR(32));
Query OK, 0 rows affected (0.02 sec)

mysql> INSERT INTO d1.t1 VALUES (1, 'one');
Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO d1.t1 VALUES (2, 'two');
Query OK, 1 row affected (0.00 sec)

プライマリーノードで sysbench を使って100万行くらいのテーブルを作る。

### node1
$ sysbench --mysql-user=root oltp_common --table_size=1000000 prepare
sysbench 1.0.17 (using system LuaJIT 2.0.4)

Creating table 'sbtest1'...
Inserting 1000000 …
[さらに読む]
グループレプリケーションの group_replication_applier と group_replication_recovery のリレーログ

TL;DR

  • グループレプリケーションは(形式上かも知れないけど) group_replication_applier というレプリケーションチャンネルと group_replication_recovery というレプリケーションチャンネルを持っている
  • グループレプリケーションの通信が問題なく行われている間は GCS(Group Communication System) から group_replication_applier のリレーログに書き込まれて group_repliation_applierのSQLスレッドが処理
    • この時、プライマリーノードはGCSから応答が返ってきた後にバイナリログに書く
  • グループレプリケーションが途切れてGCSから直接受け取っていない間に発生した書き込みはバイナリログを経由して group_replication_recovery チャンネルを通じて受け取る
[さらに読む]
グループレプリケーションのメンバーとInnoDB Clusterのメタデータと cluster.rescan()

TL;DR

  • グループレプリケーション(mysqldそのもの)が認識してるノードの情報は performance_schema.replication_group_members
  • InnoDB Clusterの中でMySQL ShellとMySQL Routerが使うノードの情報は mysql_innodb_cluster_metadata.instances
  • 整合性が取れなったら cluster.rescan でグループレプリケーション側の情報を正としてInnoDB Clusterのメタデータを修正できる

以下、 performance_schema.replication_group_members をメンバー、 mysql_innodb_cluster_metadata.instances をメタデータと略するます。 メンバーにいるけどメタデータにいないパターン 再現方法

  • 手で(=MySQL Shellを使わずに)グループレプリケーションのノードを追加したり、 …
[さらに読む]
シングルプライマリーとDDLとDMLと

TL;DR

  • シングルプライマリー構成のInnoDB Clusterにおいて
    • プライマリーノードで ALTER TABLE 中の後続のDDL, DMLはプライマリーノードでブロックされない限りは ALTER TABLE を追い越してコミットすることができる
      • コミットされた後続のDDL, DMLはセカンダリーのリレーログに渡ってリプレイされるので(セカンダリーでの実行にかかる時間程度で)データが同期される
    • セカンダリーノードで ALTER TABLE をリプレイ中にプライマリーで実行されたDDL, DMLはその対象に関わらず 「セカンダリーでリプレイ中の ALTER TABLE を追い越せない」
      • よって、セカンダリーノード側で最初に受け取った …
[さらに読む]
1965 件中 461 - 470 件を表示
« 前の 10 件 | 次の 10 件 »