GaussDB(DWS)升級問題定位指南（三）

GaussDB(DWS)升級問題定位指南（三）

3.4??????升級集群

3.4.1?????升級集群（9%）報錯sssd服務(wù)啟動失敗

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

升級集群（9%）報錯sssd服務(wù)啟動失敗

查看報錯的詳細(xì)信息

查看update-manager的日志，提示ldapclient失敗

查看ldapclient的日志

手動拉起sssd服務(wù)失敗

觸發(fā)了os的dbus和systemd的bug導(dǎo)致臨時資源不可用。

重啟有問題節(jié)點的OS（確認(rèn)manager節(jié)點正常）。

3.4.2?????升級集群到35%報錯，啟動kerberosServer報錯

【GaussDB(DWS)】【C80SPC600->C80SPC800】

升級集群到35%報錯，啟動kerberosServer報錯

未執(zhí)行preset導(dǎo)致環(huán)境上sudo腳本無config_coredump_dir方法。

按升級指導(dǎo)書重新執(zhí)行preset步驟，然后界面重試。

3.4.3??????升級集群（42%）報錯 The cluster's static configuration does not match the new configuration file，cn個數(shù)前后臺不一致

【GaussDB(DWS)】【C80SPC312->8.0.0.1】

升級集群（42%）報錯 The cluster's static configuration does not match the new configuration file

后臺有3個cn 前臺只有2個 前后臺cn不一致

現(xiàn)場之前在前臺做增刪cn，失敗了未做處理，導(dǎo)致前后臺配置不一致。

手動修改主cms_server節(jié)點的mppdb-install-config.xml文件，增加cn配置信息，保持與后臺集群實際情況一致，然后界面重試。

3.4.4??????升級集群（42%）報錯 The cluster's static configuration does not match the new configuration file，配置完全錯亂

【GaussDB(DWS)】【C80SPC311->C80SPC800】

升級集群（42%）報錯 The cluster's static configuration does not match the new configuration file ：

通過發(fā)回來的靜態(tài)配置文件和xml文件對比，6個數(shù)據(jù)節(jié)點 從現(xiàn)場反饋的集群狀態(tài)看前三個節(jié)點成一個環(huán)，后3個節(jié)點成一個環(huán)，現(xiàn)在升級時下發(fā)的xml文件里面是6個節(jié)點整體成一個環(huán)了 配置完全對不上。

查看C80SPC600目錄的xml文件是與靜態(tài)配置文件一致，手動將該xml文件拷貝到800的xml文件目錄（集群所有節(jié)點），前臺重試正常。升級完成后在FI前臺做下同步配置。

升級時FIM下發(fā)的xml文件成環(huán)信息與集群實際情況不符，導(dǎo)致升級失敗。

手動將C80SPC600目錄的xml文件拷貝到800的xml文件目錄（集群所有節(jié)點），前臺重試正常。升級完成后在FI前臺做下同步配置。

3.4.5??????升級集群失敗(42%)：報SCP /opt/huawei/Bigdata/mppdb/gtm/gtm.control：Permission denied

【GaussDB(DWS)】【C80SPC300->8.0.0.1】

升級集群失敗(42%)：報SCP? /opt/huawei/Bigdata/mppdb/gtm/gtm.control_b: Permission denied

由于現(xiàn)場在備份 /opt/huawei/Bigdata/mppdb/gtm/gtm.control文件使用root用戶備份，導(dǎo)致 /opt/huawei/Bigdata/mppdb/gtm/目錄下含有非omm用戶的文件。

修改文件gtm.control_b 屬主為omm:wheel規(guī)避。

3.4.6??????升級集群（42%）報錯報讀alarm_Item.conf文件失敗

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

C80SPC300在升級8.0.0.1的過程中，在升級集群階段報Failed to read: /opt/huawei/Bigdata/mppdb/core/bin/alarmItem.conf文件失敗，如下:

檢查報錯節(jié)點的alarmItem.conf文件，發(fā)現(xiàn)文件里只有告警的信息，缺少alarm_component配置項，導(dǎo)致無法解析文件。

