Return-Path: X-Original-To: apmail-hadoop-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C3B43D08E for ; Thu, 23 Aug 2012 15:40:50 +0000 (UTC) Received: (qmail 64347 invoked by uid 500); 23 Aug 2012 15:40:46 -0000 Delivered-To: apmail-hadoop-user-archive@hadoop.apache.org Received: (qmail 64184 invoked by uid 500); 23 Aug 2012 15:40:45 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 64176 invoked by uid 99); 23 Aug 2012 15:40:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Aug 2012 15:40:45 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of albertoandreotti@gmail.com designates 74.125.82.48 as permitted sender) Received: from [74.125.82.48] (HELO mail-wg0-f48.google.com) (74.125.82.48) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Aug 2012 15:40:39 +0000 Received: by wgbdq11 with SMTP id dq11so597985wgb.29 for ; Thu, 23 Aug 2012 08:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6V6EoyUudKa6m9kduohK51dpPVPf/3T7hHvpLusa7aY=; b=K/T++laE8HlnldPXxG3gTLtm8n4EIcjv9Z7H1hReoL2D+OX6LQGjuamFi1Vz8FNpHI v06X+Kg9EPUZRkAmuhyYSKgQ4+z7twxVUsiATjJmmaGq8w+VwxHEFSjptrh77fYKk6v2 zc6qDlkIcNKGGu7sGY3Vu9sc3KBXyaJzyobeNifzalYinvFe6jNN1mJwCd7ZryqWLMAZ mkXTltk0GJDQr8raty1Pyb5DaFKlIP8YGeRPTynLFXyIXLkCQEN+Q9xshBibb0tL12AG HY+kY0ZI8Hwa1JskywSDDPGULTeEu/u8n1SzpDXiHY7lUMfWhtxXXx8XV08k2DGk6I4l yEGA== MIME-Version: 1.0 Received: by 10.180.95.193 with SMTP id dm1mr15919796wib.10.1345736418117; Thu, 23 Aug 2012 08:40:18 -0700 (PDT) Received: by 10.194.43.6 with HTTP; Thu, 23 Aug 2012 08:40:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Aug 2012 12:40:18 -0300 Message-ID: Subject: Re: Reg: when failures on writing to DB from map\reduce From: Alberto Andreotti To: user@hadoop.apache.org Content-Type: multipart/alternative; boundary=f46d041825da29c79504c7f0addb X-Virus-Checked: Checked by ClamAV on apache.org --f46d041825da29c79504c7f0addb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable unsubscribe On 23 August 2012 12:36, Manoj Babu wrote: > > Hi All, > > In Sqoop: > When exporting from HDFS to DB, If an export map task fails due to these > or other reasons, it will cause the export job to fail. The results of a > failed export are undefined. Each export map task operates in a separate > transaction. Furthermore, individual map tasks commit their current > transaction periodically. If a task fails, the current transaction will b= e > rolled back. Any previously-committed transactions will remain durable in > the database, leading to a partially-complete export. > > When using DBOutputFormat in custom map\reduce program: > When emitting from multiple mappers or reducers and if any one of the > mapper or reducer got failure only the failed transaction will be rolled > back Any previously-committed transactions will remain durable in the > database, leading to a partially-complete export. > > Is there any way to commit at last to avoid partially-complete? > > Cheers! > Manoj. > > > --=20 Jos=E9 Pablo Alberto Andreotti. Tel: 54 351 4730292 M=F3vil: 54351156526363. MSN: albertoandreotti@gmail.com Skype: andreottialberto --f46d041825da29c79504c7f0addb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable unsubscribe

On 23 August 2012 12:36, Mano= j Babu <manoj444@gmail.com> wrote:

Hi All,

In Sqo= op:
When exporting from HDFS to DB,=A0If an export map task fails= due to these or other reasons, it will cause the export job to fail. The r= esults of a failed export are undefined. Each export map task operates in a= separate transaction. Furthermore, individual map tasks commit their curre= nt transaction periodically. If a task fails, the current transaction will = be rolled back. Any previously-committed transactions will remain durable i= n the database, leading to a partially-complete export.

When using DBOutputFormat in custom map\reduce program:=
When=A0emitting from multiple mappers or reducers and if any one= of the mapper or reducer got failure=A0only=A0the failed transaction will = be rolled back=A0Any previously-committed transactions will remain durable = in the database, leading to a partially-complete export.

Is there any way to commit=A0at last=A0to avoid=A0parti= ally-complete?

Cheers!=
Manoj.





--
Jos=E9 Pablo Alberto An= dreotti.
Tel: 54 351 4730292
M=F3vil: 54351156526363.
MSN: albertoandreotti@= gmail.com
Skype: andreottialberto
--f46d041825da29c79504c7f0addb--