泰國10歲公鹿國家公園內暴斃!胃袋被「7kg塑膠袋」塞爆 巡邏員心都碎了

摘錄自2019年11月28日ETtoday新聞雲報導

泰國坤沙坦國家公園(Khun Sathan National Park)巡邏員,近日在園內發現一頭10歲大野生公鹿陳屍林中,身上卻沒有明顯外傷。經檢查後發現,這頭鹿生前吞下約7公斤重的塑膠垃圾,導致牠喪命。

根據英國廣播公司(BBC)泰語頻道報導,巡邏員11月25日在泰國北部楠府(Nan Province)納內縣(Na Noi)的國家公園內發現這頭鹿的屍體,並在牠的胃部發現塑膠袋、塑膠繩、橡膠手套、即溶咖啡包裝袋、泡麵包裝袋、毛巾、內褲等塑膠或其他垃圾。

坤沙坦國家公園野生動植物保護部門主任克利安薩(Kriangsak Thanompun)說,「我們認為,這頭公鹿在死亡前,早已長期誤食塑膠垃圾。官方初步認為是塑膠袋堵住牠的消化道,但我們仍會進一步詳細調查。」

消息傳開後在社群網站上引起熱議,網友紛紛批評部分隨意棄置垃圾的遊客。其中一名網友說,「有點責任感,把自己的垃圾帶走」;另一名網友則說,「這是從小就必須教育和養成的,否則成年後習慣就很難改變了。」

克利安薩則說,當局將會制定一項「三階段計畫」,目的是鼓勵當地居民主動清理國家公園內的塑膠或其他垃圾。該計畫包括要建立一個專責管理廢棄物的委員會,最終目標則是教育大眾不要隨意棄置垃圾。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

日本女川核電廠2號反應爐獲准重新啟動 防波堤加高到29公尺

摘錄自2019年11月29日ETtoday報導

日本東北電力公司(Tohoku Electric Power)在27日表示,已經獲得日本核監管局的初步批准,重新啟動女川核電廠(Onagawa nuclear powerplant)2號反應爐。日本2011年大地震時,女川核電廠是最接近震央的一座核電廠,當時受到地震及海嘯的破壞而關閉,目前還需要當地居民的同意才能重新啟動。

女川核電廠在311地震時被海嘯淹沒,但裡面的冷卻系統倖存下來,使反應爐免遭受類似於東京電力福島第一核電廠發生的慘況。

東北電力公司預計為女川核電廠的安全升級投資3,400億日元(約新台幣950億元),將電廠防波堤的海拔高度提高到29公尺,這將會是日本各核電廠中最高的一座防波堤。若重新啟動2號反應爐,每年將為公用事業節省350億日元(約新台幣98億元)的燃料成本。

日本在福島核災之前有54座核反應爐在營運,提供日本三分之一的電力,災難突顯了營運和監管方面的缺陷之後,所有的核反應爐若要重啟,都必須按照新的標準許可。

日本的核能安全問題在最近才又被提起,天主教教宗方濟各在上周末訪問日本時表示,除非可以真正保障人民的安全,否則不該再使用核能。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

南投搬家前需注意的眉眉角角,別等搬了再說!

新北清潔公司,居家、辦公、裝潢細清專業服務

Mariadb之日誌相關配置

  前面我們聊到了mariadb的事務,以及事務隔離級別,回顧請參考https://www.cnblogs.com/qiuhom-1874/p/13198186.html;今天我們來聊一聊mariadb的日誌相關話題;mariadb日誌有6種,分別是查詢日誌(general_log),慢查詢日誌(log_slow_queries),錯誤日誌(log_error,log_warnings),二進制日誌(binlog),中繼日誌(relay_log)和事務日誌(innodb_log);

  1、查詢日誌,主要記錄查詢語句,日誌存儲位置可放在表中,也可以放在文件中,這個要根據自己的配置,當然也可以同時放在表和文件中;一般情況服務器IO壓力不大的情況下是可以開啟查詢日誌的,如果服務器IO壓力大,建議不要開啟查詢日誌;具體配置方法如下

  把查詢日誌放在mysql庫的general_log 表中的配置方法:

  在/etc/my.cnf.d/server.cnf中的server配置段下添加如下配置,並重啟mariadb服務即可

  提示:以上配置表示開啟查詢日誌,日誌輸出到表;默認會把查詢日誌存放在mysql庫中的general_log表中;

  重啟服務,然後查看general_log表是否有數據?

[root@lxc my.cnf.d]# systemctl restart mariadb
[root@lxc my.cnf.d]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.5.4-MariaDB-log MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> use mysql
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [mysql]> select * from mysql.general_log ;
+----------------------------+---------------------------+-----------+-----------+--------------+----------------------------------+
| event_time                 | user_host                 | thread_id | server_id | command_type | argument                         |
+----------------------------+---------------------------+-----------+-----------+--------------+----------------------------------+
| 2020-06-28 09:14:33.402211 | [root] @ localhost []     |         3 |         3 | Connect      | root@localhost on  using Socket  |
| 2020-06-28 09:14:33.409731 | root[root] @ localhost [] |         3 |         3 | Query        | select @@version_comment limit 1 |
| 2020-06-28 09:14:38.087307 | root[root] @ localhost [] |         3 |         3 | Query        | SELECT DATABASE()                |
| 2020-06-28 09:14:38.087952 | root[root] @ localhost [] |         3 |         3 | Init DB      | mysql                            |
| 2020-06-28 09:14:38.091356 | root[root] @ localhost [] |         3 |         3 | Query        | show databases                   |
| 2020-06-28 09:14:38.092713 | root[root] @ localhost [] |         3 |         3 | Query        | show tables                      |
| 2020-06-28 09:14:38.094222 | root[root] @ localhost [] |         3 |         3 | Field List   | column_stats                     |
| 2020-06-28 09:14:38.095628 | root[root] @ localhost [] |         3 |         3 | Field List   | columns_priv                     |
| 2020-06-28 09:14:38.096401 | root[root] @ localhost [] |         3 |         3 | Field List   | db                               |
| 2020-06-28 09:14:38.097869 | root[root] @ localhost [] |         3 |         3 | Field List   | event                            |
| 2020-06-28 09:14:38.099603 | root[root] @ localhost [] |         3 |         3 | Field List   | func                             |
| 2020-06-28 09:14:38.100382 | root[root] @ localhost [] |         3 |         3 | Field List   | general_log                      |
| 2020-06-28 09:14:38.101266 | root[root] @ localhost [] |         3 |         3 | Field List   | global_priv                      |
| 2020-06-28 09:14:38.101867 | root[root] @ localhost [] |         3 |         3 | Field List   | gtid_slave_pos                   |
| 2020-06-28 09:14:38.102563 | root[root] @ localhost [] |         3 |         3 | Field List   | help_category                    |
| 2020-06-28 09:14:38.103556 | root[root] @ localhost [] |         3 |         3 | Field List   | help_keyword                     |
| 2020-06-28 09:14:38.104430 | root[root] @ localhost [] |         3 |         3 | Field List   | help_relation                    |
| 2020-06-28 09:14:38.105328 | root[root] @ localhost [] |         3 |         3 | Field List   | help_topic                       |
| 2020-06-28 09:14:38.106362 | root[root] @ localhost [] |         3 |         3 | Field List   | index_stats                      |
| 2020-06-28 09:14:38.107459 | root[root] @ localhost [] |         3 |         3 | Field List   | innodb_index_stats               |
| 2020-06-28 09:14:38.109085 | root[root] @ localhost [] |         3 |         3 | Field List   | innodb_table_stats               |
| 2020-06-28 09:14:38.110367 | root[root] @ localhost [] |         3 |         3 | Field List   | plugin                           |
| 2020-06-28 09:14:38.111098 | root[root] @ localhost [] |         3 |         3 | Field List   | proc                             |
| 2020-06-28 09:14:38.112958 | root[root] @ localhost [] |         3 |         3 | Field List   | procs_priv                       |
| 2020-06-28 09:14:38.113798 | root[root] @ localhost [] |         3 |         3 | Field List   | proxies_priv                     |
| 2020-06-28 09:14:38.114734 | root[root] @ localhost [] |         3 |         3 | Field List   | roles_mapping                    |
| 2020-06-28 09:14:38.115476 | root[root] @ localhost [] |         3 |         3 | Field List   | servers                          |
| 2020-06-28 09:14:38.116419 | root[root] @ localhost [] |         3 |         3 | Field List   | slow_log                         |
| 2020-06-28 09:14:38.118138 | root[root] @ localhost [] |         3 |         3 | Field List   | table_stats                      |
| 2020-06-28 09:14:38.119065 | root[root] @ localhost [] |         3 |         3 | Field List   | tables_priv                      |
| 2020-06-28 09:14:38.120027 | root[root] @ localhost [] |         3 |         3 | Field List   | time_zone                        |
| 2020-06-28 09:14:38.120907 | root[root] @ localhost [] |         3 |         3 | Field List   | time_zone_leap_second            |
| 2020-06-28 09:14:38.121914 | root[root] @ localhost [] |         3 |         3 | Field List   | time_zone_name                   |
| 2020-06-28 09:14:38.122718 | root[root] @ localhost [] |         3 |         3 | Field List   | time_zone_transition             |
| 2020-06-28 09:14:38.123713 | root[root] @ localhost [] |         3 |         3 | Field List   | time_zone_transition_type        |
| 2020-06-28 09:14:38.124958 | root[root] @ localhost [] |         3 |         3 | Field List   | transaction_registry             |
| 2020-06-28 09:14:38.126722 | root[root] @ localhost [] |         3 |         3 | Field List   | user                             |
| 2020-06-28 09:14:48.615477 | root[root] @ localhost [] |         3 |         3 | Query        | select * from mysql.general_log  |
+----------------------------+---------------------------+-----------+-----------+--------------+----------------------------------+
38 rows in set (0.002 sec)

MariaDB [mysql]> 

  提示:可以看到重啟服務后,general_log表中就有數據了,此時查詢日誌記錄到表中就配置好了;通常不建議開啟查詢日誌,這個很消耗服務器性能;

  配置查詢日誌記錄到文件

  提示:以上配置表示明確開啟查詢日誌,並把日誌記錄到/var/lib/mysql/general_log中;

  重啟服務,看看對應目錄下是否生成日誌文件,連接到數據,執行查詢操作,看看是否把日誌記錄到相應文件中哦?

[root@lxc my.cnf.d]# systemctl restart mariadb
[root@lxc my.cnf.d]# ll /var/lib/mysql/general_log 
-rw-rw---- 1 mysql mysql 143 Jun 28 09:22 /var/lib/mysql/general_log
[root@lxc my.cnf.d]# cat /var/lib/mysql/general_log
/usr/sbin/mariadbd, Version: 10.5.4-MariaDB-log (MariaDB Server). started with:
Tcp port: 0  Unix socket: (null)
Time                Id Command  Argument
[root@lxc my.cnf.d]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.5.4-MariaDB-log MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| first_db           |
| information_schema |
| mysql              |
| performance_schema |
| test               |
+--------------------+
5 rows in set (0.001 sec)

MariaDB [(none)]> \q
Bye
[root@lxc my.cnf.d]# cat /var/lib/mysql/general_log
/usr/sbin/mariadbd, Version: 10.5.4-MariaDB-log (MariaDB Server). started with:
Tcp port: 0  Unix socket: (null)
Time                Id Command  Argument
200628  9:22:32      3 Connect  root@localhost on  using Socket
                     3 Query    select @@version_comment limit 1
200628  9:22:37      3 Query    show databases
200628  9:22:38      3 Quit
[root@lxc my.cnf.d]# 

  提示:可以看到我們在數據庫中執行了一個show databases; 在對應日誌文件中是能夠記錄對應語句的;

  配置查詢日誌記錄同時記錄到表和文件中

  提示:以上配置表示開啟查詢日誌功能,並把日誌同時記錄到表和文件中,文件路徑為/var/lib/mysq/general_log;

  重啟mariadb,執行查詢操作,看看對應表和文件中是否有記錄?