將cn數(shù)據(jù)目錄下的postgrs.conf文件中的alarm_component=/opt/huawei/Bigdata/mppdb/snas_cm_cmd加入到報錯節(jié)點的

/opt/huawei/Bigdata/mppdb/core/bin/alarmItem.conf文件末尾，保存后再update-sevice點擊重試。

3.4.7??????升級集群到87%報錯MPPDB升級服務(wù)數(shù)據(jù)報錯

【GaussDB(DWS)】【C80SPC600->C80SPC800】

升級集群到87%報錯MPPDB升級服務(wù)數(shù)據(jù)報錯：

查看日志/var/log/Bigdata/mpp/upgrade/upgrade.log，報錯：

stopMPPDB failed.

從日志上下文分析，此時數(shù)據(jù)庫內(nèi)核升級已完成，是在后續(xù)停止集群時報錯。

使用gs_ssh -c "ps ux |grep mppdb"? 查看未正常停止的進(jìn)程是一個cn實例

登錄該實例所在節(jié)點kill -9 pid將該cn殺掉，然后界面點擊重試。

3.4.8??????升級集群到89%報錯備份元數(shù)據(jù)2h超時

【GaussDB(DWS)】【C80SPC600->C80SPC800】

某局點升級集群到89%報錯備份元數(shù)據(jù)步驟超時失敗：Timed out, Killed by signal 9

C80以上版本采用就地升級方式，期間會備份各個實例的元數(shù)據(jù)，元數(shù)據(jù)量越大備份時間越長，且備份超時時間為2h，當(dāng)實例元數(shù)據(jù)特別大，備份時間超過2h，就會導(dǎo)致超時報錯回滾。

登錄主cm_server節(jié)點，手動調(diào)長2h超時時間為4h后重試

${BIGDATA_HOME}/FusionInsight_MPPDB_V100R002C80SPC800/install/FusionInsight-MPPDB-2.8.0/package/MPPDB/script/util/Common.py

TIMEOUT_PSSH_INPLACE_UPGRADE = 7200??改為? TIMEOUT_PSSH_INPLACE_UPGRADE = 14400

3.4.9??????升級集群（89%）報錯update catalog failed

【GaussDB(DWS)】【C80SPC311->C80SPC800】

升級集群89%步驟報錯update catalog failed：

分析報錯09節(jié)點的gs_local日志，報錯為連接丟失

查看第一個cn的pg_log日志，發(fā)現(xiàn)當(dāng)時有客戶業(yè)務(wù)還在跑。

現(xiàn)場沒有按照升級指導(dǎo)書執(zhí)行禁用白名單隔離業(yè)務(wù)步驟，升級過程中仍然有業(yè)務(wù)接入，導(dǎo)致升級執(zhí)行sql超時失敗。

待報錯回滾后，按照升級指導(dǎo)書禁用白名單隔離業(yè)務(wù)，然后重新執(zhí)行升級。

3.4.10????升級集群失敗，mppdb升級服務(wù)數(shù)據(jù)報錯

【GaussDB(DWS)】【C80SPC600->C80SPC800】

升級集群在啟動新集群階段超時，過程中查看集群狀態(tài)主備dn均已啟動，從備dn未啟動：

排查system-call日志有報錯max_wal_senders must be less than max_connections

排查從備實例postgresql.conf配置文件，max_wal_senders和max_connections參數(shù)值均為100

查看日志

max_wal_senders值配置不合理導(dǎo)致從備dn啟動失敗。

將max_wal_senders 值改為默認(rèn)值 4然后重試。

3.4.11????升級集群過程中報錯The value 256 is outside the valid range for parameter "max_coordinators"

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

在C80SPC300升級8.0.0.1的過程中，在升級集群階段報錯，報錯為The value 256 is outside the valid range for parameter "max_coordinators"，如下：

max_coordinators設(shè)置過大導(dǎo)致。

將max_coordinators修改為默認(rèn)值10，在upds頁面重試。

3.4.12????升級集群在啟動新集群階段所有備dn都是pending狀態(tài)，啟動超時

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

在C80SPC300在升級8.0.0.1,在升級集群階段所有備dn都是pending狀態(tài)，導(dǎo)致集群無法正常啟動，升級失敗

