nilabのブックマーク / 2018年2月7日 - はてなブックマーク

nilab id:nilab

2018年2月7日のブックマーク (3件)

グーグルがMySQLを切り捨ててMariaDBを採用 | readwrite.jp
熱力学の第一法則にある通り、エネルギーというものは破壊することができない。ただ、ある形態から別の形態に変化するだけである。この自然法則はビジネスの話にも当てはまる。ある会社に対して良からぬことを行えば、いつの日かその会社にしっぺ返しをされかねないのだ。検索エンジンのグーグルが、現在使用しているオラクルMySQLリレーショナル・データベースのシステムの全てを、MySQLから派生したMariaDBに移行することを決めた。これに関し、公式な理由などはおそらく何もないだろう。意図的ではないのかもしれないが、そこには明らかにオラクルに対する因縁めいた物が感じられる。オラクルはここ数年間、グーグルがAndroidオペレーティングシステムにJavaコードの一部をコピーしていることと、37のアプリケーション·プログラミング·インターフェースにJavaプログラミング言語を利用していることで、著作権侵害を
nilab 2018/02/07
2013年の記事。「グーグルは厳密に言うとMariaDB 10.0の社内ブランチに移行を行っているようだ。グーグル独自の変更が組み込まれ、MySQL 5.6と同等のものになる予定だという」
リンク
長年の議論に終止符 -- MySQL/MariaDBのバックアップとロックの関係＋クラッシュセーフについて - interdb’s diary
よい機会なのでまとめておく。対象はMySQL5.6以下とMariaDB10.0以下。 (2014.12.3追記：以下の書籍にも記述した。) 要旨 MySQL/MariaDBのバックアップについて、相変わらず「InnoDBさえ使っていれば、FLUSH TABLES WITH READ LOCKは不要。よってバックアップ中に更新不可になることはない！」との主張が繰り返されているが、少なくとも5.6/10.0まではそんなことはない。オンラインバックアップに関するロックの正確な記述より正確に言えば「全データベース領域をバックアップする場合には、FLUSH TABLES WITH READ LOCKは必須。特定のInnoDBだけのデータベースやテーブルをバックアップする際は、この限りではない」。なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。ロックの必要
nilab 2018/02/07
「全データベース領域をバックアップする場合には、FLUSH TABLES WITH READ LOCKは必須。特定のInnoDBだけのデータベースやテーブルをバックアップする際は、この限りではない」

mysql
リンク
このコピペ思い出す　中学の頃、大村君が苗字音読みでダイソンって呼ばれ..
このコピペ思い出す中学の頃、大村君が苗字音読みでダイソンって呼ばれてて、それが元で梅村君はバイソン、若村君はジャクソン、下村君はアンダーソンとみんなかっこいいあだ名がついたのに津村君だけあだ名がバスロマンだったのはイジメに近いし、今思うとバスロマンはツムラじゃなくてアース製薬 [追記]---すまん引用情報が不親切だった。俺がコピったのはここなんだけど http://2chcopipe.com/archives/51878640.html たぶん初めて見たとこは別だし他に元ネタありそうだし何が本当のオリジナルなんだろうね？
nilab 2018/02/07
「中学の頃、大村君が苗字音読みでダイソンって呼ばれてて、それが元で梅村君はバイソン、若村君はジャクソン、下村君はアンダーソンとみんなかっこいいあだ名がついたのに津村君だけあだ名がバスロマンだった」
リンク
- 2018年2月8日
- 2018年2月7日
- 2018年2月6日