[root@lxc my.cnf.d]# systemctl restart mariadb     
[root@lxc my.cnf.d]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.5.4-MariaDB-log MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> select * from mysql.general_log;
+----------------------------+---------------------------+-----------+-----------+--------------+----------------------------------+
| event_time                 | user_host                 | thread_id | server_id | command_type | argument                         |
+----------------------------+---------------------------+-----------+-----------+--------------+----------------------------------+
| 2020-06-28 09:14:33.402211 | [root] @ localhost []     |         3 |         3 | Connect      | root@localhost on  using Socket  |
| 2020-06-28 09:14:33.409731 | root[root] @ localhost [] |         3 |         3 | Query        | select @@version_comment limit 1 |
| 2020-06-28 09:14:38.087307 | root[root] @ localhost [] |         3 |         3 | Query        | SELECT DATABASE()                |
| 2020-06-28 09:14:38.087952 | root[root] @ localhost [] |         3 |         3 | Init DB      | mysql                            |
| 2020-06-28 09:14:38.091356 | root[root] @ localhost [] |         3 |         3 | Query        | show databases                   |
| 2020-06-28 09:14:38.092713 | root[root] @ localhost [] |         3 |         3 | Query        | show tables                      |
| 2020-06-28 09:14:38.094222 | root[root] @ localhost [] |         3 |         3 | Field List   | column_stats                     |
| 2020-06-28 09:14:38.095628 | root[root] @ localhost [] |         3 |         3 | Field List   | columns_priv                     |
| 2020-06-28 09:14:38.096401 | root[root] @ localhost [] |         3 |         3 | Field List   | db                               |
| 2020-06-28 09:14:38.097869 | root[root] @ localhost [] |         3 |         3 | Field List   | event                            |
| 2020-06-28 09:14:38.099603 | root[root] @ localhost [] |         3 |         3 | Field List   | func                             |
| 2020-06-28 09:14:38.100382 | root[root] @ localhost [] |         3 |         3 | Field List   | general_log                      |
| 2020-06-28 09:14:38.101266 | root[root] @ localhost [] |         3 |         3 | Field List   | global_priv                      |
| 2020-06-28 09:14:38.101867 | root[root] @ localhost [] |         3 |         3 | Field List   | gtid_slave_pos                   |
| 2020-06-28 09:14:38.102563 | root[root] @ localhost [] |         3 |         3 | Field List   | help_category                    |
| 2020-06-28 09:14:38.103556 | root[root] @ localhost [] |         3 |         3 | Field List   | help_keyword                     |
| 2020-06-28 09:14:38.104430 | root[root] @ localhost [] |         3 |         3 | Field List   | help_relation                    |
| 2020-06-28 09:14:38.105328 | root[root] @ localhost [] |         3 |         3 | Field List   | help_topic                       |
| 2020-06-28 09:14:38.106362 | root[root] @ localhost [] |         3 |         3 | Field List   | index_stats                      |
| 2020-06-28 09:14:38.107459 | root[root] @ localhost [] |         3 |         3 | Field List   | innodb_index_stats               |
| 2020-06-28 09:14:38.109085 | root[root] @ localhost [] |         3 |         3 | Field List   | innodb_table_stats               |
| 2020-06-28 09:14:38.110367 | root[root] @ localhost [] |         3 |         3 | Field List   | plugin                           |
| 2020-06-28 09:14:38.111098 | root[root] @ localhost [] |         3 |         3 | Field List   | proc                             |
| 2020-06-28 09:14:38.112958 | root[root] @ localhost [] |         3 |         3 | Field List   | procs_priv                       |
| 2020-06-28 09:14:38.113798 | root[root] @ localhost [] |         3 |         3 | Field List   | proxies_priv                     |
| 2020-06-28 09:14:38.114734 | root[root] @ localhost [] |         3 |         3 | Field List   | roles_mapping                    |
| 2020-06-28 09:14:38.115476 | root[root] @ localhost [] |         3 |         3 | Field List   | servers                          |
| 2020-06-28 09:14:38.116419 | root[root] @ localhost [] |         3 |         3 | Field List   | slow_log                         |
| 2020-06-28 09:14:38.118138 | root[root] @ localhost [] |         3 |         3 | Field List   | table_stats                      |
| 2020-06-28 09:14:38.119065 | root[root] @ localhost [] |         3 |         3 | Field List   | tables_priv                      |
| 2020-06-28 09:14:38.120027 | root[root] @ localhost [] |         3 |         3 | Field List   | time_zone                        |
| 2020-06-28 09:14:38.120907 | root[root] @ localhost [] |         3 |         3 | Field List   | time_zone_leap_second            |
| 2020-06-28 09:14:38.121914 | root[root] @ localhost [] |         3 |         3 | Field List   | time_zone_name                   |
| 2020-06-28 09:14:38.122718 | root[root] @ localhost [] |         3 |         3 | Field List   | time_zone_transition             |
| 2020-06-28 09:14:38.123713 | root[root] @ localhost [] |         3 |         3 | Field List   | time_zone_transition_type        |
| 2020-06-28 09:14:38.124958 | root[root] @ localhost [] |         3 |         3 | Field List   | transaction_registry             |
| 2020-06-28 09:14:38.126722 | root[root] @ localhost [] |         3 |         3 | Field List   | user                             |
| 2020-06-28 09:14:48.615477 | root[root] @ localhost [] |         3 |         3 | Query        | select * from mysql.general_log  |
| 2020-06-28 09:19:46.865108 | root[root] @ localhost [] |         3 |         3 | Quit         |                                  |
| 2020-06-28 09:28:29.542343 | [root] @ localhost []     |         3 |         3 | Connect      | root@localhost on  using Socket  |
| 2020-06-28 09:28:29.549997 | root[root] @ localhost [] |         3 |         3 | Query        | select @@version_comment limit 1 |
| 2020-06-28 09:28:44.924061 | root[root] @ localhost [] |         3 |         3 | Query        | select * from mysql.general_log  |
+----------------------------+---------------------------+-----------+-----------+--------------+----------------------------------+
42 rows in set (0.002 sec)

MariaDB [(none)]> \q
Bye
[root@lxc my.cnf.d]# cat /var/lib/mysql/general_log 
/usr/sbin/mariadbd, Version: 10.5.4-MariaDB-log (MariaDB Server). started with:
Tcp port: 0  Unix socket: (null)
Time                Id Command  Argument
200628  9:22:32      3 Connect  root@localhost on  using Socket
                     3 Query    select @@version_comment limit 1
200628  9:22:37      3 Query    show databases
200628  9:22:38      3 Quit
/usr/sbin/mariadbd, Version: 10.5.4-MariaDB-log (MariaDB Server). started with:
Tcp port: 0  Unix socket: (null)
Time                Id Command  Argument
200628  9:28:29      3 Connect  root@localhost on  using Socket
                     3 Query    select @@version_comment limit 1
200628  9:28:44      3 Query    select * from mysql.general_log
200628  9:28:47      3 Quit
[root@lxc my.cnf.d]# 

  提示:可以看到mysql.general_log表中和/var/lib/mysql/general_log文件中是可以記錄我們執行的查詢語句;

  2、慢查詢日誌,這個日誌對於運維來講是比較重要的,通常我們可以利用慢查詢日誌來判斷哪些語句執行時間超出指定時間;慢查詢日誌主要記錄運行時間超出指定時長度查詢語句;這個日誌同查詢日誌類似,它也是可以存儲在表和文件中的;具體配置方式如下

  配置慢查詢日誌存放在表中

  提示:以上配置表示開啟慢查詢日誌,並把日誌記錄到表中,默認是mysql.slow_log表中;log_slow_filter用來定義過濾哪些語句不記錄的;log_slow_rate_limit表示開啟慢查詢日誌記錄速率;log_slow_verbosity開啟慢查詢日誌詳細記錄;long_query_time定義時長,超出我們指定的時長就會視為慢查詢;配置好以上配置以後重啟服務,我們就可以在mariadb中看到對應變量的值;

[root@lxc my.cnf.d]# systemctl restart mariadb;
[root@lxc my.cnf.d]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.5.4-MariaDB-log MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show global variables like 'slow%';
+---------------------+--------------+
| Variable_name       | Value        |
+---------------------+--------------+
| slow_launch_time    | 2            |
| slow_query_log      | ON           |
| slow_query_log_file | lxc-slow.log |
+---------------------+--------------+
3 rows in set (0.003 sec)

MariaDB [(none)]> show global variables like 'log_slow%';
+------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name                | Value                                                                                                                                |
+------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+
| log_slow_admin_statements    | ON                                                                                                                                   |
| log_slow_disabled_statements | sp                                                                                                                                   |
| log_slow_filter              | admin,filesort,filesort_on_disk,filesort_priority_queue,full_join,full_scan,query_cache,query_cache_miss,tmp_table,tmp_table_on_disk |
| log_slow_rate_limit          | 1                                                                                                                                    |
| log_slow_slave_statements    | ON                                                                                                                                   |
| log_slow_verbosity           | innodb                                                                                                                               |
+------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+
6 rows in set (0.002 sec)

MariaDB [(none)]> show global variables like 'long%';    
+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| long_query_time | 3.000000 |
+-----------------+----------+
1 row in set (0.003 sec)

MariaDB [(none)]>

  提示:從上面的信息可以看到我們配置的相關參數已經生效;

  測試:執行select sleep(5);看看mysql.slow_log表中是否有記錄?

MariaDB [(none)]> select sleep(5) ;               
+----------+
| sleep(5) |
+----------+
|        0 |
+----------+
1 row in set (5.001 sec)

MariaDB [(none)]> select * from mysql.slow_log\G
*************************** 1. row ***************************
    start_time: 2020-06-28 10:32:19.643885
     user_host: root[root] @ localhost []
    query_time: 00:00:05.000700
     lock_time: 00:00:00.000000
     rows_sent: 1
 rows_examined: 0
            db: 
last_insert_id: 0
     insert_id: 0
     server_id: 3
      sql_text: select sleep(5)
     thread_id: 3
 rows_affected: 0
1 row in set (0.001 sec)

MariaDB [(none)]> 

  提示:可以看到slow_log表中已經記錄了我們執行的select sleep(5)語句,執行時長為5.007秒;

  配置慢查詢日誌記錄到文件;

  提示:以上配置表示把慢查詢日誌保存在/var/lib/mysql/slow_query_log文件中;

  測試:重啟mariadb,執行select sleep(5)語句,看看對應文件是否記錄?

[root@lxc my.cnf.d]# systemctl restart mariadb
[root@lxc my.cnf.d]# ll /var/lib/mysql/slow_query_log
-rw-rw---- 1 mysql mysql 143 Jun 28 10:39 /var/lib/mysql/slow_query_log
[root@lxc my.cnf.d]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.5.4-MariaDB-log MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show global variables like 'slow%';
+---------------------+-------------------------------+
| Variable_name       | Value                         |
+---------------------+-------------------------------+
| slow_launch_time    | 2                             |
| slow_query_log      | ON                            |
| slow_query_log_file | /var/lib/mysql/slow_query_log |
+---------------------+-------------------------------+
3 rows in set (0.003 sec)

MariaDB [(none)]> show global variables like 'log_slow%';
+------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name                | Value                                                                                                                                |
+------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+
| log_slow_admin_statements    | ON                                                                                                                                   |
| log_slow_disabled_statements | sp                                                                                                                                   |
| log_slow_filter              | admin,filesort,filesort_on_disk,filesort_priority_queue,full_join,full_scan,query_cache,query_cache_miss,tmp_table,tmp_table_on_disk |
| log_slow_rate_limit          | 1                                                                                                                                    |
| log_slow_slave_statements    | ON                                                                                                                                   |
| log_slow_verbosity           | innodb                                                                                                                               |
+------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+
6 rows in set (0.003 sec)

MariaDB [(none)]> show global variables like 'long%';    
+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| long_query_time | 3.000000 |
+-----------------+----------+
1 row in set (0.002 sec)

MariaDB [(none)]> select sleep(5);
+----------+
| sleep(5) |
+----------+
|        0 |
+----------+
1 row in set (5.001 sec)

MariaDB [(none)]> \q
Bye
[root@lxc my.cnf.d]# cat /var/lib/mysql/slow_query_log
/usr/sbin/mariadbd, Version: 10.5.4-MariaDB-log (MariaDB Server). started with:
Tcp port: 0  Unix socket: (null)
Time                Id Command  Argument
# Time: 200628 10:40:50
# User@Host: root[root] @ localhost []
# Thread_id: 3  Schema:   QC_hit: No
# Query_time: 5.000553  Lock_time: 0.000000  Rows_sent: 1  Rows_examined: 0
# Rows_affected: 0  Bytes_sent: 64
SET timestamp=1593355250;
select sleep(5);
[root@lxc my.cnf.d]# 

  提示:可以看到我們配置的參數在mariadb中已經可正常查詢到,對應的文件中已經記錄我們執行select sleep(5)這條語句執行了5.000553秒;

  配置慢查詢日誌記錄到表和文件中

  提示:紅框中的內容表示把慢查詢日誌同時記錄到文件和表中;

  測試:重啟mariadb服務,執行select sleep(5)語句看看是否在表和文件中都記錄了?

[root@lxc my.cnf.d]# systemctl restart mariadb       
[root@lxc my.cnf.d]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.5.4-MariaDB-log MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> select sleep(5);                   
+----------+
| sleep(5) |
+----------+
|        0 |
+----------+
1 row in set (5.002 sec)

MariaDB [(none)]> select * from mysql.slow_log\G
*************************** 1. row ***************************
    start_time: 2020-06-28 10:32:19.643885
     user_host: root[root] @ localhost []
    query_time: 00:00:05.000700
     lock_time: 00:00:00.000000
     rows_sent: 1
 rows_examined: 0
            db: 
last_insert_id: 0
     insert_id: 0
     server_id: 3
      sql_text: select sleep(5)
     thread_id: 3
 rows_affected: 0
*************************** 2. row ***************************
    start_time: 2020-06-28 10:45:37.720365
     user_host: root[root] @ localhost []
    query_time: 00:00:05.000784
     lock_time: 00:00:00.000000
     rows_sent: 1
 rows_examined: 0
            db: 
last_insert_id: 0
     insert_id: 0
     server_id: 3
      sql_text: select sleep(5)
     thread_id: 3
 rows_affected: 0
2 rows in set (0.001 sec)

MariaDB [(none)]> \q
Bye
[root@lxc my.cnf.d]# cat /var/lib/mysql/slow_query_log
/usr/sbin/mariadbd, Version: 10.5.4-MariaDB-log (MariaDB Server). started with:
Tcp port: 0  Unix socket: (null)
Time                Id Command  Argument
# Time: 200628 10:40:50
# User@Host: root[root] @ localhost []
# Thread_id: 3  Schema:   QC_hit: No
# Query_time: 5.000553  Lock_time: 0.000000  Rows_sent: 1  Rows_examined: 0
# Rows_affected: 0  Bytes_sent: 64
SET timestamp=1593355250;
select sleep(5);
/usr/sbin/mariadbd, Version: 10.5.4-MariaDB-log (MariaDB Server). started with:
Tcp port: 0  Unix socket: (null)
Time                Id Command  Argument
# Time: 200628 10:45:37
# User@Host: root[root] @ localhost []
# Thread_id: 3  Schema:   QC_hit: No
# Query_time: 5.000784  Lock_time: 0.000000  Rows_sent: 1  Rows_examined: 0
# Rows_affected: 0  Bytes_sent: 64
SET timestamp=1593355537;
select sleep(5);
[root@lxc my.cnf.d]# 

  提示:可以看到slow_log表和我們指定文件中都記錄;

  用mysqldumpslow來統計慢查詢日誌

