巨大なサイズのテーブルに対するALTER TABLE実行時間の概算方法English
技術めも » mysql
v0.5.2からv0.6.1までの主な変更は以下のとおりです。 テーブル・シーケンスの右クリックに「Edit」追加（ダブルクリック以外でも開けるように） DDLインポート修正（DOCコメントの不具合、カラムオプションに生成列とチェック制約を登録できるように） 起動時に最新バージョンのチェックを行う（古いバージョンの場合最新バージョンのリンクが表示されます） HTMLにおいて、ダイアログの外側をクリックしたときに、ダイアログを閉じる処理を追加 やりたいことはたくさんあるのですが、なかなか実装が難しいので、 とりあえず未来のTODOを記録しておきます。 VIEWの対応 TRIGGERの対応 FUNCTIONの対応 PROCEDUREの対応 まとめて行う処理諸々（テーブルやパーティションに対してのグループの一括付与・除去とか、テーブルからカラムをまとめて付与・除去とか） カラムを選択可能にしたい
クラッシュセーフなスレーブ - interdb’s blog
MySQLでslaveをクラッシュセーフ*1にするには、 MySQL 5.6以上 relay_log_recovery=ON relay_log_info_repository=TABLE というセッティングが必要。詳細は"こちら"、翻訳版は"こちら"。 ざっくり言えば、リレーログのreplayと同じトランザクションで、InnoDBテーブルにリレーログの情報を書き込みcommitするので、大丈夫だよというお話。 MariaDBがこの機能に追従しないので、どうしたんだろうと思っていたら、MariaDBはGTIDのreplay状態などをgtid_slave_posというInnoDBテーブルに書き込むという技術的選択をしていた。もちろん、書き込むタイミングはreplayとおなじトランザクション。 よって、MariaDB10.0以降は、GTIDを設定すればslaveがクラッシュセーフになる。Mar
MySQL入門 レプリケーション編 - Qiita
#経緯 とある勉強会の内容の復習＆整理 #タイトル インストール・アーキテクチャ基礎編 レプリケーション編 ←今回はこちら バックアップ編 チューニング基礎編 #レプリケーション編 アジェンダ レプリケーションとは レプリケーションの仕組み レプリケーションの種類 レプリケーションの設定方法 バイナリログの管理方法 その他の考慮事項 参考情報 #1. レプリケーションとは ##1.1. 基礎知識 データの複製（レプリカ）を別のサーバにモテる機能 MySQLの標準機能で、多数のWebサイト等で利用されている － シンプルな設定で利用可能 － マスター → スレーブ構成 ##1.2. マスタースレーブ構成 サーバはマスター、スレーブまたは両方になれる マスターサーバ － データを変更 － 変更内容をスレーブに転送 － マスターは複数のスレーブを持てる スレーブサーバ － マスターでの変更内容を
Maxscaleで設定ファイル編集後reloadを行う | 俺的備忘録 〜なんかいろいろ〜
systemctlでMaxscaleを使っていると、どうもreloadが利用出来ない状態になっている事に気づく。 こうなると、設定ファイルを編集した後、またいちいちrestartしないといけないのかなぁ…と思っていたのだが、どうやらreloadは出来るようだ。 Maxscaleには管理コマンドであるmaxadminというコマンドがあるのだが、これでreloadが行えるのだ。 以下、reloadコマンド。 maxadmin -p mariadb reload config ただし、サーバの追加・削除に使うにはちょっと怖い挙動をしている。 サーバを追加したり削除すると、どうも上手く動いているように見えないのだ。 以下、その挙動。 サーバ追加時 [root@BS-PUB-GFRONT-01 ~]# maxadmin -p mariadb list servers Servers. -------
Maxscaleで「Too many open files. Failed to accept new client connection.」エラーが出た際の対応 | 俺的備忘録 〜なんかいろいろ〜
Blog 201604 Maxscaleで「Too many open files. Failed to accept new client connection.」エラーが出た際の対応 会社のシステム(Maxscale経由でDBに接続)で負荷テストをしていたところ、不可解な接続エラーが発生していた。どうも新しいセッションが作成出来ないとの事なのだが、後ろのMariaDB側のMax Connection値は余裕がある。で、いろいろと調べていたところ、Maxscaleのエラーログに以下のようなエラーが出ていた。 2016-04-26 16:53:56 Error 24, Too many open files. Failed to accept new client connection. Oh...(´・ω・`) どうやら、ファイルディスクリプタが上限を超えてしまったらしい。デフォルトの値
MaxscaleのLimitations and Knownを読んでみた | 俺的備忘録 〜なんかいろいろ〜
仕事でMaxscaleを利用しているのだが、Limitation and Knownを読んでなかったので読むことにした。 そんなに文章量も無いので、以下重要そうなトコだけ抜粋して記述していく。 MySQL Serverのハンドシェイクに圧縮は含まれない Compression is not included in MySQL server handshake Galera Cluster Monitorではデフォルトのマスターは「wsrep_local_index」が最も低いノードが対象となる The default master selection is based only on MIN(wsrep_local_index). This can be influenced with the server priority mechanic described in the Galera
Maxscaleの設定ファイルに記述するパスワードを暗号化する | 俺的備忘録 〜なんかいろいろ〜
Maxscaleでは、設定ファイルにモニタリング・接続するGalera ClusterのID/PWを記述する必要があるのだけど、そのままの生パスワードだと、やはりセキュリティ的によろしくない。 というわけで、MaxscaleにはそのパスワードをHash化して記述することができるようになっている。 まず、以下のコマンドで鍵ファイルを設置する「/usr/local/maxscale」ディレクトリを作成し、maxscale用の鍵ファイル「.secrets」を生成する。 mkdir -p /usr/local/maxscale maxkeys /usr/local/maxscale/ あとは、以下のコマンドでハッシュ化したパスワードを取得、それをmaxscaleの設定ファイルでパスワードとして記述すれば良い。 maxpasswd 鍵ファイルのあるディレクトリ ハッシュ化するパスワード [root@
アプリケーションサーバとMaxscaleを同居させる場合はローカルのTCPソケットポートの食いつぶしに注意しよう | 俺的備忘録 〜なんかいろいろ〜
Maxscaleとアプリケーションサーバが同居したサーバで負荷テストを行ったところ、どうも途中でDBとの通信が失敗したりする部分があった。 で、なんでなんだろと調べていく際にssコマンドを実行したところ… [root@test-server01 ~]# ss -nap | grep ':3306' | wc -l 24299 …えっΣ(ﾟдﾟ ) 3306って、確かにMaxscaleのポートだけど… どうも、すべてTIME-WAIT状態でローカルのTCPポート(CentOS7のデフォルトのローカルポート範囲が「61000-32768=28232」)を使い潰していたようだ。通信内容はほぼすべて「127.0.0.1:ソケットポート ↔ 127.0.0.1:3306」というもの。これはあかん…。 これを対処するには、以下の内容を「/etc/sysctl.conf」に追記してやると良いだろう。 n
Maxscaleで指定したサーバをメンテナンスモードにする | 俺的備忘録 〜なんかいろいろ〜
Maxscaleを使っていて、再起動などで後ろにいる特定のDBサーバに接続させないようにしたい時もあるだろう。 そんなときは、指定したDBサーバをメンテナンスモードにすればよい。 Maxscaleで特定サーバをメンテナンスモードにしたい場合は、maxadminコマンドで以下のように実行すればよい。 maxadmin -p パスワード(初期:mariadb) set server サーバ名 maintenance [root@BS-PUB-GFRONT-01 ~]# maxadmin -p mariadb list servers Servers. -------------------+-----------------+-------+-------------+-------------------- Server | Address | Port | Connections | St
【5分でできる】MySQL/MariaDBをリバースエンジニアリングして、ER図を作成する - Qiita
この投稿は？ すでにあるMySQL/MariaDBから、ER図を作成するまでの説明です。 自分用メモでもあるので、文字ばかりです。 とても簡単なので、問題ないはず。 わからなければコメントください。 何を使うの？ MySQL Workbenchを使います。 http://www-jp.mysql.com/products/workbench/ ダウンロードしてインストールしちゃってください。 ダウンロードページに進むと、いつもどおり(？)「OracleのWeb Account作りなよ！」といわれますが、 スルーしたい場合は Login / Sign Up ボタンの下にある No thanks, just start my download. リンクを押下して、ファイルをダウンロードすることもできます。 ER図を作ってみよう MySQL Workbenchを起動し、上部メニューから下記を選択
MaxScale で MySQL をロードバランスする
アプリケーションの変更を最小限にするため、MaxScale の Read-Write Splitting 機能により、クエリは参照系を各 slave に分散し、更新系を master に向けたい。 インストール EC2 に MaxScale をインストールしていく。 まず MaxScale の yum レポジトリの設定を追加する。 # $EDITOR /etc/yum.repos.d/maxscale.repo [maxscale] name = maxscale baseurl = http://downloads.mariadb.com/software/MaxScale/maxscale/RPM/rhel6 enabled=1 gpgcheck=true RPM の公開鍵をインポートする。 # rpm --import http://downloads.mariadb.com/sof
AWS News Blog
New — File Release for Amazon FSx for Lustre Amazon FSx for Lustre provides fully managed shared storage with the scalability and high performance of the open-source Lustre file systems to support your Linux-based workloads. FSx for Lustre is for workloads where storage speed and throughput matter. This is because FSx for Lustre helps you avoid storage bottlenecks, increase utilization of compute
Enabling GTIDs for Server Replication in MariaDB Server 10.2 | MariaDB
I originally wrote this post in 2014, after the release of MariaDB Server 10.0. Most of what was in that original post still applies, but I've made some tweaks and updates since replication and high availability (HA) remain among the most popular MariaDB/MySQL features. Replication first appeared on the MySQL scene more than a decade ago, and as replication implementations became more complex over
Auto increments in Galera - MariaDB.org
Lets start by considering a scenario where records are being inserted in a single auto-increment table via different nodes of a multi-master cluster. One issue that might arise is ‘collision’ of generated auto-increment values on different nodes, which is precisely the subject of this article. As the cluster is multi-master, it allows writes on all master nodes. As a result of which a table might
MariaDB Galera Cluster Known Limitationsを勝手に翻訳 - orenoblog
MariaDB Galera Cluster - Known Limitationsの日本語訳です。 ありがとう同僚のInoiうじそしてGoogle翻訳こんにゃく MariaDB Galera Cluster既知の問題 この記事ではMariaDB Galera Clusterの既知の問題と制約に関する情報を記載しています。 codership.comからの制限 現在レプリケーションはInnoDBのみ動作します。 他のシステム(mysql.)テーブルなどのテーブルへの書き込みはレプリケーションされません （この制限は暗黙的にmysql.テーブルを変更するユーザの作成などのDDLステートメントを除外し、レプリケーションします） MyISAMはwsrep_replication_myisamシステム変数で実験的なサポートが行われています。 LOCK TABLES, FLUSH TABLES {e
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - datacharmer/test_db: A sample MySQL database with an integrated test suite, used to test your applications and database servers
MariaDB MaxScale 21.06
mariadb-enterprise-azure/maxscale.cnf.template at master · mariadb-corporation/mariadb-enterprise-azure · GitHub
MariaDB+GaleraClusterの運用事例(MySQL勉強会2016-01-28)