查看備dn的日志，有端口被使用的報錯：Cannot assign requested address.Maybe port 25518 is used，run 'netstat -anop |grep 25518' or 'lsof -i:25518'，具體如下：

查詢端口，未被占用

查詢備dn的postgresql.conf文件，確認(rèn)listen_addresses和local_bind_address不一致，如下：

檢查報錯節(jié)點的alarmItem.conf文件，發(fā)現(xiàn)文件里只有告警的信息，缺少alarm_component配置項，導(dǎo)致無法解析文件。

將所有備dn的local_bind_address修改的和listen_addresses一致，然后在頁面點擊重試。

3.4.13????升級集群在啟動新集群階段cn啟動失敗

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

升級集群在啟動新集群階段cn啟動失敗

lvs的浮動ip沒有和cn綁定導(dǎo)致，初步判斷是lvs的啟動沒有寫入操作系統(tǒng)啟動項導(dǎo)致集群CN啟動失敗。

1.以root用戶身份登錄服務(wù)器，執(zhí)行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令啟動環(huán)境變量；

2.執(zhí)行g(shù)s_loadbalance更新負(fù)載均衡配置

gs_loadbalance -t reload -U omm -X? ${BIGDATA_HOME}/FusionInsight_MPPDB_8.0.0/*_*_MPPDBServer/etc/mppdb-install-config.xml?? --lvs-addr=xxx

3.4.14????升級集群在啟動新集群階段cm_server啟動失敗

【GaussA 8.0.0.1】【C80SPC305->8.0.0.1】

升級集群在啟動新集群階段cm_server啟動失敗

查看主cms節(jié)點：/var/log/Bigdata/mpp/omm/om/gs_upgradectl*.log日志，有集群啟動失敗的報錯

查看集群狀態(tài)，有個備cms節(jié)點沒拉起來，如下：

查看該節(jié)點的cm_agent日志，有如下報錯：

該節(jié)點的cm_server.pid文件為root用戶，刪除后在界面重試正常。

cm_server.pid為root用戶導(dǎo)致備cm_server沒拉起來，集群啟動失敗。

手動刪除cm_server.pid后正常拉起，前臺重試正常。

3.4.15????升級集群在啟動新集群階段cn、dn處于down unknown狀態(tài)啟動失敗

【Gauss A C80SPC800】【C80SPC208->C80SPC800】

升級集群在啟動新集群階段cn、dn處于down unknown狀態(tài)啟動失敗。查看失敗節(jié)點的system-call日志，有報錯FATAL: invalid value for parameter "max_stack_depth":2048

操作系統(tǒng)stack size值設(shè)置2048，小于最低要求3072導(dǎo)致cn、dn啟動報錯。

修改操作系統(tǒng)的stack size值，并kill 節(jié)點上om_monitor、nodeagent進(jìn)程使得進(jìn)程中的值也生效，然后界面重試。

1、修改操作系統(tǒng)的stack size值

修改/etc/security/limits.conf中stack的soft值為8192 如下所示

*?????? soft??? stack?? 8192

*?????? hard??? stack?? 8192

2、kill om_monitor、nodeagent進(jìn)程

ps -ef |grep om_monitor |grep -v grep

ps -ef |grep nodeagent |grep -v grep

kill -9?pid? --pid替換為上面查到的om_monitor、nodeagent進(jìn)程pid

3、確認(rèn)om_monitor、nodeagent進(jìn)程已被正常拉起且stack size值刷新為修改后的值

ps -ef |grep om_monitor |grep -v grep

ps -ef |grep nodeagent |grep -v grep

cat /proc/pid/limits???--pid替換為上面查到的om_monitor、nodeagent進(jìn)程pid

3.4.16????C80SPC310升級8.0.0.1在升級集群階段，報Can not found sequence value in GTM

【GaussA 8.0.0.1】【C80SPC310->8.0.0.1】

集群c80spc310升級8.0.0.1在升級集群階段，報Can not found sequence value in GTM，如下：

由于8.0以前版本的seq在gtm上存儲的信息比較多，alter操作等將會導(dǎo)致gtm上的sequence信息殘留以及有可能出現(xiàn)gtm上sequence丟失。

當(dāng)gtm中的sequence信息與cn中sequence信息不一致時，就會在啟動集群階段報錯，具體分為如下兩種情況：

1）GTM中的sequence比CN上的少導(dǎo)致在升級過程中對老的sequence生成sequence時在gtm.control文件和gtm.sequence文件中查找不到報錯；

2）GTM中有sequence，而CN上沒有sequence導(dǎo)致gtm.sequence文件沒有更新，使用新二進(jìn)制讀取老格式的數(shù)據(jù)報錯。

所有GTM上的sequence需要從數(shù)據(jù)庫的CN去恢復(fù)，查找所有使用該sequence的表，取最大值+20000當(dāng)做該sequence修復(fù)后的當(dāng)前值。

1）在所有數(shù)據(jù)庫上創(chuàng)建以下函數(shù)

create or replace procedure find_seq(dbname text)

as

seq_name??? varchar(1000);

tablename?? varchar(1000);

columnname? varchar(1000);

schemanname varchar(1000);

schmaname?? varchar(1000);

rel_oid???? Oid;

adnum?????? int;

cur_max_seq int;

max_seq???? int;

start_value bigint;

increment_by bigint;

max_value bigint;

min_value bigint;

cache_value bigint;

is_cycled? bool;

is_cycled_str char(1);

is_called? bool;

is_called_str char(1);

type ref_cur_type is ref cursor;

my_cur ref_cur_type;

my_cur_seq_name ref_cur_type;

my_cur_rel_att_name ref_cur_type;

my_cur_max_seq_num ref_cur_type;

my_seq_info ref_cur_type;

sqlstr varchar(1000);

sqlstr2 varchar(2560);

sqlstr3 varchar(2560);

sqlstr4 varchar(2560);

begin

open my_cur for 'select c.relname, n.nspname from pg_class c, pg_namespace n where c.relnamespace = n.oid AND c.relkind = ''S''';

fetch my_cur into seq_name, schmaname;

while my_cur%found loop

-- dbms_output.put_line(seq_name);

max_seq = 0;

sqlstr='select adrelid, adnum from pg_attrdef where adsrc like ''%' || seq_name || '%''';

open my_cur_seq_name for sqlstr;

fetch my_cur_seq_name into rel_oid, adnum;

while my_cur_seq_name%found loop

-- dbms_output.put_line('-> ('||rel_oid || ' , ' || adnum || ')');

cur_max_seq = 0;

sqlstr2? = 'select c.relname as tablename, a.attname, n.nspname as columname from pg_class c, pg_attribute a, pg_namespace n where c.relnamespace = n.oid and c.oid = a.attrelid and a.attrelid = ' || rel_oid || ' and a.attnum = ' || adnum || ';';

open my_cur_rel_att_name for sqlstr2;

fetch my_cur_rel_att_name into tablename, columnname, schemanname;

while my_cur_rel_att_name%found loop

--???? dbms_output.put_line('-> ('|| tablename || ' , ' || columnname || ')');

sqlstr3 = 'select max(' || columnname || ') from ' || schemanname || '.' ||tablename || ';';

open my_cur_max_seq_num for sqlstr3;

fetch my_cur_max_seq_num into cur_max_seq;

if (cur_max_seq > max_seq) then

max_seq = cur_max_seq;

end if;

close my_cur_max_seq_num;

fetch my_cur_rel_att_name into tablename, columnname;

end loop;

close my_cur_rel_att_name;

fetch my_cur_seq_name into rel_oid, adnum;

end loop;

close my_cur_seq_name;

-- dbms_output.put_line(seq_name || ' max value : ' || max_seq);

sqlstr4 = 'select start_value, increment_by, max_value, min_value, cache_value, is_cycled, is_called from ' || schmaname || '.' || seq_name;

open my_seq_info for sqlstr4;

fetch my_seq_info into start_value, increment_by, max_value, min_value, cache_value, is_cycled, is_called;

while my_seq_info%found loop

if (is_cycled) then

is_cycled_str = 't';

else

is_cycled_str = 'f';

end if;

is_called_str = 't';

max_seq = max_seq + 20000;

dbms_output.put_line(dbname || '.'|| schmaname || '.' ||seq_name || '

dbms_output.put_line(dbname || '.'|| schmaname || '.' ||seq_name || '\00' || E'\t' || max_seq || E'\t' || start_value || E'\t' || increment_by || E'\t' || min_value || E'\t'|| max_value || E'\t' || is_cycled_str || E'\t' || is_called_str || E'\t' || '1');

' || E'\t' || max_seq || E'\t' || start_value || E'\t' || increment_by || E'\t' || min_value || E'\t'|| max_value || E'\t' || is_cycled_str || E'\t' || is_called_str || E'\t' || '1');

fetch my_seq_info into start_value, increment_by, max_value, min_value, cache_value, is_cycled, is_called;

end loop;

close my_seq_info;

fetch my_cur into seq_name, schmaname;

end loop;

close my_cur;

end;

/

2）獲取所有數(shù)據(jù)庫列表

source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile

gsql -p 25308 postgres -r -t -c "select datname from pg_database where datname not in ('template1', 'template0', 'template2', 'information_schema');" > datname.txt

3）生成新的sequence信息

cat datname.txt | while read LINE

do

if [ -z "$LINE" ]; then

echo "skip"

else

gsql -p 25308 $LINE -r -c "call find_seq('$LINE');" 2>gtm_contrl.txt.$LINE

fi

done

4）停止主備gtm（主備兩個節(jié)點）

cm_ctl stop -n?nodeid?-D gtmpath

5）重建gtm.control文件

1.?備份gtm.control文件

2.?保存gtm.control文件的前3行信息

head -n 3 gtm.control > gtm.control.tmp

3. sequence?同步到gtm.control.tm

cat datname.txt | while read LINE

do

if [ -z "$LINE" ]; then

echo "skip"

else

cat gtm_contrl.txt.$LINE >> gtm.control.tmp

fi

done

6）發(fā)送gtm.control.tmp到gtm的主備目錄

scp gtm.control.tmp ...

7）啟動gtm節(jié)點（主備兩個節(jié)點）

cm_ctl start -n?nodeid?-D datapath

3.4.17????升級集群在確認(rèn)階段報錯靜態(tài)配置文件不匹配

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

在升級確認(rèn)時報錯，如下：

查看主cms節(jié)點：/var/log/Bigdata/mpp/omm/om/gs_upgradectl*.log，有報靜態(tài)配置文件不一致的報錯：

查看對應(yīng)報錯節(jié)點的/opt/huawei/Bigdata/FusionInsight_MPPDB_*/*_MPPDBServer/etc/mppdb-install-config.xml對應(yīng)的cooNum為3個，但是通過cm_ctl query -Cv查出來的cn個數(shù)為2個