[root@lxc my.cnf.d]# mysqldumpslow 
Can't determine datadir from 'my_print_defaults instances' output: --slow_query_log=on
--log_output=file,table
--slow_query_log_file=/var/lib/mysql/slow_query_log
--log_slow_filter=admin,filesort,filesort_on_disk,filesort_priority_queue,full_join,full_scan,query_cache,query_cache_miss,tmp_table,tmp_table_on_disk
--log_slow_rate_limit=1
--log_slow_verbosity=1
--long_query_time=3
--server_id=3
--read_only
--relay_log_purge=0
--skip_name_resolve=1
[root@lxc my.cnf.d]# mysqldumpslow /var/lib/mysql/slow_query_log

Reading mysql slow query log from /var/lib/mysql/slow_query_log
Count: 2  Time=5.00s (10s)  Lock=0.00s (0s)  Rows_sent=1.0 (2), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
  select sleep(N)

Count: 1  Time=4.02s (4s)  Lock=0.00s (0s)  Rows_sent=1.0 (1), Rows_examined=2.0 (2), Rows_affected=0.0 (0), root[root]@localhost
  select sleep(N),count(id) from first_db.test_tb

Count: 3  Time=4.00s (12s)  Lock=0.00s (0s)  Rows_sent=1.0 (3), Rows_examined=5.0 (15), Rows_affected=0.0 (0), root[root]@localhost
  select sleep(N),count(start_time) from mysql.slow_log

Count: 1  Time=4.00s (4s)  Lock=0.00s (0s)  Rows_sent=1.0 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
  select sleep(N)as a, N as b

[root@lxc my.cnf.d]# 

  提示:默認mysqldumpslow 不加任何選項和參數 它會打印配置文件內容,mysqldumpslow 後面給指定的slow日誌 它會統計出那些命令執行了幾次,總時長是多少等等;

  使用日誌分析工具mysqlsla工具分析慢查詢日誌

  安裝mysqlsla

[root@lxc my.cnf.d]# yum install perl-DBI perl-DBD-MySQL perl-devel -y
Loaded plugins: fastestmirror
base                                                                                                                                                | 3.6 kB  00:00:00     
docker-ce-stable                                                                                                                                    | 3.5 kB  00:00:00     
epel                                                                                                                                                | 4.7 kB  00:00:00     
extras                                                                                                                                              | 2.9 kB  00:00:00     
mariadb-main                                                                                                                                        | 2.9 kB  00:00:00     
mariadb-maxscale                                                                                                                                    | 2.4 kB  00:00:00     
mariadb-tools                                                                                                                                       | 2.9 kB  00:00:00     
updates                                                                                                                                             | 2.9 kB  00:00:00     
(1/3): updates/7/x86_64/primary_db                                                                                                                  | 2.9 MB  00:00:00     
(2/3): epel/x86_64/updateinfo                                                                                                                       | 1.0 MB  00:00:00     
(3/3): epel/x86_64/primary_db                                                                                                                       | 6.8 MB  00:00:01     
Loading mirror speeds from cached hostfile
 * base: mirrors.aliyun.com
 * extras: mirrors.aliyun.com
 * updates: mirrors.aliyun.com
Package perl-DBI-1.627-4.el7.x86_64 already installed and latest version
Resolving Dependencies
--> Running transaction check
---> Package perl-DBD-MySQL.x86_64 0:4.023-5.el7 will be updated
---> Package perl-DBD-MySQL.x86_64 0:4.023-6.el7 will be an update
---> Package perl-devel.x86_64 4:5.16.3-295.el7 will be installed
……省略部分內容
Installed:
  perl-devel.x86_64 4:5.16.3-295.el7                                                                                                                                       

Dependency Installed:
  gdbm-devel.x86_64 0:1.10-8.el7                           glibc-devel.x86_64 0:2.17-307.el7.1                      glibc-headers.x86_64 0:2.17-307.el7.1                  
  kernel-headers.x86_64 0:3.10.0-1127.13.1.el7             libdb-devel.x86_64 0:5.3.21-25.el7                       perl-ExtUtils-Install.noarch 0:1.58-295.el7            
  perl-ExtUtils-MakeMaker.noarch 0:6.68-3.el7              perl-ExtUtils-Manifest.noarch 0:1.61-244.el7             perl-ExtUtils-ParseXS.noarch 1:3.18-3.el7              
  perl-Test-Harness.noarch 0:3.28-3.el7                    pyparsing.noarch 0:1.5.6-9.el7                           systemtap-sdt-devel.x86_64 0:4.0-11.el7                

Updated:
  perl-DBD-MySQL.x86_64 0:4.023-6.el7                                                                                                                                      

Dependency Updated:
  glibc.x86_64 0:2.17-307.el7.1          glibc-common.x86_64 0:2.17-307.el7.1          libdb.x86_64 0:5.3.21-25.el7          libdb-utils.x86_64 0:5.3.21-25.el7         

Complete!
[root@lxc my.cnf.d]#cd
[root@lxc ~]#wget  ftp://ftp.tw.freebsd.org/pub/distfiles/mysqlsla-2.03.tar.gz
--2020-06-28 11:07:02--  ftp://ftp.tw.freebsd.org/pub/distfiles/mysqlsla-2.03.tar.gz
           => ‘mysqlsla-2.03.tar.gz’
Resolving ftp.tw.freebsd.org (ftp.tw.freebsd.org)... 140.113.17.209
Connecting to ftp.tw.freebsd.org (ftp.tw.freebsd.org)|140.113.17.209|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /pub/distfiles ... done.
==> SIZE mysqlsla-2.03.tar.gz ... 33674
==> PASV ... done.    ==> RETR mysqlsla-2.03.tar.gz ... done.
Length: 33674 (33K) (unauthoritative)

100%[=================================================================================================================================>] 33,674      --.-K/s   in 0s      

2020-06-28 11:07:10 (195 MB/s) - ‘mysqlsla-2.03.tar.gz’ saved [33674]
[root@lxc ~]# ls
192.168.0.22  lxc_br_set.sh  LXC-Web-Panel  mysqlsla-2.03.tar.gz
[root@lxc ~]# tar xf mysqlsla-2.03.tar.gz 
[root@lxc ~]# cd mysqlsla-2.03/
[root@lxc mysqlsla-2.03]# perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for mysqlsla
[root@lxc mysqlsla-2.03]# make
cp lib/mysqlsla.pm blib/lib/mysqlsla.pm
cp bin/mysqlsla blib/script/mysqlsla
/usr/bin/perl -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/mysqlsla
Manifying blib/man3/mysqlsla.3pm
[root@lxc mysqlsla-2.03]# make install
Installing /usr/local/share/perl5/mysqlsla.pm
Installing /usr/local/share/man/man3/mysqlsla.3pm
Installing /usr/local/bin/mysqlsla
Appending installation info to /usr/lib64/perl5/perllocal.pod
[root@lxc mysqlsla-2.03]#

  使用mysqlsla分析慢查詢日誌/var/lib/mysql/slow_query_log

[root@lxc mysqlsla-2.03]# mysqlsla -lt slow /var/lib/mysql/slow_query_log  
Report for msl logs: /var/lib/mysql/slow_query_log
7 queries total, 4 unique
Sorted by 't_sum'
Grand Totals: Time 30 s, Lock 0 s, Rows sent 7, Rows Examined 17


______________________________________________________________________ 001 ___
Count         : 3  (42.86%)
Time          : 12.003227 s total, 4.001076 s avg, 4.000803 s to 4.001615 s max  (39.97%)
Lock Time (s) : 595 otal, 198 vg, 151 o 257 ax  (26.81%)
Rows sent     : 1 avg, 1 to 1 max  (42.86%)
Rows examined : 5 avg, 4 to 6 max  (88.24%)
Database      :   QC_hit: No
Users         : 
        root@localhost  : 100.00% (3) of query, 100.00% (7) of all users

Query abstract:
SELECT sleep(N),COUNT(start_time) FROM mysql.slow_log;

Query sample:
select sleep(4),count(start_time) from mysql.slow_log;

______________________________________________________________________ 002 ___
Count         : 2  (28.57%)
Time          : 10.001337 s total, 5.000668 s avg, 5.000553 s to 5.000784 s max  (33.31%)
Lock Time (s) : 0 total, 0 avg, 0 to 0 max  (0.00%)
Rows sent     : 1 avg, 1 to 1 max  (28.57%)
Rows examined : 0 avg, 0 to 0 max  (0.00%)
Database      :   QC_hit: No
Users         : 
        root@localhost  : 100.00% (2) of query, 100.00% (7) of all users

Query abstract:
SELECT sleep(N);

Query sample:
select sleep(5);

______________________________________________________________________ 003 ___
Count         : 1  (14.29%)
Time          : 4.023146 s total, 4.023146 s avg, 4.023146 s to 4.023146 s max  (13.40%)
Lock Time (s) : 1.624 ms total, 1.624 ms avg, 1.624 ms to 1.624 ms max  (73.19%)
Rows sent     : 1 avg, 1 to 1 max  (14.29%)
Rows examined : 2 avg, 2 to 2 max  (11.76%)
Database      :   QC_hit: No
Users         : 
        root@localhost  : 100.00% (1) of query, 100.00% (7) of all users

Query abstract:
SELECT sleep(N),COUNT(id) FROM first_db.test_tb;

Query sample:
select sleep(4),count(id) from first_db.test_tb;

______________________________________________________________________ 004 ___
Count         : 1  (14.29%)
Time          : 4.000851 s total, 4.000851 s avg, 4.000851 s to 4.000851 s max  (13.32%)
Lock Time (s) : 0 total, 0 avg, 0 to 0 max  (0.00%)
Rows sent     : 1 avg, 1 to 1 max  (14.29%)
Rows examined : 0 avg, 0 to 0 max  (0.00%)
Database      :   QC_hit: No
Users         : 
        root@localhost  : 100.00% (1) of query, 100.00% (7) of all users

Query abstract:
SELECT sleep(N)AS a, N AS b;

Query sample:
select sleep(4)as a, 1 as b;
[root@lxc mysqlsla-2.03]# 

  提示:可以看到msyqlsla把慢查詢日誌更具體的分析了一次,每個語句執行了多少次,總時間,平均時間等等信息;

  3、錯誤日誌,該日誌記錄了mairadbd啟動關閉過程中的輸出信息,mariadbd運行中產生的錯誤信息,事件調度產生的信息,和主從複製架構中,從服務器複製線程啟動時產生的信息;配置錯誤日誌如下

  提示:以上紅框中的內容表示啟動錯誤日誌功能,並保持到/var/log/mariadb/mariadb_error.log;並開啟記錄警告信息到錯誤日誌中;

  重啟服務看看對應文件中是否會記錄mariadb啟動信息?

[root@lxc my.cnf.d]# systemctl restart mariadb
[root@lxc my.cnf.d]# ll /var/log/mariadb/mariadb_error.log
-rw-rw---- 1 mysql mysql 2411 Jun 28 11:35 /var/log/mariadb/mariadb_error.log
[root@lxc my.cnf.d]# cat /var/log/mariadb/mariadb_error.log
2020-06-28 11:35:44 0 [Note] /usr/sbin/mariadbd (initiated by: unknown): Normal shutdown
2020-06-28 11:35:44 0 [Note] Event Scheduler: Purging the queue. 0 events
2020-06-28 11:35:44 0 [Note] InnoDB: FTS optimize thread exiting.
2020-06-28 11:35:44 0 [Note] InnoDB: Starting shutdown...
2020-06-28 11:35:44 0 [Note] InnoDB: Dumping buffer pool(s) to /var/lib/mysql/ib_buffer_pool
2020-06-28 11:35:44 0 [Note] InnoDB: Buffer pool(s) dump completed at 200628 11:35:44
2020-06-28 11:35:45 0 [Note] InnoDB: Shutdown completed; log sequence number 91510; transaction id 181
2020-06-28 11:35:45 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2020-06-28 11:35:45 0 [Note] /usr/sbin/mariadbd: Shutdown complete

