log4j pattern

%c	ログイベントのカテゴリー名を出力する。
%C	ロギング要求を行うクラス名を出力する。
%d	ログイベントの日時を出力する。 %d{HH:mm:ss} や %d{dd MMM yyyy HH}として、より柔軟に日時情報を出力することが出来る。
%F(*)	ログ要求が発生したファイル名を出力する。
%l(*)	ログが生成されたときに呼び出された位置（ソース名、行）を出力する。
%L(*)	ロギング要求を行なった行番号を出力する。
%m	ロギングイベントで設定されたメッセージを出力する。
%M(*)	ログ要求が行なわれたメソッド名を出力する。
%n	プラットフォーム依存の改行文字を出力する。
%p	ログの優先度を出力します。
%r	アプリケーションが開始してから、ログが出力されるまでの時間をミリ秒単位で出力する。
%t	ログを生成したスレッドの名前を出力する。
%x	ログが生成されたスレッドのNDC(ネスト化診断コンテキスト) を出力する。
%%	%を出力する。

 例：
<PatternLayout>
                <Pattern>%d %c{1.} [%t] %m%n</Pattern>
  </PatternLayout>

Read more

mysql binlog_row_image

In MySQL row-based replication, each row change event contains two images, a “before” image whose columns are matched against when searching for the row to be updated, and an “after” image containing the changes.
Normally, MySQL logs full rows (that is, all columns) for both the before and after images. However, it is not strictly necessary to include every column in both images, and we can often save disk, memory, and network usage by logging only those columns which are actually required.
For the before image, it is necessary only that the minimum set of columns required to uniquely identify rows is logged.
In the after image, it is necessary to log only the columns which have actually changed.



    full: Log all columns in both the before image and the after image.

    minimal: Log only those columns in the before image that are required to identify the row to be changed; log only those columns in the after image that are actually changed.

    noblob: Log all columns (same as full), except for BLOB and TEXT columns that are not required to identify rows, or that have not changed.
   
■条件付けだね。。
Setting this variable has no effect when the binary logging format is STATEMENT
じゃ。logging formatを「MIX」にして、
Optimized Row Based Replication

By only replicating those elements of the row image that have changed following INSERT, UPDATE and DELETE operations, replication throughput for both the master and slave(s) can be increased while binary log disk space, network resource and server memory footprint are all reduced.
スレーブとマスターのデータは、同じ順番であることが必要。。
その保証が難しい。

Read more

tomcat catalina.sh log

・Tomcat(Java)の標準エラーを標準出力へあらかじめリダイレクトしておく（2>&1）のがミソ。
>> "$CATALINA_OUT" 2>&1 "&"


・rotatelogsへのオプションにより、yyyy-mm-dd形式のタイムスタンプを${CATALINA_BASE}/logs/catalina.out末尾に付与し、
一日ごと（86400秒）に、JST（540分=+9時間のGMTからの時差）のローカルタイム基準でログを午前0時に新しいファイルにローテートする設定となる。
繰り返すけど、二か所あるので、同じように変更しておく。元の設定は、"#"でコメントアウトしておくとよい。
>> 2>&1 | /usr/sbin/rotatelogs "$CATALINA_BASE"/logs/catalina.out.%Y-%m-%d.log 86400 540 &

Read more

MySQL的innodb_flush_log_at_trx_commit配置值的设定

我发现同事在项目做压力测试的时候，误解了innodb_flush_log_at_trx_commit的含义，认为配置为0是不写日志，所以性能高。

配置项说明

0

如 果innodb_flush_log_at_trx_commit的值为0,log buffer每秒就会被刷写日志文件到磁盘，提交事务的时候不做任何操作。（执行是由mysql的master thread线程来执行的。主线程中每秒会将重做日志缓冲写入磁盘的重做日志文件(REDO LOG)中。不论事务是否已经提交。）默认的日志文件是ib_logfile0,ib_logfile1

1

当设为默认值1的时候，每次提交事务的时候，都会将log buffer刷写到日志。

2

如果设为2,每次提交事务都会写日志，但并不会执行刷的操作。每秒定时会刷到日志文件。要注意的是，并不能保证100%每秒一定都会刷到磁盘，这要取决于进程的调度。每次事务提交的时候将数据写入事务日志，而这里的写入仅是调用了文件系统的写入操作，而文件系统是有 缓存的，所以这个写入并不能保证数据已经写入到物理磁盘

默认值1是为了保证完整的ACID。 当然，你可以将这个配置项设为1以外的值来换取更高的性能，但是在系统崩溃的时候，你将会丢失1秒的数据。设为0的话，mysqld进程崩溃的时候，就会 丢失最后1秒的事务。设为2,只有在操作系统崩溃或者断电的时候才会丢失最后1秒的数据。InnoDB在做恢复的时候会忽略这个值。

刷写的概念

刷 写其实是两个操作，刷（flush）和写（write），区分这两个概念（两个系统调用）是很重要的。在大多数的操作系统中，把Innodb的log buffer（内存）写入日志（调用系统调用write），只是简单的把数据移到操作系统缓存中，操作系统缓存同样指的是内存。并没有实际的持久化数据。

所以，通常设为0和2的时候，在崩溃或断电的时候会丢失最后一秒的数据，因为这个时候数据只是存在于操作系统缓存。之所以说“通常”，可能会有丢失不只1秒的数据的情况，比如说执行flush操作的时候阻塞了。

总结