此集群之前應(yīng)該有做過刪除cn的操作，前后臺配置不一致，手動修改該xml文件，將對應(yīng)的節(jié)點cooNum從1改為0，然后在界面重提通過。

確認(rèn)成功后，在FI界面找到對應(yīng)的節(jié)點的實例，將cn配置從1改為0，保存后正常，前后臺配置一致。

手動修改該xml文件，將對應(yīng)的節(jié)點cooNum從1改為0，然后在界面重提通過。

確認(rèn)成功后，在FI界面找到對應(yīng)的節(jié)點的實例，將cn配置從1改為0，保存后正常，前后臺配置一致。

3.4.18????DWS升級8.0過程中更新系統(tǒng)表失敗

【DWS】【8.0.0】

dws集群升級8.0過程中更新系統(tǒng)表失敗，日志中報錯用戶名或密碼無效：

帶sequence的集群升級系統(tǒng)表過程中會涉及切換database，dws切換database需要交互式輸入密碼，導(dǎo)致升級系統(tǒng)表失敗。

設(shè)置cn dn免密登錄后重試

gs_guc set -Z coordinator -Z datanode -N all -I all -c 'local?? all???? ????all??? trust'

3.5??????升級后驗證

3.5.1??????升級C80SPC800后sql on hadoop配置文件被manager刷新重置