2020-06-28 11:35:45 0 [Note] InnoDB: Using Linux native AIO
2020-06-28 11:35:45 0 [Note] InnoDB: Uses event mutexes
2020-06-28 11:35:45 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
2020-06-28 11:35:45 0 [Note] InnoDB: Number of pools: 1
2020-06-28 11:35:45 0 [Note] InnoDB: Using SSE4.2 crc32 instructions
2020-06-28 11:35:45 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
2020-06-28 11:35:45 0 [Note] InnoDB: Completed initialization of buffer pool
2020-06-28 11:35:45 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2020-06-28 11:35:45 0 [Note] InnoDB: 128 rollback segments are active.
2020-06-28 11:35:45 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-06-28 11:35:45 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-06-28 11:35:45 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2020-06-28 11:35:45 0 [Note] InnoDB: 10.5.4 started; log sequence number 91510; transaction id 180
2020-06-28 11:35:45 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2020-06-28 11:35:45 0 [Note] Plugin 'FEEDBACK' is disabled.
2020-06-28 11:35:45 0 [Note] InnoDB: Buffer pool(s) load completed at 200628 11:35:45
2020-06-28 11:35:45 0 [Note] Server socket created on IP: '::'.
2020-06-28 11:35:45 0 [Warning] 'proxies_priv' entry '@% root@lxc' ignored in --skip-name-resolve mode.
2020-06-28 11:35:45 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.5.4-MariaDB-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Server
[root@lxc my.cnf.d]# 

  提示:可以看到我們手動指定的文件是可以正常記錄mariadb啟動過程中產生的日誌信息和警告信息;

  測試:故意把配置文件配置錯誤,重啟服務,看看是否反映到錯誤日誌中?

  提示:紅框中內容是我故意多寫了一個i ,接下來我們重啟服務,看看錯誤日中是否會反饋出來;

  提示:可以看到在錯誤日誌文件中,它告訴我們未知的變量;

  4、二進制日誌:用於記錄引起數據改變或存在引起數據改變的潛在可能性的語句(STATEMENT)或改變后的結果(ROW),也可能是二者混合;這個日誌在主從複製架構中非常重要,主要功能就是記錄增刪改語句,用於“重放”實現從節點和主節點數據相同的目的;配置如下

  提示:以上紅框中的配置表示開啟二進制日誌,並保持到/var/lib/mysql/下,以mysql-bin開頭命名;二進制文件的最大容量是1G;sync_binlog=1表示只要有二進制文件產生就立刻同步到磁盤;

  測試:重啟服務,看看對應文件是否產生?

  提示:可以看到/var/lib/mysql/目錄下有一個mysql-bin.000001的文件產生了;

  連接數據庫,查看二進制文件列表

[root@lxc my.cnf.d]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 4
Server version: 10.5.4-MariaDB-log MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       513 |
+------------------+-----------+
1 row in set (0.001 sec)

MariaDB [(none)]> show binary logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       513 |
+------------------+-----------+
1 row in set (0.000 sec)

MariaDB [(none)]> 

  提示:以上語句都表示查看二進制日誌文件列表;

  查看當前正在使用的二進制日誌文件

MariaDB [(none)]> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      513 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.000 sec)

MariaDB [(none)]> 

  提示:可以看到當前正在使用mysql-bin.000001這個文件,當前位置是328

  查看二進制日誌文件中的事件

MariaDB [first_db]> show binlog events;
+------------------+-----+-------------------+-----------+-------------+-----------------------------------------------------------+
| Log_name         | Pos | Event_type        | Server_id | End_log_pos | Info                                                      |
+------------------+-----+-------------------+-----------+-------------+-----------------------------------------------------------+
| mysql-bin.000001 |   4 | Format_desc       |         3 |         256 | Server ver: 10.5.4-MariaDB-log, Binlog ver: 4             |
| mysql-bin.000001 | 256 | Gtid_list         |         3 |         285 | []                                                        |
| mysql-bin.000001 | 285 | Binlog_checkpoint |         3 |         328 | mysql-bin.000001                                          |
| mysql-bin.000001 | 328 | Gtid              |         3 |         370 | BEGIN GTID 0-3-1                                          |
| mysql-bin.000001 | 370 | Query             |         3 |         482 | use `first_db`; insert into test_tb values(3,"wangwu",22) |
| mysql-bin.000001 | 482 | Xid               |         3 |         513 | COMMIT /* xid=17 */                                       |
+------------------+-----+-------------------+-----------+-------------+-----------------------------------------------------------+
6 rows in set (0.001 sec)

MariaDB [first_db]> 

  提示:以上是在數據庫上用語句查看二進制日誌事件;我們也可以在shell中使用mysqlbinlog命令來查看二進制文件內容;

  使用msyqlbinlog命令查看二進制日誌內容

[root@lxc ~]# mysqlbinlog /var/lib/mysql/mysql-bin.000001 
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#200628 11:58:31 server id 3  end_log_pos 256 CRC32 0x9afc2aa7  Start: binlog v 4, server v 10.5.4-MariaDB-log created 200628 11:58:31 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
J774Xg8DAAAA/AAAAAABAAABAAQAMTAuNS40LU1hcmlhREItbG9nAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAnvvheEzgNAAgAEgAEBAQEEgAA5AAEGggAAAAICAgCAAAACgoKAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEEwQADQgICAoKCgGnKvya
'/*!*/;
# at 256
#200628 11:58:31 server id 3  end_log_pos 285 CRC32 0x516669db  Gtid list []
# at 285
#200628 11:58:31 server id 3  end_log_pos 328 CRC32 0x8395a8cd  Binlog checkpoint mysql-bin.000001
# at 328
#200628 12:13:13 server id 3  end_log_pos 370 CRC32 0xd9b2a8a4  GTID 0-3-1 trans
/*!100101 SET @@session.skip_parallel_replication=0*//*!*/;
/*!100001 SET @@session.gtid_domain_id=0*//*!*/;
/*!100001 SET @@session.server_id=3*//*!*/;
/*!100001 SET @@session.gtid_seq_no=1*//*!*/;
BEGIN
/*!*/;
# at 370
#200628 12:13:13 server id 3  end_log_pos 482 CRC32 0x5737f424  Query   thread_id=5     exec_time=0     error_code=0
use `first_db`/*!*/;
SET TIMESTAMP=1593360793/*!*/;
SET @@session.pseudo_thread_id=5/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1, @@session.check_constraint_checks=1, @@session.sql_if_exists=0/*!*/;
SET @@session.sql_mode=1411383296/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
insert into test_tb values(3,"wangwu",22)
/*!*/;
# at 482
#200628 12:13:13 server id 3  end_log_pos 513 CRC32 0x43126028  Xid = 17
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
[root@lxc ~]# 

  提示:可以看到我們往test_tb表中插入的數據,在二進制文件中有記錄,但是沒有查詢語句;二進制日誌文件是不會記錄查詢語句,它只會記錄對數據有變動的語句;

  用mysqlbinlog工具查看指定位置後端日誌內容

[root@lxc ~]# mysqlbinlog -j 370 /var/lib/mysql/mysql-bin.000001 
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#200628 11:58:31 server id 3  end_log_pos 256 CRC32 0x9afc2aa7  Start: binlog v 4, server v 10.5.4-MariaDB-log created 200628 11:58:31 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
J774Xg8DAAAA/AAAAAABAAABAAQAMTAuNS40LU1hcmlhREItbG9nAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAnvvheEzgNAAgAEgAEBAQEEgAA5AAEGggAAAAICAgCAAAACgoKAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEEwQADQgICAoKCgGnKvya
'/*!*/;
# at 370
#200628 12:13:13 server id 3  end_log_pos 482 CRC32 0x5737f424  Query   thread_id=5     exec_time=0     error_code=0
use `first_db`/*!*/;
SET TIMESTAMP=1593360793/*!*/;
SET @@session.pseudo_thread_id=5/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1, @@session.check_constraint_checks=1, @@session.sql_if_exists=0/*!*/;
SET @@session.sql_mode=1411383296/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
insert into test_tb values(3,"wangwu",22)
/*!*/;
# at 482
#200628 12:13:13 server id 3  end_log_pos 513 CRC32 0x43126028  Xid = 17
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
[root@lxc ~]# 

  用mysqlbinlog查看指定起始位置的日誌信息

[root@lxc ~]# mysqlbinlog --start-position=370 --stop-position=482 /var/lib/mysql/mysql-bin.000001      
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#200628 11:58:31 server id 3  end_log_pos 256 CRC32 0x9afc2aa7  Start: binlog v 4, server v 10.5.4-MariaDB-log created 200628 11:58:31 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
J774Xg8DAAAA/AAAAAABAAABAAQAMTAuNS40LU1hcmlhREItbG9nAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAnvvheEzgNAAgAEgAEBAQEEgAA5AAEGggAAAAICAgCAAAACgoKAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEEwQADQgICAoKCgGnKvya
'/*!*/;
# at 370
#200628 12:13:13 server id 3  end_log_pos 482 CRC32 0x5737f424  Query   thread_id=5     exec_time=0     error_code=0
use `first_db`/*!*/;
SET TIMESTAMP=1593360793/*!*/;
SET @@session.pseudo_thread_id=5/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1, @@session.check_constraint_checks=1, @@session.sql_if_exists=0/*!*/;
SET @@session.sql_mode=1411383296/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
insert into test_tb values(3,"wangwu",22)
/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
[root@lxc ~]# 

  用mysqlbinlog查看指定開始時間以後的日誌

[root@lxc ~]# mysqlbinlog --start-datetime="2020-06-28 12:39:05" /var/lib/mysql/mysql-bin.000001
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#200628 11:58:31 server id 3  end_log_pos 256 CRC32 0x9afc2aa7  Start: binlog v 4, server v 10.5.4-MariaDB-log created 200628 11:58:31 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
J774Xg8DAAAA/AAAAAABAAABAAQAMTAuNS40LU1hcmlhREItbG9nAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAnvvheEzgNAAgAEgAEBAQEEgAA5AAEGggAAAAICAgCAAAACgoKAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEEwQADQgICAoKCgGnKvya
'/*!*/;
# at 513
#200628 12:39:05 server id 3  end_log_pos 555 CRC32 0xf924553d  GTID 0-3-2 trans
/*!100101 SET @@session.skip_parallel_replication=0*//*!*/;
/*!100001 SET @@session.gtid_domain_id=0*//*!*/;
/*!100001 SET @@session.server_id=3*//*!*/;
/*!100001 SET @@session.gtid_seq_no=2*//*!*/;
BEGIN
/*!*/;
# at 555
#200628 12:39:05 server id 3  end_log_pos 668 CRC32 0x496c0f4f  Query   thread_id=6     exec_time=0     error_code=0
use `first_db`/*!*/;
SET TIMESTAMP=1593362345/*!*/;
SET @@session.pseudo_thread_id=6/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1, @@session.check_constraint_checks=1, @@session.sql_if_exists=0/*!*/;
SET @@session.sql_mode=1411383296/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
insert into test_tb values (4,"wukong",99)
/*!*/;
# at 668
#200628 12:39:05 server id 3  end_log_pos 699 CRC32 0xf5032d63  Xid = 27
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
[root@lxc ~]# 

  用mysqlbinlog查看指定時間段的日誌信息

[root@lxc ~]# mysqlbinlog --start-datetime="2020-06-28 12:13:13" --stop-datetime="2020-06-28 12:43:42" /var/lib/mysql/mysql-bin.000001        
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#200628 11:58:31 server id 3  end_log_pos 256 CRC32 0x9afc2aa7  Start: binlog v 4, server v 10.5.4-MariaDB-log created 200628 11:58:31 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
J774Xg8DAAAA/AAAAAABAAABAAQAMTAuNS40LU1hcmlhREItbG9nAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAnvvheEzgNAAgAEgAEBAQEEgAA5AAEGggAAAAICAgCAAAACgoKAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEEwQADQgICAoKCgGnKvya
'/*!*/;
# at 328
#200628 12:13:13 server id 3  end_log_pos 370 CRC32 0xd9b2a8a4  GTID 0-3-1 trans
/*!100101 SET @@session.skip_parallel_replication=0*//*!*/;
/*!100001 SET @@session.gtid_domain_id=0*//*!*/;
/*!100001 SET @@session.server_id=3*//*!*/;
/*!100001 SET @@session.gtid_seq_no=1*//*!*/;
BEGIN
/*!*/;
# at 370
#200628 12:13:13 server id 3  end_log_pos 482 CRC32 0x5737f424  Query   thread_id=5     exec_time=0     error_code=0
use `first_db`/*!*/;
SET TIMESTAMP=1593360793/*!*/;
SET @@session.pseudo_thread_id=5/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1, @@session.check_constraint_checks=1, @@session.sql_if_exists=0/*!*/;
SET @@session.sql_mode=1411383296/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
insert into test_tb values(3,"wangwu",22)
/*!*/;
# at 482
#200628 12:13:13 server id 3  end_log_pos 513 CRC32 0x43126028  Xid = 17
COMMIT/*!*/;
# at 513
#200628 12:39:05 server id 3  end_log_pos 555 CRC32 0xf924553d  GTID 0-3-2 trans
/*!100001 SET @@session.gtid_seq_no=2*//*!*/;
BEGIN
/*!*/;
# at 555
#200628 12:39:05 server id 3  end_log_pos 668 CRC32 0x496c0f4f  Query   thread_id=6     exec_time=0     error_code=0
SET TIMESTAMP=1593362345/*!*/;
insert into test_tb values (4,"wukong",99)
/*!*/;
# at 668
#200628 12:39:05 server id 3  end_log_pos 699 CRC32 0xf5032d63  Xid = 27
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
[root@lxc ~]# 

  提示:根據上面時間或者位置指定範圍后,我們就可以過濾我們需要的信息來做處理;如下,過濾insert語句

