阅读xtrabackup代码的一点笔记
xtrabackup binary最重要的两个过程是backup和prepare,对应的函数分别是xtrabackup_backup_func()和xtrabackup_prepare_func(),这里做一些阅读代码时的笔记。
xtrabackup backup的线程模型:
1. 一个log拷贝线程;
2. n个ibd文件拷贝线程;
3. 一个io监控线程;
4. 通过suspend_start/suspend_end文件来标注是否启动终止线程;
typedef struct {
datafiles_iter_t *it;
uint num;uint *count;
os_ib_mutex_t count_mutex;
os_thread_id_t id;
}data_thread_ctxt_t;
数据线程上下文切换工作目录;116 /** Set if InnoDB must operate in read-only mode. We don't do any
117 recovery and open all tables in RO mode instead of RW mode. We don't
118 sync the max trx id to disk either. */
xb_set_innodb_read_only() 将innodb设成只读模式
srv_backup_mode=TRUE; 将innodb设成backup模式;
设置innodb的一系列参数
innodb_init_param()
xb_normalize_init_values(void)
修改srv_unix_file_flush_method
根据bp大小,调整srv_max_n_threads参数
1017 /*********************************************************************//**
1018 Initializes the synchronization primitives, memory system, and the thread
1019 local storage. */
srv_general_init()
ut_crc32_init()
xb_filters_init()
2567 /************************************************************************
2568 Initializes the I/O and tablespace cache subsystems. */
xb_fil_io_init(void)
838 /******************************************************//**
839 Initializes the log. */
log_init(void)585 /*********************************************************************//**
586 Creates the lock system at database start. */
lock_sys_create()
open_or_create_log_file
创建xtrabackup_extra_lsndir/extrabackup_traget_dir
表空间memory cache
fil_system_t* f_system = fil_system;
recv_find_max_checkpoint(&max_cp_group, &max_cp_field)
log_group_read_checkpoint_info(max_cp_group, max_cp_field)
checkpoint_lsn_start/checkpoint_no_start
确认一致的checkpoint状态;
创建XB_LOG_FILENAME文件,写入文件头信息;
创建io_watching_thread;
从checkpoint位置开始copy log文件;
xtrabackup_copy_logfile(checkpoint_lsn_start, FALSE)
log_copying/log_copying_stop
创建日志copy线程
os_thread_create(log_copying_thread, NULL, &log_copying_thread_id);
2591 /****************************************************************************
2592 Populates the tablespace memory cache by scanning for and opening data files.
2593 @returns DB_SUCCESS or error code.*/
xb_load_tablespaces()
挂起,等待XB_FN_SUSPENDED_AT_START文件被删除
xtrabackup_suspend
xb_page_bitmap_init()
根据xtrabackup_parallel设置,创建data_copy_thread_func线程
等待所有data_copy_thread_func线程退出
挂起,等待XB_FN_SUSPENDED_AT_END文件被删除
xtrabackup_suspend
读取最新的checkpoint, 记录在metadata的to_lsn字段;
通过设置log_copying=FALSE && set log_copying_stop,停止log_copying_thread;
创建一个文件XB_FN_LOG_COPIED,通知外部脚本,log_copying_thread已经结束;
写metadata;prepare_func1. 切换到xtrabackup_real_target_dir
2. 读取XTRABACKUP_METADATA_FILENAME,获取原信息;
metadata_type
3. xtrabackup_init_temp_log()
4. innodb_init_param()
2670 /************************************************************************
2671 Initialize the tablespace memory cache and populate it by scanning for and
2672 opening data files.
2673 @returns DB_SUCCESS or error code.*/
xb_data_files_init()
应用增量到全量xtrabackup_apply_deltas()
重设innodb初始化参数
innodb_init_param()
innodb_init()遍历文件mtr_start -> mtr_commit
trx_sys_print_mysql_binlog_offset()
将binlog位置信息输出到 xtrabackup_binlog_pos_innodb文件中
xtrabackup_close_temp_log(TRUE)
输出记录metadata_log
backup$./xtrabackup_56 --defaults-file=/u01/my3928/my.cnf --backup --target_dir=/u01/xianlin.lh/backup_dir/
./xtrabackup_56 version 2.1.8 for MySQL server 5.6.15 Linux (x86_64) (revision id: undefined)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /u01/my3928/data
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = /u01/my3928/data
xtrabackup: innodb_data_file_path = ibdata1:4G;ibdata2:16M:autoextend
xtrabackup: innodb_log_group_home_dir = /u01/my3928/data
xtrabackup: innodb_log_files_in_group = 4
xtrabackup: innodb_log_file_size = 1073741824
2014-05-05 17:29:35 2ac06bc4a2c0 InnoDB: Using Linux native AIO
xtrabackup: using O_DIRECT
>> log scanned up to (1451746590)
[01] Copying /u01/my3928/data/ibdata1 to /u01/xianlin.lh/backup_dir/ibdata1
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
[01] ...done[01] Copying /u01/my3928/data/ibdata2 to /u01/xianlin.lh/backup_dir/ibdata2
[01] ...done[01] Copying ./test/t2.ibd to /u01/xianlin.lh/backup_dir/test/t2.ibd
[01] ...done[01] Copying ./test/t4.ibd to /u01/xianlin.lh/backup_dir/test/t4.ibd
[01] ...done[01] Copying ./test/t3.ibd to /u01/xianlin.lh/backup_dir/test/t3.ibd
[01] ...done[01] Copying ./test/sbtest1.ibd to /u01/xianlin.lh/backup_dir/test/sbtest1.ibd
>> log scanned up to (1451746590)
>> log scanned up to (1451746590)
[01] ...done[01] Copying ./test/t1.ibd to /u01/xianlin.lh/backup_dir/test/t1.ibd
[01] ...done[01] Copying ./mysql/innodb_index_stats.ibd to /u01/xianlin.lh/backup_dir/mysql/innodb_index_stats.ibd
[01] ...done[01] Copying ./mysql/slave_worker_info.ibd to /u01/xianlin.lh/backup_dir/mysql/slave_worker_info.ibd
[01] ...done[01] Copying ./mysql/innodb_table_stats.ibd to /u01/xianlin.lh/backup_dir/mysql/innodb_table_stats.ibd
[01] ...done[01] Copying ./mysql/slave_relay_log_info.ibd to /u01/xianlin.lh/backup_dir/mysql/slave_relay_log_info.ibd
[01] ...done[01] Copying ./mysql/slave_master_info.ibd to /u01/xianlin.lh/backup_dir/mysql/slave_master_info.ibd
[01] ...done>> log scanned up to (1451746590)
xtrabackup: The latest check point (for incremental): '1451746590'
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1451746590)
xtrabackup: Transaction log of lsn (1451746590) to (1451746590) was copied.
创建备份的流程http://www.percona.com/doc/percona-xtrabackup/2.1/xtrabackup_bin/creating_a_backup.html
1 backup_type = full-backuped
2 from_lsn = 03 to_lsn = 1451746590
4 last_lsn = 1451746590
5 compact = 0prepare$./xtrabackup_56 --defaults-file=/u01/my3928/my.cnf --prepare --target-dir=/u01/xianlin.lh/backup_dir/
./xtrabackup_56 version 2.1.8 for MySQL server 5.6.15 Linux (x86_64) (revision id: undefined)
xtrabackup: cd to /u01/xianlin.lh/backup_dir/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1451746590)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:4G;ibdata2:16M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
2014-05-05 18:38:32 2b7f2f5202c0 InnoDB: Using Linux native AIO
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:4G;ibdata2:16M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
2014-05-05 18:38:32 2b7f2f5202c0 InnoDB: Using Linux native AIO
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using Linux native AIO
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: The log sequence numbers 552524932 and 552524932 in ibdata files do not match the log sequence number 1451746590 in the ib_logfiles!
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Last MySQL binlog file position 0 26767310, file name mysql-bin.000023
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
2014-05-05 18:38:33 2b7f49056700 InnoDB: Warning: table 'test/sbtest1'
InnoDB: in InnoDB data dictionary has unknown flags 50.
InnoDB: 5.6.15 started; log sequence number 1451746590
[notice (again)]
If you use binary log and don't use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 26767310, file name mysql-bin.000023
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 1451747281
prepare的流程:
http://www.percona.com/doc/percona-xtrabackup/2.1/xtrabackup_bin/preparing_the_backup.html
1 backup_type = full-prepared
2 from_lsn = 0
3 to_lsn = 1451746590
4 last_lsn = 1451746590
5 compact = 0

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