【GaussDB(DWS)】【C80SPC600->C80SPC800】

某局點升級C80SPC800后sql on hadoop配置文件被manager刷新重置。從hd側(cè)抽數(shù)會報錯：

ERROR:Login failed on cn_5001, check your principal and keytab.

局點現(xiàn)場hd集群做過遷移，遷移后未在FIM界面上對配置進(jìn)行更新，導(dǎo)致升級SPC800時下發(fā)的還是遷移前的ip。

重新對按照hd遷移后sql on hadoop方案進(jìn)行配置，將后臺刷新成最新的hd側(cè)配置文件后恢復(fù)。

3.5.2??????升級到C80SPC800后Raid卡緩存策略被重置

【GaussDB(DWS)】【C80SPC600->C80SPC800】

升級過程中修改了raid卡緩存策略，由write back更改為write through，導(dǎo)致升級后業(yè)務(wù)運(yùn)行性能下降嚴(yán)重。

C80版本不支持做Preinstall時設(shè)置緩存策略，Preinstall成功后diskmgtd進(jìn)程每次啟動的時候會設(shè)置一把磁盤緩存策略，默認(rèn)是透寫（高可靠性）。

如果希望修改成回寫，需要創(chuàng)建一個標(biāo)志文件/usr/local/diskmgt/ini/wce，文件中內(nèi)容為“1”，然后重啟diskmgt進(jìn)程。