[root@lxc ~]# mysqlbinlog --start-datetime="2020-06-28 12:13:13" --stop-datetime="2020-06-28 12:43:42" /var/lib/mysql/mysql-bin.000001|grep insert
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
insert into test_tb values(3,"wangwu",22)
insert into test_tb values (4,"wukong",99)
[root@lxc ~]# 

  提示:可以看到通過過濾關鍵字就可以很快定位到我們日誌中記錄了那些語句,一眼就能清楚知道之前執行過什麼語句;

  5、中繼日誌,該日誌主要是在主從複製架構中記錄從主服務器的二進制日誌文件同步過來的事件信息;開啟中繼日誌配置如下

  提示:以上配置表示開啟中繼日誌並保持到/var/lib/mysql/relay_log中;

  確定配置中繼日誌是否開啟成功,方法一,搭建主從複製,開啟主從複製線程,在對應目錄看是否有對應文件生成,方法二,直接在數據庫里查看reay_log變量的值,如果是我們配置的路基,表示開啟成功,否則失敗

  提示:從上面的截圖可以看到關於中繼日誌參數的配置有以上幾種,max_relay_log_size表示中繼日誌的最大容量;relay_log表示中繼日誌存放路徑和中繼日誌以那個名稱開頭,這個和二進制日誌的配置邏輯差不多;relay_log_basename表示已那個名字作為中繼日誌的基名;relay_log_index表示relay_log.index文件存放地;relay_log_info_file表示relay_log.info 文件名;relay_log_purge表示是否開啟修剪中繼日誌;relay_log_recovery表示是否開啟中繼日誌恢復功能(是否隨mariadb服務啟動而創建一個新的relay_log,將sql線程的位置初始化到新的relay log,並將i/o線程初始化到sql線程位置。)relay_log_space_limit表示是否開啟中繼日誌空間限制;sync_relay_log表示多少次事務同步一次中繼日誌到磁盤;sync_relay_log_info表示多少次事務同步一次relay-log.info;

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

新北清潔公司,居家、辦公、裝潢細清專業服務

項目一再跳票?試試這一招:用Deadline倒逼生產力

我想也許你早就聽說過“Deadline是第一生產力”這句話,哪怕以前沒聽說過,我相信看完本文後,再也不會忘記這句話,甚至時不時還要感慨一句:“Deadline是第一生產力!”。

在日常生活中,Deadline倒逼生產力的例子比比皆是,比如說:

  • 上學時,臨近到要交作業的Deadline了,遊戲都顧不上玩了,急急忙忙趕作業。
  • 工作中,項目發布的Deadline臨近了,大家加班加點,熱火朝天趕着開發功能和修復bug。
  • 生活中,快到了要報稅的Deadline了,每個人都急急忙忙趕在Deadline前把稅給報了。
    不管多拖延的人,快到了Deadline的時候,總能爆發出驚人的生產力。這就是為什麼我們總是說:Deadline 是第一生產力。

與之相反的例子也很多,一些沒有Deadline的事情,總會能拖則拖,直到不能拖為止,或者乾脆不了了之。比如說:

  • 程序員常有一些絕妙的想法,比如寫一個開源項目,做一個App或者網站,結果因為沒有Deadline,結果總是開了個頭,就再沒結果了。
  • 工作中很多項目,雖然有計劃,但是沒有強Deadline,結果需求一改再改,計劃總是在跟着調整延遲,一直不能上線。
  • 比如說我這篇文章,打算寫很久了,但因為沒有Deadline一直拖着,最近終於給自己定了一個Deadline是這周末要寫出來,這才開始動筆。
    這些失敗的例子,歸根結底,一個很重要的原因就是沒有Deadline,導致不能發揮出生產力,或者生產力沒有用在正確的地方。

Deadline為什麼能創造出巨大的生產力?

為什麼Deadline這麼神奇,能創造出巨大的生產力?

無論是個人的事情還是項目,生產力低下,不能按時完成的原因,總結下來不外乎三種:

  1. 想太多
  2. 過於追求完美、關注細節
  3. 不夠專註

想太多

回想一下你做過的事或者項目,是不是會有“想太多”的情況。這並不是說在動手做之前先思考不好,而是有時候,因為停留在想的時間太長,遲遲沒有動手,導致想的太多對於做成一件事反而會成為一種阻礙。

比如說想寫一篇文章,打腹稿打的太久,最後都模糊了當初要寫的觀點,真下筆的時候,很多思考完全用不上;想寫一個程序,設計了太久,不僅花了太多的時間在不必要的設計上,最後留給寫程序的時間就不多了;做一個項目,在需求上想太多,遲遲不能確定,最後留給後面設計和開發的時間很短。

當有了明確的Deadline,想太多的問題就會有明顯的改善,該寫的文章就動手寫起來了,程序差不多時間也就動手編碼起來了,需求也能早點明確下來。

過於追求完美、關注細節

追求完美、關注細節不是壞事,像喬布斯就以關注細節而聞名,但對一個項目來說,有時候過於追求完美、關注細節反而會導致項目失敗。

比如說想打造“完美”的產品,導致產品一改再改,遲遲無法上線;程序設計時考慮各種未來可能的需求,導致設計非常複雜,很難實現。

想象一下,如果你本來想做一個完美的產品、設計一個完美的架構設計,但是有個很嚴格的Deadline,必須要保證在Deadline前交付,那麼你是不是就不會那麼追求完美和細節,而是抓住最核心最主要的功能和設計,先保證能交付。

不夠專註

當一件事沒有明確的deadline時,就很容易被其他事情分心,比如說上上網、玩玩遊戲,只有在deadline臨近時,才能專註在要做的事情上,不再被那些無關緊要的事所分心。

借用時間四象限的理論,有了Deadline,你要做的事情就變成了“重要並且緊急”,否則就會變成“重要不緊急”甚至是“不重要不緊急”,以至於一拖再拖。

結合項目管理金三角來分析

我曾經在《怎樣平衡軟件質量與時間成本範圍的關係?》一文中提到了項目管理金三角的理論,也就是軟件質量和時間成本範圍三者之間是相互制約的關係。

結合前面的分析:

  • “想太多”的問題本質上是在壓縮了你的有效時間和擴大了範圍,導致失控;
  • “過於追求完美、關注細節”的問題本質上是擴大了範圍,導致失控;
  • “不夠專註”則是一些不重要的事情擠壓了你的時間。

而當你的項目有強Deadline的時候,說明金三角的三條邊中,時間這條邊是固定住的,只能少不能多,那你就只能去調整範圍和成本另兩條邊。而成本很多時候也是不能動的,最終結果就是縮小範圍和有效利用時間。

所以說,Deadline之所以能提升生產力,歸根結底,是由於利用Deadline,倒逼着你縮小“範圍”,做當前最重要最有價值的事情;利用Deadline,讓你專註,不浪費時間在不重要的事情上。從而可以把Deadline,變成第一生產力。

如何在項目中應用好“Deadline 是第一生產力”?

既然Deadline是第一生產力,那是不是只要凡事設置一個Deadline,就萬事大吉,自然就可以把事情做好?把項目完成好?

顯然也不是那麼簡單的事情!並不是隨便把一個時間點設成Deadline,就可以馬上激發生產力。

首先你的Deadline是否有一定的強制性?

Deadline之所以能成為Deadline,就是因為它具有一定的強制性,Deadline到了之後沒能完成會有一定後果。比如說你作業沒能按時交,那麼分數就會受影響;項目沒能按時交付,績效就會受影響。

很多優秀的程序員,在公司的項目中能高效的完成任務,相反自己在做Side Project的時候卻各種拖延,難以交付,就是因為無法給自己定一個Deadline,就算定了時間點,到時間沒能完成也不用承擔什麼後果,自然就難以將Deadline變成生產力。

有時候如果自己真的難以執行,可以讓家人朋友幫助監督,或者可以學學亞馬遜的逆向工作法(Working backwards),在打造一個新產品前,不是按傳統的需求、設計、開發、測試和發布流程,而是先寫新聞稿,然後開新聞發布會告訴大眾要打造一個什麼樣的產品,以及什麼時間發布,再去設計開發。這樣在寫新聞稿的時候就想清楚你的產品要交付的最核心的功能是什麼,以及你的Deadline是什麼。

當你把要做的事情和Deadline當作牛逼吹出去了,要想不被人笑話,就要考慮為你吹過的牛逼奮鬥,保證在Deadline之前有所交付了。

然後你的Deadline是否具有可操作性?

成功的Deadline一定都是以科學的計劃為基礎的,否則不切實際的Deadline就會鬧出像“兩個女人5個月生孩子”這樣的笑話。

怎麼樣的Deadline才算具有可操作性呢?

首先Deadline的時間點不宜太遙遠。

當你的Deadline定的太過遙遠,只有在Deadline臨近的時候,才能發揮出作用,但可能已經太遲了。

傳統的瀑布模型開發軟件就是典型的例子。使用瀑布模型開發軟件項目,也會有一個項目發布的Deadline,但是這個Deadline通常在幾個月甚至一年之後,結果通常就是開發過程前松后緊,剛開始不忙,臨到上線時加班加點。

後來針對這種情況,一個改善的方案就是設置里程碑,里程碑本質上就是把一個長的Deadline拆分成幾個短的Deadline,比如說需求分析完成是一個裡程碑、開發完成是一個裡程碑。這樣的藉助一個個裡程碑,讓Deadline貫穿項目始終,持續的激發生產力。

然後Deadline到了必須要有交付。

很多人有追求完美的情結,即使Deadline到了,因為覺得產品不完美而不願意交付,所以寧可將Deadline不斷調整,一直延期,最終導致Deadline形同虛設。

完美是沒有止境的,在你眼裡不完美的東西也許在其他人而言,已經可以滿足需求了。Deadline的一個意義也在於通過Deadline,讓你在有限的時間內必須要有交付,倒逼着你放棄完美清潔,想清楚什麼是你應該交付的最重要的東西。

交付,也不意味之交付一個漏洞百出半成品給大眾,而是通過縮小範圍,交付一個完成的最小可用的版本。

另外軟件的交付也分兩種,一種是內部的可供測試的版本,一種是外部的正式發布的版本。比如像Chrome (Chrome Release Cycle) 的開發,會交付不同的版本給不同的用戶,比如每天交付的開發版本,但是只是內部人員使用。還有Beta版本,只是給一部分測試用戶,最終交付給用戶的,已經是一個經過反覆測試完善的穩定版本了。

再有就是Deadline到了必須要有完整的交付。

前面說的里程碑的方案可以很好的解決Deadline太長的問題,但也有問題,那就是在里程碑的Deadline到了的時候,雖然有交付,但交付的產物並不是十分清晰。比如說需求設計里程碑到了,只是一些模糊不清的需求文檔。結果就只能是基於這種模糊不清的需求文檔,邊開發邊修改,導致後續因為需求修改而產生很多不必要的浪費。

所以Deadline到了的時候,不能交付一個半成品或者模稜兩可的結果,而必須是一個完整的結果,否則這樣的Deadline,生產力是大打折扣的。

最後再給你看一個在軟件項目中,應用好“Deadline 是第一生產力”的經典例子。

敏捷開發的時間盒子

可能你已經知道敏捷開發,每天都在用敏捷開發管理軟件項目,也許你還不知道什麼是敏捷開發,在這裏我並展開多講,只講其中的時間盒子(Time Boxing)概念。

在敏捷開發中,一個軟件項目的開發,是採用的迭代開發的模式,並不是一次交付完整的產品,而是通過一個個的迭代,每次交付一部分可以運行的產品,最終交付完整的交付。

每一個迭代都是一個固定時長的時間盒子,時間通常不會太長,1-4周左右,但每個迭代結束,都要求要交付可執行的產品。

這個時間盒子本質上就是一個個的Deadline,每次時間盒子的結束點就是一個Deadline。那這樣做有什麼意義呢?

首先,每次迭代前,你要計劃好:當前迭代要做哪些事情?deadline到了的時候能交付什麼?

因為有Deadline的壓力,每次迭代時間是有限的,而你又必須要交付,那麼就會倒逼着你在計劃的時候,會優先選擇當前優先級最高的任務,專註在重要的事情上。

然後,在迭代的過程中,你要盡可能的提升效率,保證在Deadline之前能交付。

如果你想要在Deadline之前盡可能的交付更多的東西,那就會倒逼着你去提升效率。

所以你在設計的時候,只會做剛剛好的設計;所以你會寫自動化測試,從而提升測試的效率;所以你會採用像CI/CD這樣的工具,幫助你將很多工作自動化,提升效率。

最後,在迭代完成的時候,Deadline到了,你一定要有完整的交付。

前面說到了:在Deadline到了后,有交付、有完整的交付非常重要。這也會倒逼着你去思考如果提升發布版本的質量。

要保證你有一個穩定的可交付的版本,在敏捷開發中有很多很好的實踐:

  • 首先是要有充分的測試,完全人工測試顯然是跟不上快速迭代的節奏的,所以要有大量自動化測試來輔助,保證可以同自動化的方式覆蓋各種測試用例;
  • 然後需求不能頻繁變更,這就意味着在一個迭代中,通常不會接受需求的變更;
  • 還有就是採用分支的方式來開發新功能或開發bug,只有代碼審查和測試通過才能合併,這樣你就有一個穩定的隨時可以發布的分支。

敏捷開發的時間盒子,就是一個藉助Deadline來提升生產力的經典應用。藉助Deadline,倒逼着你專註於重要的事,倒逼着你提升效率,倒逼着你按時交付可執行的內容。

即使你不是採用的敏捷開發的時間盒子來開發項目,其中很多藉助Deadline激發生產力的思想和方法,都可以借鑒到你的項目開發甚至是日常生活中。

Deadline就是第一生產力,希望你能理解和應用好Deadline,幫助你提升生產力。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

讀懂操作系統之虛擬內存頁表(五)

前言

在一個擁有32位的地址空間,4KB的頁面(212),並且每個PTE為4個字節,那麼頁表大小為4MB(4 * 232 / 212),但若為64位地址空間,4KB的頁面(212)且每個PTE為4字節,那麼頁表大小為16TB(4 * 264 / 212),由於頁表常駐內存,佔用內存會很大,所以必須對頁表存儲結構進行優化,這就是我們本文所要講解的內容,常見的頁表數據結構為多級頁表(兩級、三級等)、倒置頁表、哈希頁表,我們來一一進行分析。