従来のコンピューティングを超える能力を備えているだけでなく、より低コストでより効率的なパフォーマンスを実現する人工知能モデルを想像してみてください。これは SF ではありません。世界で最も強力なオープンソース MoE モデルである DeepSeek-V2[1] が登場しました。 DeepSeek-V2 は、経済的なトレーニングと効率的な推論の特徴を備えた強力な専門家混合 (MoE) 言語モデルです。これは 236B のパラメータで構成されており、そのうち 21B は各マーカーをアクティブにするために使用されます。 DeepSeek67B と比較して、DeepSeek-V2 はパフォーマンスが優れていると同時に、トレーニング コストを 42.5% 節約し、KV キャッシュを 93.3% 削減し、最大生成スループットを 5.76 倍に高めます。 DeepSeek は一般的な人工知能を研究する会社です

AI は確かに数学を変えつつあります。最近、この問題に細心の注意を払っている陶哲軒氏が『米国数学協会会報』(米国数学協会会報)の最新号を送ってくれた。 「機械は数学を変えるのか?」というテーマを中心に、多くの数学者が意見を述べ、そのプロセス全体は火花に満ち、ハードコアで刺激的でした。著者には、フィールズ賞受賞者のアクシャイ・ベンカテシュ氏、中国の数学者鄭楽軍氏、ニューヨーク大学のコンピューター科学者アーネスト・デイビス氏、その他業界で著名な学者を含む強力な顔ぶれが揃っている。 AI の世界は劇的に変化しています。これらの記事の多くは 1 年前に投稿されたものです。