升級時候會做Preinstall的升級，Preinstall升級后會重啟每個節(jié)點的diskmgt進(jìn)程（每個節(jié)點一個），diskmgt進(jìn)程每次啟動的時候會設(shè)置一把磁盤緩存策略。

1)????FusionInsight去掉當(dāng)前在擴(kuò)容和安裝等場景對OS緩存設(shè)置的方法：（這是針對以后的擴(kuò)容或新建場景）

在產(chǎn)品安裝包的preinstall目錄下 preinstall/script/modules/070.autopart/autopart/inner/diskmgtd 文件中注釋掉如下的代碼；

${CMD_SUDO_SDPARM} --clear=WCE ${sddisk}

2)????針對集群中已經(jīng)關(guān)閉OS緩存的配置，需要進(jìn)行打開os緩存并開啟raid卡回寫模式的操作方法如下：（這是針對當(dāng)前的整改場景）

新建腳本os_cache_raid.sh,內(nèi)容如下：

#!/bin/bash

echo "1" >> /usr/local/diskmgt/ini/wce???? #標(biāo)志位設(shè)為1

/usr/local/diskmgt/script/diskmgt.sh -r? ?#重啟diskmgt進(jìn)程，使上面的標(biāo)志生效并打開os緩存

cd /opt/MegaRAID/storcli???????????? ?#切換路徑到對應(yīng)工具所在路徑下，默認(rèn)在/opt/MegaRAID/storcli路徑下，使用storcli在線操作，要求設(shè)備安裝storcli工具

./storcli64 /c0/vall set wrcache=wb???????????? #設(shè)置所有raid組讀寫策略為wb（回寫）

./storcli64 /c0/vall set iopolicy=direct??????????????? #設(shè)置所有raid組IO策略為direct

然后在集群內(nèi)用root用戶通過批量執(zhí)行的腳本工具clustercmd.sh（這個工具的使用說明和前提條件在FusionInsight產(chǎn)品文檔中有詳細(xì)說明），按照需要配置好配置文件中的節(jié)點列表后，具體操作樣例如下：

./clustercmd.sh? "os_cache_raid.sh"

3)????另外一點，需要注意的是，如果采用改腳本這種方式，由于當(dāng)前所有版本默認(rèn)都是關(guān)閉OS緩存，后續(xù)升級時，也需要把以后待升級的目標(biāo)版本的preinstall腳本中的代碼注釋掉，否則升級后OS緩存就又被關(guān)閉了，然后raid卡的策略又會被調(diào)整回透寫模式。

EI企業(yè)智能 Gauss AP 數(shù)據(jù)倉庫服務(wù) GaussDB(DWS)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。