多級頁表

首先我們講講2級頁表,然後通過2級頁表延伸到多級頁表,現假設有16KB(214)的地址空間,並且每頁大小為64(26)字節,每個PTE為4字節,那麼說明頁表為1KB(4 * 214 / 26),若我們有64字節的頁,那麼將1KB可劃分為16個64字節的頁面,每個頁面可容納16個PTE,前面我們講解到虛擬地址劃分為虛擬頁號(VPN)和虛擬頁偏移量(VPO),但虛擬頁偏移量已經固定,那麼我們只能從VPN下手將其作為索引用於索引頁表目錄,那麼我們該如何利用VPN來構建各個部分的索引呢?我們首先需要構建頁表目錄,根據上述假設,總共有256個PTE分佈在16頁上,頁目錄在頁表的每頁上需要一個條目,因此它具有16個條目, 最終我們需要VPN中的4位索引到目錄中,這也就意味着我們需要使用VPN的前4位,如下所示:

我們從VPN提取出了頁表目錄索引(PDI),那麼我們就可以計算出每個PDE(Page Directory Entry)的地址值:

PDEAddress = PageDirectoryBase + (PDIndex * sizeof(PDE))。

有了頁目錄索引后我們還需進行進一步翻譯,如果頁目錄索引為空,很顯然第2級頁表根本就不會存在,如此一來則達到了減少內存的要求,因為只有第一級頁表才會存在於主存中,虛擬內存系統會根據需要調入或調出第2級頁表,這就減少了主存的壓力,只有經常使用的2級頁表才需要緩存在主存中。如果第1級頁表即頁目錄索引有值,那麼還需根據頁目錄指向的頁表頁面去獲取PTE,要找到此PTE,我們還需要使用VPN的其餘索引映射到頁表的部分。

 通過使用如上頁表索引來索引頁表本身,從而找到PTE地址,也就找到了PFN(物理頁幀號)

PTEAddress = (PDE.PFN << SHIFT) + (PTIndex * sizeof(PTE))

從頁面目錄獲得的頁面幀號(PFN)必須先左移到適當位置,然後再與頁表索引組合以形成PTE的地址。假設如下為二級頁表扁平化的片段

 

如上第1片段為頁表目錄,在其中存在索引到第2級頁表的索引,還包括有效位,第2和第3片段分別為第1級頁表目錄索引對應的頁表(其中包含保護位,可讀?可寫?等等),假設CPU產生虛擬地址(0xFE16 = 25410 = 111111102),由於我們假設虛擬地址空間為14位,所以將轉換后的2進制不足用0填充即11111110000000,同時我們將地址空間進行虛擬頁號(VPN)和虛擬頁偏移量(VPO)劃分,然後對VPN劃分為頁表目錄和頁表索引,我們通過紅色、綠色、藍色由左至右分別代表頁表目錄索引、頁表索引、虛擬頁偏移量即1111 1110  000000,經過如此劃分后,此時前4位(11112 = 1510)為頁表目錄索引,對應上述頁表目錄最後一行,此時頁表目錄幀號為101對應第2個頁表片段,然後根據接下來的4位(11102 = 1410),最終得到索引為倒數第2行,即最終物理頁幀號為55。最後我們通過如下物理地址計算公式

 PhysAddress = (PTE.PFN << SHIFT) + offset

 即最終物理地址為:55 * 2+ 000000 = 352010 = 0XDC016。假設為32位地址空間,那麼頁目錄索引、頁表索引、虛擬頁偏移量分別對應為10、10、12位,那麼對應的2級頁表將是如下形式

簡而言之,對於32位地址空間,會將VPN中的前10位(位22..31)用於索引頁表目錄,緊接下來的10位(12 ..21)用於索引所選的頁表。換言之,對於2級頁表結構其本質是:VPN的前m位為頁表目錄索引,而接下來的n位為頁表索引,同時需要注意的是2級頁表其地址是從上往下增加。根據上述將32位地址空間中的頁表以2級結構劃分,此時第1級頁表大小為(1024 * 4) = 4KB,而第2級頁表為(1024 * 1024 * 4) = 4MB,所以頁表大小將為4KB + 4MB,這麼算來比直接使用單級頁表結構為4MB情況更糟糕了不是嗎,其實情況並不是這樣,如上算出的4KB + 4MB為最極限的情況,上述已經講解過只有經常需要用到的2級頁表才緩存在主存中,所以實際情況下頁表大小會小於4MB。

 

早期操作系統採用的是2級頁表結構,但是現如今大多數操作系統採用多級頁表結構,就像樹一樣,不過是深度或層次更深了而已。假設我們有一個30位虛擬地址空間和一個較小的頁面(512字節),因此,我們的虛擬地址具有21位的虛擬頁號和9位的偏移量,使頁表的每個部分都適合單個頁面是構建多級頁表的目標,但到目前為止,我們僅考慮了頁表本身,如果頁表目錄很大,那該怎麼辦?為了確定一個多級頁表中需要多少級才能使頁表的所有部分用一個頁面容納,我們首先確定一個頁面中可以容納多少個PTE。我們假設給定的頁面大小為512字節,並假設PTE大小為4字節,我們知道在單個頁面上可容納128個PTE。當我們索引到頁表的頁面時,可以得出結論,我們需要使用VPN的最低有效7位(log2128)作為索引

通過確定單頁面需要容納128個PTE,那麼將佔據地址空間7位,那麼還剩下14位地址空間,如果將剩下的214作為頁表目錄, 那麼將橫跨128頁而不再是1頁,那麼對於構建多級頁表的目標將無法實現,為了解決這個問題,我們需要將14位進行再次劃分,將頁表目錄進行設置為多頁,頁表目錄位於上方從而指向另一頁表目錄,因此我們可以進行如下劃分

現在,在索引上層頁表目錄時,我們使用虛擬地址的最高位(圖中PD Index:0),該索引可用於從頂級頁表目錄中獲取頁表目錄的條目,如果有效,則對來自自頂層PDE和VPN的下一部分(PD Index:1)的物理幀號組合來查詢頁表目錄的第二層,最後,如果有效,則為PTE地址通過將頁表索引與第二級PDE中的地址結合使用,可以形成一個地址。 當然這個過程需要做很多工作,所有這些都是為了在多級表中查找物理頁幀號。最終多級頁表結構如下這般

上述我們講過若為64位地址空間,4KB的頁面(212)且每個PTE為4字節,在單級頁表情況下,那麼頁表大小為16TB(4 * 264 / 212)= 16TB,若我們劃分為3級,如下:

 

那麼對於上述外部頁即頁目錄索引將需要佔內存4 * 232 = 16GB,所以我們仍需繼續劃分層級,但是每個層級都有一個額外的間接方式,因此會產生額外的開銷。比如64位地址空間在4KB頁面上將使用大地址空間,所以多級頁表成為具有小頁的大地址空間的內存消耗。 

哈希頁表

處理大於32位地址空間常用的方法是使用哈希頁表(使用稀疏的地址空間),採用虛擬頁碼作為哈希值,對於每一個PTE使用鏈表結構存儲從而解決衝突或碰撞,每個元素由三個字段組成:虛擬頁碼、映射的頁幀、指向鏈表內下一個元素的指針。通過哈希算法將虛擬頁碼映射到哈希頁表,然後將虛擬頁碼與鏈表第一個元素的第一個字段進行比較,若匹配則將第二個字段用來形成物理地址,否則遍歷鏈表查找對應匹配項。哈希頁表如下圖所示

雖然通過哈希頁表查找很快,同時採用如上划重點標記的鏈表數據結構解決衝突問題,雖說消除了條目在內存中連續的需求,但是仍然以更高的內存開銷進行存儲即消耗更多內存,特別是如果頁表是完整的,並且具有有效/無效位以使未使用的條目無效,那麼哈希頁表不再那麼適用,此時我們採用其他方案,如下倒置頁表。

倒置頁表

通過前面內容學習我們知道對於每個進程都有一個關聯的頁表,該進程中的每一個虛擬頁都在頁表中對應一項,不管是否有效,進程通過虛擬地址引用頁,操作系統通過計算虛擬地址在頁表中的位置即PTE,但這種方式有明顯的缺點,如上我們也敘述過,每個頁表可能包含數以百萬計的條目,如此一來,頁表將佔用大量的物理內存以跟蹤其他物理內存是如何使用的,為解決這個問題,我們可以使用倒置頁表(inverted page table),對於每個真正的內存頁,倒置頁表才有一個條目,每個條目包含保存在真正內存位置上的頁的虛擬地址,以及擁有該頁進程的信息,因此,整個系統中所有進程將只有一個頁表,並且每個物理內存的頁只有一個相應的條目,換言之,與知道每個進程的虛擬頁在哪裡相反,現在我們知道擁有哪個物理頁的進程與它對應的虛擬頁。IBM是最早採用倒置頁表的公司,從IBM System 38、RS/6000、到現代的IBM Power CPU。對於IBM  RT,系統的虛擬地址包含三部分:進程Id、頁碼、頁偏移量,每個倒置頁表條目包含兩部分:進程Id、頁碼,這裏的進程Id作為地址空間的標識符,當發生內存引用時,由進程Id和頁碼組成的虛擬地址被提交到內存子系統,然後搜索倒置頁表來尋址匹配,如果找到匹配條目,則生成物理地址,如果未找到匹配條目則為非法地址訪問。 倒置頁表結構如下:

雖然倒置頁表減少了存儲每個頁表所需的內存空間,但是它增加了由於引用頁而查找頁表所需要的時間,由於倒置頁表是按照物理地址排序,而查找則是根據虛擬地址,因此查找匹配可能需要搜索整個表,這種搜索需要耗費很長時間,為解決這個問題,可以使用一個哈希表結構,從而將搜索限制在一個或最多數個頁表條目,當然,每訪問哈希表就增加了一次內存引用,因此每次虛擬地址的引用至少需要兩個內存讀,一個用於哈希表條目,另一個用於頁表條目即PTE,同時結合前面所學,在搜索哈希表之前,肯定先搜索TLB,這樣可大大提高性能。對於倒置頁表還會帶來一個問題,那就是實現共享內存,共享內存需要將多個虛擬地址映射到同一物理地址,很顯然,這種標準的方式無法應用於倒置頁表,因為每一個物理頁只有一個虛擬頁條目,一個物理頁不可能有兩個或多個共享的虛擬地址,所以為解決這個問題,只能允許頁表包含一個虛擬地址到共享物理地址的映射,這也就意味着,對於未映射的虛擬地址的引用勢必會導致頁錯誤。

總結

本節我們非常詳細的討論了多級頁表結構、對於哈希頁表和倒置頁表數據結構通過看圖理解起來非常簡單,從本節內容我們可總結出:對應頁表結構可以擁有良好的時間複雜度或空間複雜度,但不能同時兼得。到此關於虛擬內存重要內容基本上都已囊括,若有遺漏,後續我會繼續進行補充。接下來我們將進入內存管理分頁和分段的學習,講完之後,會陸續進入到程序的執行、進程、死鎖、併發等,相信大家會比較感興趣,感謝您的閱讀,我們下節再見。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

南投搬家前需注意的眉眉角角,別等搬了再說!

新北清潔公司,居家、辦公、裝潢細清專業服務

氣候峰會前歐亞示威者上街 籲當局對抗暖化

摘錄自2019年11月30日中央通訊社德國報導

全球有成千上萬示威者今天走上街頭,歐洲和亞洲占多數,呼籲當局採取行動對抗全球暖化,期望在聯合國(UN)氣候峰會展開的數日前,向全球領導者施壓。

抗議民眾舉著看板寫著「一個地球,一場抗爭」和「海平面在湧升,我們也湧入街頭」。數以千計的群眾聚集在柏林布蘭登堡大門(Brandenburg)參與最新一場「週五為未來而戰」(Fridays for Future)抗議行動,受16歲瑞典環保少女童貝里(Greta Thunberg)先前發起的同名運動啟發。

「週五為未來而戰」運動表示,德國各地超過500座城市,總共有約63萬人上街示威。德國警方表示,光是漢堡就聚集3萬人左右,大多是年輕人,而慕尼黑則集結1萬7000人,他們為了平均地表溫度逐漸上發出警告。

童貝里正搭乘帆船橫渡大西洋,並在推特上傳她舉著寫有「為氣候罷課」標語看板的圖片。這次示威浪潮席捲全歐洲,不過規模仍小於9月「氣候大罷課」的規模。當時籌辦方表示,全球各大城市約400萬人佔據街頭。

為期12天的聯合國氣候變化綱要公約第25次締約方會議(COP25)將於下周展開,目標是鼓勵各國政府減少溫室氣體排放和對抗氣候變遷。這次COP25主辦城市馬德里今天有約1700名示威人士參與。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

新北清潔公司,居家、辦公、裝潢細清專業服務

亞馬遜經濟開發引衝突 NGO不畏強權抗爭多年

摘錄自2019年11月30日中央通訊社巴西報導

環境保護與經濟發展孰輕孰重一直是受到矚目的議題。巴西亞馬遜雨林主要觀光目的地之一Alter do Chao聚落一直受到開發商青睞,當地NGO不畏強權,守護土地,抗爭多年。

巴西北部巴拉州刑警3天前拘捕Alter do Chao社區消防隊4名志工消防員,指控他們在亞馬遜雨林故意製造火災,以獲取國際金援,引起當地社運人士、原住民和環保團體抗議。

