<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                ## 問題描述 收到一枚RDS TokuDB實例crash導致HA切換的報警,上去一看錯誤如下: ~~~ tokudb/ft-index/ft/cachetable/cachetable.cc toku_cachetable_openfd_with_filenum: Assertion `filenum.fileid != FILENUM_NONE.fileid' failed /bin/mysqld(_Z19db_env_do_backtraceP8_IO_FILE+0x1b)[0xc57ddb] /bin/mysqld(_Z35toku_cachetable_openfd_with_filenumPP9cachefileP10cachetableiPKc7FILENUMPb+0x223)[0xbb49b3] /bin/mysqld(_Z19toku_ft_handle_openP9ft_handlePKciiP10cachetableP7tokutxn+0x135)[0xbf3c05] /bin/mysqld(_Z20toku_ft_handle_clonePP9ft_handleS0_P7tokutxn+0xb5)[0xbf42f5] /bin/mysqld(_Z29toku_db_lt_on_create_callbackPN4toku8locktreeEPv+0x2a)[0xb801ba] /bin/mysqld(_Z18toku_db_open_inameP9__toku_dbP13__toku_db_txnPKcji+0x276)[0xb805b6] /bin/mysqld(_ZN9ha_tokudb20open_main_dictionaryEPKcbP13__toku_db_txn+0x1ab)[0xb50a0b] /bin/mysqld(_ZN9ha_tokudb16initialize_shareEPKci+0x2c8)[0xb70848] /bin/mysqld(_ZN9ha_tokudb4openEPKcij+0x5e9)[0xb71349] /bin/mysqld(_ZN7handler7ha_openEP5TABLEPKcii+0x33)[0x5e74b3] ~~~ 這個錯誤信息在RDS上第一次碰到,隱隱感到這是一個“可遇不可求”的bug導致,開始捉蟲。 ## 問題分析 每個表(索引)文件被打開后,TokuDB都會為這個文件賦予一個唯一id,即filenum。 filenum有什么作用? TokuDB在寫redo log的時候,每個事務里會帶一個filenum屬性,用來標示該事務屬于哪個表文件,在崩潰恢復的時候,會根據這個filenum回放到相應的表里。 filenum在什么時候被分配? 表(索引)文件被打開的時候會被分配。 filenum如何分配? 為了保證唯一性,TokuDB維護了一個filenum數據結構(類似binary tree) : m_active_filenum,分配算法: ~~~ uint32_t m_next_filenum_to_use; //全局變量,用來標識已分配的最大filenum lock(); retry: int ret = m_active_filenum.find(m_next_filenum_to_use); if (ret == 0) { //m_next_filenum_to_use被占用 m_next_filenum_to_use++; goto retry; } filenum = m_next_filenum_to_use; //得到我們想要的filenum m_next_filenum_to_use++; unlock(); ~~~ 這樣問題就來了,如果用戶有非常多的表(索引)文件,不停的被打開和關閉,m_next_filenum_to_use會一直遞增下去,由于是uint32_t類型,小宇宙終于爆發了,filenum 遞增到4294967295(UINT_MAX),從而導致assert失敗。 ## 問題修復 當一些表(索引)文件被close后,這些filenum可以被回收再利用,所以當filenum遞增到UINT_MAX后,重置到0即可: ~~~ uint32_t m_next_filenum_to_use; //全局變量,用來標識已分配的最大filenum lock(); retry: int ret = m_active_filenum.find(m_next_filenum_to_use); if (ret == 0) { //m_next_filenum_to_use被占用 m_next_filenum_to_use++; goto retry; } // 從0開始重新獲取未被使用的filenum if (m_next_filenum_to_use == UINT_MAX) { m_next_filenum_to_use = 0; goto retry; } filenum = m_next_filenum_to_use; //得到我們想要的filenum m_next_filenum_to_use++; unlock(); ~~~ RDS版本已修復此問題,官方patch戳[這里](https://github.com/percona/PerconaFT/commit/1b289f788c6b50956321f4d977ac1cb63bd72013)。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看