设为1当然是最安全的，但性能页是最差的（相对其他两个参数而言，但不是不能接受）。如果对数据一致性和完整性要求不高，完全可以设为2,如果只最求性能，例如高并发写的日志服务器，设为0来获得更高性能

Read more

mysql: logs-slave-updates

--logs-slave-updates
通常情况，从服务器从主服务器接收到的更新不记入它的二进制日志。该选项告诉从服务器将其SQL线程执行的更新记入到从服务器自己的二进制日志。为 了使该选项生效，还必须用--logs-bin选项启动从服务器以启用二进制日志。如果想要应用链式复制服务器，应使用--logs-slave- updates。例如，可能你想要这样设置：
A -> B -> C

也就是说，A为从服务器B的主服务器，B为从服务器C的主服务器。为了能工作，B必须既为主服务器又为从服务器。你必须用--logs-bin启动A和B以启用二进制日志，并且用--logs-slave-updates选项启动B。

以上是摘自mysql对于logs-slave-updates启动选项的描述。
当然logs-slave-upates也可以写入my.cnf :
//////////////////
log_slave_updates=1
//////////////////
当然在这种机制下可能有的同学会存在这么个问题：
如果a->b b->a 这样的双master架构下，a,b都打开log_slave_updates选项会不会出现无限循环的状态。
mysql已经考滤到了这个问题，每条bin-log都会记录执行语句的源server_id.当slave读到语句的server_id等于本身的ID的时候，不会忽略执行，所以我们不用担心a,b会不会无限循环下去。

基于以上这种情况，mysql的replication集群将更加灵活，你如果需要可以做成各种各样的链式复制。比如 a->b b->a b中设置log_slave_updates后还可以b->c. 这样a,c中的数据也是一致的。

在双A的情况下，如果log-slave-updates = 1 ，replicate-save-server-id = 1 ，那势必会造成循环复制sql。
“当然在这种机制下可能有的同学会存在这么个问题：
如果a->b b->a 这样的双master架构下，a,b都打开log_slave_updates选项会不会出现无限循环的状态。
mysql已经考滤到了这个问题，每条bin-log都会记录执行语句的源server_id.当slave读到语句的server_id等于本身的ID的时候，不会忽略执行，所以我们不用担心a,b会不会无限循环下去。”

以上问题只是因为replicate-same-server-id 默认值为0

Read more

mysql replication logging formats

Starting with version 5.1, MySQL supports three binary logging formats: statement,
row, and mixed.


Row-based logging records raw data about rows in the log. The slave
does not execute the same queries as the master, but instead updates
table rows directly. This is the safest binary logging format because it
can’t insert into the slave table any values that do not exist on the master.
This format can be used safely even when you call nondeterministic
functions such as NOW().
Statement-based logging just puts queries in the original SQL format
into the log, so the slave executes the same commands as the master. If
you use this format, network traffic usually—although not always—is
much lower than if a row-based format is used because a query can take
up less data than the actual changes it makes to rows. This is especially
noticeable when you update several rows in a table with BLOB columns.
The disadvantage of this format is that it forces you to ensure data
consistency. For example, if you insert the output of the function
NOW() into a column, you will most likely have different data on the
master and slave.
The mixed binary logging format contains the advantages of both row
and statement logging: it saves the majority of queries in statement
format but switches to row format when a query is not safe, i.e., when
it uses a nondeterministic function such as NOW().

Read more

Mysql Slave failed to initialize relay log info structure from the repository

何らかの理由で、リレーログが読めなくなってしまった
(今回の場合はhard_copy。。。。。。)

この時は、MySQLは上がっていて、スレーブのステータスもとれるので、SHOW SLAVE STATUSで最後の状態を調べる。

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State:
                  Master_Host: ***.***.***.***
                  Master_User: ********
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000009
:(略)
                   Last_Errno: 1872
                   Last_Error: Slave failed to initialize relay log info structure from the repository
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 4840135
:(略)
1 row in set (0.00 sec)

で、Master_Log_FileとExec_Master_Log_Posを見る。ここまでマスターのバイナリログの実行が終わっているので、
＝＝＞失敗したところから再開する！！

一旦スレーブをリセットして、ここから再開させる。

RESET SLAVE;

CHANGE MASTER TO
MASTER_HOST='***.***.***.***',
MASTER_USER='********',
MASTER_PASSWORD='********',
MASTER_LOG_FILE='mysql-bin.000009', // Master_Log_Fileのファイル名をセット
MASTER_LOG_POS=4840135; // Exec_Master_Log_Posの値をセット

START SLAVE;

これで、スレーブが再開するか確認。
今回はこれで動き出したようだ。

Read more

database catalog schema

いずれもも抽象的な物、名前衝突を防ぐために。。
SQL標準では
catalogー＞schemaー＞tables,view...
各DBの状況は違う。

Read more

mysql see binlog

=>mysqlbinlog
mysqlbinlog mysql-bin.000100 > /tmp/statement.sql

Read more

javaFx dialogBox

There is no common dialog support. .....

do yourself...

Stage dialogStage = new Stage();
dialogStage.initModality(Modality.WINDOW_MODAL);
dialogStage.setScene(new Scene(VBoxBuilder.create().
    children(new Text("Hi"), new Button("Ok.")).
    alignment(Pos.CENTER).padding(new Insets(5)).build()));
dialogStage.show();

・controlsfx?　jdk8からサーポート

・javafx-dialogs-0.0.3.jar　使える、かなり便利！ 

Read more