在近百個非政府組織(NGO)聯合施壓下,巴西法院昨天(29日)傍晚下令釋放這4名協助撲滅該地區森林火災的非政府組織Alter do Chao社區消防隊成員,但當地與非政府組織的緊張關係已經持續幾10年。

桑塔林觀光局指出,2018年約19萬名遊客造訪Alter do Chao。該地區的旅遊熱潮使村莊周圍地區,房地產開發商具有強烈的開發興趣。一方面,有強大的地方家族勢力和企業家主張在以清澈的河水和白色的沙灘而聞名的塔巴鳩斯(Tapajos)河沿岸建造大型酒店和度假村。另一方面,社運人士、例如與被逮捕的Alter do Chao社區消防隊有聯繫的環保團體,則主張對環境衝擊較小的旅遊業,以保留該區域的特點,並防止傳統社區被驅逐趕離。

巴拉聯邦大學(Ufpa)社會學家托瑞斯(Mauricio Torres)指出,Alter do Chao的爭議邏輯不同於亞馬遜其他區域,當地的旅遊文化、環境保護與經濟開發衝突,才是促成逮捕志工消防員的真實背景。

托瑞斯說,這是屬於一個一直在擴大發展的城市的衝突,有傳統社區面臨被驅逐趕離的壓力,但幕後推手不是木材商或農牧場,而是聚焦於旅遊業的房地產投機與開發。

有論點指出,巴拉州刑警對志工人員進行預防性拘留,指控他們自行引發火災,之後加以撲滅,以獲取國際機構的金援。但一名不願具名、害怕遭到報復的聯邦公務員告訴巴西媒體,社運人士、大學生和原住民強烈反對,致使提案沒有取得進展,所以在當地活動的環保團體都相信逮捕志工消防員的行動含政治動機。巴拉州長巴爾巴柳(Helder Barbalho)昨天已宣布撤換負責此案的警長,並質疑行動的合法性。

聯邦檢察廳自2015年以來進行的調查指出,非法佔領土地和房地產投機,是導致Alter do Chao環境退化的因素,「由於該地區是巴西最著名的度假勝地之一,成為旅遊和房地產業的爭相競奪的目標,且經常受到公共土地入侵者的壓力。」

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

控制暖化不超過2°C 燃煤電廠需大規模改建更新 | 解讀《 2019年世界能源展望》報告1/3

環境資訊中心外電;姜唯 翻譯;林大利 審校;稿源:Carbon Brief

國際能源署(IEA)13日發表報告。報告中指出,全球能源系統正在進行「深層更新」,但儘管如此,除非積極度再提升,否則全球的二氧化碳排放量還是會繼續增長數十年。

今年810頁版本的特點在於「承諾政策情境(Stated Policies Scenario, STEPS)」(以前稱為「新政策情境」),反映政府已經說出口的政策的效果。風能和太陽能的激增將使再生能源滿足全球能源需求的大部分成長。但是煤炭的平穩發展,加上對石油和天然氣的需求不斷增加,全球排放量在到2040年的展望期內將繼續上升。

相對地,報告的「永續發展情境(Sustainable Development Scenario, SDS)」描繪出有50%機率將升溫限制在1.65°C內所需的條件,IEA表示這是「完全符合巴黎協定」的情況。

報告說,SDS需要投資「大量重新分配」,從化石燃料轉向效率和再生能源、淘汰全球約一半的燃煤電廠,以及全球經濟的其他變化。

IEA今年還探討了將升溫限制在工業化前1.5°C內(即巴黎協定的理想目標)所需條件,不過沒有建立詳細模型。

未來情境

《世界能源展望》(WEO)是這個主題的年度出版物中審查最嚴格的報告之一。長達數百頁的分析以世界各國政府的數千個資料庫和IEA的世界能源模型為基礎。

IEA表示報告沒有對前景預測。相反地,它以二氧化碳排放量和其他資料形式呈現了特定能源選擇的後果。該報告說明道:

「《世界能源展望》的目的不是提供一個關於2030年或2040年世界能源將在何處的觀點。這將取決於未來的各種重大選擇。 WEO-2019的目的是,提供決策者制訂新政策、考慮新投資或以其他方式塑造能源未來時所需的資訊。透過探索各種可能的未來、實現的方式、不同選擇的後果以及一些關鍵的不確定性來做到這一點。」

引言中介紹了三種可能的「前景」,在報告發表前,部落格文章「了解WEO情境」也提前對此做了說明。

展望報告的中心觀點是「STEPS」,它的目的是「在不預期未來有所改變的情況下,讓政策制定者好好審視自己的計畫和積極度會有何表現」,包括政府做出的巴黎氣候承諾。不過,IEA並不認為所有政策目標都會實現:

「積極度不會自動被納入情境中:徹底落實不是理所當然的,因此政策落實的前景和時機是以我們對相關監管、市場、基礎建設和財務限制的評估為基礎。」

承諾政策包括零排放淨目標,如英國的目標。 IEA表示,已商定或討論中的類似目標(包括歐盟)涵蓋了全球排放量的12%。就解決全球排放而言,這些目標很重要,但不是決定性的。IEA表示,為實現零排放目標而開發的技術和方法可能會產生更大的連鎖反應,這可能有助於其他國家減少排放。

WEO的第二個未來情境是「永續發展情境(SDS)」。這個情境從能源獲取、空氣污染和碳排放方面的永續發展目標開始,探討達到目標所需的條件。

最後,在「當前政策情境(Current Policies Scenario, CPS)」中,政府放棄其承諾目標和意圖,能源系統僅以已經制定好的政策和法律為指導。

今年的報告文字、圖表和數據將繼續提到CPS,只是重要性較低,「當前政策情境」這個詞在810頁中僅使用了102次,遠少於STEPS的793次和SDS的535次。報告也說明,CPS就是不採取行動的後果,可看出STEPS情境所需的額外努力。

(2010年《世界經濟展望》 中,CPS被提及了340次,而當時的中心觀點NPS出現981次,「450種情境」出現745次。)

需求上升

IEA表示,根據全球已承諾的計畫和政策,到2040年,全球能源需求將繼續每年增長1%,相當於中國目前的總需求量。

根據國際貨幣基金組織(IMF)的預測,人口增加(根據聯合國的「中等」預測,2040年將達到90億人口)和經濟持續擴大(全球GDP每年增加3.4%)推動了這個成長。

IEA表示,由於產業轉向低能耗,能源效率的提高和「飽和效應」(如汽車需求封頂),2019年能源需求的成長率大約是2000年以來平均2%的一半。

如下圖中的紅線所示,STEPS中再生能源將滿足約49%的需求增長。天然氣的使用也預期將迅速增加(藍色),超過煤炭成為僅次於石油的第二大能源,並滿足總體需求增長的三分之一。

1990年至2040年全球各類型能源需求量,單位是數百萬噸石油當量。未來需求預測以STEPS為基礎。其他再生能源包括太陽能、風能、地熱能和海洋能。資料來源:國際能源署《 2019年世界能源展望》。Carbon Brief使用Highcharts繪製圖表。

與天然氣和再生能源的快速發展相比,IEA STEPS情境預測煤炭使用量將達到平穩,然後從今日的水平略降(上方黑線)。這呼應去年的分析,即全球煤炭需求在2014年達到頂峰。

IEA現在還建議,由於汽車燃油效率的提高和電動汽車(EV)的增加,到2030年(橙色線)石油需求將開始趨於穩定,這將使汽車的石油需求在2020年代末期達到峰值。報告說,由於電動汽車成本下降,傳統汽車的未來將是值得深思的問題。

IEA表示,貨運、航運、航空和化學產品的石油需求「持續增長」,SUV因日益普及,成為另一個潛在的需求支撐因素。(值得注意的是,阿拉伯國家石油公司的股票銷售文件也顯示,全球石油需求將從2035年左右開始趨於穩定。)

根據IEA STEPS,到2040年,全球能源需求增長的三分之二來自亞太地區。印度成為世界上人口最多的國家,其能源需求成長一倍,成為全球需求成長的最大貢獻者,佔成長總量的四分之一以上。

在這一總數中,STEPS預測亞洲國家對煤炭的需求增加抵消了美國和歐洲的大幅減少。IEA說:

「煤炭需求來自大多數亞洲發展中國家:在煤基礎設施方面的新投資決策已顯著放緩,但是現有的煤電廠和用煤工廠還是很多……為煤炭提供了可觀的發展動力。」

比例變動

STEPS之下,到2040年,再生能源的興起體現了IEA所形容的「深層更新」,但同時也指出了全球能源系統「變動緩慢」的特性,如煤炭長期的需求高原。

需求成長的比例變化顯示在下面圖表中,煤炭、石油和天然氣(藍色色塊)滿足了能源史上的大部分成長(最左欄)。

儘管STEPS之下,再生能源能滿足2040年需求成長一半,而且成長速度因為經濟因素和能源效率變化而放慢(中間欄),但它仍然遠遠沒有限制全球碳排放量(參閱下文)。

如果要阻止全球氣溫上升,需要有更具決定性的變化,如實現IEA SDS(最右欄)。

全球能源需求年均變化量,以百萬噸石油當量為單位。左:歷史變化。中:IEA STEPS。右:IEA SDS。資料來源:國際能源署《 2019年世界能源展望》 。Carbon Brief使用Highcharts繪製。

在STEPS之下可見再生能源所能滿足的需求成長越來越多,化石燃料在全球能源用量的比例將從2018年的81%下降到2040年的74%,SDS之下則下降到58%。

從STEPS到SDS的需要大規模的變革,其中大多數已經在決策者的議程中很久了。報告解釋:

「2018年化石燃料消費補貼的全球價值,幾乎是再生能源和電動汽車補貼以及全球碳定價計畫收入總和的兩倍。這種不平衡使排放儘早達到峰值的任務變得十分複雜。」

SDS之下,2030年代無碳捕集的化石燃料投資將減少至2014年到2018年平均的一半,再生能源、電網和核能方面的投資將翻倍,而在能源效率上的支出將翻兩倍。

IEA表示,這反映了一個事實,即能源效率是解決排放的最重要因素,這表示SDS下2040年的總體需求會略低於今日的水平。

IEA說「提高能源效率很有機會讓全世界實現永續能源目標」,它召集了「全球能源效率緊急行動委員會」來促成進展。

某種程度上這是對數據的回應,數據顯示效率的改善正在放緩,2018年的效率成長率是2010年以來最低的,這「疲軟的氣力」直得「深切關注」。IEA表示「新能源效率政策和加強現有措施的努力相對缺乏」。

較低的需求會帶來連鎖反應,特別是加上再生能源的快速成長。值得注意的是,在SDS之下,對煤炭、石油和天然氣的需求逐漸下降,而煤炭減幅特別大(上方最右欄中的灰色部分)。

在這個總數中,IEA說,電業的煤炭用量受影響最大。到2040年,超過一半的當前燃煤電廠將退役,規模大於全中國目前的容量。

有半數的退役發生在壽命結束之前,如果將升溫保持在2°C以下,那麼投資於全球現有煤電廠的10億美元中,有部分將面臨風險。歐洲222GW燃煤中有約98%、美國276GW中約88%將關閉。

IEA說,在SDS之下,剩餘的燃煤電廠大部分必須「改建或翻新」。他們得在需求高峰和再生能源產出低谷期間運作有限的時間,不然就得大量投資碳捕集與封存(CCS)技術來減排。

今年的展望報告包含了對煤炭開採過程中釋放的甲烷的新分析。分析結果說明,與航空和航運業相比,煤炭開採的暖化效應更大。(1/3,)

‘Profound shifts’ underway in energy system, says IEA World Energy Outlook (1/3) by Simon Evans

The world’s CO2 emissions are set to continue rising for decades unless there is greater ambition on climate change, despite the “profound shifts” already underway in the global energy system.

That is one of the key messages from the International Energy Agency’s (IEA) , published today. This year’s 810-page edition is notable for its renamed central “Stated Policies Scenario” (STEPS), formerly known as the “New Policies Scenario”.

In this scenario, which aims to mirror the outcome of policies already set out by governments, a surge in wind and solar power would see renewable sources of energy meeting the majority of increases in global energy demand. But a plateau for coal, along with rising demand for oil and gas, would mean global emissions continue to rise throughout the outlook period to 2040.

In contrast, the report’s “Sustainable Development Scenario” (SDS) sets out what would be required to give a 50% chance of limiting warming to 1.65C, which the IEA describes as “fully in line with the Paris Agreement”.

It says the SDS would require a “significant reallocation” of investment away from fossil fuels towards efficiency and renewables, as well as the retirement of around half the world’s fleet of coal-fired power stations and other changes across the global economy.

The IEA has this year also explored, but not modelled in detail, what it would take to limit warming to no more than 1.5C above pre-industrial temperatures, the aspirational goal of the Paris Agreement.

Future scenarios

The World Energy Outlook (WEO) is one of the most heavily scrutinised documents in the annual calendar of publications on the topic. Its hundreds of pages of analysis are based on thousands of datapoints, drawn from governments around the world, as well as the IEA’s .

The IEA says that it does not make forecasts in its outlook. Instead, it presents the consequences of societal energy “choices” in terms of CO2 emissions and other outcomes. The report explains:

“The World Energy Outlook does not aim to provide a view on where the energy world will be in 2030 or 2040. This will depend on hugely important choices that lie ahead. What the WEO-2019 does aim to do is to inform decision-makers as they design new policies or consider new investments or shape our energy future in other ways. It does so by exploring various possible futures, the ways that they come about, the consequences of different choices and some of the key uncertainties.”