Google が推進する JAX のパフォーマンスは、最近のベンチマーク テストで Pytorch や TensorFlow のパフォーマンスを上回り、7 つの指標で 1 位にランクされました。また、テストは最高の JAX パフォーマンスを備えた TPU では行われませんでした。ただし、開発者の間では、依然として Tensorflow よりも Pytorch の方が人気があります。しかし、将来的には、おそらくより大規模なモデルが JAX プラットフォームに基づいてトレーニングされ、実行されるようになるでしょう。モデル 最近、Keras チームは、ネイティブ PyTorch 実装を使用して 3 つのバックエンド (TensorFlow、JAX、PyTorch) をベンチマークし、TensorFlow を使用して Keras2 をベンチマークしました。まず、主流のセットを選択します

Boston Dynamics Atlas は正式に電動ロボットの時代に突入します!昨日、油圧式アトラスが歴史の舞台から「涙ながらに」撤退したばかりですが、今日、ボストン・ダイナミクスは電動式アトラスが稼働することを発表しました。ボストン・ダイナミクス社は商用人型ロボットの分野でテスラ社と競争する決意を持っているようだ。新しいビデオが公開されてから、わずか 10 時間ですでに 100 万人以上が視聴しました。古い人が去り、新しい役割が現れるのは歴史的な必然です。今年が人型ロボットの爆発的な年であることは間違いありません。ネットユーザーは「ロボットの進歩により、今年の開会式は人間のように見え、人間よりもはるかに自由度が高い。しかし、これは本当にホラー映画ではないのか?」とコメントした。ビデオの冒頭では、アトラスは仰向けに見えるように地面に静かに横たわっています。次に続くのは驚くべきことです

今月初め、MIT やその他の機関の研究者らは、MLP に代わる非常に有望な代替案である KAN を提案しました。 KAN は、精度と解釈可能性の点で MLP よりも優れています。また、非常に少数のパラメーターを使用して、多数のパラメーターを使用して実行する MLP よりも優れたパフォーマンスを発揮できます。たとえば、著者らは、KAN を使用して、より小規模なネットワークと高度な自動化で DeepMind の結果を再現したと述べています。具体的には、DeepMind の MLP には約 300,000 個のパラメーターがありますが、KAN には約 200 個のパラメーターしかありません。 KAN は、MLP が普遍近似定理に基づいているのに対し、KAN はコルモゴロフ-アーノルド表現定理に基づいているのと同様に、強力な数学的基礎を持っています。以下の図に示すように、KAN は

目標検出は自動運転システムにおいて比較的成熟した問題であり、その中でも歩行者検出は最も初期に導入されたアルゴリズムの 1 つです。ほとんどの論文では非常に包括的な研究が行われています。ただし、サラウンドビューに魚眼カメラを使用した距離認識については、あまり研究されていません。放射状の歪みが大きいため、標準のバウンディング ボックス表現を魚眼カメラに実装するのは困難です。上記の説明を軽減するために、拡張バウンディング ボックス、楕円、および一般的な多角形の設計を極/角度表現に探索し、これらの表現を分析するためのインスタンス セグメンテーション mIOU メトリックを定義します。提案された多角形モデルの FisheyeDetNet は、他のモデルよりも優れたパフォーマンスを示し、同時に自動運転用の Valeo 魚眼カメラ データセットで 49.5% の mAP を達成しました。

テスラのロボット「オプティマス」の最新映像が公開され、すでに工場内で稼働可能となっている。通常の速度では、バッテリー(テスラの4680バッテリー)を次のように分類します:公式は、20倍の速度でどのように見えるかも公開しました - 小さな「ワークステーション」上で、ピッキング、ピッキング、ピッキング:今回は、それがリリースされたハイライトの1つビデオの内容は、オプティマスが工場内でこの作業を完全に自律的に行い、プロセス全体を通じて人間の介入なしに完了するというものです。そして、オプティマスの観点から見ると、自動エラー修正に重点を置いて、曲がったバッテリーを拾い上げたり配置したりすることもできます。オプティマスのハンドについては、NVIDIA の科学者ジム ファン氏が高く評価しました。オプティマスのハンドは、世界の 5 本指ロボットの 1 つです。最も器用。その手は触覚だけではありません

前に書かれたプロジェクトのリンク: https://nianticlabs.github.io/mickey/ 2 枚の写真が与えられた場合、それらの写真間の対応関係を確立することで、それらの間のカメラのポーズを推定できます。通常、これらの対応は 2D 対 2D であり、推定されたポーズはスケール不定です。いつでもどこでもインスタント拡張現実などの一部のアプリケーションでは、スケール メトリクスの姿勢推定が必要なため、スケールを回復するために外部深度推定器に依存します。この論文では、3D カメラ空間でのメトリックの対応を予測できるキーポイント マッチング プロセスである MicKey を提案します。画像全体の 3D 座標マッチングを学習することで、相対的なメトリックを推測できるようになります。