The outlook spans three alternative “futures”, set out in the introduction and described in a , published ahead of the report’s release, on “understanding the WEO scenarios”.

The outlook’s central scenario is STEPS, which has “the intention to ‘hold up a mirror’ to the plans and ambitions announced by policymakers without trying to anticipate how these plans might change in future”. This includes the made by governments. The IEA does not assume that all policy goals will be met, however:

“[A]mbitions are not automatically incorporated into the scenario: full implementation cannot be taken for granted, so the prospects and timing for their realisation are based upon our assessment of the relevant regulatory, market, infrastructure and financial constraints.”

Stated policies include some net-zero emissions goals, such as . Similar goals agreed or under discussion, including in the EU, cover 12% of global emissions, the IEA says. This makes the targets significant, but not decisive, in terms of tackling the global emissions. But the IEA says there could be larger knock-on effects due to the technologies and approaches developed to meet net-zero targets, which could help others to also cut emissions.

The second WEO future is the “Sustainable Development Scenario” or SDS. This is a different type of scenario that starts from on energy access, air pollution and CO2 emissions before working backwards to show what would be needed to reach them.

Finally, the “Current Policies Scenario” (CPS) would see governments renege on their stated goals and intentions, with the energy system guided only by policies and laws that are already in place.

This year’s outlook continues to feature the CPS in its text, charts and data. But it is afforded lower priority, with the phrase “current policies scenario” used 102 times over 810 pages – far less often than the 793 mentions of the STEPS or the 535 for the SDS. The outlook says the CPS highlights the consequences of inaction and the level of effort required to meet even the STEPS pathway.

(For comparison, the CPS is mentioned 340 times in the , against 981 uses of the then-central NPS and 745 mentions of the “450 scenario”.)

Rising demand

On the basis of stated plans and policies around the world, the IEA says that global energy needs will continue to rise by 1% per year until 2040, adding demand equivalent to China’s current total.

This growth is driven by a rising population – based on the UN’s to reach 9 billion people by 2040 – and an expanding economy, with global GDP increasing by 3.4% a year, per projections.

The rate of energy demand growth is around half the average rate of 2% seen since 2000, the IEA says, due to shifts towards less energy-intensive industries, energy efficiency gains and “saturation effects” – for example, where demand for cars reaches a peak.

Some 49% of demand growth would be met by renewables in the STEPS, as shown with the red line in the chart, below. Gas use is also expected to rise rapidly (blue), overtaking coal to become the second-largest source of energy after oil and meeting a third of the rise in overall demand.

Global primary energy demand by fuel, millions of tonnes of oil equivalent, between 1990 and 2040. Future demand is based on the STEPS. Other renewables includes solar, wind, geothermal and marine. Source: IEA . Chart by Carbon Brief using .

In contrast to the rapid gains for gas and renewables, the IEA STEPS sees coal use plateau and then decline slightly from today’s levels (black line above). This confirms last year’s analysis that global coal demand peaked in 2014.

The IEA now also suggests that oil demand will start to level off by the 2030s (orange line) as a result of vehicle fuel-efficiency gains and the rise of electric vehicles (EVs), which see passenger car oil demand peak in the “late 2020s”. There are “profound questions” over the future of conventional cars, it says, given falling costs for EVs.

Oil demand for freight, shipping, aviation and chemicals “continues to grow”, the IEA says, with the growing popularity of SUVs another potential factor propping up demand. (Notably, documentation for the Saudi Aramco share sale also has global oil demand levelling off from around 2035.)

The global rise of SUVs is challenging efforts to reduce emissions.

If the appetite for heavier & bigger cars continues to grow at a similar pace to the past decade, this would add nearly 2m barrels a day in global oil demand by 2040.

4/

— Fatih Birol (@IEABirol)

Some two-thirds of the increase in global energy demand to 2040 comes from the Asia Pacific region, under the IEA STEPS. India becomes the country and its energy demand doubles, making it the single largest contributor to global growth and accounting for more than a quarter of the total increase.

Within this total, the STEPS sees rising offset large declines in the US and Europe. The IEA says:

“Coal is the incumbent in most developing Asian countries: new investment decisions in coal-using infrastructure have slowed sharply, but the large stock of existing coal-using power plants and factories…provides coal with considerable staying power in the STEPS.”

Shifting shares

The rise of renewables anticipated under the STEPS to 2040 is demonstrative of the “profound shifts” described by the IEA, yet it also points to the “slow moving” nature of the global energy system, as exemplified by the long, high plateau in demand for coal.

These shifting shares of demand growth are shown in the chart, below, with coal, oil and gas (shades of blue) having met most of the historical increases in energy use (leftmost columns).

While the STEPS maps a future where renewables meet half of the increase in demand to 2040, and the pace of growth slows due to shifting economic factors and energy efficiency (central columns), it remains well short of putting a cap on global CO2 emissions (see discussion below).

If increases in global temperatures are to be stopped, then even more decisive changes will be required, as shown in the example of the IEA SDS (rightmost columns).

Average annual change in global energy demand, by fuel, million tonnes of oil equivalent. Left: historical changes. Centre: IEA STEPS. Right: IEA SDS. Source: IEA . Chart by Carbon Brief using .

The rising portion of demand growth met by renewables sees the fossil fuel share of global energy use decline from 81% in 2018 to 74% in 2040 under the STEPS, or 58% under the SDS.

Moving from the STEPS to the SDS will require a wide range of changes, most of which have long been on the agenda for policymakers. As the report explains:

“The global value of fossil fuel consumption subsidies in 2018 was almost double the combined value of subsidies to renewable energy and electric vehicles and the revenue from carbon pricing schemes around the world. This imbalance greatly complicates the task of achieving an early peak in emissions.”

By the 2030s, investment in fossil fuels without carbon capture would halve in the SDS, relative to the average during 2014-2018. At the same time, investment in renewables, electricity networks and nuclear would roughly double and spending on energy efficiency would nearly quadruple.

This reflects the fact that energy efficiency is the single most important factor in tackling emissions, the IEA says, meaning that overall demand in 2040 under the SDS is slightly below today’s levels.

It says “the potential for efficiency improvements to help the world meet its sustainable energy goals is massive” and it has convened a to boost progress.

In part, this is a response to data showing that efficiency improvements are drying up and 2018 saw the , with this “faltering momentum” a cause for “deep concern”. It cites “a relative lack of new energy efficiency policies and of efforts to tighten existing measures”.

The World Energy Outlook is out today and shows once again the critical role of energy efficiency for achieving carbon goals.

— Jan Rosenow (@janrosenow)

Lower demand has knock-on consequences, particularly when combined with more rapid growth from renewables. Notably, demand for coal, oil and gas progressively declines under the SDS, with coal facing particularly large reductions (grey chunks in the rightmost columns, above).

Within this total, the IEA suggests that coal use in the power sector would be hardest hit. It says that more than half of current coal-fired power stations would retire by 2040 in the SDS, representing a fleet larger than .

With half of retirements coming before the end of their useful lives, some of the $1tn of capital invested in the world’s existing coal fleet would be put at risk, if warming is kept below 2C. Some 98% of the 222 gigawatts (GW) of coal in Europe and 88% of the 276GW in the US would close.

Under the SDS, the remaining coal plants would mostly need to be “repurposed or retrofitted”, the IEA says. This means they would either operate limited hours, during peaks in demand and troughs in renewable output, or would face substantial investments to fit (CCS) technology to prevent their CO2 emissions.

This year’s outlook contains new analysis on the methane released during coal mining, which it suggests has a greater warming impact than .

※ 全文及圖片詳見:()

作者

如果有一件事是重要的,如果能為孩子實現一個願望,那就是人類與大自然和諧共存。

於特有生物研究保育中心服務,小鳥和棲地是主要的研究對象。是龜毛的讀者,認為龜毛是探索世界的美德。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

南投搬家前需注意的眉眉角角,別等搬了再說!

新北清潔公司,居家、辦公、裝潢細清專業服務

曼谷空中動物園 環境惡劣成動物空中監獄

摘錄自2019年12月2日公視報導

泰國曼谷一間百貨商場,表面平凡無奇。低樓層賣男女服飾,但商場的頂樓,竟是一座空中動物園,裡面關了多達200隻動物,環境惡劣,是一座名符其實的「空中監獄」。裡頭有母猩猩,一關超過30年,處境孤單淒涼,被認為是全世界最悲傷的動物園之一。動保團體要求關閉動物園,還給動物們應有的生存尊嚴。

泰國曼谷的pata百貨購物中心,六樓跟七樓的頂樓,是已被判定違法的動物園。這隻被關在鐵籠子裡的母猩猩,泰國的譯名是白色小蓮花,小蓮花雖然有人餵食照顧,但生活環境惡劣,充滿惡臭。最可憐的是,牠被關在這座空中動物園已整整36年,過著完全失去自由的生活。為了解救小蓮花,動保團體本周再次出面呼籲,儘快關閉這座空中監獄。他們強調,殘忍的對待動物,決不等於提供人們娛樂的方式。善待動物組織成員奧莉維亞表示,「Pata動物園是我們在亞洲遇見過最糟糕的情況,很顯然,一座百貨公司根本不是該有動物存在的場所。」

母猩猩小蓮花,1983年起被關進這座大鐵籠,從此就沒再踏出外面的世界。她在籠子裡打滾,拔毛,流淚的畫面陸續在網路上流傳。動保人士研判,小蓮花已出現精神疾病,其他包括紅毛猩猩,跟狐猴等動物,也都出現焦躁的情緒反應,看了令人鼻酸。善待動物組織成員奧莉維亞說:「這隻猩猩從1983年起就關在這裡,還有一隻紅毛猩猩也被關這很久了,都已經出現精神疾病的症狀,意味著長期被關著心理已經受創。」

事實上,這間pata百貨公司頂樓的動物園,早已多次遭人檢舉。泰國2014年通過動保法,pata動物園2015年更被判定違反動保法,但當局依舊持續核發經營執照,法律形同虛設。至於動物園的經營者也有話要說,不僅強調當初開設動物園時都諮詢過專業意見,也把小蓮花當作自己的女兒照顧,更堅稱網路上流傳小蓮花看似悲傷的表情,其實那是猩猩原本的長相,被外界誤解。不過也坦承,目前要將裡面200多隻動物移往更大的飼養空間,在經費上確實有困難。pata動物園經營者坎尼特表示,「我們有打算將動物移走,因為我們的空間確實有限。我們也打算繼續飼養這些動物,我們有計畫將動物園移往自然的開放空間,但要這麼做的同時,我也必須承認動物園是社會企業,並非以營利投資為主,因此其他的因素(經費)是最主要的問題。」

但實際走訪過這座空中監獄的泰國動物專家強調,pata動物園的存在是泰國的恥辱,猩猩的基因有超過96%跟人類相似,也跟人類有一樣的情感,被關在籠子裡36年,對他們而言可以想像是無比的折磨與煎熬。不僅是小蓮花,其他動物被關在密不通風,底下又是空氣汙染的空間,失去自由,也磨滅了動物的天性。動保團體大聲疾呼泰國政府,拿出鐵腕手段與同理心,盡快關閉這座空中動物園,早日將動物們移往適合的環境,還給他們原本就該擁有的生存尊嚴。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

新北清潔公司,居家、辦公、裝潢細清專業服務

UN氣候變化綱要公約 締約方大會登場

摘錄自2019年12月2日公視、中央通訊社報導

聯合國氣候變化綱要公約,第25次締約方大會在西班牙舉行。而聯合國秘書長古提瑞斯也在大會前夕強調,說氣候變遷的危機已經「迫在眉睫」,呼籲各國要加強行動。同時也宣布,請來即將卸任的英國央行總裁卡尼,從明年開始出任氣候行動與氣候融資的新特使。

卡尼主張氣候風險管理必須轉型,投資淨零碳排放必須成為主流,未來將會盡全力,促使氣候變遷的影響成為財務報告、風險管理和報酬計算的重點。

這場大會原訂12月2號到13號在智利登場,但因為國內動亂,改在西班牙舉行,包括國家領袖、科學家、談判人員和環保運動人士等兩萬多人參與。這也是未來一年一連串國際密集協商的開端,要為明年11月格拉斯哥舉行的全球氣候峰會鋪路,屆時各國將依照巴黎氣候協定要求,提交對抗暖化的具體減碳方案,以便達成把全球溫度控制在比工業化升高1.5度到2度之內的目標。

目前幾乎全球各國都簽署了巴黎氣候協定,但排碳大戶美國,上個月4號已經展開了為期一年的退出程序。這次會議,美國只派層級不高的外交代表團,由負責環境科學事務的首席副助理國務卿伯尼卡特率隊。民主黨籍的眾議院議長裴洛西則率國會代表團參加,當中也沒有共和黨議員。

古提瑞斯今(2日)在氣候峰會的開幕全體會議上表示,面對威脅自身文明的氣候危機,人類必須在即時行動、追求希望,或是無動於衷、舉手投降之間作出抉擇。

世界氣象組織表示,過去5年是有紀錄以來最炎熱的5年,而且大氣裡導致地球暖化的二氧化碳(CO2)濃度已達300萬至500萬年來未見的程度。

古提瑞斯說:「現在北極圈永凍層比預測早70年融化。南極洲融化速度是10年前的三倍,海平面上升速度比預期更快。而且全球超過2/3的巨型都市都靠海。」根據近期研究,到2050年以前,全球會有超過1億5000萬人身處沿海洪患區。

去年聯合國一份重要報告則指出,若要防止氣溫升幅超過攝氏1.5度,全球經濟須在世紀中以前達成碳中和(carbon neutral)。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